Subject: Re: [Anima] [lamps] 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
--

---

From: Eliot Lear <[email-masked]>
Date: Sun, 21 Mar 2021 10:27:00 +0100

[Reducing]

Hi Nico,

> On 20 Mar 2021, at 21:36, Nico Williams <[email-masked]> wrote:
>> 

Mostly not.  There are two objects that have to be addressed:

Device LDevID expiration and update.
Trust Anchor roll.

The Second case is generally easier, so long as the device is regularly in service; and it may even be easy when the device is out of service for extended periods (think years) so long as it is thought about in advance by both implementor and deployment.

The LDevID change out is harder.  A device can have many trust anchors, but the LDevID change-out has to be handled a bit more carefully.

And how this happens may well vary.  Let’s consider several use cases:

An electrical substation, in which the device is expected to remain in service for perhaps two decades without an outage.  In this case, the updates have to occur in service.
A hospital bed.  In this case, the device will be out of service as often as in, and updates can occur when it is out of service.
A railroad box car/container.  These things are expected to run on battery without maintenance for five years, and may sit idle for weeks or months without any connectivity.  This case is extremely tough and is a bit of a stretch goal.

Each of these sorts of examples occurs in nearly every vertical.  One question is whether scheduling should be in protocols like EST or in device configuration.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 21 Mar 2021 10:30:09 +0100

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

See my answer to Nico.  The EST server certainly knows when it wants to roll the information.  But doing so in the middle of a heart bypass operation is not something it should decide.  Once the decision is made, however, the three phase commit sounds good,

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Mar 2021 20:01:06 -0400

> See my answer to Nico.  The EST server certainly knows when it wants to
    > roll the information.  But doing so in the middle of a heart bypass
    > operation is not something it should decide.  Once the decision is
    > made, however, the three phase commit sounds good,

Yes, you are completely correct.
So, the device clearly needs also be able to decline to do the roll-over, or at
least, to decline to change any connections.

Similarily, you likely never want any of your mobile devices (whether phones
or automobiles) to perform any kind of update when you are away from home.

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Mar 2021 16:28:42 -0500

> [Reducing]

[Whenever possible]

> The Second case is generally easier, so long as the device is
> regularly in service; and it may even be easy when the device is out
> of service for extended periods (think years) so long as it is thought
> about in advance by both implementor and deployment.

End entities send a validation chain for their EE certs, but not the
root CA's cert, and anyways, RPs need to know trust anchors a priori.
Therefore rolling out new TAs is tricky.

TA rollover needs a device update protocol.  Which is a pain in large
part because it's completely unstandardized and anyways implies a
separate trust structure for update signing (e.g., a package signer
PKI).

Maybe the chains should always have included the roots so that rollover
could have been handled via the old one signing the new one.  Or maybe
we need an extension like AuthorityInfoAccessSyntax (or maybe just use a
URI issuerAlternativeName?) to indicate rollover information for roots
that can be used by RPs to update trust anchors (again, with
old-signs-new or with a signature by some separate PKI as in the
packaging case).

(Speaking of uniformResourceIdentifier type issuerAltNames, what are
their semantics?  If RFC5280 covers that, I've missed it.)

> The LDevID change out is harder.  A device can have many trust
> anchors, but the LDevID change-out has to be handled a bit more
> carefully.
>
> [...]

Yes, devices can have considerations that an EST server may not be able
to know.

So I think we're talking about the server indicating a refreshAfter time
or a doNotRefreshBefore time rather than a refreshAt time.  An
informative "you can refresh after this $time" and maybe a normative "do
not even think of refreshing before this $time".

That said, a simple certificate refresh where no algorithms change, no
parameters change, no critical extensions are added, etc. -- where the
only real change is the validity period -- surely this is safe to
perform whenever the device can talk to the online CA.  One could argue
that making sure that the only change is the validity period (and maybe
the SPKI, but not its alg or params) is difficult to ensure.  Michael
tells me maybe the CA software gets upgraded and other changes sneak in
that one did not expect.

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Mar 2021 07:46:53 +0100

> On 22 Mar 2021, at 22:28, Nico Williams <[email-masked]> wrote:
> 

The presumption we make in the enterprise is that distribution of TAs in services happens as a matter of normal system management.  Absent those TAs the service is going to experience a whole lot of failures.  At the application level beyond the bounds of the enterprise, this is a different matter, to be sure.

> 
> TA rollover needs a device update protocol.

Within the bounds of the enterprise, that’s EST (RFC 7030).  See Section 4.1.2 “/cacerts”.  This delivers a PKCS#7 pack of certs.  RFC 8951 modestly amends that.

> their semantics?  If RFC5280 covers that, I've missed it.)

Good question.

> not even think of refreshing before this $time".

That covers one case.  Another case that has to be covered is when there’s a need for an unscheduled rollover.  This might happen if there was some concern that a private key has been compromised.  And then...

> tells me maybe the CA software gets upgraded and other changes sneak in

Well, and we haven’t even begun to discuss secure time stamps here (you can track some recent discussion of that discussion on the openssl-users list).  And you’re hitting another issue- stuff like RFC 4476.  I don’t know how widely that extension is found, but there are others; and there is something of a debate in some circles about whether to do RBAC et al in certs.

And so an occasional query also seems appropriate.  EST doesn’t really define that.

Eliot

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Mar 2021 09:19:35 -0400

>> their semantics?  If RFC5280 covers that, I've missed it.)

It is a URI, including both a scheme (e.g., "http" or "ftp") and a scheme-specific-part, that can be used to communicate with the subject of the certificate.

Russ

---

From: Nico Williams <[email-masked]>
Date: Tue, 23 Mar 2021 09:49:35 -0500

On Tue, Mar 23, 2021 at 07:46:53AM +0100, Eliot Lear wrote:
> Within the bounds of the enterprise, that’s EST (RFC 7030).  See
> Section 4.1.2 “/cacerts”.  This delivers a PKCS#7 pack of certs.  RFC
> 8951 modestly amends that.

Sure, but there's still a bootstrap issue that will be solved with
packaging (in the enterprise).

> > their semantics?  If RFC5280 covers that, I've missed it.)

I was hoping someone here would know the answer :)

Maybe EST (and any CA-relevant protocol that can be discovered through
/.well-known) could be used to provide semantics for http/https scheme
URI issuerAltNames.

> That covers one case.  Another case that has to be covered is when
> there’s a need for an unscheduled rollover.  This might happen if
> there was some concern that a private key has been compromised.  And
> then...

And then?  Well, then you need a field update, possibly by sending out a
technician.  Firmware and software have eaten the world, and just as we
have to trim vegetation under power transmission lines and so on, we
must update devices in the field.  Currently this seems infeasible just
on account of abandonware (of which we'll have more and more), let alone
cost for non-abandonware.

> Well, and we haven’t even begun to discuss secure time stamps here
> (you can track some recent discussion of that discussion on the
> openssl-users list).  [...]

Oh, you're concerned that a device might get a postdated certificate or
something?  Why would a CA issue a postdated certificate?  Or perhaps
RPs won't have access to secure time services and so they may observe a
valid certificate as invalid?  But I think secure time is an orthogonal
concern and it is present even in the absense of certificate rollover.

You could say that super-long-lived certificates don't have this
problem, but they have other problems.  And lacking secure time will
hurt devices in other unrelated ways.  The trade-off is validity period
length vs CRL size and online OCSP infrastructure requirements, and if
the choice made by implementors is long-lived certs w/ no revocation
then costly manual field updates will be needed in the event of
compromise.

I'm not keen on recommending very long-lived certificates for devices
just because of the potentially difficult rollover circumstances.

>               [...].  And you’re hitting another issue- stuff like RFC
> 4476.  I don’t know how widely that extension is found, but there are
> others; and there is something of a debate in some circles about
> whether to do RBAC et al in certs.

Rolling of ACs is relevant.  I'm not sure how much ACs get used in any
of these devices.  In the enterprise I've yet to see any AC use.
Haven't authorization token systems won out anyways?

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Mar 2021 11:49:23 -0400

> Therefore rolling out new TAs is tricky.

TLS discourages sending the root CA cert.
I prefer to send it for a number of reasons, and this is one of them.

    > separate trust structure for update signing (e.g., a package signer

EST includes includes updating the CA trust anchors as a protocol item.
We don't have to have to replace the firmware.

    > not even think of refreshing before this $time".

Yes, that's exactly what I'm after.
We can, as you suggest, do this as an HTTP header in EST.
It could also go into some new certificate extension, although it's rather
more meta data, and it isn't clear it should get shared with peers.

    > Michael

So, I was thinking of a hypothetical that could result in a surprising change
in the field during what should be a non-event renewal.

---

From: Nico Williams <[email-masked]>
Date: Tue, 23 Mar 2021 11:06:24 -0500

> I prefer to send it for a number of reasons, and this is one of them.

You can only send them when they are available as certificates (which
TAs are not required to be).  But +1.

> We don't have to have to replace the firmware.

Yeah, I know, but in the enterprise we still use packages, though not
necessarily packages with software, just configuration.

> more meta data, and it isn't clear it should get shared with peers.

Well, I suppose there one more way.  I asked about the semantics of URI
issuerAltNames, and maybe the right answer is that /.well-known for the
base URI should let you discover... lots of things, like EST, and...
this.

>     > Michael tells me maybe the CA software gets upgraded and other
>     > changes sneak in that one did not expect.
> 

I agree it's possible, likely even.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 23 Mar 2021 18:44:01 -0500

> more meta data, and it isn't clear it should get shared with peers.

Hmmm, but maybe it is worth sharing with the peers if they could alert
about a device with a yet valid cert that way out of renewal policy.

That could be an extension saying "holder is expected to renew every
$fraction of (notAfter - notBefore)".

Not that RPs should log _every_ time they see a peer with a certificate
that's out of renewal policy, but that it could be useful to warn when
doing so doesn't risk filling logs with useless information.

In a hospital, for example, devices could have a warning light for when
they need maintenance or when their peers need maintenance.

Nico
--