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

[Laurence Lundblade <[e-mail]>]

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

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