PKI Engine - CRLNumber + Reason

Vault
1

Hi,
Vault : Version 1.1.3

  1. I have been issuing some CRL and did not see the CRLNumber in the certificate ? Is there any configuration steps to perform ?
  2. Is there any option to integrate the Reason in the revocation too ?

Thanks for your help.

2

My understanding is that Vault is now not compliant to the RFC regarding CRL ? Am i correct ?
Thanks

3

Hi @BrunoP-dev,

Can you explain why you think it isn’t RFC compliant? As far as we know it is compliant.

4

Hi, as explain I did not see the CRLNumber in the CRL or i missed some configuration steps.

The RFC mentioned:

The CRL number is a non-critical CRL extension that conveys a
monotonically increasing sequence number for a given CRL scope and
CRL issuer. This extension allows users to easily determine when a
particular CRL supersedes another CRL. CRL numbers also support the
identification of complementary complete CRLs and delta CRLs. CRL
issuers conforming to this profile MUST include this extension in all
CRLs and MUST mark this extension as non-critical.

Do you know a way to integrate CRLNumber and/or the recovation reason ? thanks

5

That text refers to v3 CRLs, which support extensions. We do not use any extensions and generate v2 CRLs, which are not required to (and cannot) include extensions, including CRL number.

6

Hey mate, it’s all right. i just asked if there is a way to set it up the way to be compliant to PKI practices. no worries. Hopping someone in HC will fix it. Cheers.

7

(Just to be clear, in my last post, I meant v2 and v1 respectively. Also, I am at HC and the main maintainer of the PKI secrets engine.)

A few things:

  • Technically we’re non conforming because the RFC says if a CA is issuing CRLs it must be v2.
  • Revocation reason is not a required field for v2 CRLs – only nextUpdate, CRL number, and authority key identifier.

However, one issue with the first bullet point is that we don’t issue CRLs on a schedule. The backend was really designed to work well with short-lived certificates, and our CRL support is really meant to support CRLSets style approaches. There is a lot of information about there about the problems with traditional CRL approaches, which I won’t go into, but we can’t tell you when the next update will be because we generate CRLs as certificates are revoked. If there is no new revocation, there is no reason to generate a new CRL, so we don’t.

The nextUpdate field encourages polling at fixed intervals, which is a large part of the problem with CRLs in the first place – caching and soft failing. The CRLSets approach, which is what the major browser vendors are using (along with Certificate Transparency), pushes CRLs to clients instead and has them do the lookups locally. This eliminates soft-fail issues and caching is fully at the discretion of the operator and how often they want to push out new CRLs. It also means that v1 CRLs are essentially sufficient because you can ensure that the authority key is in the local trust store and you aren’t promising a nextUpdate time that you aren’t sure you’ll keep. Security and simplicity in one.

Of course, all this is worked around in many cases by simply having short lived certificates and not using CRLs (which is the idea behind the design of the PKI engine in the first place). I realize that in some cases it’s hard to transition software over to consuming lots of certificate changes but it’s by far the most secure approach. It’s way better to never have to worry about when the CRL changes because you change your certificates at a faster interval than you would have used for CRL checking (or soft failing, or caching, or pushing out) in the first place.

Another issue is that right now Go doesn’t support creating v2 CRLs. I’ve opened an issue to track that (https://github.com/golang/go/issues/35428) but they may or may not accept it.