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 =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
