Subject: [Anima] unsigned voucher requests in BRSKI

From: Michael Richardson <[email-masked]>
Date: Sun, 25 Nov 2018 23:06:27 -0500

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-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 26 Nov 2018 08:55:03 +0100

HI Michael,

"Also, I still am unclear if the constrained-BRSKI belongs in the
constrained-voucher document.  I would sure like some clear opinions."

I like to react but do not understand the question.
What is constrained-BRSKI?
Is the proposal to split the constrained voucher document into two
documents?
- one describing the constrained voucher,
- one describing the voucher functionality extension to EST?

I am not clear what the advantage is of having two documents.
The disadvantage is clear: 2 is more difficult than 1.

Peter