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

[Benjamin Kaduk <[e-mail]>]

On Fri, Oct 26, 2018 at 09:56:27PM +0700, Laurence Lundblade wrote:
> See end...
> 
> > On Oct 26, 2018, at 9:30 PM, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > On Fri, Oct 26, 2018 at 12:12:58PM +0700, Laurence Lundblade wrote:
> >> (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.
> > 
> > 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.
> 
> 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. 

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