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

Laurence Lundblade <> Fri, 26 October 2018 05:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53ADC12F1A6 for <>; Thu, 25 Oct 2018 22:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xtBNK1TwiTnc for <>; Thu, 25 Oct 2018 22:13:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BE23130934 for <>; Thu, 25 Oct 2018 22:13:04 -0700 (PDT)
Received: from ([]) by :SMTPAUTH: with ESMTPSA id FuQdgS5VfCAU6FuQegrhuJ; Thu, 25 Oct 2018 22:13:04 -0700
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C0759A6E-6F86-4F62-9487-09D29F6ECE12"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 26 Oct 2018 12:12:58 +0700
In-Reply-To: <>
Cc: Carl Wallace <>, "Eric Voit (evoit)" <>, Jeremy O'Donoghue <>, "" <>, Michael Richardson <>, "" <>, Henk Birkholz <>
To: "Smith, Ned" <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfGvjDiYsMaaQ1BAJ33UaqxO93MXiCK1ItjlUD630Gz3g+yxmWBm3g91RF5UvkqaTa3Y0f+Tsbs7uPamNUT23ybNCH3bs1duw1jJXrokOtIqPVWiQP4Eu cloD/51IG5bM58L9/grTRm89dRZIAQK/EcQ8XDU77GGzD/bdpS9D+jffgfs/Vl/ZXqGcJexEVV9bZhFK0oIaVWy30msMxd7XvnPNDnk2DfWkHiX0luGESwQF evVRn3EDlN62Zev9B2TkElkr9V4A4W8/+OnM9eBeEjrg4Vej0iGfnWnD+MtD37dJFXSr8bUhX+boeAK3fj+nMvdJAdCVqVShFzNJOaN+GrOdE3t4CB2tydED JCK+/YJCAgd0beQy5uGuIIahjGfBUkQ0oBPcLrmnQpT9W8P4LlofSKC4C8JULCbIjjZqMOtbPsV5m+31w1daGRmYH9EAkg==
Archived-At: <>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Oct 2018 05:13:09 -0000

(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. 


> On Oct 26, 2018, at 7:22 AM, Smith, Ned <> wrote:
> 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:
> 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" <> wrote:
>    On 10/25/18, 10:11 AM, "Laurence Lundblade" <> wrote:
>>> On Oct 25, 2018, at 8:47 PM, Carl Wallace <>
>>> wrote:
>>> On 10/25/18, 9:15 AM, "RATS on behalf of Laurence Lundblade"
>>> < on behalf of> 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.
>> 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
>> format CSR (yet).
>    [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 -
> 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
>> we define.
>    [CW] I can't imagine this would be necessary.
>> LL