Yes that is the essence of what I am looking for in terms of dealing with a new trust point.
Jim > -----Original Message----- > From: Panos Kampanakis (pkampana) <pkamp...@cisco.com> > Sent: Monday, January 28, 2019 9:42 PM > To: Jim Schaad <i...@augustcellars.com>; ace@ietf.org > Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > Thanks Jim > > > You say that the client should use the new explicit trust anchors right after > the cacerts request, but if you do not tear down the DTLS connection you are > not doing that. You are still using the old implicit trust anchors. The MAY in > section 11.1 for me is overridden by the previous SHOULD unless this case is > specifically called out in section 7. I cannot understand the logic that says > when you get a certificate a year from now the explicit TAs SHOULD be used, > but it does not matter when you get the first certificate. > > In the draft we want to say that when you get the cacerts response start > using those as your explicit trust anchor. But we also want to say that if you > pipeline EST-coaps messages in the same connection then you MAY keep the > DTLS connection open. That has implications on the trust anchor if one of the > EST-coaps requests included a cacerts request. I am thinking that in order to > make it clearer we can add text to say that "After a cacerts you are expected > to use the new trust anchor. If pipelining is used you MAY keep the > connection open, but the client SHOULD still authenticate the server identity > received during the DTLS handshake against the new trust anchor receive in > response to a cacerts in the same connection. " What do you think? I open to > other text suggestion to convey the point as well. > > About the Examples we will address the Max-Age and Content Format in the > examples. I created new github issues for those. > > Panos > > > > -----Original Message----- > From: Jim Schaad <i...@augustcellars.com> > Sent: Monday, January 28, 2019 4:37 PM > To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; ace@ietf.org > Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > Clipping out things which are not issues: > > > > -----Original Message----- > > From: Ace <ace-boun...@ietf.org> On Behalf Of Panos Kampanakis > > (pkampana) > > Sent: Friday, January 18, 2019 12:59 PM > > To: Jim Schaad <i...@augustcellars.com>; ace@ietf.org > > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > > > Hi Jim, > > > > Again, thank you for your thorough reviews. We addressed all of them. > > The new version of the draft is at > > https://github.com/SanKumar2015/EST- > > coaps/blob/master/draft-ietf-ace-coap-est.txt > > > > For a more easily consumable content, your latest feedback was tracked > > and addressed here https://github.com/SanKumar2015/EST- > > coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+draft-ietf-ace-coap-est-07 > > > > I also lay out the changes below: > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > - About the persistent DTLS connections (Sect 7), the last two > > paragraphs > of > > section 7 explain why in some cases DTLS connections need to stay open > > for a limited amount of time. They also point to the Section 11.1 > > about the caveats of a persistent connection and the implicit DB. I do > > not think it > is up to > > this draft to tell the client that he should use the new cert after an > > enrollment. The old cert might still be perfectly valid or the new > > cert > may be > > generated for a non DTLS client auth use. So, I don't think we need to > state in > > this draft that the new cert needs to be used in new DTLS connections. > > > > - About the DTLS connections (Sec 11.1), We have usecases where a > > client does not want to spend the resources, time, performance > > implications to do > > 3-5 DTLS connections back to back in order to update its trustanchor > > and > do > > its enrollments for multiple certs. In this cases, explained in > > section 7 > last > > paragraphs will keep a persistent DTLS connection. That is what > > section > 11.1 is > > trying to explain. Please keep in mind that in there we state that it > > is RECOMMENDED for the client to start using the new explicit DB right > > after the cacerts request. We just add the MAY keep the authenticated > > with implicit DB DTLS connection open in some cases, but then he MUST > > use the new DB starting for the next DTLS connection. > > > > So, I think our language in Sections 7 and 11.1 suffices when talking > about > > persistent TLS connections. > > Any time that the set of trust anchors is changed, you have also changed the > set of things that you are going to trust. If you remove the trust anchor for > the current connection, or restrict it in some manner, you may no longer > have any trust in that connection. This is the worry that I have. I completely > agree that doing multiple certificate requests (not sure why) or a query > about the csr attributes followed by the certificate request is totally > reasonable. > > You say that the client should use the new explicit trust anchors right after > the cacerts request, but if you do not tear down the DTLS connection you are > not doing that. You are still using the old implicit trust anchors. > The MAY in section 11.1 for me is overridden by the previous SHOULD unless > this case is specifically called out in section 7. I cannot understand the logic > that says when you get a certificate a year from now the explicit TAs SHOULD > be used, but it does not matter when you get the first certificate. > > * It does not look from the version on github that you made any changes for > the examples: > > Examples: > > * Section A.1 I don't know what the meaning of Max-Age would be for a GET > request. You may want to remove this just to avoid confusion. > > * Section A.2 - I am unclear about the Content-Format note in this example. > If you are asking for a specific content then the correct option would be > Accept. If you are indicating the content type of the response then you > should probably put a header line in to that effect. > > In the virtual CoAP WG meeting last week we went through in some explicit > detail that both Content-Format and Max-Age have no meaning when > appearing on a request and therefore should not be there. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
