[Servercert-wg] Discussion Period Begins: Ballot SC-061v3: New CRL Entries must have a Revocation Reason Code

Wed Feb 1 20:01:15 UTC 2023

For better or worse, RFC 5280 says nothing about the meanings of the
various revocation reasons, other than their names. X.509 itself (
https://www.itu.int/rec/T-REC-X.509-201910-I/en) has this to say:

The following reason code values indicate why a public-key certificate was
> revoked:
> – unspecified can be used to revoke public-key certificates for reasons
> other than the specific codes.
> – keyCompromise is used in revoking an end-entity public-key certificate;
> it indicates that it is known or
> suspected that the subject's private key, or other aspects of the subject
> validated in the public-key
> certificate, have been compromised.
> – cACompromise is used in revoking a CA certificate; it indicates that it
> is known or suspected that the
> subject's private key, or other aspects of the subject validated in the CA
> certificate, have been
> compromised.
> – affiliationChanged indicates that the subject's name or other
> information in the public-key certificate
> has been modified but there is no cause to suspect that the private key
> has been compromised.
> – superseded indicates that the public-key certificate has been superseded
> but there is no cause to suspect
> that the private key has been compromised.
> – cessationOfOperation indicates that the public-key certificate is no
> longer needed for the purpose for
> which it was issued but there is no cause to suspect that the private key
> has been compromised.
> – privilegeWithdrawn indicates that a public-key certificate was revoked
> because a privilege contained
> within that public-key certificate has been withdrawn.
> – aACompromise is only relevant for ACRL entries (see 17.2.3.1).
> – weekAlgorithm indicates that the public-key certificate was revoked due
> to a weak cryptographic
> algorithm and/or key (e.g., due to short key length or unsafe key
> generation).
>

Aaron

On Wed, Feb 1, 2023 at 11:36 AM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> Well, if Mozilla policy is wrong, we shouldn’t do the wrong thing just
> because it’s already in Mozilla policy.  It just needs we would need a bit
> of coordination with Mozilla to fix it.  However I don’t believe that’s
> necessary.
>
>
>
> If you read the highlighted section Wendy posted, it’s pretty clear that
> RFC 5280 explicitly intends for superseded to be (mis)used in this manner.
> Only the first unhighlighted part before the first “or” requires a request
> for a new certificate.
>
>
>
> I share Aaron’s concern about the fact that this code means three things,
> two of them unrelated to the other, but unfortunately there doesn’t appear
> to be an IANA expansion point here to allow easy allocation of a new reason
> code.  However a short RFC could allocate a “compliance (9)” reason code
> and describe its proper use, if desired.
>
>
>
> I hope I don’t have to state that the CABForum unilaterally choosing to
> use an undocumented reason code would be highly undesirable.
>
>
>
> -Tim
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Aaron
> Gable via Servercert-wg
> *Sent:* Wednesday, February 1, 2023 1:30 PM
> *To:* Ben Wilson <bwilson at mozilla.com>; CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Discussion Period Begins: Ballot SC-061v3:
> New CRL Entries must have a Revocation Reason Code
>
>
>
> I will admit that I also don't *love* using Superseded for this purpose.
> However:
>
>
>
> - There is no other revocation reason that is better: it's certainly not
> keyCompromise, affiliationChanged, cessationOfOperation, or
> privilegeWithdrawn. Using "unspecified" for such incidents also feels bad,
> as this lumps together CA-initiated revocations due to incidents with the
> majority of Subscriber-requested revocations.
>
>
>
> - This ballot is attempting to incorporate current Mozilla requirements
> into the BRs. The MRSP currently says that Superseded should be used for
> this purpose. If the BRs choose to diverge from MRSP in this way, there
> will be contradictory requirements until one or the other changes.
>
>
>
> - One could choose to interpret Superseded as, rather than a declaration
> that the CA already has replaced the certificate, a declaration that
> they're *willing* to. A no-fault revocation, for lack of a better term.
>
>
>
> None of these are particularly strong arguments in favor of using
> Superseded for this purpose, but together I think they make it the most
> reasonable option.
>
>
>
> Aaron
>
>
>
> On Wed, Feb 1, 2023 at 10:01 AM Ben Wilson via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> Thanks, Wendy.
>
> Do others want to chime in on these points?
>
> Ben
>
>
>
> On Wed, Feb 1, 2023, 10:45 AM Wendy Brown - QT3LB-C <wendy.brown at gsa.gov>
> wrote:
>
> Superseded for these 2 reasons doesn't seem appropriate unless you also
> add that a new certificate was issued or at least requested, as a
> replacement.
>
> 6. The Certificate no longer complies with the requirements of [Section
> 6.1.5](#615-key-sizes) and [Section
> 6.1.6](#616-public-key-parameters-generation-and-quality-checking)
> (CRLReason #4, superseded);
>
> and
>
> 12. The CA is made aware that the Certificate was not issued in accordance
> with these Requirements or the CA's Certificate Policy or Certification
> Practice Statement (CRLReason #4, superseded);
>
>
>
> The definition isn't clear that a new cert has been issued (or even
> requested) based on the highlighted text - was it supposed to say that the
> CA issued a replacement certificate because it has reasonable evidence
> ....? Or should it just have ended with a . before the ", or the CA has ..."
>
>   * **superseded (RFC 5280 CRLReason #4):** Indicates that the Certificate
> Subscriber has requested a new Certificate to replace an existing
> Certificate, or the CA has reasonable evidence that the validation of
> domain authorization or control for any fully‐qualified domain name or IP
> address in the Certificate should not be relied upon or the CA has revoked
> the Certificate for compliance reasons such as the Certificate does not
> comply with these Baseline Requirements or the CA's CP or CPS;
>
>
>
> Thanks,
>
> Wendy
>
>
>
> Wendy Brown
>
> Supporting GSA
>
> FPKIMA Technical Liaison
>
> Protiviti Government Services
>
> 703-965-2990 (cell)
>
>
>
>
>
> On Wed, Feb 1, 2023 at 12:22 PM Aaron Gable via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> Wonderful, thank you! I have no further comments.
>
>
>
> Aaron
>
>
>
> On Tue, Jan 31, 2023 at 4:08 PM Ben Wilson <bwilson at mozilla.com> wrote:
>
> Thanks, Aaron - the numbering change was unintentional, so I fixed that,
> and I made other changes as requested.  See
>
>
> https://github.com/BenWilson-Mozilla/servercert/commit/f1ed2357c6c9fe9bcedaec040582f872e0f519de
> <https://avanan.url-protection.com/v1/url?o=https%3A//github.com/BenWilson-Mozilla/servercert/commit/f1ed2357c6c9fe9bcedaec040582f872e0f519de&g=YWViMDQzOWVjODgwNjI1Nw==&h=N2Q0ODVjYjQ2NGM1ZTM4NWM0MDQ5MTlmYmMyZWIzY2Q1YzM0YjhhMjBkNzdlOGMzNTE5YmMzMjlmZWM3MWFlNw==&p=YXAzOmRpZ2ljZXJ0OmE6bzpjODAzMjllZGMxNDZmMjFjOWU4MzU3NDA0ZDE4M2MwMzp2MTpoOkY=>
>
> Before I re-announce the discussion period, does anyone else have other
> changes that they would like to see?
>
> Thanks,
>
> Ben
>
>
>
> On Mon, Jan 30, 2023 at 9:58 AM Aaron Gable <aaron at letsencrypt.org> wrote:
>
> The current redline appears to undo the recent renumbering of section
> 4.9.1.1, causing it to have two different instances of paragraphs 1 through
> 5. These were renumbered in Ballot SC-56 Cleanup[1]. Can we please preserve
> the new numbering?
>
>
>
> Additional notes:
>
> - In 4.1.1.1 (1), perhaps "without specifying a CRLReason", rather than
> "without giving a reason"? A Subscriber might state "Please revoke this
> because I accidentally deleted the keys", in which case they are giving a
> reason, but the best revocation reason is still 0 (Unspecified). One might
> believe that Superseded is applicable in this case, but that revocation
> request does not necessarily indicate that the Subscriber has also replaced
> the certificate.
>
> - A very minor comment, but there's inconsistent phrasing between the five
> revocation reasons in Section 7.2.2: the first begins "Indicates that..."
> while the others begin "It is intended to be used...". Can we give all five
> of these entries the same structure/phrasing?
>
>
>
> Aaron
>
>
>
> [1]
> https://github.com/cabforum/servercert/pull/401/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1214-R1224
> <https://avanan.url-protection.com/v1/url?o=https%3A//github.com/cabforum/servercert/pull/401/files%23diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1214-R1224&g=M2UwYTBkMDgwN2Q5MTExYg==&h=MzhiZDYwZGUxNjhjYjlhZDgxOTkyNzVkMWRiZTUxODAzYmJkM2M4ZTc1MmZhMjkxYzBiZWJlYzE3YzQzY2NmYg==&p=YXAzOmRpZ2ljZXJ0OmE6bzpjODAzMjllZGMxNDZmMjFjOWU4MzU3NDA0ZDE4M2MwMzp2MTpoOkY=>
>
>
>
> On Thu, Jan 19, 2023 at 1:55 PM Ben Wilson via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> All,
>
>
>
> This is version 3 of Ballot SC-061. I've moved some of the language down
> into section 7.2.2, and I've added back in two paragraphs that have been in
> the original Mozilla Root Store Policy regarding changing the reason code
> and revocation date for key compromise.  I also changed the compliance date
> to July 15, 2023. (The compliance date for CAs in Mozilla's program was
> Oct. 1, 2022.)
>
>
>
> *Purpose of Ballot SC-061 v.3*
>
>
>
> The purpose of this ballot is to modify sections 4.9.1.1 and 7.2.2 of the
> Baseline Requirements to incorporate the CRL reason codes that Mozilla has
> adopted in section 6.1.1 of the Mozilla Root Store Policy.
>
>
>
> *Motion*
>
>
>
> The following motion has been proposed by Ben Wilson of Mozilla and
> endorsed by David Kluge of Google Trust Services and Kiran Tummala of
> Microsoft.
>
> *—–Motion Begins—–*
>
> This ballot modifies sections 4.9.1.1 and 7.2.2 of the “Baseline
> Requirements for the Issuance and Management of Publicly-Trusted
> Certificates” as defined in the following redline, based on Version 1.8.6:
>
>
> https://github.com/cabforum/servercert/compare/2c63814fa7f9f7c477c74a6bfbeb57e0fcc5dd5b..b1a3d9b491c9744a50a0e194678d76c639d6076b
> <https://avanan.url-protection.com/v1/url?o=https%3A//github.com/cabforum/servercert/compare/2c63814fa7f9f7c477c74a6bfbeb57e0fcc5dd5b..b1a3d9b491c9744a50a0e194678d76c639d6076b&g=ODQ0Mzc1NzQ3OGVhNjQyZg==&h=OGYwYjI0YmRmYjUwNzllMzU5MTkwOWQ4ZTZkYjEwMGVjN2IwNzg3ZDc5ZDA1ZDZkNjJlZjc0MzBkYjAzOTNlZA==&p=YXAzOmRpZ2ljZXJ0OmE6bzpjODAzMjllZGMxNDZmMjFjOWU4MzU3NDA0ZDE4M2MwMzp2MTpoOkY=>
>
>
>
>  *—–Motion Ends—–*
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time:  January 19, 2023 22:00 UTC
>
> End Time: January 26, 2023 22:00 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time:  January 26, 2023 TBD
>
> End Time: February 2, 2023 TBD
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://avanan.url-protection.com/v1/url?o=https%3A//lists.cabforum.org/mailman/listinfo/servercert-wg&g=ZjM2YTU2YmIyNDQwOWVhMA==&h=YWJmMDk1Mjc0OWU1MTM1ZmVlYmY3YTU1MTc0MzdjMzkxYTk4Mjc4NTVmNzE2YWRlZGE1Yzc3MTRmMmU3MjhkNw==&p=YXAzOmRpZ2ljZXJ0OmE6bzpjODAzMjllZGMxNDZmMjFjOWU4MzU3NDA0ZDE4M2MwMzp2MTpoOkY=>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://avanan.url-protection.com/v1/url?o=https%3A//lists.cabforum.org/mailman/listinfo/servercert-wg&g=NzhhMDFhZTQxMjk2YzRkNw==&h=NmFkMjZmNDIyNjhmZjg4MzI4ZjVlOTA4MzQ3ZGQ3NTIyYWUxZTliMTYyMDc4NmE2MzZjMTE4MTU1MjU5Mjg4NA==&p=YXAzOmRpZ2ljZXJ0OmE6bzpjODAzMjllZGMxNDZmMjFjOWU4MzU3NDA0ZDE4M2MwMzp2MTpoOkY=>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://avanan.url-protection.com/v1/url?o=https%3A//lists.cabforum.org/mailman/listinfo/servercert-wg&g=M2IyNjQyM2EzN2Q3YmUxNg==&h=NzcwNzMxNGExYzMzN2Y2NDY1MDdjMGZjOGUxMDRkZGM5NmQwYTIzNTFmNWRiYzMzMjc4YTM3ZDE2NzE2NWYxMQ==&p=YXAzOmRpZ2ljZXJ0OmE6bzpjODAzMjllZGMxNDZmMjFjOWU4MzU3NDA0ZDE4M2MwMzp2MTpoOkY=>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230201/bf9b2f1b/attachment-0001.html>