Subject: Re: [Ace] WGLC comments draft-ietf-ace-coap-est-07

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jan 2019 10:12:55 -0500

Jim Schaad <[email-masked]> wrote:
    > Section 11.1 - When changing from the implicit trust anchor to explicit
    > trust anchors, do you expect that the est server that you are going to
    > be talking to is generally going to change?  I think that it should
    > probably be recommended that the DTLS connection NOT be persistent
    > across a change in the trust anchors if they are different.

I'm trying to understand the question better.

To be clear:
   - implicit trust anchors -- what the device was built with.
   - explicit trust anchors -- what is returned from /cacerts|/crts

So after calling /cacerts, the client now can authenticate an EST server
with the domain registrar.  Beforehand, it has to use something built-in.

I think you are asking about whether or not the server identification
(certificate) is different in the two cases?  If we could be sure that
a different EST server would be used for renewals of the certificate
(LDevID), then that EST server could have a locally anchored certificate.

I don't think we want to force this change of servers so the we must be
prepared for a single EST server to do both initial enrollment and also
renewal.

@Hannes, it would be good to have your opinion here.

This problem can be solved with correct use of SNI extension in DTLS,
but it is unclear how much detail we need to be explicit about.

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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 15 Jan 2019 10:10:39 -0800

> -----Original Message-----
> From: Michael Richardson <[email-masked]>
> Sent: Tuesday, January 15, 2019 7:13 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: WGLC comments draft-ietf-ace-coap-est-07
> 
> 
with
> the domain registrar.  Beforehand, it has to use something built-in.

The question I was asking was more about the original enrollment rather than
renewal although it could come into question there as well.

- I have the implicit trust anchors and get a EST server URL.
- Call /cacerts
- I now have the explicit trust anchors but potentially have the same EST
server URL.
- Given that I have a NEW trust anchor, what do I do with the current DTLS
session?
- I now do an enrollment with the EST server to get a certificate.

One can say it is fine to use the implicit TA for that enrollment, but one
could also say that as the certificate chain is now different then the DTLS
session should be released and a new one established.

Jim

> (certificate) is different in the two cases?  If we could be sure that a
different
> EST server would be used for renewals of the certificate (LDevID), then
that
> EST server could have a locally anchored certificate.
> 
> This problem can be solved with correct use of SNI extension in DTLS, but
it is
> unclear how much detail we need to be explicit about.
> 
> --

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jan 2019 15:25:39 -0500

Jim Schaad <[email-masked]> wrote:
    > The question I was asking was more about the original enrollment rather
    > than renewal although it could come into question there as well.

    > could also say that as the certificate chain is now different then the
    > DTLS session should be released and a new one established.

I think that the purpose of calling /cacerts is to get context for living
within the network.  I think that one continues with enrollment with the
same connection.  Restarting it might not actually work.

The resulting certificate should validate with the set of trust anchors
provided, and the anchors should let the client validate other clients.