Henk, Well you have definitely written a message designed to get a response from me.
-----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Henk Birkholz Sent: Wednesday, March 4, 2020 10:41 AM To: r...@ietf.org; ace@ietf.org; c...@ietf.org Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? Hi RATS enthusiasts, hi ACE, hi CBOR, in the RATS WG we had a lot of discussions about the nature of an Entity Attestation Token (EAT): > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ > https://github.com/ietf-rats-wg/eat/ A bit of (hopefully useful) context: an EAT is one way to convey believable evidence from an Attester (a role residing on a device-like entity) to a Verifier (another role defined by RATS - the appraiser of evidence). All that is done to provide a Relying Party with "simple enough" attestation results generated by the Verifier to enable Relying Parties (in general, the remote peer) to make an informed decision about whether to put trust in the trustworthiness of that Attester or not. In summary, an Attester could be compromised in some way and RATS tries to inhibit that Attester to lie about that. There are a lot of benefits if an EAT (representing evidence) is a CWT: * we avoid conflicting CWT claim index/label definitions in the IANA registry, while being able to use the CWT world of claims (existing, cnf soon, and such), * at first glance it seems simpler to use existing code that can process CWT, and * EAT can simply inherit the well defined COSE signing conventions. Alas, there is also a very specific drawback: * sometimes RATS might not want to sign a token (maybe that does render it not a token anymore, but rather a ticket. But that is just a rather minor detail for now) Why do RATS sometimes not require a signature around their CWT Claims Sets? Because the surrounding secure channel between two entities with well established authenticity and trustworthiness can be good enough to convey useful CWT Claims Sets without a signature (emphasis on: in RATS). Now - there are multiple options discussed in the RATS WG how to deal with this: 1.) go to COSE and ask for a "null signature", [JLS] For suggesting this, you should have all of you security credentials revoked. The idea of deliberately introducing a way to take the security value of COSE signatures to zero is something that should be staked like a vampire and not allowed to continue. I strongly believe that this is a fatal flaw in the current JOSE security suite and have several times deliberated writing a document to remove the "null signature" from JOSE. While it is bad to have signatures which are no longer adequately secure, having one with zero security is just brain dead. 2.) go to ACE and ask for an "unsigned token" option, or [JLS] I don't have a problem with this, I am not sure that I see any reason for it however. See below. 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not signed). [JLS] I don't see any difference between this and option #2 [JLS] 4.) Just write your CWT code in a sensible manner. My CWT code base does not make any assumptions about the number or order of COSE security wrapping layers on a token. It thus looks like while (true) { if input has a COSE_Encrypt tag { decrypt it; set input to the content; save the encryption information if needed e.g. shared key authentication; continue; } if input has a COSE_MAC tag { validate it; set input to the content; save the MAC information if needed e.g. shared key authentication; continue;} if input has a COSE_Signature tag { validate it; set input to the content; save the signer information; continue } if input is a map - return input as the set of claims; throw an exception because it is not the correct format. } This does not require a tag for a naked set of claims and would allow that set of claims to be pass in the same place as a CWT can be passed. What you are suggesting would require extra code to exist someplace that is going to check for an additional tag. It is also going to lead to people thinking that this new tag should be legal to place inside of a CWT. After all it makes more sense to always include it than to just sometimes include it. This would be more of an issue if an array rather than a map was being used to carry the claims as there would be a chance to not know what type of security wrapper exists. [JLS END] At the last RATS virtual interim there was no certainty how to approach this. So this is a call out. COSE, ACE, and CBOR, how would you approach this "unsigned CWT Claims Set" requirement? If one of the three options highlighted above is out of the question, please say so (and please elaborate on the why for the sake of helping the RATS WG understand why that is not a good idea). If one of the three options looks like a low hanging fruit & viable, please say so (and... you know the drill). I hope that this email contains all the information required to help the RATS WG in this call out to other WGs. If it does not, please say so :) Last but not least, if there are other relevant WGs or experts that could lend opinions or alternatives, let us know. Viele Grüße, Henk _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
