Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation
draft-ietf-lamps-keyusage-crl-validation-04

[Ballot comment]
Thanks for the discussion on 5280 and the security issue I raised, and for pointing out that such setup was already technically incorrect.
I have updated my ballot to Yes

[Ballot discuss]
Like Mahesh, I am a bit nervous about what is expected to happen if the keyUsage extension is not there? I think this document means to say "That was not a valid CRL signer, so this should not be treated as a valid CRL entry". But this could potentially be happening right now in what up to this document's publication is a valid CRL setup that does not use a keyUsage extension. Should there perhaps be some Operational Considerations on how to handle these? Or is it the WG's opinion that any such CRL signers were broken and it is justified to treat these CRLs as invalid? Could such discarding of a CRL not lead to a security issue (eg a compromised private key is being decommissioned with a CRL but now the CRL is ignored because of a missing keyUsage, and the compromise is not contained via the CRL mechanism)

[Ballot comment]
Section 4, paragraph 5
>    _OLD:_
>
>      (f) Obtain and validate the certification path for the issuer of
>      the complete CRL.  The trust anchor for the certification path
>      MUST be the same as the trust anchor used to validate the target
>      certificate.  If a keyUsage extension is present in the CRL
>      issuer's certificate, verify that the cRLSign bit is set.
>
>    _NEW:_
>
>      (f) Obtain and validate the certification path for the issuer of
>      the complete CRL.  The trust anchor for the certification path
>      MUST be the same as the trust anchor used to validate the target
>      certificate.  If the version of the CRL issuer’s certificate is
>      version 3 (v3), then verify that the keyUsage extension is present
>      and verify that the cRLSign bit is set.

While the NEW statement goes further in its clarification, it is not obvious what happens if the keyUsage extension is NOT present. As is, and per the Security Considerations section, the fact that the extension is included in only RECOMMENDED and is not a MUST opens up the possibility that it may not be present.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

These URLs in the document did not return content:

* https://CBonnell.github.io/ietf-lamps-keyusage-crl-validation-clarification/draft-ietf-lamps-keyusage-crl-validation.html

Section 3, paragraph 11
> certificates signed in step 2. 5. Relying parties download the CRL published
>                                  ^^^^^^^
The verb "rely" requires the preposition "on" (or "upon").

Section 4, paragraph 5
> Section 4.2.1.3 of [RFC5280], then relying party applications that have implented
>                                    ^^^^^^^
The verb "rely" requires the preposition "on" (or "upon").

[Ballot comment]
Thanks to the authors and the WG for their work on the document.

I have only one editorial comment to offer. The abstract and the introduction sections are nearly identical. The abstract should be short and self contained to give an overview of the document. Reference to RFC 5280 which this document updates is appropriate in the abstract, but at references to specific sections seem inappropriate. Please consider rephrasing the abstract without those section references?

[Ballot comment]
Hi Corey, Tadahiko, and Tomofumi,

Thank you for the effort put into this document.

I only have few nits that I submitted as a PR for authors convenience [1].

Cheers,
Med

[1] https://github.com/CBonnell/lamps-keyusage-crl-validation-clarification/pull/4

The following Last Call announcement was sent out (ends 2025-12-03):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-lamps-keyusage-crl-validation@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, spasm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Clarification to processing Key Usage values during CRL validation) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: -
'Clarification to processing Key Usage values during CRL validation'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-12-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  RFC 5280 defines the profile of X.509 certificates and certificate
  revocation lists (CRLs) for use in the Internet.  Section 4.2.1.3 of
  RFC 5280 requires CRL issuer certificates to contain the keyUsage
  extension with the cRLSign bit asserted.  However, the CRL validation
  algorithm specified in Section 6.3 of RFC 5280 does not explicitly
  include a corresponding check for the presence of the keyUsage
  certificate extension.  This document updates RFC 5280 to require
  that check.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-keyusage-crl-validation/



No IPR declarations have been submitted directly on this I-D.

Shepherd Write-up for draft-ietf-lamps-keyusage-crl-validation-02


(1) Does the working group (WG) consensus represent the strong
concurrence of a few individuals, with others being silent, or did it
reach broad agreement?

  There is support for this document in the LAMPS WG.

(2) Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

  During the WG Last Call there was a very active discussion in late
  June 2025, and the modifications made to the document reflect the
  consensus that was reached.
 
(3) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal or indicated any discontent.

(4) For protocol documents, are there existing implementations of the
contents of the document?  Have a significant number of potential
implementers indicated plans to implement?  Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  It is clear that several people already implement this document.

(5) Does this document need review from other IETF working groups or
external organizations?  Have those reviews occurred?

  None needed.

(6) Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
reviews.

  The document discusses the ASN.1 in RFC 5280, but no new ASN.1
  definitions are needed.

(7) If the document contains a YANG module, has the final version of the
module been checked with any of the recommended validation tools for
syntax and formatting validation?  If there are any resulting errors or
warnings, what is the justification for not fixing them at this time?
Does the YANG module comply with the Network Management Datastore
Architecture (NMDA) as specified in RFC 8342?

  YANG is not used in the document.

(8) Describe reviews and automated checks performed to validate sections
of the final version of the document written in a formal language, such
as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

  None.

(9) Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  The document shepherd finds the document clear and complete.

(10) Several IETF Areas have assembled lists of common issues that their
reviewers encounter.  Do any such issues remain that would merit specific
attention from subsequent reviews?

  The document shepherd finds no concerns.

(11) What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)?  Why is this the proper type
of RFC?  Do all Datatracker state attributes correctly reflect this
intent?

  Proposed Standard.  The datatracker indicates this intent.

(12) Has the interested community confirmed that any and all appropriate
IPR disclosures required by BCP 78 and BCP 79 have been filed?  If not,
explain why.  If yes, summarize any discussion and conclusion regarding
the intellectual property rights (IPR) disclosures, including links to
relevant emails.

  Each author has explicitly confirmed that all IPR disclosures that
  are required for full conformance with the provisions of BCP 78
  and BCP 79 have already been filed.  There are none.

(13) Has each Author or Contributor confirmed their willingness to be
listed as such?  If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  Each author has explicitly confirmed their willingness to be listed
  as an author.  All other contributors are comfortable not being
  listed as authors.

(14) Identify any remaining I-D nits in this document.  (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts).  Simply running the idnits tool is not enough; please
review the entire guidelines document.

  IDnits raises a new concerns, not noe of them seems to be relevant.
 
  First, IDnits complains about non-ASCII characters in the document,
  but these are legitimate use of non-ASCII characters.
 
  Second, IDnits complains about long lines, but they are associated with
  the legitimate use of non-ASCII characters in the document.
 
  Third, IDnits complains that:
 
    -- The draft header indicates that this document updates RFC5280, but the
    abstract doesn't seem to directly say this.  It does mention RFC5280
    though, so this could be OK.

  As document shepherd, it seems fine, and no one raise a concern during
  WG Last Call.

  Finally, IDnits raise a concern that "you may need to add the pre-RFC5378
  disclaimer".  This is not correct.  As author of RFC 5280, I have provided
  the necessary rights to the IETF Trust to avoid the need for this disclaimer.

(15) Should any informative references be normative or vice-versa?

  All three references are normative.

(16) List any normative references that are not freely available to
anyone.  Did the community have sufficient access to review any such
normative references?

  All normative references are RFCs.

(17) Are there any normative downward references (see RFC 3967, BCP 97)?
If so, list them.

  There are no downrefs.

(18) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If they exist, what is
the plan for their completion?

  All of the normative references have already been published.

(19) Will publication of this document change the status of any existing
RFCs?  If so, does the Datatracker metadata correctly reflect this and
are those RFCs listed on the title page, in the abstract, and discussed
in the introduction?  If not, explain why and point to the part of the
document where the relationship of this document to these other RFCs is
discussed.

  Publication of this document will not effect the status of any
  other documents.

(20) Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries.  Confirm that any referenced IANA registries have been
clearly identified.  Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a reasonable
name (see RFC 8126).

  No  IANA actions are needed.

(21) List any new IANA registries that require Designated Expert Review
for future allocations.  Are the instructions to the Designated Expert
clear?  Please include suggestions of designated experts, if appropriate.

  No new IANA registries are needed.

Shepherd Write-up for draft-ietf-lamps-keyusage-crl-validation-02


(1) Does the working group (WG) consensus represent the strong
concurrence of a few individuals, with others being silent, or did it
reach broad agreement?

  There is support for this document in the LAMPS WG.

(2) Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

  During the WG Last Call there was a very active discussion in late
  June 2025, and the modifications made to the document reflect the
  consensus that was reached.
 
(3) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal or indicated any discontent.

(4) For protocol documents, are there existing implementations of the
contents of the document?  Have a significant number of potential
implementers indicated plans to implement?  Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 recommends) or elsewhere (where)?

  It is clear that several people already implement this document.

(5) Does this document need review from other IETF working groups or
external organizations?  Have those reviews occurred?

  None needed.

(6) Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
reviews.

  The document discusses the ASN.1 in RFC 5280, but no new ASN.1
  definitions are needed.

(7) If the document contains a YANG module, has the final version of the
module been checked with any of the recommended validation tools for
syntax and formatting validation?  If there are any resulting errors or
warnings, what is the justification for not fixing them at this time?
Does the YANG module comply with the Network Management Datastore
Architecture (NMDA) as specified in RFC 8342?

  YANG is not used in the document.

(8) Describe reviews and automated checks performed to validate sections
of the final version of the document written in a formal language, such
as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

  None.

(9) Based on the shepherd's review of the document, is it their opinion
that this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director?

  The document shepherd finds the document clear and complete.

(10) Several IETF Areas have assembled lists of common issues that their
reviewers encounter.  Do any such issues remain that would merit specific
attention from subsequent reviews?

  The document shepherd finds no concerns.

(11) What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)?  Why is this the proper type
of RFC?  Do all Datatracker state attributes correctly reflect this
intent?

  Proposed Standard.  The datatracker indicates this intent.

(12) Has the interested community confirmed that any and all appropriate
IPR disclosures required by BCP 78 and BCP 79 have been filed?  If not,
explain why.  If yes, summarize any discussion and conclusion regarding
the intellectual property rights (IPR) disclosures, including links to
relevant emails.

  Each author has explicitly confirmed that all IPR disclosures that
  are required for full conformance with the provisions of BCP 78
  and BCP 79 have already been filed.  There are none.

(13) Has each Author or Contributor confirmed their willingness to be
listed as such?  If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  Each author has explicitly confirmed their willingness to be listed
  as an author.  All other contributors are comfortable not being
  listed as authors.

(14) Identify any remaining I-D nits in this document.  (See the idnits
tool and the checkbox items found in Guidelines to Authors of
Internet-Drafts).  Simply running the idnits tool is not enough; please
review the entire guidelines document.

  IDnits raises a new concerns, not noe of them seems to be relevant.
 
  First, IDnits complains about non-ASCII characters in the document,
  but these are legitimate use of non-ASCII characters.
 
  Second, IDnits complains about long lines, but they are associated with
  the legitimate use of non-ASCII characters in the document.
 
  Third, IDnits complains that:
 
    -- The draft header indicates that this document updates RFC5280, but the
    abstract doesn't seem to directly say this.  It does mention RFC5280
    though, so this could be OK.

  As document shepherd, it seems fine, and no one raise a concern during
  WG Last Call.

  Finally, IDnits raise a concern that "you may need to add the pre-RFC5378
  disclaimer".  This is not correct.  As author of RFC 5280, I have provided
  the necessary rights to the IETF Trust to avoid the need for this disclaimer.

(15) Should any informative references be normative or vice-versa?

  All three references are normative.

(16) List any normative references that are not freely available to
anyone.  Did the community have sufficient access to review any such
normative references?

  All normative references are RFCs.

(17) Are there any normative downward references (see RFC 3967, BCP 97)?
If so, list them.

  There are no downrefs.

(18) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If they exist, what is
the plan for their completion?

  All of the normative references have already been published.

(19) Will publication of this document change the status of any existing
RFCs?  If so, does the Datatracker metadata correctly reflect this and
are those RFCs listed on the title page, in the abstract, and discussed
in the introduction?  If not, explain why and point to the part of the
document where the relationship of this document to these other RFCs is
discussed.

  Publication of this document will not effect the status of any
  other documents.

(20) Describe the document shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all aspects of the document requiring IANA
assignments are associated with the appropriate reservations in IANA
registries.  Confirm that any referenced IANA registries have been
clearly identified.  Confirm that each newly created IANA registry
specifies its initial contents, allocations procedures, and a reasonable
name (see RFC 8126).

  No  IANA actions are needed.

(21) List any new IANA registries that require Designated Expert Review
for future allocations.  Are the instructions to the Designated Expert
clear?  Please include suggestions of designated experts, if appropriate.

  No new IANA registries are needed.