Re: [Lake] spt review of echoc-12

[Sean Turner <[e-mail]>]

Hi I pruned out the “done” ones and removed them from this response. I wanted to close the loop on some of the others, which frankly mostly appeared to be my misunderstanding.

> On Jan 11, 2022, at 03:55, Göran Selander <[e-mail]> wrote:
> 
> s3.2/s3.5.2 (question): Smarter people than I have devised plans to allow mixing of different METHODs. How does this impact the key usage extension present in certificates? In other words, are METHODS 1 and 2 suggesting that a DS and DH key be used together and does that violate any kind of restrictions on the key usage settings for certificates?
>  
> [GS: Note that the METHODs are not mixed, and that a given METHOD has fixed authentication method for each endpoint (i.e. Initiator authenticate in one way, R in another). Since there is a fixed authentication method in each direction I don't think this causes any problem: Key usage remains well-defined for each peer. Or perhaps I misunderstood the comment?
> ] 

Nope that explains it.

> [GS: firsta a preliminary note on 3.5; Stephen's review included a proposal to shorten this section and issue #223 also comments on this section, so there will be subsequent changes besides what is proposed here]

Okay I can re-review when it’s shortened up.

> s3.5.1, 1st bullet (question): This seems like the “mixing” discussed in s3.2, relies on the identity provide in the certificate?
> 
>     The certification path provides proof that the
>     subject of the certificate owns the public key in the certificate.
> 
> [GS: I didn't understand this comment. As mentioned in the response to the comment on s3.2, mixing is not with respect to a single endpoint. With that in mind, does the comment still apply?
> ]

I think you can safely ignore this one ;)

> s3.5.3 (question): EDHOC seems to assume you only provide the reference for the initiator's/responder’s. Was there any thought it to providing references for the rest of the certification path up to but not including the Root CA’s certificate? I mean technically they can also be in there certificate provided so not necessarily needed.
> 
> [GS: I'm not sure I understand the comment. I assume the question is aboutinitiator's/responder’s *end-entity certificate* (since you speak of "the rest of the certification path" in the next sentence). Note that references can be to the entire certificate chain, see x5u in:
> https://cose-wg.github.io/X509/draft-ietf-cose-x509.html#name-x509-cose-header-parameters
>  
> (Incidently, this third option is missing from the latest submitted version of that draft!)
> ]

I was thinking about how CMS has a bag of certs and how S/MIME says send up to but not including the root. The x5u, as you noted, serves the same purpose. You can safely ignore this comment.

> s3.8 (comment): Wow .. so you can send in the CSR in EAD, if it works then you can use the cert in the later messages (e.g., kind of like EAP)? Sure hope there’s no kind of CSR-related error. And, you know that the CA gets to decide the name right. Sorry just trying to digest it all.
> 
> [GS: We discussed this in the LAKE interim where you participated, but just for the record: Yes, the intent is to be able to send CSR in EAD. This is expected to be detailed in an accompanying specification. One example would be the enrolment of an "operational" certificate as an add-on to initial authentication, the authentication of which could be performed using a manufacturer certificate included in the device from factory.
> ]

Yeah I remember I was there. As long as your consider what to do when you get an enrollment error this will be fine to do.

> 
> s5.2.1, s.5.3.1, s5.4.1, s5.5.1 (nit): is the “,” before the closing bracket right? e.g.,
> 
> OLD:
> 
>     ? EAD_1 : ead,
> }
> 
> NEW:
> 
>     ? EAD_1 : ead
> }
> 
> [GS: This is accepted by CDDL syntax so we kept it for simplicity. Previously I used to trim off these last commas, but when we changed order of parameters or added parameters we always forgot some comma. Less so if all lines end with one. I propose to keep this unless someone has a strong opinion not to.
> ]

I’d leave it if it works. No strong objection on my part.
> s6.2 (nit): It’s really more “Freeform” than unspecified right? I mean the string is required so it’s definitely not unspecified per se.
> 
> [GS: Hmm. The error format is specified but the actual error is not specified. I changed to "Unspecified Error", is that better?
> ]

Yes I think that’s a better way to describe it.
> s6.3.2/s5.2.1 (nit): Might be worth noting earlier that SUITES_R is not important.
>  
> [GS: I guess you mean that *the order of suites* in SUITES_R is not important, right? :-) This is noted at the end of section 6.3.0 (i.e. before 6.3.1) which is the paragraph where SUITES_R is introduced, so couldn't really be noted earlier unless we also move the description of SUITES_R. But I made that statement into a standalone paragraph to highlight that it applies to all cases when SUITES_R is used: "In contrast to SUITES_I, the order of the cipher suites in SUITES_R has no significance."
> ]

And there I missed it ;)

>  s8 (question): Isn’t some kind of consideration needed to address the use of PSKs shared by more than two? See RFC 8773 for some considerations wrt to group key sharing and that sharing impact on authentication.
> 
> [GS: I didn't understand this comment. PSK is explicitly out of scope of EDHOC (only mentioned when that is stated). Were you thinking of group communication protected with OSCORE? In that case, EDHOC is not used but there is the body of work in ACE including draft-ietf-ace-key-groupcomm-oscore.
> ]

You’re confused. I think it was me. You can safely ignore this one.

Cheers,
spt