Adjusting the Draft Policy for Revocation Reason Codes

[Kathleen Wilson]

All,

In regards to the DRAFT Policy about CRLRevocation Reason Codes for TLS End-Entity Certificates...

I do not want to detract from the ongoing discussions here, but I would like to make forward progress on the following items, so I'm starting this separate discussion thread.

1) Should we add policy to encourage CAs to update the CRL entry for a certificate that was previously revoked for a non-keyCompromise reason, but then later it is learned that the private key has been compromised? Similarly, the CA may learn that the compromise date was earlier than what they originally put into the CRL.

My opinion: I think this is a good idea, that I have not yet addressed.

2) Should the non-keyCompromise reason codes be required? Or should the language "The CRLReason ... MUST be used" be changed to "The CRLReason ... MAY be used"?

My opinion: I think the language should remain "MUST", because I would like to get to the point that relying parties can depend on these reason codes being used consistently, and decide for themselves about how to use them. In my explanation about why establishing this policy is important, I focused on keyCompromise, but it would be reasonable for Mozilla to decide to hard-fail for other allowed CRLReasons as well.

3) Should there be a priority order to the CRLReason codes?

My opinion: I think it's safe to say that keyCompromise is top priority, but I prefer not to assign priority to the other CRLReasons. It is fine with me if you all want to discuss priorities for the purpose of implementation logic -- if that's the case and you think this should be a recommendation in the policy, then please suggest what the implementation/logic order should be.

4) Should CAs provide the explanation about CRLReason codes in their subscriber agreement? Or should the policy leave it open as to where the CA provides that information for their customers?

My opinion: I think it should be in the subscriber agreement, and the CA is welcome to provide it other places too.

5) What CRLReason makes sense for the following two scenarios?

- the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; or
- the CA obtains 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.

My opinion: In certain situations it might be appropriate for the CA to use keyCompromise -- that's why these are currently in the draft as "MAY use keyCompromise". But if the situation does not warrant keyCompromise, should privilegeWithdrawn be used?

Thanks to all of you who have been providing input into this draft policy. I greatly appreciate it!

Kathleen

[Kathleen Wilson]

On Wednesday, February 9, 2022 at 9:16:23 AM UTC-8 Kathleen Wilson wrote:

All,

In regards to the DRAFT Policy about CRLRevocation Reason Codes for TLS End-Entity Certificates...

I do not want to detract from the ongoing discussions here, but I would like to make forward progress on the following items, so I'm starting this separate discussion thread.

1) Should we add policy to encourage CAs to update the CRL entry for a certificate that was previously revoked for a non-keyCompromise reason, but then later it is learned that the private key has been compromised? Similarly, the CA may learn that the compromise date was earlier than what they originally put into the CRL.

My opinion: I think this is a good idea, that I have not yet addressed.

I added the following paragraph to the keyCompromise section:

"When the CA obtains verifiable evidence of private key compromise for a certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension.  Additionally, the CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the certificate was compromised prior to the revocation date that is indicated in the CRL entry for that certificate. "

 

2) Should the non-keyCompromise reason codes be required? Or should the language "The CRLReason ... MUST be used" be changed to "The CRLReason ... MAY be used"?

My opinion: I think the language should remain "MUST", because I would like to get to the point that relying parties can depend on these reason codes being used consistently, and decide for themselves about how to use them. In my explanation about why establishing this policy is important, I focused on keyCompromise, but it would be reasonable for Mozilla to decide to hard-fail for other allowed CRLReasons as well.

I kept the "MUST" wording, and added a "Background Information" section to the end of the document.

 

3) Should there be a priority order to the CRLReason codes?

My opinion: I think it's safe to say that keyCompromise is top priority, but I prefer not to assign priority to the other CRLReasons. It is fine with me if you all want to discuss priorities for the purpose of implementation logic -- if that's the case and you think this should be a recommendation in the policy, then please suggest what the implementation/logic order should be.

I have not added priorities to the reason codes.

Distantly related...

I updated the list of acceptable reason codes to more clearly explain the numbers, and removed the reason flag numbers from the rest of the draft policy.

- keyCompromise (RFC 5280 Reason Flag #1)
- affiliationChanged (RFC 5280 Reason Flag #3)
- superseded (RFC 5280 Reason Flag #4)
- cessationOfOperation (RFC 5280 Reason Flag #5)
- privilegeWithdrawn ((RFC 5280 Reason Flag #7)

 

4) Should CAs provide the explanation about CRLReason codes in their subscriber agreement? Or should the policy leave it open as to where the CA provides that information for their customers?

My opinion: I think it should be in the subscriber agreement, and the CA is welcome to provide it other places too.

I have kept it as needing to be in the subscriber agreement. That does not preclude the CA providing the information elsewhere.

 

5) What CRLReason makes sense for the following two scenarios?

- the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; or
- the CA obtains 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.

My opinion: In certain situations it might be appropriate for the CA to use keyCompromise -- that's why these are currently in the draft as "MAY use keyCompromise". But if the situation does not warrant keyCompromise, should privilegeWithdrawn be used?

The following paragraph is in the keyCompromise section:

"The CA MUST use either the keyCompromise reasonCode or the privilegeWithdrawn reasonCode when the CA obtains verifiable evidence that the certificate was issued to a subscriber who does not own or control all of the domain names listed in the certificate. The CA SHALL determine which of those two reasonCodes is appropriate under the circumstances of the revocation. For example;

- the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; or
- the CA obtains 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.

 "

I will appreciate your feedback on these changes.

Thanks,

Kathleen

[Kathleen Wilson]

All,

I have made the following changes to the “DRAFT Policy about CRLRevocation Reason Codes for TLS End-Entity Certificates” document, based on feedback received during a discussion with the CA/Browser Forum Server Certificate Working Group.

1) Changed the order of the list and sections to indicate an order of precedence:

keyCompromise (RFC 5280 Reason Flag #1)

privilegeWithdrawn (RFC 5280 Reason Flag #9)

cessationOfOperation (RFC 5280 Reason Flag #5)

affiliationChanged (RFC 5280 Reason Flag #3)

superseded (RFC 5280 Reason Flag #4)

2) When applicable, moved the intended usage scenarios to the top of each section.

3) Added the information in parentheses to the following sentence in the third paragraph of top section.
“Tools that the CA provides to the certificate subscriber MUST allow for these options to be easily specified when the certificate subscriber requests revocation of their certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL).”

4) Clarified the sentence about CSR in the keyCompromise section:

Changed

“A CSR does NOT prove possession of the certificate’s private key for the purpose of initiating a revocation.”

To
“A CSR alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation.”

5) Added Note about updating the revocationDate to the third paragraph of the keyCompromise section:
"Note: Backdating the revocationDate field is an exception to best practice described in RFC 5280 (section 5.3.2); however, this policy specifies the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the certificate is first considered to be compromised."

6) Moved the paragraph about not-authorized/incomplete validations from the keyCompromise section to the privelegeWithdrawn section.
“The CA MUST use either the privilegeWithdrawn reasonCode or the superseded reasonCode when the CA obtains verifiable evidence that the certificate was issued to a subscriber who does not own or control all of the domain names listed in the certificate. The CA SHALL determine which of those two reasonCodes is appropriate under the circumstances of the revocation. For example;

- the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; or
- the CA obtains 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.”

I will greatly appreciate feedback on the current draft of this policy.

Thanks,

Kathleen

[Kathleen Wilson]

Hi Man Ho,

==
Regarding your point about the privilegeWithdrawn CRLReason not being a reason that is requested by subscriber...

I think you are correct, so I added:
"** The privilegeWithdrawn reasonCode does not need to be made available to the certificate subscriber as a revocation reason option, because the use of this reasonCode is determined by the CA and not the subscriber."

==

Regarding your points about the following paragraph -- the first bullet really applies to the privilegeWithdrawn reasonCode, and the second bullet really applies to the superseded reasonCode:

The CA MUST use either the privilegeWithdrawn reasonCode or the superseded reasonCode when the CA obtains verifiable evidence that the certificate was issued to a subscriber who does not own or control all of the domain names listed in the certificate. The CA SHALL determine which of those two reasonCodes is appropriate under the circumstances of the revocation. For example;

• the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; or

• the CA obtains 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.

I think you are correct, and that will make the text simpler. So I moved the bullet items into their corresponding sections and deleted the extra paragraph.

==

Regarding your question about cessationOfOperation reasonCode: Should CA actually verify the subscriber has ceased operation?

That's a good question.

All, should we add policy about having the CA verify that the subscriber has ceased operation?

==

Regarding your questions about keyCompromise, CSR, and verifiable evidence:

I plan to provide information in a wiki page that contains further details about the new policy, such as answers to your questions.

In the meantime, there was lengthy discussion about CSRs and demonstrating key compromise, starting here:
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/RVFnJJRuUag/m/9kMbNY-BAwAJ

==


Thanks,
Kathleen

On 3/16/22 10:03 PM, Man Ho (Certizen) wrote:

Hi Kathleen,

I apologize if I missed previous discussions on this topic. But as I take a fresh look at the draft policy, I'm confused on the context of some descriptions , such as:

***********************************************************

keyCompromise

A CSR alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation[MHaC1] .

---

 [MHaC1]While a generic CSR alone does not prove possession of the certificate's private key, could a CSR with a specific common name do (e.g. "Proof of Key Compromise for [name of CA]") ?

***********************************************************

keyCompromise

The CRLReason keyCompromise MUST be used when one or more of the following occurs:

●       the CA obtains verifiable evidence [MHaC2] that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise;

---

 [MHaC2]If a CSR alone does not prove possession of the certificate's private key, what kind of verifiable evidence could it be?

***********************************************************

keyCompromise

●       If the certificate subscriber requests that the CA revoke the certificate for keyCompromise, and has not previously demonstrated and cannot currently demonstrate[MHaC3]  possession of the associated private key of that certificate, the CA MAY revoke all certificates associated with that subscriber that contain that public key. The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key.

---

 [MHaC3]Why should CA bother whether the subscriber possess the associated private key, if CA has already authenticated the subscriber? Is it meant to let CA decline the subscriber request in this case?

***********************************************************

keyCompromise

Additionally, the CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the certificate was compromised prior to the revocation date that is indicated in the CRL entry [MHaC4] for that certificate.

---

 [MHaC4]How can it be determined? By self-declaration of the requester?

***********************************************************

privilegeWithdrawn

The CA MUST use either the privilegeWithdrawn reasonCode or the superseded reasonCode when the CA obtains verifiable evidence [MHaC5] that the certificate was issued to a subscriber who does not own or control all of the domain names listed in the certificate.

---

 [MHaC5]So, this CRLreason is not requested by subscriber?

***********************************************************

For example;

●       the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization[MHaC6] ; or

●       the CA obtains 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[MHaC7] .

---

 [MHaC6]For the first bullet,  is it correct that this condition refer to certificate request authorization? So, the reasonCode is privilegeWithdrawn.

 [MHaC7]For the second bullet, is it correct that this condition refer to domain authorization? So, the reasonCode is superseded.

***********************************************************

cessationOfOperation

The CRLReason cessationOfOperation MUST be used when the certificate subscriber has requested that their certificate be revoked for this reason, or the CA has received verifiable evidence that the certificate subscriber no longer owns all of the domain names [MHaC8] in the certificate and there is no evidence of keyCompromise as described above.

---

 [MHaC8]It is very similar to the privilegeWithdrawn reasonCode.  Should CA actually verify the subscriber has ceased operation?

Thanks a lot.

Man Ho

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a3055259-d86c-449d-9588-8c5b61e0ab02n%40mozilla.org.

[Doug Beattie]

Hi Kathleen,

 

I have a couple of additional questions on the latest policy:

 

#1) regarding the last sentence of the second bullet under the scope of the keyCompromise which says:

• The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key.

 

And specifically the statement “MAY block issuance… “.  Should this be limited to this subscriber, or would a CA be permitted to block issuance of ALL certificates with this public key?  If it’s globally, then I think there is a DoS issue.  Should we clarify the scope of the “MAY” by adding “…for that certificate subscriber” to the end of the sentence?

 

#2 privilegeWithdrawn

 

I understand the prior intent that the CA must be the entity that sets this and that it cannot be supplied by the Subscriber; however, a new bullet was added that says: “the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization.”  Isn’t this basically the subscriber specifying the reason without the CA actually “validating” it’s true?  If so, then is it necessary to prohibit the subscriber from selecting this reason directly?

 

#3 superseded

 

This was recently added

• or the CA has replaced the certificate due to domain authorization or compliance issues other than those related to keyCompromise or privilegeWithdrawn.

 

but does a CA ever “replace” certificates?  I think that the applicant/subscriber is the only entity that can request replacement certificates, unless there is a scenario that I’m not thinking of.

 

 

#4 General question

 

In a few places we say to use a specific reason code only when X, Y and Z reasons are not used.  Is this necessary vs. just saying when it can be used and being silent on when it can’t be used or adding these dependencies?  It makes determining the right reason code much more transparent, imo

 

Doug

--

[Ryan Sleevi]

On Tue, Mar 22, 2022 at 8:02 AM 'Doug Beattie' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

#1) regarding the last sentence of the second bullet under the scope of the keyCompromise which says:

• The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key.

 

And specifically the statement “MAY block issuance… “.  Should this be limited to this subscriber, or would a CA be permitted to block issuance of ALL certificates with this public key?  If it’s globally, then I think there is a DoS issue.  Should we clarify the scope of the “MAY” by adding “…for that certificate subscriber” to the end of the sentence?

Isn't that more restrictive on CAs? That is, you end up limiting the reasons they may block issuance to a single reason. There is potential for DoS, yes, but managed at an individual CA, and with the CAs' discretion as to when and how they act.

That is, the scope seems fine as-is, in one of the few times I find myself arguing for CA discretion 😅

 

#2 privilegeWithdrawn

 

I understand the prior intent that the CA must be the entity that sets this and that it cannot be supplied by the Subscriber; however, a new bullet was added that says: “the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization.”  Isn’t this basically the subscriber specifying the reason without the CA actually “validating” it’s true?  If so, then is it necessary to prohibit the subscriber from selecting this reason directly?

Isn't the difference that the subscriber is directly affirming the intended semantics, versus the proposed change, which would let them express this for any arbitrary reason?

That is, I think the difference here is whether or not the customer receives guidance about the intended semantics or not. Is that critical? I'm not sure, but it at least seems to be a functional difference here.

 

#3 superseded

 

This was recently added

• or the CA has replaced the certificate due to domain authorization or compliance issues other than those related to keyCompromise or privilegeWithdrawn.

 

but does a CA ever “replace” certificates?  I think that the applicant/subscriber is the only entity that can request replacement certificates, unless there is a scenario that I’m not thinking of.

I agree with your first question but not sure I understand your second remark? That is, a certificate cannot be distinguished by itself as a "replacement" certificate - a certificate is simply a certificate, independent of all that came before and after. A customer requests a new certificate to replace an old certificate, and so it's functionally a replacement, but that's technically indistinguishable. If CA Foo issues a certificate for domain.example , and then the domain owner goes to CA Bar to obtain a certificate for domain.example, has Bar replaced Foo?

Where I'm going is do you think the language resolves if "the CA has revoked the certificate due to ...", and avoids the word "replace" (and the presumption of a 'new', from either Foo or Bar)?

 

#4 General question

 

In a few places we say to use a specific reason code only when X, Y and Z reasons are not used.  Is this necessary vs. just saying when it can be used and being silent on when it can’t be used or adding these dependencies?  It makes determining the right reason code much more transparent, imo

I'm having trouble following this, perhaps you could explain more?

That is, it seems like the risk exists either way of CA's misinterpreting, and I thought the general preference of most CAs was to give every explicit MUST/MUST NOT. Leaving things underspecified (by silent on when it can't be used) seems like it invites the default allow/default deny ambiguity? 

[Doug Beattie]

Hi Ryan,

 

I tried to put some comments in-line below with delimiters before/after (---).  Outlook is lousy at this, so if you can’t find my comments I can try this another way.

 

Doug

 

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Tuesday, March 22, 2022 11:17 AM
To: Doug Beattie <doug.b...@globalsign.com>
Cc: Kathleen Wilson <kwi...@mozilla.com>; dev-secur...@mozilla.org
Subject: Re: Adjusting the Draft Policy for Revocation Reason Codes

 

 

 

On Tue, Mar 22, 2022 at 8:02 AM 'Doug Beattie' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

#1) regarding the last sentence of the second bullet under the scope of the keyCompromise which says:

·  The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key.

 

And specifically the statement “MAY block issuance… “.  Should this be limited to this subscriber, or would a CA be permitted to block issuance of ALL certificates with this public key?  If it’s globally, then I think there is a DoS issue.  Should we clarify the scope of the “MAY” by adding “…for that certificate subscriber” to the end of the sentence?

 

Isn't that more restrictive on CAs? That is, you end up limiting the reasons they may block issuance to a single reason. There is potential for DoS, yes, but managed at an individual CA, and with the CAs' discretion as to when and how they act.

 

That is, the scope seems fine as-is, in one of the few times I find myself arguing for CA discretion 😅

 

---

I’m proposing that we change this:

·         The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key.

To this:

·         The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key for that subscriber.

If we don’t do this, then a CA would be permitted to globally block issuance with certs with that key.  Do we want CAs to do that?  We went out of our way to prevent this in the keyCompromise section.

---

 

#2 privilegeWithdrawn

 

I understand the prior intent that the CA must be the entity that sets this and that it cannot be supplied by the Subscriber; however, a new bullet was added that says: “the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization.”  Isn’t this basically the subscriber specifying the reason without the CA actually “validating” it’s true?  If so, then is it necessary to prohibit the subscriber from selecting this reason directly?

 

Isn't the difference that the subscriber is directly affirming the intended semantics, versus the proposed change, which would let them express this for any arbitrary reason?

 

---

Most of the other reasons affirm specific semantics, so I don’t see a difference with this reason code.

• the certificate subscriber requests that the CA revoke the certificate for this reason, with the scope of revocation being described below.

• the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization.

 

Seems that the subscriber asserts something and then it’s reflected in the CRL reason code.  Is privilegeWithdrawn any different?

---

 

That is, I think the difference here is whether or not the customer receives guidance about the intended semantics or not. Is that critical? I'm not sure, but it at least seems to be a functional difference here.

 

 

 

#3 superseded

 

This was recently added

·  or the CA has replaced the certificate due to domain authorization or compliance issues other than those related to keyCompromise or privilegeWithdrawn.

 

but does a CA ever “replace” certificates?  I think that the applicant/subscriber is the only entity that can request replacement certificates, unless there is a scenario that I’m not thinking of.

 

I agree with your first question but not sure I understand your second remark? That is, a certificate cannot be distinguished by itself as a "replacement" certificate - a certificate is simply a certificate, independent of all that came before and after. A customer requests a new certificate to replace an old certificate, and so it's functionally a replacement, but that's technically indistinguishable. If CA Foo issues a certificate for domain.example , and then the domain owner goes to CA Bar to obtain a certificate for domain.example, has Bar replaced Foo?

 

Where I'm going is do you think the language resolves if "the CA has revoked the certificate due to ...", and avoids the word "replace" (and the presumption of a 'new', from either Foo or Bar)?

---

Yes, I think a wording update would solve the problem here

---

 

#4 General question

 

In a few places we say to use a specific reason code only when X, Y and Z reasons are not used.  Is this necessary vs. just saying when it can be used and being silent on when it can’t be used or adding these dependencies?  It makes determining the right reason code much more transparent, imo

 

I'm having trouble following this, perhaps you could explain more?

 

That is, it seems like the risk exists either way of CA's misinterpreting, and I thought the general preference of most CAs was to give every explicit MUST/MUST NOT. Leaving things underspecified (by silent on when it can't be used) seems like it invites the default allow/default deny ambiguity? 

 

---

Most of the reason codes are supplied by the Subscriber and not the CA (not all of course).  If CAs are responsible for “training” users on the proper use, it would be more beneficial to say exactly when they need to use it and not tie in other reasons, like this – does this add any value if the reasons for using the code is clear?

This is extremely hard to parse:

• The CRLReason affiliationChanged MUST be used when

• the certificate subscriber has requested that their certificate be revoked for this reason, or
• the CA has

• replaced the certificate due to changes in the certificate’s subject information and
• the CA has not replaced the certificate for the other reasons: keyCompromise, superseded, cessationOfOperation, or privilegeWithdrawn.

 

What are the CA rules for when this reason can be used?  Maybe it’s just the “CA has replaced” wording again that needs to be cleaned up, but it’s not clear to me when a CA MUST use this reason code.

 

--

[Kathleen Wilson]

Doug,

I believe I have addressed all of the items that you recently raised in the DRAFT Policy about CRLRevocation Reason Codes for TLS Server Certs. Would you please double-check?

#1) added "for that subscriber" to the last sentence of the second bullet under the scope of the keyCompromise.

The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key for that subscriber.

#2) Rephrased the last bullet point in the privilegeWithdrawn section

the CA determines or is made aware that the original certificate request was not authorized and does not retroactively grant authorization.

#3) Rephrased parts of the superseded section

- the certificate subscriber has requested a new certificate to replace an existing certificate; or

- the CA has revoked the certificate for compliance reasons ...

#4) General question

I broke up some of the paragraphs into bullet points to hopefully make it easier to read.

I separated moved the "Otherwise, the <reason> CRLReason MUST NOT be used." sentence to the bottom of each section, as it's own paragraph.

Thanks,

Kathleen

[Doug Beattie]

Hi Kathleen,

 

Thanks, those updates help a lot!

 

Doug

 

From: Kathleen Wilson <kwi...@mozilla.com>
Sent: Tuesday, March 22, 2022 8:47 PM
To: dev-secur...@mozilla.org
Cc: Doug Beattie <doug.b...@globalsign.com>; Ryan Sleevi <ry...@sleevi.com>
Subject: Re: Adjusting the Draft Policy for Revocation Reason Codes

 

Doug,