Subject: [Rats] Serialization formats for attestation results

From: Laurence Lundblade <[email-masked]>
Date: Tue, 3 Mar 2020 11:44:01 -0800

The current architecture document has a serialization formats diagrams that I’ve pasted in below.

Such a plethora of serialization formats, many of which are cannot be converted between, seems counter to IETF interoperability. Don’t we want to minimize formats?

Top of my list would be strong preference for JWT for attestation results returned by web-based attestation services. 

Next would be preference for CWT for evidence, with JWT as second.

I can see maybe creating a mapping document that says how to encode the CDDL in EAT to ASN.1 for X.509, but I don’t see that as a mainline activity.

Wouldn’t it be appropriate to call out the TPM format as fixed and owned by the TCG?

In the case of local verifiers, the format becomes a very local issue and less an IETF interoperability concern.

Basically, it seems RATS should adopt a goal and strategy to maximize interoperability here.

LL

                       Evidence           Attestation Results

       .--------------.   CWT                    CWT   .-------------------.
       |  Attester-A  |------------.      .----------->|  Relying Party V  |
       '--------------'            v      |            `-------------------'
       .--------------.   JWT   .------------.   JWT   .-------------------.
       |  Attester-B  |-------->|  Verifier  |-------->|  Relying Party W  |
       '--------------'         |            |         `-------------------'
       .--------------.  X.509  |            |  X.509  .-------------------.
       |  Attester-C  |-------->|            |-------->|  Relying Party X  |
       '--------------'         |            |         `-------------------'
       .--------------.   TPM   |            |   TPM   .-------------------.
       |  Attester-D  |-------->|            |-------->|  Relying Party Y  |
       '--------------'         '------------'         `-------------------'
       .--------------.  other     ^      |     other  .-------------------.
       |  Attester-E  |------------'      '----------->|  Relying Party Z  |
       '--------------'                                `-------------------'

      Figure 7: Multiple Attesters and Relying Parties with Different

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 3 Mar 2020 20:19:06 +0000

The objective in creating the “bow tie” diagram isn’t to advocate non-interoperability. It is to acknowledge that interoperability may require significant effort given there are many ways to format/encode what is essentially the same or similar information.

The “…” in the bow tie diagram is significant as there are many more encodings currently in use today.

The architecture doesn’t / can’t enforce the goal of universal interoperability in part because it is a non-normative document. Even if it were normative and it had language that required a particular encoding. There is no practical way the IETF could enforce compliance. An architecture that hopes for interoperability by ignoring the other formats and encoding already in use doesn’t seem very realistic to me. It is better to acknowledge it, offer reasonable ways forward that are technically sound, and make meaningful observations about how the goals of interoperability, security, reliability, etc… can be better realized if there were fewer options.

It will be up to the industry to figure out how to justify the cost (economics).

The industry has made infrastructure investments in PKI over many years. Realistically, that investment will continue to be amortized for a long time (unless something disruptive causes it to change). Similarly, the industry has made infrastructure investments in TPMs and other HSM, TEE and SE technologies. There are replacement cycles that potentially replaces them with something that is ‘more interoperable’ than current formats but replacement cycles are not binary. There will be proprietary formats in use for a long time into the future. That means Verifier(s) need to consider the implications of the ‘bow tie’ figure for a long time into the future too.

-Ned

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Tuesday, March 3, 2020 at 11:44 AM
To: "[email-masked]" <[email-masked]>
Subject: [Rats] Serialization formats for attestation results

LL

       .--------------.   CWT                    CWT   ..-------------------.

       .--------------.   JWT   .------------.   JWT   ..-------------------.

       .--------------.  X.509  |            |  X.509  ..-------------------.

       .--------------.   TPM   |            |   TPM   ..-------------------.

       .--------------.  other     ^      |     other  ..-------------------.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Mar 2020 15:51:52 -0500

Laurence,

Thank you for raising the discussion point.  I agree that this is
concerning, but I am more concerned with the development of additional
serialization formats that are being developed.  If there was a way to stop
or slow it down, organizations hoping to benefit from the possible
automation for assessment capabilities that come with attestation would be
fantastic.  I fear that it is becoming too complex to reach that goal.
Having said that, Ned is right with the existing set.

TPM has been around for a while and is here to stay.  PKI has as well and
the use cases that can be enabled with attribute certificates are
important.  In this list, that leave us with JWT and CWT, which have
already been argued for with agreement.  The other is where things become
concerning for me.  How many more are necessary?  Can we as an industry try
to to hang our hooks on a format and allow that to be the part we
interoperate on to help customers and to keep their management
environments as simple as we can, enabling interoperability between
products and up a stack when one component relies upon another?  This type
of agreement has to be across industry though as some formats may be out of
our purview.

Best regards,
Kathleen

On Tue, Mar 3, 2020 at 3:19 PM Smith, Ned <[email-masked]> wrote:

> The objective in creating the “bow tie” diagram isn’t to advocate
> non-interoperability. It is to acknowledge that interoperability may
> require significant effort given there are many ways to format/encode what
> is essentially the same or similar information.
>
>
>
> The architecture doesn’t / can’t enforce the goal of universal
> interoperability in part because it is a non-normative document. Even if it
> were normative and it had language that required a particular encoding.
> There is no practical way the IETF could enforce compliance. An
> architecture that hopes for interoperability by ignoring the other formats
> and encoding already in use doesn’t seem very realistic to me. It is better
> to acknowledge it, offer reasonable ways forward that are technically
> sound, and make meaningful observations about how the goals of
> interoperability, security, reliability, etc… can be better realized if
> there were fewer options.
>
>
>
> The industry has made infrastructure investments in PKI over many years.
> Realistically, that investment will continue to be amortized for a long
> time (unless something disruptive causes it to change). Similarly, the
> industry has made infrastructure investments in TPMs and other HSM, TEE and
> SE technologies. There are replacement cycles that potentially replaces
> them with something that is ‘more interoperable’ than current formats but
> replacement cycles are not binary. There will be proprietary formats in use
> for a long time into the future. That means Verifier(s) need to consider
> the implications of the ‘bow tie’ figure for a long time into the future
> too.
>
>
>
> -Ned
>
>
>
> *From: *RATS <[email-masked]> on behalf of Laurence Lundblade <
> [email-masked]>
> *Date: *Tuesday, March 3, 2020 at 11:44 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Rats] Serialization formats for attestation results
>
>
>
> Such a plethora of serialization formats, many of which are cannot be
> converted between, seems counter to IETF interoperability. Don’t we want to
> minimize formats?
>
>
>
> Top of my list would be strong preference for JWT for attestation results
> returned by web-based attestation services.
>
>
>
> I can see maybe creating a mapping document that says how to encode the
> CDDL in EAT to ASN.1 for X.509, but I don’t see that as a mainline activity.
>
>
>
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

-- 

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 4 Mar 2020 08:18:10 -0800

I’d like to see words like this somewhere in a RATS document, maybe in the architecture document:

For the sake of Interoperability, the JWT format is strongly preferred for attestation results. If the Verifier is passing on any claims from Attestation Evidence, then it should convert them to JWT format.

Similarly, for the sake of Interoperability, the CWT and JWTs formats are preferred for Attestation Evidence, though it is understood that in many use cases other extant serialization formats will have to be used.

LL

> On Mar 3, 2020, at 12:51 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Laurence,
> 
> Thank you for raising the discussion point.  I agree that this is concerning, but I am more concerned with the development of additional serialization formats that are being developed.  If there was a way to stop or slow it down, organizations hoping to benefit from the possible automation for assessment capabilities that come with attestation would be fantastic.  I fear that it is becoming too complex to reach that goal.  Having said that, Ned is right with the existing set.
> 
> TPM has been around for a while and is here to stay.  PKI has as well and the use cases that can be enabled with attribute certificates are important.  In this list, that leave us with JWT and CWT, which have already been argued for with agreement.  The other is where things become concerning for me.  How many more are necessary?  Can we as an industry try to to hang our hooks on a format and allow that to be the part we interoperate on to help customers and to keep their management environments as simple as we can, enabling interoperability between products and up a stack when one component relies upon another?  This type of agreement has to be across industry though as some formats may be out of our purview.
> 
> Best regards,
> Kathleen
> 
> On Tue, Mar 3, 2020 at 3:19 PM Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
> From: RATS <[email-masked] <mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 4 Mar 2020 18:32:21 +0000

On 04/03/2020, 16:18, "Laurence Lundblade" <[email-masked]> wrote:
> For the sake of Interoperability, the JWT format is strongly preferred
> for attestation results. If the Verifier is passing on any claims from
> Attestation Evidence, then it should convert them to JWT format.
>
> Similarly, for the sake of Interoperability, the CWT and JWTs formats
> are preferred for Attestation Evidence, though it is understood that
> in many use cases other extant serialization formats will have to be
> used.

I think I agree with Laurence here.  We can probably do better than just
acknowledging the status quo.  We seem to be in a position where we can
at least try and steer the ecosystem to a place where the number of
formats the parties have to understand is minimised, while at the same
time the translation between formats can be easily automated.

cheers!
--

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 4 Mar 2020 22:53:13 +0000

Nms> A guiding principle is that market forces often decide which formats become winners. The architecture hopes market forces will value interoperability (Metcalf's law https://en.wikipedia.org/wiki/Metcalfe's_law) but in the meantime, the architecture assumes Verifier and Relying Party will have to deal with the complexity of multiple formats. The other constraint is the architecture expects messages produced by RATS roles can (must?) be digest-able, sign-able / encrypt-able. This rules out some markup languages.

The Attester, Verifier and Endorser are the roles that create messages and therefore make the decision which encoding to use. The architecture can (a) create a short list (b) define criteria for making a good choice or (c) expect a negotiation. Given (a) and the language of the Internet moves away from what is on the list then the advice in the architecture is counter-productive IMO. Given (b) there is still a lot of leeway for non-convergence. Given (c) negotiation protocol is an additional barrier to attestation adoption.

If the SAAG were to endorse (a) then that would send a message to all IETF WGs that there is a need to encourage convergence. In other words the language of the Internet will converge because everyone at the IETF agrees to drive convergence. 

On 3/4/20, 10:32 AM, "Thomas Fossati" <[email-masked]> wrote:

    
    cheers!
    --

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 5 Mar 2020 13:45:28 +0000

On 04/03/2020, 22:53, "Smith, Ned" <[email-masked]> wrote:
> Nms> A guiding principle is that market forces often decide which
> formats become winners. The architecture hopes market forces will
> value interoperability (Metcalf's law
> https://en.wikipedia.org/wiki/Metcalfe's_law) but in the meantime, the
> architecture assumes Verifier and Relying Party will have to deal with
> the complexity of multiple formats. The other constraint is the
> architecture expects messages produced by RATS roles can (must?) be
> digest-able, sign-able / encrypt-able. This rules out some markup
> languages.
>
> The Attester, Verifier and Endorser are the roles that create messages
> and therefore make the decision which encoding to use. The
> architecture can (a) create a short list (b) define criteria for
> making a good choice or (c) expect a negotiation. Given (a) and the
> language of the Internet moves away from what is on the list then the
> advice in the architecture is counter-productive IMO. Given (b) there
> is still a lot of leeway for non-convergence. Given (c) negotiation
> protocol is an additional barrier to attestation adoption.
>
> If the SAAG were to endorse (a) then that would send a message to all
> IETF WGs that there is a need to encourage convergence. In other words
> the language of the Internet will converge because everyone at the
> IETF agrees to drive convergence.

Thanks Ned.  One question: within the RATS scope, i.e., for specs
produced by this working group, do we envisage encodings other than
[JC]WT?  If so, which one?

cheers, t
--

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 6 Mar 2020 19:47:07 +0000

On 3/5/20, 5:46 AM, "Thomas Fossati" <[email-masked]> wrote:

    Thanks Ned.  One question: within the RATS scope, i.e., for specs
    produced by this working group, do we envisage encodings other than
    [JC]WT?  If so, which one?
Nms> The RATS architecture considers interoperability challenges given existing installed base of trusted entities (e.g. TPM, TEEs - such as Intel SGX and ARM TrustZone, and any environment that can digest, mac, sign or encrypt; but may not be thought of as a 'root of trust'). A RATS Verifier and Relying Party might encounter these other secure data encoding formats. 

The IETF is responsible for defining some of these other formats: 
	- CMS (BER) - RFC5652
	- X.509 (BER) - RFC5280, RFC5755
	- Signed XML - RFC3275
	- COSE, JOSE - RFC8152, RFC7515
	- YANG - https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-13
	- NEA PA-TNC - RFC5792
	- others?

Additionally, IETF defined protocol header formats and payload formats can be thought of as 'secure data encoding formats'. 

RATS Verifiers and Relying Parties potentially need to interface with any / all of the above encoding formats to extract 'claims' information. 

A concrete example involving both X.509 and COSE for RATS is the case where a device obtains an embedded key pair by its manufacturer who issues an X.509 certificate. The mfg includes attestation Evidence claims in the X.509 certificate. The key is used to sign a CWT EAT token. The Verifier must parse claims found in both the token and in the certificate. 

Other anticipated cases involve using unsigned CWT EAT tokens because the signing key (aka attestation key) is used to sign a protocol data unit or frame containing the unsigned token / claims. It goes without saying that other standards bodies define protocols that involve 'secure data encoding formats'. 

It might be impossible to expect convergence of protocols but it seems (more?) realistic that unsigned token / claims formats, as payload objects, could converge. 

A RATS Verifier / RP could anticipate appraisals, that operate on the unsigned claims maps, use common encoding such as CBOR. The RATS Verifier / RP code that deals with verification of digital signatures, encryption, digests etc., might need to be more tolerant of the above variety of encodings. 

An example of how IETF could drive convergence of secure protocols is OSCORE; where the security in CoAPs and HTTPs are transferred to OSCORE; which specifies COSE encodings rather than TLS/DTLS specific frame/packet encodings. 

Convergence at the DDL layer is also challenging because PKI is X.509 / BER centric and there aren't any widely deployed alternatives AFAIK. The IETF would need to propose an alternative to RFC5280 and RFC5755 that is CBOR / COSE based. Possibly the ACE WG believes CWT is doing that somehow, but CWT is closer to a CBOR realization of CMS than of X.509 IMHO. The ACE WG seems to put JOSE/JWT on the same level of importance as COSE/CWT which doesn't seem to drive convergence. OSCORE, for example, doesn't support JOSE AFAIK.

Bringing this back full circle. RATS WG charter focus is first on CWT and JWT encodings (and we're pushing for a naked version of CWT/JWT as we speak). But really the focus is more on the claims semantics and RATS drafts try to use CDDL or YANG for that. Specifying JWT/CWT essentially *adds* to Verifier / RP complexity because existing formats (e.g., X.509, binary) cannot be ignored due to the installed base of trustworthy computing technology. One could reasonably ask why RATS allows both JWT and CWT. Why not pick just one? It may be fair to position that RATS WG is hopeful that industry will tolerate an increase in encoding format complexity as an avenue toward later consolidations? But the IETF must itself be convinced of this and take all reasonable steps to build a path to convergence by updating RFCs that existentially advocate for non-convergence.

-Ned
    
    cheers, t
    --

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Mar 2020 17:52:33 -0500

> are preferred for Attestation Evidence, though it is understood that in
    > many use cases other extant serialization formats will have to be
    > used.

I think that those are reasonable things to state.
I would even go to CWT-only for Evidence, but that's me.
(I guess in the background-check flow, JWT makes life somewhat easier)

The key thing to realize is that a given Attester will speak only one format,
likely determined (by fiat) by the designer of the Attester.

A given Verifier/Relying Party interaction will speak only one format.
Whether it is the Verifier or the Relying Party gets to specify the format is
probably going to be determined by Market Capitalization rather than
technical merits.
But, to the extent that the IETF has been successful in promoting
interoperability, it has often been to constrain the translation from
un-cooperative "SDO"s specifications to ones that we control.
{I think that's as nice as I can be}

So the life of the Verifier will be difficult, as was the life of the
LotusNotes/SMTP gateway and the X.500(EAN!)/SMTP gateway.  But, observe what
happened there: SMTP won, and everything is mostly SMTP, except when it's jSMTP.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Smith, Ned" <[email-masked]>
Date: Sat, 7 Mar 2020 00:17:30 +0000

Nms> see inline

On 3/6/20, 2:52 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    The key thing to realize is that a given Attester will speak only one format,
    likely determined (by fiat) by the designer of the Attester.
Nms> In many cases, device vendors are embedding keys at manufacturing time. These keys are often certified using X.509 PKI. That means the Attester designer already has determined some minimal support of BER is included in the BOM cost. The SUIT WG concluded that for IoT updates the device bom already includes some CBOR. If the goal is to narrow on a short list of encoding formats, BER and CBOR are at the top of the list (at least for IoT devices). PCs and Servers still don't embrace SUIT manifest / SW update package format AFAIK.

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 7 Mar 2020 09:19:09 -0800

> On Mar 6, 2020, at 4:17 PM, Smith, Ned <[email-masked]> wrote:
> 

Here’s how I’d expect a lot of the X.509 PKI’s to work.

0) A root cert (a form / part of endorsement) is generated by the manufacturer / endorser and is given to the verifier.

1) The manufacturer puts the private part of a key pair into the attester. It can be in any format including some raw format or some BER encoded format or even COSE format. It will just be used to sign evidence, so the best is probably some raw format. For ECDSA, best is probably just a 256-bit number.

2) The manufacturer puts one or more X.509 certs into the attester including one with the corresponding public key.

3) The attester signs evidence  with the private key

4) The attester bundles the X.509 certs into the COSE headers. See https://tools.ietf.org/html/draft-ietf-cose-x509-05

5) The verifier walks the cert chain from the COSE headers up to the root 

Net-net, the attester copies X.509 certs around, but never looks inside so no BER code is needed. 

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 7 Mar 2020 12:15:10 -0800

My approach for EAT is that claims are defined / described in CDDL with accompanying explanatory text. There will also be clear and complete instructions on how to encode them in CBOR and JSON.  The EAT document will go no further than that.

If someone wants to create a separate document that maps the EAT CDDL into ASN.1 that’s fine. Maybe it is for just a few claims, maybe it is a methodology that will work for every claim in the IANA CWT registry.

If someone wants to suggest tweaks to the EAT CDDL to make it easier to encode in ASN.1, that is OK, but only tweaks.

If someone wants to create a separate document that maps claims into Yang that is OK, but this will not be a token format because YANG is not good for that or used that way.

If someone wants to suggest tweaks to the EAT CDDL to make it easier to encode in Yang, that is OK, but only tweaks.

If someone wants to wrap claims sets in CMS, that is fine, but not as a preferred format. 

If someone wants to create a separate document that maps EAT CDDL into XML, that’s fine… Same comments as for ASN.1… 

…

Also, I believe the crypto and key management infrastructure for EAT is just like with CWT — whatever COSE / JOSE provides. For specific use cases / sub industries and such, there will be profiles narrowing the crypto, describing key management and such. Most of it just goes into COSE / JOSE headers.

LL

> On Mar 6, 2020, at 11:47 AM, Smith, Ned <[email-masked]> wrote:
> 
> 
> 
> On 3/5/20, 5:46 AM, "Thomas Fossati" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 	- YANG - https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-13 <https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-13>
> 	- NEA PA-TNC - RFC5792
> 	- others?
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 07 Mar 2020 16:21:27 -0500

Smith, Ned <[email-masked]> wrote:
    mcr> The key thing to realize is that a given Attester will speak only one format,
    mcr> likely determined (by fiat) by the designer of the Attester.

    Nms> In many cases, device vendors are embedding keys at manufacturing
    Nms> time. These keys are often certified using X.509 PKI. That means the
    Nms> Attester designer already has determined some minimal support of BER
    Nms> is included in the BOM cost. The SUIT WG concluded that for IoT
    Nms> updates the device bom already includes some CBOR. If the goal is to
    Nms> narrow on a short list of encoding formats, BER and CBOR are at the
    Nms> top of the list (at least for IoT devices).

Just because the certificate is BER encoded doesn't mean that an entity using
the private key to create a signed artifact has to have any ASN.1/PKIX code
to do the signing.
Validaing the connection to the verifier might require certificate chain
validation, or it could be designed around an embedded RPK, or CoID.

What I'm trying to say is that CBOR is really the only part that we can be
sure is in the BOM cost.

    Nms> PCs and Servers still
    Nms> don't embrace SUIT manifest / SW update package format AFAIK.

It's true, and SUIT has made them out of scope.
But, BMCs will adopt SUIT quickly, I think.
The rest of the server upgrade path is leverages the secure (attested)
connection to the BMC.  As for PCs... increasingly irrelevant outside of
technical creators from what I can see :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 07 Mar 2020 16:24:47 -0500

> 4) The attester bundles the X.509 certs into the COSE headers. See
    > https://tools.ietf.org/html/draft-ietf-cose-x509-05

In draft-selander-ace-ake-authz we are looking at a way to pass the key by
reference rather than value, since bytes really count.

    > so no BER code is needed.

We are in complete agreement.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 7 Mar 2020 21:28:59 +0000

Nit: DER, not BER.

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 7 Mar 2020 13:09:20 +0000

Hi Ned,

Thanks for taking the time to articulate your views, and apologies for
the savage cutting; I'd like to reply on a couple of interesting points
you raise.

On 06/03/2020, 19:47, "Smith, Ned" <[email-masked]> wrote:
> RATS Verifiers and Relying Parties potentially need to interface with
> any / all of the above encoding formats to extract 'claims'
> information.

Sure, legacy is legacy, but new players esp. attestation producers have
a choice and we have an opportunity here in RATS to gently steer that
choice in a direction of decreased fragmentation.

> An example of how IETF could drive convergence of secure protocols is
> OSCORE; where the security in CoAPs and HTTPs are transferred to
> OSCORE; which specifies COSE encodings rather than TLS/DTLS specific
> frame/packet encodings.

I'm not sure about OSCORE paving the way here.  I think it is more
realistic to assume HTTP over TLS (or QUIC) as the present and future
narrow waist and work from there.  (This holds for constrained
environments as well, maybe replacing HTTP with CoAP.)

Proposals like [1] that allow CWT, and therefore EAT, to be used
natively at TLS session establishment seem to plug into the stack at the
right layer.

Another bit in the IETF toolbox that looks like it's going in a similar
direction is [2], which allows CWT to wrap assertions made by x.509
identities.

These are both relatively new items - in particular, one of them is
still an individual draft - but they similarly work in the direction of
making the ecosystem more CWT/JWT friendly.

They are also emerging as apparently uncoordinated efforts, but this is
just how IETF's bottom-up model tends to work.  This organisation isn't
very good at imposing top-down directives (by design).

So, if there is a will to do so here, and I think this is the promise in
our current charter, RATS might try and tilt the table a bit instead of
taking a completely neutral stance.

My two cents,
Cheers!

[1] https://datatracker.ietf.org/doc/draft-tschofenig-tls-cwt
[2] https://datatracker.ietf.org/doc/draft-ietf-cose-x509
--

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 8 Mar 2020 11:47:34 +0000

Hi Laurence,

Agree.  See below a tiny note.

On 07/03/2020, 17:19, "Laurence Lundblade" <[email-masked]> wrote:
> >  Nms> In many cases, device vendors are embedding keys at
> >  manufacturing time. These keys are often certified using X.509 PKI.
> >  That means the Attester designer already has determined some
> >  minimal support of BER is included in the BOM cost. The SUIT WG
> >  concluded that for IoT updates the device bom already includes some
> >  CBOR. If the goal is to narrow on a short list of encoding formats,
> >  BER and CBOR are at the top of the list (at least for IoT devices).
> >  PCs and Servers still don't embrace SUIT manifest / SW update
> >  package format AFAIK.
>
>  0) A root cert (a form / part of endorsement) is generated by the
>  manufacturer / endorser and is given to the verifier.
>
>  1) The manufacturer puts the private part of a key pair into the
>  attester. It can be in any format including some raw format or some
>  BER encoded format or even COSE format. It will just be used to sign
>  evidence, so the best is probably some raw format. For ECDSA, best is
>  probably just a 256-bit number.
>
>  2) The manufacturer puts one or more X.509 certs into the attester
>  including one with the corresponding public key.

There are provisioning workflows where the key-pair is generated inside
the device.  But even in those cases, outputting the CSR (or equivalent)
in DER format can be done with minimal complexity: one thing is having
to parse generic ASN.1 and another is filling a few gaps in a static
template.  (I'd expect the trust model in the factory such that the
device can just install the resulting cert without having to validate
it.)

cheers!

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 10 Mar 2020 00:23:31 +0000

More inline Nms>

On 3/7/20, 1:21 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    
Nms> Correct. But if the vendor decides to issue X.509 certs it is assuming Verifiers (even constrained verifiers) will parse ASN.1 and implement PKI. 
    
    What I'm trying to say is that CBOR is really the only part that we can be
    sure is in the BOM cost.
Nms> A (different?) vendor in the supply chain could also decide they don't want to incur ASN.1/BER/PKI BoM cost and therefore align on CBOR. That vendor is assuming the Verifier will parse CBOR/COSE/CWT/SUIT Manifests etc. Now the Verifier has to support both ASN.1/BER/PKI and CBOR/COSE/CWT/SUIT and so forth. The various endpoint vendor(s?) are optimizing their respective costs by transferring costs to the Verifier. If Verifiers aren't already paying the cost then the economics break down. In IoT the Verifier is often a constrained entity since the Sensor (designed to be a Server) verifies Controllers (designed to be Clients). 

    It's true, and SUIT has made them out of scope.
    But, BMCs will adopt SUIT quickly, I think.
Nms> That doesn't change the dynamic that vendors embed keys and decide (assume?) the Verifier wants to see an X.509 certificate. Verifiers still have to deal with both formats.
    The rest of the server upgrade path is leverages the secure (attested)
    connection to the BMC.  As for PCs... increasingly irrelevant outside of
    technical creators from what I can see :-)
Nms> This thread began with an observation that Verifier / RP was complex and "can't RATS do something to fix it" by disallowing other formats. It seems the suggestions focus on pushing complexity somewhere else (instead of making it go away) and the somewhere else is the Verifier. But increasingly, the Verifier is a constrained environment.

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 10 Mar 2020 00:43:18 +0000

Nms> inline

On 3/7/20, 1:24 PM, "Michael Richardson" <[email-masked]> wrote:

        > 0) A root cert (a form / part of endorsement) is generated by the manufacturer / endorser and is given to the verifier.
Nms> In X.509 format.

        > 2) The manufacturer puts one or more X.509 certs into the attester including one with the corresponding public key.
Nms> Manufacturers prefer not to put certs in the device because they use a lot of memory. This cost is multiplied by the number of devices shipped. It adds up. Instead they prefer to put them in the cloud or generate them from something more primitive (e.g. fuses, PUFs, seed). 
Nms> If the device is a 'layered' device or 'composite device' then the cost is multiplied even more.

    
    In draft-selander-ace-ake-authz we are looking at a way to pass the key by
    reference rather than value, since bytes really count.
Nms> The use case seems to suggest that "X.509 PKIs" are built around COSE? I wouldn't have expected that to be the case looking across all the devices where an X.509 cert is issued for a device/machine. 
    
        > 5) The verifier walks the cert chain from the COSE headers up to the root
Nms> Many implementations of PKI rely on a conveyance protocol such as TLS to transfer the certificates (if they are available in the first place). COSE can offer a similar capability. Not sure it should be characterized as "a lot of PKIs". Maybe in a relative way where "a lot" can be characterized as less than 'most'? 

    We are in complete agreement.
Nms> The context of the thread relates to the complexity of the Verifier and Relying Party (who is also a Verifier). The design choices of the Attester (device mfg) impact the Verifier because they issue certs in PKI/BER/X.509 and also encode things in CBOR/COSE/jSON/JOSE and a variety of other conveyance protocols. Verifier are increasingly constrained and increasingly mesh/fabric/embedded where BOM cost also matters. I'm not sure how any of this thread resolves the complexity question that arose due to the observation that there are many possible serialization formats for Attestation Results (and presumably for Evidence too).

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 9 Mar 2020 18:27:19 -0700

Agreed that X.509 is going to be needed for lots of use cases in the Verifier including ones using CBOR, but X.509 is already widely implemented and is a solved problem (OpenSSL, mbedTLS, BouncyCastle…). Probably a lot of secure/trusted boot implementations decode it already. 

Creating new ASN.1, such as an EAT token in ASN.1 format is different thing than needing X.509. It’s lots of new code to write, particularly on the decode side. So, even if it is a given that Verifiers will have to do X.509, it will still be a jump in complexity for the Verifier to have to handle ASN.1 for the token as well as CBOR.

Also, I believe a principle mentioned before was “no new ASN.1” or a least “minimal new ASN.1"

I’m not saying no ASN.1 tokens or RATS protocols ever, just that we should prefer CBOR and JSON (and YANG).

LL

> On Mar 9, 2020, at 5:23 PM, Smith, Ned <[email-masked]> wrote:
> 
> More inline Nms>
> 
> On 3/7/20, 1:21 PM, "RATS on behalf of Michael Richardson" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Mar 2020 09:19:37 -0400

Smith, Ned <[email-masked]> wrote:
    Nms> A (different?) vendor in the supply chain could also decide they
    Nms> don't want to incur ASN.1/BER/PKI BoM cost and therefore align on
    Nms> CBOR. That vendor is assuming the Verifier will parse
    Nms> CBOR/COSE/CWT/SUIT Manifests etc. Now the Verifier has to support
    Nms> both ASN.1/BER/PKI and CBOR/COSE/CWT/SUIT and so forth. The various
    Nms> endpoint vendor(s?) are optimizing their respective costs by
    Nms> transferring costs to the Verifier. If Verifiers aren't already
    Nms> paying the cost then the economics break down. In IoT the Verifier
    Nms> is often a constrained entity since the Sensor (designed to be a
    Nms> Server) verifies Controllers (designed to be Clients).

I don't think that the sensors are Verifiers.
I think that they are Relying Parties.
I know at least one company (Jitsuin) that has built a system that architects
it that way.

    > technical creators from what I can see :-)

    Nms> This thread began with an observation that Verifier / RP was complex
    Nms> and "can't RATS do something to fix it" by disallowing other
    Nms> formats. It seems the suggestions focus on pushing complexity
    Nms> somewhere else (instead of making it go away) and the somewhere else
    Nms> is the Verifier. But increasingly, the Verifier is a constrained
    Nms> environment.

We have multiple (legacy) formats.  We can either go with the worst liked legacy stuff
and infect it into all new designs, or we can contain that complexity into a
single component and allow the rest of the ecosystem to evolve.

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 10 Mar 2020 19:26:25 +0000

On 3/10/20, 6:20 AM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    

    
Nms> It isn't my intention to disagree on what role an entity may/may not implement. Rather to set the expectation that RATS architecture should set an expectation that supporting many encodings adds complexity (somewhere) and that it shouldn't be the assumption of the architecture that complexity is easily absorbed somewhere else. Different deployment architectures may put complexity in different places (e.g. Verifier in the case of Jitsuin). RATS should not presume this is the only place for it though; but more importantly, that complexity overall needs to be reduced. Some people my like JSON but it still adds complexity relative to CBOR. Some may dislike BER but it represents a legacy that isn't easily dismissed. If RATS objective is to reduce overall complexity they might consider recommending only a single encoding format from the 'well liked' category and give guidance on how to minimize complexity due to legacy and what trade-offs are likely. 

I can't tell if the list is advocating ignorance as a strategy for evolving the ecosystem.