Subject: Re: [Rats] [EAT] Attestation BoF charter updates? - Program of Work section

From: "Smith, Ned" <[email-masked]>
Date: Wed, 24 Oct 2018 18:19:37 +0000

[nms] The Program of Work section (2.) has the following statement:
"Specify interoperable cross-platform claims which provide information about systems and entities in support of the required use-cases, and extending the set of claims defined in RFC7519 and RFC8392. The specification will describe the syntax for each claim in at least the following formats:

CBOR [RFC7049]
JSON [RFC7159]
using modeling languages, such as:

YANG [RFC6020]
CDDL [I-D.ietf-cbor-cddl]
while retaining interoperability with existing formats based on ASN.1, if possible and feasible."
[nms] The intent is (should be?) that existing ASN.1 formatted claims should be semantically similar/same as their CBOR/JSON/YANG/CDDL counterparts. If the WG defines claims for which there isn't a pre-existing standardized ASN.1 representation. It should be within the scope of the WG to define the ASN.1 representation. Hence, the sentence "...while retaining interoperability with existing formats based on ASN.1, if possible and feasible." Might better be stated as:
"...while retaining interoperability with existing formats based on ASN.1, where claim semantics are the same (very similar)."
"Claims that are unique to the efforts of this working group may include definition of its ASN.1 representation."
-Ned

On 10/24/18, 5:56 AM, "EAT on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,
    
    based on Jeremy's proposal we did another big refactoring - also tried 
    to address everybody's comments, inputs and concerns.
    
    > https://github.com/ietf-rats/charter/blob/RC3/ietf-rats-charter.md
    
    Please note that this charter text is intended to be a first phase, 
    which is the reason why, for example, there still is no mentioning about 
    provisioning, profiles, or more details about out-of-band dependencies.
    
    As Michael highlighted, most types of content belong into drafts. That 
    said - on one hand the charter is a kind of "contract" wrt to scope and 
    output, on the other hand we do not want to boil the ocean (at least not 
    all at once...).
    
    Viele Grüße,
    
    Henk
    
    On 10/24/2018 01:36 PM, Jeremy O'Donoghue wrote:
    > HI Eric,
    > 
    >> On 23 Oct 2018, at 19:04, Eric Voit (evoit) <[email-masked] 
    >> <mailto:[email-masked]>> wrote:
    >>
    >> Hi Jeremy,
    >> Thanks for taking a cut at this charter simplification.  There are a 
    >> few areas covered within theGitHub Goals 
    >> <https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md>which 
    >> I can’t easily map to your text below.  Could you talk about how these 
    >> elements are covered (or not)?   For context, I am working from the 
    >> perspective ofremote attestation application 
    >> <https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/user-guide/Cisco_Integrity_Verification_Application_APIC-EM_User_Guide_1_5_0_x.pdf>developer 
    >> trying to standardize the interfaces between a controller (which is 
    >> acting as a claim verifier) and a network element (which includes TCG 
    >> based subsystems.)
    >> For my application to work properly, there are several things needed 
    >> within a network controller to validate the asserted claims coming out 
    >> of a router.  These include:
    >> ·How do we expose the attestation evidence which can be used to 
    >> validate asserted claims?
    > 
    > I think that the need to address this is covered sufficiently for a WG 
    > Charter by the statement "Produce a specification defining procedures 
    > and corresponding architectures  supporting verification of Claims".
    > 
    > If verification of Claims requires specific forms of attestation 
    > evidence (e.g. a set of measurements generated by a TPM), then it is 
    > properly a matter for an RFC to specify this, as Michael suggests.
    > 
    >> ·How do we know which root of trust which was used to generate the 
    >> attestation evidence (e.g., application event logs), and how does a 
    >> verifier differentiate this from the root-of-trust which asserts 
    >> claims made upon this evidence?
    > 
    > Again, I think this is a matter for specification rather than charter. 
    > There are a number of different ways in which Roots of Trust can be 
    > realised and many possible device architectures. The EAT draft allows 
    > one RoT to include an attestation generated by a different RoT, for 
    > example. I believe the RATS draft also provides technical mechanisms by 
    > which this can be achieved.
    > 
    >> ·What entities are allowed to read the info asserted claims?  What 
    >> subset of these can see the raw attestation evidence?
    >> These questions are significant because routers/switches are not 
    >> monolithic devices.  In fact, they are composed of subsystems with 
    >> different levels of trustworthiness. As the IETF often aims at 
    >> protocol specifications at the inter-device level, I am looking for 
    >> coverage of such questions in the charter.
    > 
    > I agree with you here as the same issue applies to claims with privacy 
    > implications. As an example, I may wish to present a unique device ID to 
    > a social media website but not my location.
    > 
    > I have added bullet point 3 to the draft - which I will post separately. 
    > Let me know if you think this addresses your concerns sufficiently.
    > 
    > Best regards
    > Jeremy
    > 
    >> Thanks,
    >> Eric
    >> *From:*Jeremy O'Donoghue, October 23, 2018 10:40 AM
    >>
    >> On 22 Oct 2018, at 22:01, Michael Richardson <[email-masked] 
    >> <mailto:[email-masked]>> wrote:
    >>
    >>
    >>     Jeremy O'Donoghue <[email-masked]
    >>     <mailto:[email-masked]>> wrote:
    >>
    >>         This is a very useful contribution, Laurence.
    >>
    >>
    >>
    >>         The current draft text is too strongly biased towards
    >>         attestation based
    >>         on measurement, and does not adequately cover other mechanisms
    >>         which
    >>         are already
    >>
    >>
    >>     But, it's for the charter, for the WG, it's not a treatise on
    >>     attestation
    >>     itself.
    >>
    >>     This is all supposed to be *meta* text about attestation, about
    >>     what we want
    >>     to say about attestation in the documents, not about what
    >>     attestation is.
    >>
    >>     Please go read some other IETF charters:
    >>
    >>     https://datatracker.ietf.org/wg/6lo/about/
    >>     https://datatracker.ietf.org/wg/6tisch/about/
    >>     https://datatracker.ietf.org/wg/suit/about/
    >>
    >> Fair comment.
    >> We have two existing proposals - EAT and RATS - which address a 
    >> similar problem space but using different mechanisms. While I believe 
    >> the RATS and EAT contributors are in broad agreement that there is 
    >> significant benefit in bringing both work streams under a single 
    >> umbrella, trying to properly incorporate EAT through incremental 
    >> modification to the draft RATS WG charter text is proving challenging.
    >> The below probably diverges too far from the current text for some 
    >> tastes, but it may address your point and provide a basis for 
    >> discussion (at this point the GitHub draft 
    >> <https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md> seems 
    >> a long way behind the list). It is deliberately significantly shorter 
    >> than the current draft - I have tried to re-use as much existing text 
    >> as possible, but it is heavily re-organised and abridged.
    >> I have taken on board the comment from Carsten that perhaps a minimum 
    >> level of terminology is acceptable in charter text, but deliberately 
    >> tried to keep the language simple and fairly generic to enable the 
    >> proper work of terminology definition to take place in the 
    >> requirements document as you suggest.
    >>
    >> Introduction
    >>
    >> ------------
    >>
    >> Remote attestation procedures can be incorporated in network protocols to
    >> provide the basis for establishing claims about an entity in a trustworthy
    >> manner. Such claims may include, but are not limited to, device identity,
    >> manufacturing origin, system integrity, configuration, operational 
    >> state and
    >> measurements of steps which led to the operational state. Such procedures
    >> expose entity characteristics in the form of claim sets which allow remote
    >> parties to establish the trustworthiness of a device, provide evidence 
    >> that a
    >> particular set of operations and functions are supported and/or that the
    >> entity is actually what it claims to be.
    >>
    >> In the absence of such procedures, while domain-specific attestation
    >> mechanisms such as TCG TPM, FIDO Alliance attestation and Android Keystore
    >> attestation exist, there is no common way for a remote party to tell 
    >> if data
    >> originates from a trustworthy device (e.g. a Trusted System designed to
    >> support a specific set of operations/functionalities) or not.
    >>
    >> The following minimal terminology is defined for the purposes of 
    >> clarifying the
    >> Working Group charter text:
    >>
    >> - attestation: a set of claims which can be verified as originating in an
    >>           entity.
    >>
    >> - claim:  as defined in RFC7519.
    >>
    >> - entity: a device or device sub-module that can generate a claim or 
    >> set of
    >>           claims which can be verified by a remote party.
    >>
    >> - remote party: an actor remote from an entity that wishes to verify 
    >> whether
    >>           a claim or set of claims originated in a given entity.
    >>
    >> Description of the Working Group
    >>
    >> --------------------------------
    >>
    >> The Working Group will define:
    >>
    >> - Standardized and interoperable mechanisms to establish a sufficient 
    >> level
    >>   of confidence that data originates from a trustworthy entity designed to
    >>   support a specific set of operations/functionalities.
    >> - Standardized and interoperable mechanisms building on (1) to allow 
    >> remote
    >>   parties to know the provenance and characteristics of an entity that 
    >> may be
    >>   requesting services.
    >>
    >> The Working Group will identify security goals which it expects a 
    >> trustworthy
    >> execution context to address, which will assume the presence of Roots of
    >> Trust (as defined by NIST [SP800-164]). The detailed specification of such
    >> contexts is out of scope.
    >>
    >> The Working Group will maintain close relationships with bodies 
    >> undertaking
    >> complementary work streams in the area of remote attestation such as
    >> GlobalPlatform, Trusted Computing Group and FIDO Alliance.
    >>
    >> The Working Group will cooperate with the TEEP Working Group, which may
    >> generate requirements for claims relevant to TEE.
    >>
    >> Work Items
    >>
    >> ----------
    >>
    >> The Working Group will develop specifications supporting the creation of
    >> interoperable remote attestation procedures for entities which 
    >> incorporate
    >> Roots of Trust. The main deliverables are as follows.
    >>
    >> - Produce a requirements document establishing a common vocabulary for 
    >> remote
    >>   attestation, identifying mechanisms which will be supported for 
    >> establishing
    >>   trust between an entity and a remote party, and enumerating sample 
    >> use-cases
    >>   for remote attestation.
    >>
    >> - Produce specification text defining interoperable cross-platform 
    >> claims which
    >>   provide information about an entity in support of the required 
    >> use-cases, and
    >>   extending the set of claims defined in RFC7519 and RFC8392. The 
    >> specification
    >>   will describe the syntax for each claim in at least the following 
    >> formats:
    >>     - CBOR [RFC7049]
    >>     - JSON [RFC7159]
    >>     - YANG [RFC6020]
    >>
    >> - Produce specification text defining procedures and corresponding 
    >> architectures
    >>   supporting verification of claims within an attestation based on 
    >> measured file
    >>   execution procedures and supporting:
    >>     - Explicit attestation wherein a set of claims is transported in 
    >> the attestation;
    >>     - Implicit attestation wherein a set of claims is implied by 
    >> possession of a secret.
    >>
    >> - Produce specification text defining procedures and corresponding 
    >> architectures
    >>   supporting verification of claims encapsulated in:
    >>
    >>     - CBOR Web Token structures [RFC8392]
    >>     - JSON Web Token structures [RFC7519]
    >>
    >> - Perform privacy analysis of both claims and the cryptographic 
    >> procedures used to
    >>   establish trust. This information will be included as appropriate in the
    >>   deliverable specifications, and may imply extension of procedures 
    >> defined in
    >>   other specifications in support of privacy goals.
    >>
    >> It seems to me that there are two ways to produce the main 
    >> specification deliverables. I have deliberately left the text above 
    >> slightly vague on this.
    >>
    >>   * A claims specification common to RATS and EAT with separate RATS
    >>     and EAT procedure specifications.
    >>   * A claims specification also incorporating EAT procedures and a
    >>     separate RATS procedure specification. This would be my preferred
    >>     option.
    >>
    >>       o I believe there are very few procedures needed for EAT other
    >>         than the possible need to support a nonce to ensure freshness
    >>
    >> Jeremy
    >>
    >>
    >>     Notice how by about the second paragraph (6tisch takes a bit
    >>     longer), each
    >>     gets into what the WG will do?
    >>
    >>     --
    >>     Michael Richardson <[email-masked]
    >>     <mailto:[email-masked]>>, Sandelman Software Works
    >>     -= IPv6 IoT consulting =-
    >>     _______________________________________________
    >>     EAT mailing list
    >>     [email-masked] <mailto:[email-masked]>
    >>     https://www.ietf.org/mailman/listinfo/eat
    >>
    > 
    > 
    > 
    > _______________________________________________
    > EAT mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/eat
    > 
    
    _______________________________________________
    EAT mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/eat

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 25 Oct 2018 20:15:03 +0700

The new charter looks pretty good to me. 

Some comments on claims formats.

The way I’ve been thinking of support for multiple formats (JSON, CBOR, ASN.1...) is that we do the main work of defining the claim semantics first. Those semantics are in common for all the syntaxes. JSON, CBOR, etc. are just syntaxes.

Agreed we should look at existing claim definitions and avoid re inventing. They should be from any source though, not just ASN.1. 

I want to bring up the issue of interoperability when there are multiple syntaxes (CBOR, JSON, ASN.1…) and securing schemes (COSE, JOSE, CMS…). I think the device should be able to pick one format and only implement that. I don’t think there should be format negotiation. The relying party thus must implement all variants for there to be full interoperability. 

It might be possible to have some intermediate service that translates the syntax of claims (e.g. from CBOR to ASN.1), but then that intermediary would have to re sign which means it would have to be fully trusted as part of the end-end security model.

So I am making some argument against ASN.1 and anything beyond JSON and CBOR.  The more formats there are the more work the relying parties will have to do and of course some won’t implement all the formats and then we’ll have less interop.

LL

BTW, the first EAT implementation I did used CMS because COSE wasn’t ready. I did a pretty small CMS implementation and then later a pretty small COSE Sign1 implementation. COSE Sign1 was easier and less code.

> On Oct 25, 2018, at 1:19 AM, Smith, Ned <[email-masked]> wrote:
>

---

From: Carl Wallace <[email-masked]>
Date: Thu, 25 Oct 2018 09:47:06 -0400

On 10/25/18, 9:15 AM, "RATS on behalf of Laurence Lundblade"
<[email-masked] on behalf of [email-masked]> wrote:

><snip>
>
>So I am making some argument against ASN.1 and anything beyond JSON and
>CBOR.  The more formats there are the more work the relying parties will
>have to do and of course some won’t implement all the formats and then
>we’ll have less interop.

[CW] At least where the claims are related to cryptographic keys, ASN.1 is
likely unavoidable as it's part of the environment. Avoiding it is not
likely to help interop.

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 25 Oct 2018 21:11:26 +0700

> On Oct 25, 2018, at 8:47 PM, Carl Wallace <[email-masked]> wrote:
> 
> 

For an attestation in the vein of EAT you have a series of claims that are signed. The sane thing to do is pick one format and apply it all the way through. The claims are in JOSE format and you sign with JWT. The claims are in CBOR and you sign with COSE. The claims are ASN.1 and you sign in CMS. 

It would be possible to have something like a PKCS10 CSR stuffed into a CBOR byte string in a CBOR/COSE format attestation, but the overall format of the attestation is CBOR/COSE. Maybe this is what you are after? 

Agreed that we might actually have to do this since there is no CBOR format CSR (yet). 

I can also see having to use X.509 for establishing trust in signing keys since there is no CBOR format for certificates (yet). Jim Schaad was working on extensions to COSE for this.

Any other examples? 

I would hope we can avoid CMS and creating ASN.1 syntax for every claim we define.

LL

---

From: Marcus Streets <[email-masked]>
Date: Thu, 25 Oct 2018 14:35:54 +0000

That is an argument for never fixing anything.

We can define a CBOR format for certificates and recommend people use it.
If that creates a need, service providers will offer to sell certificates in the correct format.

-----Original Message-----
From: EAT <[email-masked]> On Behalf Of Carl Wallace
Sent: Thursday, October 25, 2018 2:47 PM
To: Laurence Lundblade <[email-masked]>; Smith, Ned <[email-masked]>
Cc: Eric Voit (evoit) <[email-masked]>; Jeremy O'Donoghue <[email-masked]>; [email-masked]; Michael Richardson <[email-masked]>; [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section

On 10/25/18, 9:15 AM, "RATS on behalf of Laurence Lundblade"
<[email-masked] on behalf of [email-masked]> wrote:

>CBOR.  The more formats there are the more work the relying parties
>will have to do and of course some won’t implement all the formats and
>then we’ll have less interop.

[CW] At least where the claims are related to cryptographic keys, ASN.1 is likely unavoidable as it's part of the environment. Avoiding it is not likely to help interop.

_______________________________________________
EAT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eat
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: Carl Wallace <[email-masked]>
Date: Thu, 25 Oct 2018 10:43:27 -0400

The point is not an alternative certificate format, but to define the
binding between of an attestation with a certificate request.

On 10/25/18, 10:35 AM, "Marcus Streets" <[email-masked]> wrote:

>Cc: Eric Voit (evoit) <[email-masked]>; Jeremy O'Donoghue
><[email-masked]>; [email-masked]; Michael Richardson
><[email-masked]>; [email-masked]; Henk Birkholz
><[email-masked]>
>[CW] At least where the claims are related to cryptographic keys, ASN.1
>is likely unavoidable as it's part of the environment. Avoiding it is not
>likely to help interop.
>
>
>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: Carl Wallace <[email-masked]>
Date: Thu, 25 Oct 2018 11:06:31 -0400

On 10/25/18, 10:11 AM, "Laurence Lundblade" <[email-masked]> wrote:

>>>will
>>is
>For an attestation in the vein of EAT you have a series of claims that
>are signed. The sane thing to do is pick one format and apply it all the
>way through. The claims are in JOSE format and you sign with JWT. The
>claims are in CBOR and you sign with COSE. The claims are ASN.1 and you
>sign in CMS.
[CW] It may shake out such that the claims I care about could be ASN.1
from top to bottom but I doubt it. Mixing formats doesn't seem like a
problem. Base64 encodings of DER encoded structures are quite common in
XML and JSON, for example. Including COSE or JOSE structure as an
attribute in an ASN.1 structure seems fine too.
> 
>
>It would be possible to have something like a PKCS10 CSR stuffed into a
>CBOR byte string in a CBOR/COSE format attestation, but the overall
>format of the attestation is CBOR/COSE. Maybe this is what you are after?

[CW] Not exactly. The CSR would contain a mix of data that is originated
by/protected by a hardware component and data that is external (e.g.,
challenge password). It's not clear to me orchestrating including the P10
in the attestation is the right path. Including a signed claim about key
provenance in a standard cert request seems sufficient and easy enough.
>Agreed that we might actually have to do this since there is no CBOR

[CW] Not sure why that would be required. There was earlier mention of not
boiling the ocean, trying to recast everything as CBOR doesn't seem wise.
> 
>
>I can also see having to use X.509 for establishing trust in signing keys
>since there is no CBOR format for certificates (yet). Jim Schaad was
>working on extensions to COSE for this.
>
>Any other examples?

[CW] I shared a pile of examples via GitHub some weeks back -
https://github.com/Purebred/SampleAttestations. I will add Pixel 3
artifacts soon. I am not suggesting these as a basis for standardization,
but as illustrative of how attestations are used in certificate requests
in some environments. At present, w.r.t. demonstrating key provenance, we
are using:
	- Android attestations (X.509 certificates that chain to a specific root
represented as a certs-only SignedData),
	- Yubikey attestations (X.509 certificates that chain to a specific
rootrepresented as a certs-only SignedData) and
	- Surface Pro TPM attestations (CMC requests that wrap a mix of TCG and
Microsoft structures).

[CW] Each of these is attached to a SCEP request as an attribute. The
attestations are verified and the public key from the attestation is
compared to the public key in the SCEP request. We have another variant
that does use CBOR for some claims. In that case the Google attestation
certificate is included in the CBOR similar to your description above but
the CBOR layer isn't demonstrating key provenance in this case. SCEP, CMC
and EST all use similar attributes. It is not unlikely that a single spec
defining one or more attributes to convey attestations could be shared by
all three. 
>I would hope we can avoid CMS and creating ASN.1 syntax for every claim

[CW] I can't imagine this would be necessary.

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 26 Oct 2018 00:22:08 +0000

I expect a common attestation scenario can be characterized as an X.509 certificate chain having an EE certificate whose private key owner signs a document containing claims. The document could be expressed in any of the formats being discussed here. Use case context may play a role in determining which document format is appropriate, and I don't believe it is necessarily the objective of the charter to promote a philosophical bias toward any particular format, though it does make sense for the WG and charter to set some priorities - trying not to boil the ocean. 

There seems to be use case context (at least by the participants in the BOF) for 3 maybe 4 formats where ASN.1 appears to be the one on the edge (CBOR, JSON, YANG being the other less debated formats). ASN.1 isn't itself a cryptographic document format (IMO); for that we need to turn to something like CMS or X.509. 

A second, likely to be popular attestation scenario, can be characterized as an X.509 certificate chain having and EE certificate containing claims in an extension (or leverages some other extensibility capability described by RFC5280). In this scenario, it seems reasonable for the WG to have an ASN.1 description of the normative set of claims to avoid other organizations coming up with slight (but semantically similar) variants. 

If there is a use case for CMS, RFC5755 (attribute certs) or something else that describes a cryptographic document expressed in ASN.1, then it is a small / possibly inconsequential step required to include the ASN.1 formatted claims into one of these other document structures. 

Conceptually, the 'document' consists of a claims part and a signature part. The claim part could be expressed in one format (e.g. CBOR) while the signature part expressed in a different format (e.g. JWT). Given that perspective we can make lists of format types for claims and another for signed documents.
E.g.
Claims format possibilities:
	- CBOR, JSON, YANG, ASN.1

Cryptographic document format possibilities:
	- CWT, JWT, YANG(?), CMS, X.509 Cert (RFC5280), Attr Cert (RFC5755)

The charter / WG could set different priorities for each list. It could also set priority for, and/or limit, cross-format enveloping (e.g. JSON Claim inside a YANG cryptographic document etc).

A third, possibly likely attestation scenario might do away with the X.509 certificate chain favoring for example a signed-document-only model or possibly an alternative certificate chain using CWT? I don't know if anyone is strongly advocating use cases in this third scenario. If not, it makes sense to leave it out of the charter for now. 

-Ned

On 10/25/18, 8:06 AM, "Carl Wallace" <[email-masked]> wrote:

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 26 Oct 2018 12:12:58 +0700

(This isn’t really charter bashing anymore; think we’re mostly done with that)

I’ll put this in the form of a proposal:

A set of claims about a device is aggregated into a 'token' (this is the term used in CWT/JWT) or ‘document'. That token/document will be signed.  We will support only two formats for the token/document.

CWT: Claims are mainly in CBOR format, but we can stuff other things like commonly used ASN.1, XML, JSON...  structures into an individual claim if necessary. Signing is COSE format, though COSE headers might carry X.509 certs to help identify and chain up to the verification key.

JWT: Claims are mainly in JSON format, but we can stuff other things like commonly used ASN.1, XML, CBOR… structures into an individual claim if necessary. Signing is JOSE format, though JOSE headers might carry X.509 certs to help identify and chain up to the verification key.

The number of formats should be minimized for interoperability so there are only two. There will be no top-level token/document formatted in ASN.1, XML or other. The main singing of the token will never be CMS.  X.509 will not be used for the token/document format.

YANG and/or CDDL will be used describe the claims that are to be encoded in CBOR and JSON. (YANG and CDDL are not encoding formats, just a language for describing structures at a higher level)

The good thing about CBOR and JSON and CWT and JWT is that they are good friends. CBOR was designed for easy conversion to/from JSON. CWT and JWT already share claims.

I’m not sure if this addresses Carl’s use cases yet. 

LL

> On Oct 26, 2018, at 7:22 AM, Smith, Ned <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 26 Oct 2018 09:30:33 -0500

> JWT: Claims are mainly in JSON format, but we can stuff other things like commonly used ASN.1, XML, CBOR… structures into an individual claim if necessary. Signing is JOSE format, though JOSE heade…

There is perhaps something of a philosophical question about stuffing
ASN.1, XML, etc. structures into individual claims, in that "can you really
trust the signer to vouch for what it's signing if the signed contents are
in a format unknown to the signer?"  There are certainly ways to delegate
or chain trust so that the answer to the question is "yes", but I do not
think we should ignore the question entirely.

-Ben

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 26 Oct 2018 21:56:27 +0700

See end...

> On Oct 26, 2018, at 9:30 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

I don’t think the format matters in this case. The basis for the signer trusting what it signs is not dependent on the format. Some one feeding bad data to the signer could just as well feed it in the format the signer typically uses.

What matters is the SW architecture and implementation on the device. In a simple set up the signer might be in the kernel and only sign data that also came from the kernel. Or it could be in TrustZone or an embedded Secure Element and only sign data that came from the same. In something more complicated the signer could be in the kernel and accept data from user mode processes, but mark it specially (this is what the submods claims is for in EAT).  The nonce from the relying party always comes from far away, but it is special and it doesn’t matter. If a MiTM changes the nonce, the relying party will know. 

LL

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 26 Oct 2018 10:05:21 -0500

> What matters is the SW architecture and implementation on the device. In a simple set up the signer might be in the kernel and only sign data that also came from the kernel. Or it could be in Trust…

I agree that the overall system design can include trusted elements feeding
information to the signer, in which case the decision about what gets
signed is made by the individual trusted elements and the signer itself
need not know the formats of the individual claims.  If that's the
architecture we want to use, we just need to be explicit about it.

-Ben