Subject: Re: [netconf] [lamps] [Anima] Long-lived certificates, but frequently renewed certificates

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Mar 2021 14:58:08 -0400

Nico Williams <[email-masked]> wrote:
    > On Thu, Mar 18, 2021 at 05:54:55PM +0100, Toerless Eckert wrote:
    >> On Thu, Mar 18, 2021 at 08:57:04AM -0400, Michael Richardson wrote:
    >> > It seems that a CA ought to be able to express some other kind of renewal
    >> > period directly.   Is there any work in this area?

    > Well, it's a simple certificate extension to do that.  But do RPs need
    > to see it?  It seems like the enrolment protocol should tell the holder
    > when to come back.  Still, it's simplest to stick it in the certificate
    > as an extension.  No idea if there's any work going on around that.

Yes, I agree, the RP doesn't need to know.
It could well be state somewhere during the enrollment protocol.

A pity that EST (and I think SCEP, but I haven't read it all), just returns
the resulting certificate, and not something more useful, like a JSON dict
that includes the certificate.

RFC7030 has a 202, Retry-After, which could be used to tell the holder to
go away and come back later, but the intended use is not to say not now,
but rather, "I'm working on it".

If the whole thing was more RESTful, then holders could be told to GET their
certificate from some place, and we could use ETag, and Expiry headers to
tell the holder that it hasn't changed, and isn't expected to change for
awhile, so piss off and come back then.

In the full ACP situation, then we might expect holders to have active
RESTCONF management, and then we can renew certificates in a push scenario
using draft-ietf-netconf-sztp-csr-01, which I note is now past WGLC.

    > A related idea is that an RP can want certificates to be "fresh" enough
    > regardless of when their notAfters are, and again, there's no signaling
    > that via the supplicant's certificate unless somehow the issuer is
    > expected to know a policy all RPs want.

I'm much less concerned about the RP here.
The reason to issue long lifetime certificates is that things don't break
just because some less critical infrastructure is not alive, or not reachable.

Our reference example/use case in brski-async-enroll is communication between
thermostats and furnaces in a (newly built) residence.
The furnace needs to heat keep the home above zero even when the house is not
occupied, and possibly has not yet been occupied.

Maybe abuse of the certificate renewal process is the wrong way to accomplish
transfers of ownership.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Nico Williams <[email-masked]>
Date: Thu, 18 Mar 2021 14:12:05 -0500

> that includes the certificate.

But you can always send this kind of metadata in response headers.

> awhile, so piss off and come back then.

Yes, why not.

A client that wants a certificate renewed too soon is not really a
problem, unless it's abusive.  But how would a _stateless_ CA know a
client is being abusive other than by how soon the client is back?

Still, suppose some supplicant has a valid certificate and some RP balks
and says "come back with a fresher certificate"?  What if this happens
before 50% of the original certificate lifetime is up?

I think "too soon" might best be defined as after 25% or less of the
original certificate lifetime has passed since issuance.  But then, I
don't run massively popular public online CAs.

> occupied, and possibly has not yet been occupied.

In a small enough network like a home network, I would think that
forever credentials + revocation is the best answer.

> Maybe abuse of the certificate renewal process is the wrong way to accomplish

I think next time I move I'll rip out all the thermostats and replace
them with new ones to my preference :)  But yes, I suspect there will
come a time when there are many computers (and much firmware) in a home
just as in motor vehicles, many/most/all not serviceable or replaceable
by the "owner".

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Mar 2021 20:22:44 +0100

Hiya,

> On 18 Mar 2021, at 19:58, Michael Richardson <[email-masked]> wrote:
> 

This is definitely a problem in a number of deployments.  One aspect that people have to deal with is not so much the gross expiry time, but when it is convenient to take a risk of moving to a new cert.  Of course you’re going to want to make that operation as bullet-proof as possible, but in some environments they want multiple levels of resilience.  So scheduling does become an issue.

The big question is- who does the scheduling?  Is it the end system?  Is it the EST server?  Who knows when “convenient” is?  Probably the answer is “both”.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Sat, 20 Mar 2021 14:00:21 -0400

> This is definitely a problem in a number of deployments.  One aspect
    > that people have to deal with is not so much the gross expiry time, but
    > when it is convenient to take a risk of moving to a new cert.  Of
    > course you’re going to want to make that operation as bullet-proof as
    > possible, but in some environments they want multiple levels of
    > resilience.  So scheduling does become an issue.

    > The big question is- who does the scheduling?  Is it the end system?
    > Is it the EST server?  Who knows when “convenient” is?  Probably the
    > answer is “both”.

It has to be a three phase commit, and it needs to be initiated from the EST server.
1) send out new identities and trust anchors, but continue to initiate with
   old ones.
2) do a fire drill with new identities, testing responders
3) switch to new identities, mark old identities to be removed

I really like the netconf solution.
I think that putting the EST server in charge of collecting new CSRs, and
delivering new certificates is the right way.  I argued for this back when we
were doing 6tisch-minimal-security:   on a challenged network, a stampeding
herd of elephants is very undesireable.

I would like brski-async-enroll to consider
   https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/?include_text=1
as being the collection protocol between registrar agent and pledge.

---

From: Nico Williams <[email-masked]>
Date: Sat, 20 Mar 2021 15:36:56 -0500

On Thu, Mar 18, 2021 at 08:22:44PM +0100, Eliot Lear wrote:
> that people have to deal with is not so much the gross expiry time,
> but when it is convenient to take a risk of moving to a new cert.  Of

Can you elaborate on this?  Is the issue validation path construction in
complex PKIs?

Nico
--