Subject: Re: [Anima] unsigned voucher requests in BRSKI

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 6 Dec 2018 21:49:22 +0000

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-masked]> 
Sent: Sunday, November 25, 2018 11:06 PM
To: Max Pritikin (pritikin) <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>; consultancy <[email-masked]>; Kent Watsen <[email-masked]>
Cc: [email-masked]
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-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

* Unknown Key
* 0xFDFC4290

---

From: Michael Richardson <[email-masked]>
Date: Sat, 08 Dec 2018 19:11:31 -0500

> 4) CMS signed JSON, containing unsigned JSON.

So, in the unsigned pledge request, you feel that the pledge request needs to
go up to the MASA?

It is not clear from the document that anything of the pledge requests goes
upwards.

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 11 Dec 2018 03:38:21 +0000

Hey Michael, 
I was assuming it was mandatory in the current draft, but I was wrong. As you suggest it is not clear in the -17 version. I do think that an unsigned voucher should make it to the MASA, like a signed one would, for consistency. 
Panos

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Saturday, December 08, 2018 7:12 PM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Cc: Max Pritikin (pritikin) <[email-masked]>; consultancy <[email-masked]>; Kent Watsen <[email-masked]>
Subject: Re: unsigned voucher requests in BRSKI

> 4) CMS signed JSON, containing unsigned JSON.

So, in the unsigned pledge request, you feel that the pledge request needs to go up to the MASA?

It is not clear from the document that anything of the pledge requests goes upwards.

* Unknown Key
* 0xDDD0DD65

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Dec 2018 17:23:02 -0500

Panos Kampanakis (pkampana) <[email-masked]> wrote:
> I was assuming it was mandatory in the current draft, but I was wrong. As
> you suggest it is not clear in the -17 version. I do think that an unsigned
> voucher should make it to the MASA, like a signed one would, for
> consistency.

okay, I'm glad that we agree that it should be consistent.

I'm not convinced it's worth having unsigned pledge requests at all.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 11 Dec 2018 23:26:55 +0000

> On Dec 11, 2018, at 3:23 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Sadly I think we still have to respect folks that are worried about the extra crypto operations on the pledge. Particularly given the size/complexity of a CMS signature. IF we’d gone with a jwt/cwt signature I’d be more open to “just sign everything”. 

I respect the desire to forward the unsigned request “for consistency” but disagree. My reasoning is that the unsigned request is *not signed* and therefore can NOT provide any value to the MASA. As such including it in the messages is simply additional overhead and opportunity for a MASA to mess up and, for example, use the nonce from it even if the Registrar doesn’t want a nonce (or other weird bugs that would be difficult to notice until they were a pain). 

- max

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Dec 2018 10:04:59 -0500

Max Pritikin (pritikin) <[email-masked]> wrote:
> Sadly I think we still have to respect folks that are worried about the
> extra crypto operations on the pledge. Particularly given the
> size/complexity of a CMS signature. IF we’d gone with a jwt/cwt signature
> I’d be more open to “just sign everything”.

Okay, but constrained vouchers signed with COSE?
We weren't sure we'd have that when we did the unsigned pledge request.

> I respect the desire to forward the unsigned request “for consistency” but
> disagree. My reasoning is that the unsigned request is *not signed* and
> therefore can NOT provide any value to the MASA. As such including it in
> the messages is simply additional overhead and opportunity for a MASA to
> mess up and, for example, use the nonce from it even if the Registrar
> doesn’t want a nonce (or other weird bugs that would be difficult to notice
> until they were a pain).

I definitely see your point.