[lamps] Re: AD initial comments on draft-ietf-lamps-crl-validation

[Corey Bonnell <[e-mail]>]

Hi Deb,

No apology needed, you had quite a bit going on last week! Thanks for the follow-up feedback. I incorporated your feedback from this morning’s email and last week’s email in this PR: https://github.com/CBonnell/lamps-keyusage-crl-validation-clarification/pull/3/files.

 

Comments:

 

> Section 4, New:  I would make this 'MUST verify'.  I like the addition of v3 to the requirement. 

 

It appears that most of section 6 is written in the imperative form. If we switch “verify” to “MUST verify”, we’ll need a noun and not use the imperative form to make the change grammatical. As a result, this change will not flow with the rest of the steps in section 6. For that reason, I’d prefer to keep the language as-is, but I can change it if you feel strongly that it should be changed.

 

> esoteric, indeed, and it buries the lead.  Perhaps move it down before the example

 

Thanks, I did this and agree that it reads better.

 

Thanks,

Corey

 

From: Deb Cooley <[e-mail]> 
Sent: Monday, November 10, 2025 7:56 AM
To: Corey Bonnell <[e-mail]>; [e-mail]
Cc: LAMPS Chairs <[e-mail]>; LAMPS WG <[e-mail]>
Subject: Re: AD initial comments on draft-ietf-lamps-crl-validation

 

Thanks for the reply, apologies for the delay in responding.  My replies are inline below w [DC]

 

One further comment (to finish my review)

 

Section 4, New:  I would make this 'MUST verify'.  I like the addition of v3 to the requirement. 

 

Deb

 

On Mon, Nov 3, 2025 at 10:02 AM Corey Bonnell <[e-mail] <mailto:[e-mail]> > wrote:

Hi Deb,

Thanks for your comments. Replies inline.

 

> General:  Is this correct?  The general concern is that RFC 5280 requires CAs to include the key usage extension when creating a certificate that is meant to sign CRLs.  But there is no requirement for the RP to validate that the key usage extension is on a certificate that has been used to create a CRL.  

 

Yes, this is a correct summary.

 

> What about a similar situation with certificate signing? I see in section 4.2.1.3 the requirement for the CA to use a key usage extension, but I see Section 6.1.4.n. that says: 'If a key usage extension is present, verify that the keyCertSign bit is set.' which looks similar to the CRL situation.  What am I missing?  

As you note, there is also no corresponding check for keyCertSign in CA certificates. However, there is an independent check for cA: true in Basic Constraints in section 6.1.4 (k). Given that cA: true is a required element of CA certificates, there is no possibility of an RP trusting a v3 end-entity certificate as a CA certificate.

 

[DC]  ahhh, I missed that one.

 

> This leads me to one question:  Does this specification need to be broadened to include the case of a bogus CA where a TA (or CA) has signed a cert that has no key usage extension?

 

Given the requirement to include cA: true for the issuer and check for this value by the consumer, I don’t believe this draft needs to address this.

 

[DC] agreed.   

 

> Specific comments:

 

Thanks for the suggestions on improving the Abstract. Will integrate your feedback.

 

> Section 3:  Some ideas of how to simplify/clarify the CRL validation issue.
> a.  Para 2&3:  How important is it to understand indirect CRLs vs direct CRLs?

 

Given that indirect CRLs are a rather esoteric part of PKIX, I thought a summary would be useful to the reader. We can delete if we feel the text is not useful.

 

[DC]  esoteric, indeed, and it buries the lead.  Perhaps move it down before the example, maybe:   "This step does not explicitly specify a check for the presence of the keyUsage extension itself for either direct or indirect CRLs (see RFC5280, section 5.3.3 for information on indirect CRLs)'.  This is just an option, and there might be a better reference, or a better place, or better words. 

 

 

> c.  Para 6 is fine, the quote doesn't appear to support the para above.  I would remove the quote.

 

Thanks, I’ll remove the quote.


> d.  The example is horribly complicated. 
>   - It can be much simpler:  A CA issues a certificate w/out a key usage extension, that private key is used to generate a bogus CRL, and voila we have an issue.  
> - I have not included CRL DP.

 

Section 6.3.3 of RFC 5280 (the CRL validation routine) is written with the assumption that CRL DP is present. Although the example is complex, I’m concerned that by removing the CRL DP bits, we make it harder for the reader to understand the issue.

 

[DC] on a second read, I do agree.  The issue is two certificates w/ the same subject, issued by the same issuer where one has the extension and the other does not. 

 

 

> But why not MUST use v3 and KU?  why only RECOMMEND?

 

We were thinking that there might be PKIs where it is not possible to align with the RFC 5280 profile and we can give guidance to those PKIs to mitigate the issue. If we don’t care about those PKIs, we can strengthen this to a MUST. 

 

Thanks,

Corey

 

From: Deb Cooley < <mailto:[e-mail]> [e-mail]> 
Sent: Sunday, October 26, 2025 2:16 PM
To:  <mailto:[e-mail]> [e-mail]
Cc: LAMPS Chairs < <mailto:[e-mail]> [e-mail]>; LAMPS WG < <mailto:[e-mail]> [e-mail]>
Subject: Re: AD initial comments on draft-ietf-lamps-crl-validation

 

Apologies for the subject line....  it obviously should be draft-ietf-lamps-keyusage-crl-validation.  Sigh....

 

Deb

 

On Sun, Oct 26, 2025 at 2:12 PM Deb Cooley <[e-mail] <mailto:[e-mail]> > wrote:

Huzzah!  a draft I understand (I might be a touch rusty).  These are only initial comments, I will have more once I understand the real scope of this draft.

 

 

General:  Is this correct?  The general concern is that RFC 5280 requires CAs to include the key usage extension when creating a certificate that is meant to sign CRLs.  But there is no requirement for the RP to validate that the key usage extension is on a certificate that has been used to create a CRL.  


What about a similar situation with certificate signing? I see in section 4.2.1.3 the requirement for the CA to use a key usage extension, but I see Section 6.1.4.n. that says: 'If a key usage extension is present, verify that the keyCertSign bit is set.' which looks similar to the CRL situation.  What am I missing?  

This leads me to one question:  Does this specification need to be broadened to include the case of a bogus CA where a TA (or CA) has signed a cert that has no key usage extension?

Specific comments: 

Abstract:  Add a specific sentence that states that this specification updates RFC 5280.  Normally, this is at the end of the abstract.

Abstract:  This sentence isn't really clear.  CRL validators can be RPs...  The introduction states

 this more clearly.  Maybe use that language for the Abstract (with the sentence about updating RFC 5280).


Section 3:  Some ideas of how to simplify/clarify the CRL validation issue.
a.  Para 2&3:  How important is it to understand indirect CRLs vs direct CRLs?
b.  Para 4&5:  Keep this.  It is clear and explains the issue.
c.  Para 6 is fine, the quote doesn't appear to support the para above.  I would remove the quote.
d.  The example is horribly complicated. 
   - It can be much simpler:  A CA issues a certificate w/out a key usage extension, that private key is used to generate a bogus CRL, and voila we have an issue.  
   - I have not included CRL DP.
 
I'll have more comments once I understand more about what is necessary.  I have not even looked at Section 4 & Section 5. But why not MUST use v3 and KU?  why only RECOMMEND?

Deb