Hi Michael, I think 1) CMS signed JSON, containing (prior=CMS signed JSON) or 4) CMS signed JSON, containing unsigned JSON. should be the MTI. Adding CBOR instead of could be an optional thing for the future (pretty much what you say in RFC8366).
About > Also, I still am unclear if the constrained-BRSKI belongs in the > constrained-voucher document. I would sure like some clear opinions. I am of the opining to put Constrained-BRSKI in draft-ietf-anima-constrained-voucher. The reason is that they go hand in hand. The disadvantage is that then draft-ietf-anima-constrained-voucher becomes more complicated and I think that is why you folks broke down BRSKI in two documents. Now that BRSKI and Voucher are standardized though, doing both in the constrained voucher document will not be that bad. I mean, it will not defining something brand new and complicated, it will just be adjusting the two ANIMA documents in one for constrained environments. Rgs, Panos -----Original Message----- From: Michael Richardson <[email protected]> Sent: Sunday, November 25, 2018 11:06 PM To: Max Pritikin (pritikin) <[email protected]>; Panos Kampanakis (pkampana) <[email protected]>; consultancy <[email protected]>; Kent Watsen <[email protected]> Cc: [email protected] Subject: unsigned voucher requests in BRSKI * PGP Signed by an unknown key With a single signed voucher format, it's clear that if the pledge sends an unsigned voucher request that the Registrar should send a CMS signed voucher request, and ask for a CMS signed voucher. I have used the term "parboiled" for the artifact from Registrar to MASA, and "raw" for the artifact from Pledge to Registar. Not everyone liked those terms, but I used in my code. With the addition of CBOR, and COSE, we have a bunch of possibilities for the (parboiled) artifact from the Registrar to the MASA: 1) CMS signed JSON, containing (prior=CMS signed JSON) 2) CMS signed CBOR, containing (prior=CMS signed CBOR) 3) COSE signed CBOR, containing (prior=COSE signed CBOR) 4) CMS signed JSON, containing unsigned JSON. 5) CMS signed JSON, containing unsigned CBOR. 6) CMS signed CBOR, containing unsigned CBOR. I don't think we ever should be embedding JSON based artifacts inside CBOR, so there are some possibilities that I've ruled out already. Argue the point. I have up to this point assumed that 1) COSE signed CBOR pledge requests result in COSE voucher artifacts. 2) CMS signed JSON pledge requests result in CMS voucher artifacts. 3) CMS signed CBOR pledge requests result in CMS signed CBOR voucher artifacts. When the Pledge request is unsigned JSON... all we know is that it's JSON. I think that this means that the parboiled artifact should be CMS signed JSON, and it should return a CMS signed voucher to the pledge. Of course, the *MASA* knows. The Registrar can set the Accept: header to */*, and see what if understands what is returned. This seems like a poor way to get interoperable systems. Also, I still am unclear if the constrained-BRSKI belongs in the constrained-voucher document. I would sure like some clear opinions. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- * Unknown Key * 0xFDFC4290 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
