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

[Carl Wallace <[e-mail]>]

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

>
>> On Oct 25, 2018, at 8:47 PM, Carl Wallace <[e-mail]>
>>wrote:
>> 
>> 
>> On 10/25/18, 9:15 AM, "RATS on behalf of Laurence Lundblade"
>> <[e-mail] on behalf of [e-mail]> 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 -
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
>we define.

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