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

[Eliot Lear <[e-mail]>]

> On 22 Mar 2021, at 22:28, Nico Williams <[e-mail]> wrote:
> 
> 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.

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.

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

Good question.

> 
>> 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 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...

> 
> 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.

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