-----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Henk Birkholz Sent: Wednesday, March 4, 2020 2:33 PM To: Jim Schaad <i...@augustcellars.com>; r...@ietf.org; ace@ietf.org; c...@ietf.org Subject: Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
Hi Jim, I'll take a stake into my heart for the group then :) Please note that I claim that there is no evidence that I am a vampire nor that I am the provenance of option 1.). [JLS] Please note I was planning on staking the idea not the person, I was just going to de-credential you. However that does raise the question should I bring salt and a sewing kit (mummies) or a gun with a silver bullet (werewolves)? I tried to phrase the output of the last virtual interim as neutral as possible and I think your reply is to be categorized as: Option 1.) is "out of the question" as a reply from a COSE WG chair. [JLS] That would be the COSE author and ACE and CBOR WG chair. I am not a COSE WG chair. However, I guess I hit all three asks. Viele Grüße, Henk On 04.03.20 22:42, Jim Schaad wrote: > 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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
