Policy 2.8: Final Review of MRSP v. 2.8

[Ben Wilson]

All,

Here are links helpful during your final review of version 2.8 of the Mozilla Root Store Policy (MRSP) :

https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.8/rootstore/policy.md

https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.8 (redlined)

Please review the changes and provide any additional comments by the end of Tuesday, April 19, 2022.

My plan is to move this version over to the Mozilla pkipolicy repository on Github, and then I'll request that it be published on Mozilla's website to replace version 2.7.1.

Thanks,

Ben

[Doug Beattie]

Hi Ben,

 

I provided a few comments to Kathleen which she incorporated into the WIKI as guidance, but wondered if some of them should be reflected in the Mozilla policy as well.  Specifically I don’t think the policy is clear that there are exactly 6 valid reasons (5 of which MUST be contained in the CRL).  This is just a suggestion, nothing major

 

1) The policy does not explicitly prohibit the use of reason codes other than the list below for the revocation of TLS certificates.  I think it should be crystal clear, the same as Kathleen’s updates to the wiki.  The following reason codes are permitted in CRLs.  All others are prohibited.

 

• keyCompromise (RFC 5280 CRLReason #1)
• affiliationChanged (RFC 5280 CRLReason #3)
• superseded (RFC 5280 CRLReason #4)
• cessationOfOperation (RFC 5280 CRLReason #5)
• privilegeWithdrawn (RFC 5280 CRLReason #9)**

 

 

2) the policy does not say that CAs or Subscribers can use the unspecified reason code.  I think this should be explicitly called out as a valid reason code (although, it’s not to be included into the CRL)

 

I’d recommend adding something like this:

 

TLS certificates (i.e. a certificates capable of being used for TLS-enabled servers) maybe  revoked for any of the following reasons.  No other reasons are permitted.

 

• unspecified (RFC 5280 CRLReason #0)
• keyCompromise (RFC 5280 CRLReason #1)
• affiliationChanged (RFC 5280 CRLReason #3)
• superseded (RFC 5280 CRLReason #4)
• cessationOfOperation (RFC 5280 CRLReason #5)
• privilegeWithdrawn (RFC 5280 CRLReason #9)**

 

The following reason codes MUST appear in the CRL when revoked for these reasons:

• keyCompromise (RFC 5280 CRLReason #1)
• affiliationChanged (RFC 5280 CRLReason #3)
• superseded (RFC 5280 CRLReason #4)
• cessationOfOperation (RFC 5280 CRLReason #5)
• privilegeWithdrawn (RFC 5280 CRLReason #9)**

 

** 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.

--
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/CA%2B1gtaby8DypMdN2ih3xF_nf0FoshtaKUes-KC%2Baxfi-3cRiqw%40mail.gmail.com.

[Andrew Ayer]

Hi Ben,

My comments about the precertificates section haven't been fully addressed:

https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/Co65loD9i-0/m/Trt4N9QQAgAJ

Regards,
Andrew

On Wed, 13 Apr 2022 11:18:24 -0600
Ben Wilson <bwi...@mozilla.com> wrote:

> All,
>
> Here are links helpful during your final review of version 2.8 of the
> Mozilla Root Store Policy (MRSP) :
>
> https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.8/rootstore/policy.md
> https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.8
> (redlined)
>
> Please review the changes and provide any additional comments by the
> end of Tuesday, April 19, 2022.
>
> My plan is to move this version over to the Mozilla pkipolicy
> repository on Github

> <https://github.com/mozilla/pkipolicy/tree/master/rootstore>, and

> then I'll request that it be published on Mozilla's website

> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

> > to replace version 2.7.1.
>
> Thanks,
>
> Ben
>

[Ben Wilson]

Thanks, Andrew

Would this address your comments?

5.4 Precertificates

Certificate Transparency precertificates are considered by Mozilla to be a binding intent to issue a certificate, as described in section 3.1 of RFC 6962, and thus in-scope for enforcing compliance with these requirements. Thus,

·        if a final certificate cannot be verified as matching a precertificate using the algorithms in RFC 6962, then two distinct final certificates are presumed to exist, and it is misissuance if the two final certificates have the same serial number and issuer, even if only one final certificate actually exists;

·        if a precertificate implies the existence of a final certificate that does not comply with this policy, it is considered misissuance of the final certificate, even if the certificate does not actually exist;

·        a CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under this policy, even if the final certificate does not actually exist; and

·        a CA must provide CRL and OCSP services and responses in accordance with this policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist.

[Andrew Ayer]

It would, thanks!

Regards,
Andrew

On Thu, 14 Apr 2022 13:28:13 -0600

> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZJ1hk9Lk%2BzpZcpAa%3DSePbuXU9XQKvD0JoFTTGFR8W%2B8Q%40mail.gmail.com.

[Ben Wilson]

All,

I've made recent changes here:

https://github.com/BenWilson-Mozilla/pkipolicy/commit/02285dbb0115c3e61941940dd75e26aa85404406  (to MRSP 5.4, per Andrew's comments)

and here:

https://github.com/BenWilson-Mozilla/pkipolicy/commit/6ef59e784020da21954ddb15488fa865917e1152 (to MRSP 6.1.1, per Rob Stradling's comments here:  https://github.com/BenWilson-Mozilla/pkipolicy/commit/060b169294da548a8de30ec65397aadab56f12fb )

Ben

[Corey Bonnell]

Hi Ben,

While there is an effective date of October 1^st for the CRL and OCSP profile for reason codes, does the October 1^st effective date also apply for when Mozilla expects CA subscriber agreements to be updated [1]?

 

Thanks,

Corey

 

[1]  https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.8#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6R741

 

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson
Sent: Wednesday, April 13, 2022 1:18 PM
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Policy 2.8: Final Review of MRSP v. 2.8

 

All,

--

[Ben Wilson]

Yes - October 1 is the date for the CRLrevocation-reason-related changes to be effective, including the subscriber agreement amendments.

[Dimitris Zacharopoulos]

Hi Ben,

Here are the comments from the HARICA team:


### 5.4 Precertificates ###

Certificate Transparency precertificates are considered by Mozilla to be a binding intent to issue a certificate, as described in section 3.1 of RFC 6962, and thus in-scope for enforcing compliance with these requirements. Thus,

* if a final certificate cannot be verified as matching a precertificate using the algorithms in RFC 6962, then two distinct final certificates are presumed to exist, and it is misissuance if the two final certificates have the same serial number and issuer, even if only one final certificate actually exists;
* if a precertificate implies the existence of a final certificate that does not comply with this policy, it is considered misissuance of the final certificate, even if the certificate does not actually exist;
* a CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under this policy, even if the final certificate does not actually exist; and
* a CA must provide CRL and OCSP services and responses in accordance with this policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist.


The term "final certificate" is not defined. Section 6.1.1 uses the term "end-entity". It looks a bit confusing. We understand the need to separate a "precertificate" from a "certificate" but perhaps the word "final" can be omitted.

Another nit: RFC 5280 uses the term "end entity" (without the hyphen).


Section 6.1.1
- cessationOfOperation

"the CA is made aware of any circumstance indicating that use of a fully‐qualified domain name or IP address in the certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a domain name registrant’s right to use the domain name, a relevant licensing or services agreement between the domain name registrant and the applicant has terminated, or the domain name registrant has failed to renew the domain name)."

This looks like a CA-driven revocationReason and seems to fit the privilegeWithdrawn reason better.

- superseded

• "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; or"
• "the CA has revoked the certificate for compliance reasons such as the certificate does not comply with this policy, the CA/Browser Forum's Baseline Requirements, or the CA’s CP or CPS."

Looking at these reasons, we have very similar intent for the reason "privilegeWithdrawn". Most probably, the intent of the revocationReason is to indicate why a certificate has been revoked. Relying Parties probably don't care if a new certificate has been issued to replace a revoked one or not, but are more interested on why a particular certificate was revoked.

ITU-T X.509's description doesn't shed too much light either:

"superseded indicates that the public-key certificate has been superseded but there is no cause to suspect that the private key has been compromised."

We recommend adding these two bullets under the "privilegeWithdrawn" reason so that CAs have a "preferred" reason to indicate compliance, domain validation/authorization, subscriber violation issues.

In section 8.4:

• The subordinate CA operator will obtain a non-technically-constrained (per section 5.3.1 of this policy) CA certificate, and the subordinate CA operator is not approved by Mozilla to issue the type of certificates (email, TLS, or EV TLS), which they will be able to issue under the new CA certificate.
• The root CA operator is cross-signing a root certificate of a CA operator who is not currently in Mozilla’s root store.
• The root CA operator is cross-signing a root certificate of another CA operator who is currently in Mozilla’s root store, but the other CA operator has been approved for different trust bits (email, TLS, or EV TLS) than those trust bits that will be recognized under the cross-signed certificate that it will be receiving.

please consider the following changes:

• The subordinate CA operator will obtain an unconstrained (per section 5.3.1 of this policy) CA certificate, and the subordinate CA operator is not approved by Mozilla to issue the type of certificates (email, TLS, or EV TLS), which they will be able to issue under the new CA certificate.
• The root CA operator is cross-signing a CA certificate of a CA operator who is not currently in Mozilla’s root store.
• The root CA operator is cross-signing a CA certificate of another CA operator who is currently in Mozilla’s root store, but the other CA operator has been approved for different trust bits (email, websites), or EV, than those trust bits that will be recognized under the cross-signed certificate that it will be receiving.

Similarly, for the last bullet of the section

The root CA operator is cross-signing a root certificate of another CA operator that is currently in Mozilla’s root store, and that other CA operator:

• will only be able to issue the same type of certificate (email, TLS, or EV TLS) that they are already approved for in Mozilla’s root store; and
• will operate both the cross-signed certificate and their root certificate under the same policies, practices, and scope of audit that their root certificate was approved for. (Newer versions of policies and practices MAY be used, provided that the cross-signed CA operator follows the same versions of the policies for both the cross-signed certificate and their root certificate.)

please consider changing to:

The root CA operator is cross-signing a CA certificate of another CA operator that is currently in Mozilla’s root store, and that other CA operator:

• will only be able to issue the same type of certificate (email, TLS, or EV TLS) that they are already approved for in Mozilla’s root store; and
• will operate both the cross-signed certificate and their CA certificate(s) under the same policies, practices, and scope of audit that their CA certificate was approved for. (Newer versions of policies and practices MAY be used, provided that the cross-signed CA operator follows the same versions of the policies for both the cross-signed certificate and their CA certificate(s).)

Best regards,

Dimitris.

[Ben Wilson]

See responses below.

On Tue, Apr 19, 2022 at 2:56 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:

Hi Ben,

Here are the comments from the HARICA team:


### 5.4 Precertificates ###
Certificate Transparency precertificates are considered by Mozilla to be a binding intent to issue a certificate, as described in section 3.1 of RFC 6962, and thus in-scope for enforcing compliance with these requirements. Thus,
* if a final certificate cannot be verified as matching a precertificate using the algorithms in RFC 6962, then two distinct final certificates are presumed to exist, and it is misissuance if the two final certificates have the same serial number and issuer, even if only one final certificate actually exists;
* if a precertificate implies the existence of a final certificate that does not comply with this policy, it is considered misissuance of the final certificate, even if the certificate does not actually exist;
* a CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under this policy, even if the final certificate does not actually exist; and
* a CA must provide CRL and OCSP services and responses in accordance with this policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist.


The term "final certificate" is not defined. Section 6.1.1 uses the term "end-entity". It looks a bit confusing. We understand the need to separate a "precertificate" from a "certificate" but perhaps the word "final" can be omitted.

Another nit: RFC 5280 uses the term "end entity" (without the hyphen).

I have added a link to RFC 6962, which uses the term "final certificate". I could not find any other industry-accepted term that we could use to convey the concept.

Although RFC 5280 does use "end entity certificate" (without the hyphen), the current MRSP already uses "end-entity certificate" with the hyphen, so changing it now would require that I replace it in those other places as well.  Should we add this as a GitHub issue to resolve in a future version of the MRSP?

 

Section 6.1.1
- cessationOfOperation

"the CA is made aware of any circumstance indicating that use of a fully‐qualified domain name or IP address in the certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a domain name registrant’s right to use the domain name, a relevant licensing or services agreement between the domain name registrant and the applicant has terminated, or the domain name registrant has failed to renew the domain name)."

This looks like a CA-driven revocationReason and seems to fit the privilegeWithdrawn reason better.

 

This third bullet, quoted above, is very similar to the other two bullets in this section for cessationofOperation ("the certificate subscriber no longer controls, or is no longer authorized to use, all of the domain names in the certificate;" "the certificate subscriber will no longer be using the certificate because they are discontinuing their website;").  Therefore, we think it fits here, too.  A subscriber can make the CA aware of such circumstances, and these circumstances might not constitute a violation of the certificate subscriber agreement (the intention of privilegeWithdrawn).

 

- superseded

• "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; or"
• "the CA has revoked the certificate for compliance reasons such as the certificate does not comply with this policy, the CA/Browser Forum's Baseline Requirements, or the CA’s CP or CPS."

Looking at these reasons, we have very similar intent for the reason "privilegeWithdrawn". Most probably, the intent of the revocationReason is to indicate why a certificate has been revoked. Relying Parties probably don't care if a new certificate has been issued to replace a revoked one or not, but are more interested on why a particular certificate was revoked.

What if we combine the second and third bullets (failure of domain/IP address verification and compliance reasons) to read, "the CA has revoked the certificate because it was not issued in full compliance with this policy, the CA/Browser Forum's Baseline Requirements, or the CA’s CP or CPS."?  The reason being that we want "superseded" to encompass certificate replacement situations where there has not been a Subscriber's breach (privilegeWithdrawn).

 

ITU-T X.509's description doesn't shed too much light either:

"superseded indicates that the public-key certificate has been superseded but there is no cause to suspect that the private key has been compromised."

We recommend adding these two bullets under the "privilegeWithdrawn" reason so that CAs have a "preferred" reason to indicate compliance, domain validation/authorization, subscriber violation issues.

It seems that "privilegeWithdrawn" best fits the six bulleted items already there.

 

In section 8.4:

• The subordinate CA operator will obtain a non-technically-constrained (per section 5.3.1 of this policy) CA certificate, and the subordinate CA operator is not approved by Mozilla to issue the type of certificates (email, TLS, or EV TLS), which they will be able to issue under the new CA certificate.
• The root CA operator is cross-signing a root certificate of a CA operator who is not currently in Mozilla’s root store.
• The root CA operator is cross-signing a root certificate of another CA operator who is currently in Mozilla’s root store, but the other CA operator has been approved for different trust bits (email, TLS, or EV TLS) than those trust bits that will be recognized under the cross-signed certificate that it will be receiving.

please consider the following changes:

• The subordinate CA operator will obtain an unconstrained (per section 5.3.1 of this policy) CA certificate, and the subordinate CA operator is not approved by Mozilla to issue the type of certificates (email, TLS, or EV TLS), which they will be able to issue under the new CA certificate.
• The root CA operator is cross-signing a CA certificate of a CA operator who is not currently in Mozilla’s root store.
• The root CA operator is cross-signing a CA certificate of another CA operator who is currently in Mozilla’s root store, but the other CA operator has been approved for different trust bits (email, websites), or EV, than those trust bits that will be recognized under the cross-signed certificate that it will be receiving.

 Thanks - I'll make those changes this afternoon.

Similarly, for the last bullet of the section

The root CA operator is cross-signing a root certificate of another CA operator that is currently in Mozilla’s root store, and that other CA operator:

• will only be able to issue the same type of certificate (email, TLS, or EV TLS) that they are already approved for in Mozilla’s root store; and
• will operate both the cross-signed certificate and their root certificate under the same policies, practices, and scope of audit that their root certificate was approved for. (Newer versions of policies and practices MAY be used, provided that the cross-signed CA operator follows the same versions of the policies for both the cross-signed certificate and their root certificate.)

please consider changing to:

The root CA operator is cross-signing a CA certificate of another CA operator that is currently in Mozilla’s root store, and that other CA operator:

• will only be able to issue the same type of certificate (email, TLS, or EV TLS) that they are already approved for in Mozilla’s root store; and
• will operate both the cross-signed certificate and their CA certificate(s) under the same policies, practices, and scope of audit that their CA certificate was approved for. (Newer versions of policies and practices MAY be used, provided that the cross-signed CA operator follows the same versions of the policies for both the cross-signed certificate and their CA certificate(s).)

These changes will be made, too.  Thanks.

Ben

Best regards,

Dimitris.

--

[Ben Wilson]

See an additional comment below:

On Tue, Apr 19, 2022 at 2:11 PM Ben Wilson <bwi...@mozilla.com> wrote:

See responses below.

On Tue, Apr 19, 2022 at 2:56 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:

Hi Ben,

Here are the comments from the HARICA team:

...

- superseded

• "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; or"
• "the CA has revoked the certificate for compliance reasons such as the certificate does not comply with this policy, the CA/Browser Forum's Baseline Requirements, or the CA’s CP or CPS."

Looking at these reasons, we have very similar intent for the reason "privilegeWithdrawn". Most probably, the intent of the revocationReason is to indicate why a certificate has been revoked. Relying Parties probably don't care if a new certificate has been issued to replace a revoked one or not, but are more interested on why a particular certificate was revoked.

What if we combine the second and third bullets (failure of domain/IP address verification and compliance reasons) to read, "the CA has revoked the certificate because it was not issued in full compliance with this policy, the CA/Browser Forum's Baseline Requirements, or the CA’s CP or CPS."?  The reason being that we want "superseded" to encompass certificate replacement situations where there has not been a Subscriber's breach (privilegeWithdrawn).

 

On second thought, I think that the second bullet under "superseded" can be deleted and that the third bullet can be left "as is".    So it would read,

The CRLReason superseded is intended to be used to indicate when:

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

[Rob Stradling]

> I have added a link to RFC 6962, which uses the term "final certificate". I could not find any other industry-accepted term that we could use to convey the concept.

FWIW, we got rid of the term "final certificate" in RFC9162 (CTv2), which talks instead about a precertificate and its "corresponding certificate" (and also about a certificate and its "corresponding precertificate").

Even though there are no deployments of RFC9162 at this time (AFAIK), I think it's reasonable to consider RFC9162's terminology as "industry-accepted".

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Ben Wilson <bwi...@mozilla.com>
Sent: 19 April 2022 21:11
To: Dimitris Zacharopoulos <ji...@it.auth.gr>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Policy 2.8: Final Review of MRSP v. 2.8

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

--
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/CA%2B1gtaYpMY%3DaqVz%2Bm7s%3DodvmLjGfgkstyO3Gjvg%2BsyJC23rfGg%40mail.gmail.com.

[Dustin Hollenback]

Hello Ben,

Our understanding is that the information in Section 5.4 Precertificates has been a Recommended Practice (https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates) for some time. Adding this new section changes it from a Recommended Practice to a Requirement.

Similar to Section 6.1.1 that has a new requirement, can you set an effective date within the section that is farther out than the 2.8 effective date. For consistency, I'd recommend setting the same date as another new section, 6.1.1, which is effective October 1, 2022.

Thank you,


Dustin

[Andrew Ayer]

On Tue, 19 Apr 2022 16:29:29 -0700 (PDT)
"'Dustin Hollenback' via dev-secur...@mozilla.org"

<dev-secur...@mozilla.org> wrote:

>
> Our understanding is that the information in Section 5.4
> Precertificates has been a Recommended Practice
> (https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates)
> for some time. Adding this new section changes it from a Recommended
> Practice to a Requirement.
>
> Similar to Section 6.1.1 that has a new requirement, can you set an
> effective date within the section that is farther out than the 2.8
> effective date. For consistency, I'd recommend setting the same date
> as another new section, 6.1.1, which is effective October 1, 2022.

The first two bullet points in Section 5.4 (about misissuance) are not
new requirements, but follow from from this statement in RFC6962:

"The signature on the TBSCertificate indicates the certificate
authority's intent to issue a certificate. This intent is considered
binding (i.e., misissuance of the Precertificate is considered equal to
misissuance of the final certificate)."

This has been covered on this list and in
incident reports ad nauseam since 2016, long before
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices even had
a Precertificates section. All Section 5.4 does is make the existing
requirements very explicit.

The last two bullet points in Section 5.4 (about revocation)
were originally listed on
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices as a
Required practice, as a clarification of Mozilla's existing
requirements, which some CAs had already been held accountable for
violating:

https://groups.google.com/g/mozilla.dev.security.policy/c/LC_y8yPDI9Q/m/S-aAK3r1BAAJ

However, they were moved to the Recommended section because of a
concern that they conflicted with the Baseline Requirements:

https://groups.google.com/g/mozilla.dev.security.policy/c/LC_y8yPDI9Q/m/FzKrQbQJBwAJ

This conflict was resolved in 2019 with the passage of SC23. Thus, CAs
have long been on notice about Mozilla's expectations and intentions.
Indeed, at least one CA already considers it a "clear" requirement to
operate revocation services for certificates presumed to exist based
on precertificates:

https://bugzilla.mozilla.org/show_bug.cgi?id=1763203#c1

Any CA that wasn't already compliant in 2019 has already had over
two years to resolve that.

I therefore see no reason why Section 5.4 needs a later effective date.

Regards,
Andrew

[Ben Wilson]

Hi Rob and Andrew,

"Corresponding certificate" seems to work, but are you OK with this for the first bullet? 

" * if a corresponding certificate cannot be verified as matching a precertificate using the algorithms in RFC 6962, then two distinct corresponding certificates are presumed to exist, and it is misissuance if the two corresponding certificates have the same serial number and issuer, even if only one corresponding certificate actually exists;"

Thanks,

Ben

[Jacob Hoffman-Andrews]

Separate from the "final" / "corresponding" question, I find this phrasing confusing:
 

" * if a corresponding certificate cannot be verified as matching a precertificate using the algorithms in RFC 6962, then two distinct corresponding certificates are presumed to exist, and it is misissuance if the two corresponding certificates have the same serial number and issuer, even if only one corresponding certificate actually exists;"

In particular the "if" in "it is misissuance if" is confusing, since it's actually unconditional: given that

 - the precertificate and the corresponding/final certificate exist,
 - have the same serial number,
 - either have the same issuer or are related via a Precertificate signing certificate
 - and don't match per RFC 6962

Then there's a misissuance; there's no "if" because the corresponding certificate that is presumed to exist is presumed to have the same serial and issuer. Also "matching a precertificate" is ambiguous: does it mean "a specific precertificate" or "any precertificate?"

For context, Andrew's original reason for proposing this text was:

> When a Precertificate Signing Certificate is used, the issuer of a

> precertificate and its corresponding certificate are not the same, but
> there could still be a duplicate serial number violation.

The duplicate serial number violation can happen when there are two corresponding certificates with the same issuer and serial, right? But that seems to be covered by the straightforward "no duplicate serials" rule. No exemption to the "no duplicate serials" rule need apply for setups with Precertificate Signing Certificates, because those setups specifically avoid the "same issuer and serial" problem.

Here's my stab at it, knowing this has been discussed many times before and it's challenging to write well:

 - "It is misissuance for two or more certificates to be issued with the same issuer and serial, with one exception: if exactly two certificates are issued with the same issuer and serial, and one of them is a precertificate, and one of them corresponds to that precertificate, it is not misissuance."

[Jacob Hoffman-Andrews]

> #### 6.1.1 End-Entity TLS Certificate CRLRevocation Reasons ####
> **affiliationChanged**
> The CRLReason affiliationChanged is intended to be used to indicate that the subject's name or other subject information in the certificate has changed

Is this meant to refer to Subject Identity Information as defined in the BRs? "Information that identifies the Certificate Subject. Subject Identity Information does not include a Domain Name listed in the subjectAltName extension or the Subject commonName field."

[Dimitris Zacharopoulos]

On 19/4/2022 11:11 μ.μ., Ben Wilson wrote:

See responses below.

[...]

Although RFC 5280 does use "end entity certificate" (without the hyphen), the current MRSP already uses "end-entity certificate" with the hyphen, so changing it now would require that I replace it in those other places as well.  Should we add this as a GitHub issue to resolve in a future version of the MRSP?

I don't have any strong feelings about this. I just noticed this subtle difference and brought it to the community's attention. I thought of it as similar to other proposed changes (SSL --> TLS, "CA operators", subordinate --> intermediate, etc).

 

Section 6.1.1
- cessationOfOperation

"the CA is made aware of any circumstance indicating that use of a fully‐qualified domain name or IP address in the certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a domain name registrant’s right to use the domain name, a relevant licensing or services agreement between the domain name registrant and the applicant has terminated, or the domain name registrant has failed to renew the domain name)."

This looks like a CA-driven revocationReason and seems to fit the privilegeWithdrawn reason better.

 

This third bullet, quoted above, is very similar to the other two bullets in this section for cessationofOperation ("the certificate subscriber no longer controls, or is no longer authorized to use, all of the domain names in the certificate;" "the certificate subscriber will no longer be using the certificate because they are discontinuing their website;").  Therefore, we think it fits here, too.  A subscriber can make the CA aware of such circumstances, and these circumstances might not constitute a violation of the certificate subscriber agreement (the intention of privilegeWithdrawn).

 

- superseded

• "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; or"
• "the CA has revoked the certificate for compliance reasons such as the certificate does not comply with this policy, the CA/Browser Forum's Baseline Requirements, or the CA’s CP or CPS."

Looking at these reasons, we have very similar intent for the reason "privilegeWithdrawn". Most probably, the intent of the revocationReason is to indicate why a certificate has been revoked. Relying Parties probably don't care if a new certificate has been issued to replace a revoked one or not, but are more interested on why a particular certificate was revoked.

What if we combine the second and third bullets (failure of domain/IP address verification and compliance reasons) to read, "the CA has revoked the certificate because it was not issued in full compliance with this policy, the CA/Browser Forum's Baseline Requirements, or the CA’s CP or CPS."?  The reason being that we want "superseded" to encompass certificate replacement situations where there has not been a Subscriber's breach (privilegeWithdrawn).

I guess the term "breach" is a bit ambiguous because the current wording in "privilegeWithdrawn" considers reasons like "the CA is made aware of a material change in the information contained in the certificate" which doesn't clearly indicate a Subscriber's breach.

If the intent is to add all related "subscriber-side violations/breach of subscriber agreement/terms-of-use" reasons under "privilegeWithdrawn", perhaps an opening paragraph describing this intention -similar to the opening paragraph of cessationOfOperation/affiliationChanged- is needed for privilegeWithdrawn as well.

 

ITU-T X.509's description doesn't shed too much light either:

"superseded indicates that the public-key certificate has been superseded but there is no cause to suspect that the private key has been compromised."

We recommend adding these two bullets under the "privilegeWithdrawn" reason so that CAs have a "preferred" reason to indicate compliance, domain validation/authorization, subscriber violation issues.

It seems that "privilegeWithdrawn" best fits the six bulleted items already there.

See above. If the intent is to separate the revocation reasons between a subscriber-side breach of the subscriber agreement/terms-of-use and a CA-side violation/failure with "privilegeWithdrawn" and "superseded" reasons respectively, then the bullet

• "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; or"

means that there was something wrong with the CA practices/implementation and validation information should not be relied upon; nothing caused by the Subscriber. If that's the case, then it's fine to remain under "superseded" as long as we clarify the intent a bit more. I believe the implementation by CAs would be easier if they knew that "privilegeWithdrawn" is targeted to subscriber-side violations and "superseded" to CA-side violations, without being able to predict cases which might fall under both :)

Dimitris.

[Dimitris Zacharopoulos]

Although the proposed text makes sense to be, perhaps there is another way to describe it.

The BRs (section 4.9.10) introduce useful terms that could be used to better describe this scenario:

"The OCSP responder MAY provide definitive responses about "reserved" certificate serial numbers, as if there was a corresponding Certificate that matches the Precertificate [RFC6962].

A certificate serial number within an OCSP request is one of the following three options:

1. "assigned" if a Certificate with that serial number has been issued by the Issuing CA, using any current or previous key associated with that CA subject; or
2. "reserved" if a Precertificate [RFC6962] with that serial number has been issued by a. the Issuing CA; or b. a Precertificate Signing Certificate [RFC6962] associated with the Issuing CA; or
3. "unused" if neither of the previous conditions are met."

Using parts of that text, I propose the following:

A certificate serial number is one of the following three options:

1. "assigned" if a Certificate with that serial number has been issued by the Issuing CA, using any current or previous key associated with that CA subject; or
2. "reserved" if a Precertificate [RFC6962] with that serial number has been issued by a. the Issuing CA; or b. a Precertificate Signing Certificate [RFC6962] associated with the Issuing CA; or
3. "unused" if neither of the previous conditions are met."

CAs SHALL NOT use the same "reserved" serial number for different Precertificates under the same Issuing CA, even if a corresponding Certificate does not actually exist.

Using the language from the BRs (changing MAY to a SHALL), I guess the last bullet of the proposed policy could also be replaced by:

• The OCSP responder SHALL provide definitive responses about "reserved" certificate serial numbers, as if there was a corresponding Certificate that matches the Precertificate [RFC6962]

since it mainly affects the OCSP service (CRLs only provide information about "revoked" certificates).

Thanks,
Dimitris.

[Dustin Hollenback]

Andrew,

I agree with you that while the entire Section 5.4 is new in the policy, the first two bullet points have been well understood as requirements for some time. I thought it would be easier to set an effective date for the entire section out of simplicity, but have no concern with not defining a future effective date for these first two bullet points.

For the last two bullet points, while I agree that they have been discussed for quite some time, they are still new MRSP requirements. And, while I fully agree with and support the requirement change, the ask is that there be a transition time for any new requirement once it is approved. As a general principle, this would be regardless of how much they have been discussed in the past as discussion does not always lead to something becoming a requirement.

With that said, I recommend the following text for section 5.4:

### 5.4 Precertificates ###
Certificate Transparency precertificates are considered by Mozilla to be a binding intent to issue a certificate, as described in [section 3.1 of RFC 6962][6962-3.1], and thus in-scope for enforcing compliance with these requirements. Thus,
* if a final certificate cannot be verified as matching a precertificate using the algorithms in RFC 6962, then two distinct final certificates are presumed to exist, and it is misissuance if the two final certificates have the same serial number and issuer, even if only one final certificate actually exists; and
* if a precertificate implies the existence of a final certificate that does not comply with this policy, it is considered misissuance of the final certificate, even if the certificate does not actually exist.

Effective October 1, 2022,

* a CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under this policy, even if the final certificate does not actually exist; and
* a CA must provide CRL and OCSP services and responses in accordance with this policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist.

Regards,


Dustin

[Andrew Ayer]

On Tue, 19 Apr 2022 20:40:37 -0700
"'Jacob Hoffman-Andrews' via dev-secur...@mozilla.org"

It's not necessary to provide an exception to the duplicate serial
number rule for precertificates, as this is already covered by the BRs'
exemption of precertificates.

As I understand it, the goal of this bullet point is not to add an
exception to misissuance, but to make sure that there is zero ambiguity
that incidents like the following are misissuances:

https://bugzilla.mozilla.org/show_bug.cgi?id=1677737

You're correct that this is technically already covered by the "no
duplicate serials" rule in conjunction with the presumption of
certificate existence based on a precertificate. However, CAs have
repeatedly struggled with understanding this presumption, so it seems
valuable to explicitly enumerate some of the implications of the
presumption.

I agree that this is hard to write well and could be improved but I
think your proposed rewrite takes us in the wrong direction.

Regards,
Andrew

[Andrew Ayer]

On Tue, 19 Apr 2022 20:56:25 -0600
Ben Wilson <bwi...@mozilla.com> wrote:

> Hi Rob and Andrew,
>
> "Corresponding certificate" seems to work, but are you OK with this
> for the first bullet?
>
> " * if a corresponding certificate cannot be verified as matching a
> precertificate using the algorithms in RFC 6962, then two distinct
> corresponding certificates are presumed to exist, and it is
> misissuance if the two corresponding certificates have the same
> serial number and issuer, even if only one corresponding certificate
> actually exists;"

I don't think "corresponding certificate" works here because only one of the
corresponding certificates actually corresponds to an extant precertificate.

I think we should stick with "final certificate" and add a simple definition:

A certificate that is not a precertificate [RFC 6962].

Regards,
Andrew

[Ben Wilson]

Jacob,

I think it should refer to the Subject Identity Information as defined in the BRs, but I am open to what others think.

Ben

[Ben Wilson]

What about this language?

### 5.4 Precertificates ###
The logging of a precertificate in a Certificate Transparency log is considered by Mozilla to be a binding intent to issue a final certificate, as described in [section 3.1 of RFC 6962][6962-3.1]. "Final certificate" means a certificate that is not a precertificate. Precertificates are in-scope for enforcing compliance with these requirements. Thus,

* if a final certificate cannot be verified as matching a precertificate using the algorithms in RFC 6962, then two distinct final certificates are presumed to exist, and it is misissuance if the two final certificates have the same serial number and issuer, even if only one final certificate actually exists;
* if a precertificate implies the existence of a final certificate that does not comply with this policy, it is considered misissuance of the final certificate, even if the certificate does not actually exist;
* a CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under this policy, even if the final certificate does not actually exist; and
* a CA must provide CRL and OCSP services and responses in accordance with this policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist.

[Andrew Ayer]

I think that's good.

Regards,
Andrew

On Wed, 20 Apr 2022 08:32:07 -0600

> --
> 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/CA%2B1gtaagwJLhZp%2BVz7qfJko46U2%3DC7OU2jLVRjuYAMzKQRttRQ%40mail.gmail.com.

[Corey Bonnell]

> As a general principle, this would be regardless of how much they have been discussed in the past as discussion does not always lead to something becoming a requirement.

I agree with Dustin. This message [1] made it clear that providing revocation information for pre-certificates is a recommended (but not required) practice:

"I've gone ahead and moved [4] to the "Recommended Practices" section.

The ballot to modify the BRs is now in the formal discussion period leading
up to a vote [5]."

I am unaware of any changes in the written requirements in the BRs or Mozilla Policy to make this a required practice until the MozPol 2.8 proposal. Given this, I believe a reasonable effective date should be included to give time for CAs to update their operations to comply.

Thanks,

Corey

[1] https://groups.google.com/g/mozilla.dev.security.policy/c/LC_y8yPDI9Q/m/tPrL7rNkBAAJ

[Corey Bonnell]

Hi Ben,

I believe the “Non-disclosable Intermediate Certificates” section of the “CA/Subordinate CA Checklist” Wiki page [1] should be deleted given that Mozilla is now requiring the disclosure of all TCSA certificates, regardless of technical constraints.

 

Thanks,

Corey

 

[1] https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Non-disclosable_Intermediate_Certificates

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson
Sent: Wednesday, April 13, 2022 1:18 PM
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Subject: Policy 2.8: Final Review of MRSP v. 2.8

 

All,

 

Here are links helpful during your final review of version 2.8 of the Mozilla Root Store Policy (MRSP) :

 

https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.8/rootstore/policy.md

https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.8 (redlined)

 

Please review the changes and provide any additional comments by the end of Tuesday, April 19, 2022.

 

My plan is to move this version over to the Mozilla pkipolicy repository on Github, and then I'll request that it be published on Mozilla's website to replace version 2.7.1.

 

Thanks,

 

Ben

--

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/CA%2B1gtaby8DypMdN2ih3xF_nf0FoshtaKUes-KC%2Baxfi-3cRiqw%40mail.gmail.com.

[Ben Wilson]

Thanks, Corey.

I'm wondering whether we should salvage anything in that section? We could rename it "Other PKI Hierarchies", delete the second paragraph and other wording that refers to "non-disclosable", etc., and make other tweaks to keep the section and the discussion of submitting an intermediate CA certificate as a trust anchor.   Thoughts anyone?

Thanks again,

Ben

[Corey Bonnell]

Hi Ben,

Does Mozilla allow for the inclusion of non-self-signed certificates as trust anchors? From a BR standpoint, the Root Certificate is self-signed (“Root Certificate” is defined as “The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.”). If I recall correctly, there were historical exceptions to this, but I don’t believe there have been any recently.

 

If Mozilla does not allow for the inclusion of non-self-signed certificates as trust anchors, then I think the entire section can be deleted as the “intermediate” CA (relative to another PKI hierarchy, presumably “private”) can certify itself and have the self-signed certificate included in Mozilla.

 

Thanks,

Corey

 

From: Ben Wilson <bwi...@mozilla.com>
Sent: Wednesday, April 20, 2022 2:00 PM
To: Corey Bonnell <Corey....@digicert.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>

[Ben Wilson]

Yes - Mozilla allows for the inclusion of non-self-signed certificates as trust anchors.

Ben

[Ben Wilson]

All,

Here are a couple of changes that were made today based on comments received:

MRSP 5.4 (Precertificates) - https://github.com/BenWilson-Mozilla/pkipolicy/commit/64b78a8b25855d0b7077e0b95707f3563b6c510a

MRSP 6.1.1 (CRLRevocation Reasons) - https://github.com/BenWilson-Mozilla/pkipolicy/commit/781a6c12c2f4770481af4f9070c0cec0acdf9342

I also decided to not make any changes to the "superseded" language in section 6.1.1.

Thanks,

Ben

[Ben Wilson]

All,

I believe this is one of the final issues for MRSP v. 2.8, which I'd like to resolve ASAP.  I'm leaning toward adding an effective date of October 1, 2022, for the last two bullets in section 5.4.

Ben

--

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/475eeac7-5fb2-433e-bd4e-c591593fc9ddn%40mozilla.org.

[Doug Beattie]

Hi Ben,

 

I wanted to ask a question about when revocation reasons and dates can be changed. 

 

The current wording is:

 

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. 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.

 

From this, I assume that the logic needs to be:

• Reason can be changed only from a non key compromise reason to the keyCompromise reason.
• When setting the date for an initial revocation for key compromise (and only key compromise), the revocationDate may be in the past.  Backdating for other reasons is not being endorsed by Mozilla and CAs should follow RFC5280
• Date can be changed only when the reason is keyCompromise (either when changing it to keyCompromise, or when reason was already keyCompromise, if it was determined that the date first provides was inaccurate.) 
• The date can be changed to a date that’s before the current/existing revocationDate  (never move it later than a previously set date)

 

Are you expecting CAs to update reasonCode or revocationDate in any other cases to support “TLS implementations that process the revocationDate field as the date when the certificate is first considered to be compromised”?  Given RFC 5280 recommends not backdating (or changing) revocation dates, we wanted to get clear guidance for what scenarios  Mozilla wants CAs to not follow the RFC5280 best practices. 

 

If we apply the “default deny” logic to the Mozilla Policy, I believe the logic I described above is an accurate representation, so perhaps no additional changes to the policy are needed, but wanted to double check I was not missing anything.

 

Doug

 

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson
Sent: Wednesday, April 13, 2022 1:18 PM
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Policy 2.8: Final Review of MRSP v. 2.8

 

All,

 

Here are links helpful during your final review of version 2.8 of the Mozilla Root Store Policy (MRSP) :

 

https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.8/rootstore/policy.md

https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.8 (redlined)

 

Please review the changes and provide any additional comments by the end of Tuesday, April 19, 2022.

 

My plan is to move this version over to the Mozilla pkipolicy repository on Github, and then I'll request that it be published on Mozilla's website to replace version 2.7.1.

 

Thanks,

 

Ben

--

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/CA%2B1gtaby8DypMdN2ih3xF_nf0FoshtaKUes-KC%2Baxfi-3cRiqw%40mail.gmail.com.

[Ben Wilson]

Hi Doug,

I believe your email correctly summarizes the policy.

You also asked whether we were "expecting CAs to update reasonCode or revocationDate in any other cases to support TLS implementations that process the revocationDate field as the date when the certificate is first considered to be compromised”.   I am not aware of any.  Maybe others are aware of such potential implementations.

I am unaware of any other situations where Mozilla policy allows divergence from RFC 5280 (in this particular area of revocation and CRL production), but I'm open to any corrections or clarifications from the community.

Thanks,

Ben

[Jacob Hoffman-Andrews]

On Wed, Apr 20, 2022 at 6:19 AM Andrew Ayer <ag...@andrewayer.name> wrote:

As I understand it, the goal of this bullet point is not to add an
exception to misissuance, but to make sure that there is zero ambiguity
that incidents like the following are misissuances:

https://bugzilla.mozilla.org/show_bug.cgi?id=1677737

This is useful context, thanks. FWIW, I don't think the current wording achieves that goal, since it is still quite hard to parse, even for someone who understands the requirements and how they interact.

Here's another take:

 - "It is mississuance to issue a certificate based on a precertificate if they do not exactly match each other according to RFC 6962 section 3.1. A certificate is 'based on' a precertificate if they have the same serial and issuer, or they have the same serial and the certificate's issuer matches the precertificate's issuer's issuer."

[Ben Wilson]

Should it say "final certificate" in this bullet?

[Ben Wilson]

Jacob and Andrew,

What if I just added this underlined language without replacing the first bullet?

"Precertificates are in-scope for enforcing compliance with these requirements.  It is mississuance to issue a final certificate based on a precertificate if they do not exactly match each other according to RFC 6962 section 3.1. A final certificate is 'based on' a precertificate if they have the same serial and issuer, or they have the same serial and the final certificate's issuer matches the precertificate's issuer's issuer.  Thus,  ..."

Ben

[Andrew Ayer]

I think Jacob's language (with your change to use "final certificate")
is good and would be OK replacing the first bullet with it. I'm also
OK with leaving the first bullet, but it seems redundant with the
new and improved language.

Regards,
Andrew

On Thu, 21 Apr 2022 15:48:34 -0600
Ben Wilson <bwi...@mozilla.com> wrote:

> Jacob and Andrew,
>
> What if I just added this underlined language without replacing the
> first bullet?
>
> "Precertificates are in-scope for enforcing compliance with these

> requirements. *It is mississuance to issue a final certificate based

> on a precertificate if they do not exactly match each other according
> to RFC 6962 section 3.1. A final certificate is 'based on' a
> precertificate if they have the same serial and issuer, or they have
> the same serial and the final certificate's issuer matches the

> precertificate's issuer's issuer.* Thus, ..."

[Ben Wilson]

OK - thanks.

[Ben Wilson]

See https://github.com/BenWilson-Mozilla/pkipolicy/commit/55066357d674adb8da4b8ee20b5cd60cf2b6f8bd

[Kathleen Wilson]

Hi Doug,

I added a new section to the wiki page, with the clarifications that you provided.

https://wiki.mozilla.org/CA/Revocation_Reasons#Updating_CRL_Entries

Thanks!

Kathleen

[Ben Wilson]

All,

We are changing the effective date of MRSP v. 2.8 from May 1, 2022, to June 1, 2022, to provide more time to finalize and publish the document and to send out the CA Communication and Survey, which will be emailed to CA representatives in mid-May. A read-only copy of the working draft of the Communication and Survey is stored here:  https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a058Z000013UmsDQAS. I am in the process of adding hyperlinks to the document.  Please review and provide feedback.

Thanks,

Ben

[Andrew Ayer]

I am concerned by effective date of October 1, 2022 for the last two
bullet points of Section 5.4 (Precertificates). Although some CAs have
argued that these are "new" requirements, they haven't explained _why_
they need this amount of time to become compliant, and for the reasons I
previously stated
<https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/-yDazqfWzN8/m/FvyoY6KfCQAJ>,
such a long phase-in period doesn't seem justifiable given the history.

The second-to-last bullet point is especially important, and if Mozilla
doesn't enforce it until October, then for the next 5+ months, CAs will
be allowed to leave misissued certificates unrevoked by simply claiming
that they never issued a final certificate, which no one has any way of
verifying.

Note that both of these bullet points are already implied by RFC6962's
statement that precertificates create a binding intent to issue a
certificate. CAs should not assume that other root programs have made
or will make an exception to RFC6962's implication. Apple and Chrome
likely have strong opinions here, since as CT-enforcing UAs, their
users have the most to lose from a weakening of a precertificate's
meaning. Unless these other root programs say otherwise, I will
continue reporting noncompliance observed by OCSP Watch even when the
only evidence of issuance is a precertificate.

Regards,
Andrew

[Ben Wilson]

Thanks, Andrew

I think it will be really helpful for OCSP Watch to monitor compliance based on precertificates going forward.

Ben

[Ben Wilson]

All,

During my final read-through, I noticed some things that I want to fix, in addition to minor grammar and punctuation (e.g. I'll replace the hyphen with a space between "end" and "entity" as requested by Dimitris and in accordance with usage in RFC 5280):

1 - In section 5.2, I'll change "included certificate" to "root certificate" or "included root certificate" to clarify that it applies to root certificates and not to intermediates and for consistency with the Baseline Requirements (see https://github.com/mozilla/pkipolicy/issues/242);

2 - I'll rephrase the sentence in section 5.3 which says that an "intermediate CA operator" "refers to any organization or legal entity ..." and move it to section 1 (because it is better to define CA operator earlier in the document); and

3 - in the much-discussed new section 6.1.1 (TLS revocation reasons) and in 6.2 (S/MIME revocation reasons), I'll replace most instances of "CA" with "CA operator" - for consistency with the rest of the MRSP.

I'll make those changes now, and then I'll circulate the Github commit that shows those changes when I'm done.

Ben

[Ben Wilson]

All,

Here are the changes mentioned in my previous email on this thread.

https://github.com/BenWilson-Mozilla/pkipolicy/commit/0c4201a2cfab4a68f82c99f4efcdc5bd14bf4785

And here is the blob - https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.8/rootstore/policy.md

Please provide any comments or questions.

Thanks,

Ben

[Corey Bonnell]

Hi Ben,

In giving the draft 2.8 policy another read, I found a potential inconsistency that should be resolved. Section 5.3.1 [1] says:

"If the intermediate CA certificate includes the id-kp-serverAuth extended key usage, then to be considered technically constrained, the certificate MUST be Name Constrained as described in section 7.1.5 of version 1.3 or later of the Baseline Requirements. The id-kp-clientAuth EKU MAY also be present. The conformance requirements defined in section 2.3 of this policy also apply to technically constrained intermediate certificates.

If the intermediate CA certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2.4 of the Baseline Requirements. The values id-kp-serverAuth and anyExtendedKeyUsage MUST NOT be present. id-kp-clientAuth MAY be present. Other values that the CA is allowed to use and are documented in the CA’s CP, CPS, or combined CP/CPS MAY be present."

In particular, the sentence "Other values that the CA is allowed to use and are documented in the CA’s CP, CPS, or combined CP/CPS MAY be present." should also be added to the paragraph for id-kp-serverAuth. Without that sentence, a "default deny" interpretation of that paragraph may lead some readers to the conclusion that other EKU values are not allowed.

Thanks,

Corey

[1] https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.8/rootstore/policy.md#531-technically-constrained

[Ryan Sleevi]

On Thu, Apr 28, 2022 at 11:29 AM 'Corey Bonnell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

Hi Ben,

In giving the draft 2.8 policy another read, I found a potential inconsistency that should be resolved. Section 5.3.1 [1] says:

"If the intermediate CA certificate includes the id-kp-serverAuth extended key usage, then to be considered technically constrained, the certificate MUST be Name Constrained as described in section 7.1.5 of version 1.3 or later of the Baseline Requirements. The id-kp-clientAuth EKU MAY also be present. The conformance requirements defined in section 2.3 of this policy also apply to technically constrained intermediate certificates.

If the intermediate CA certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2.4 of the Baseline Requirements. The values id-kp-serverAuth and anyExtendedKeyUsage MUST NOT be present. id-kp-clientAuth MAY be present. Other values that the CA is allowed to use and are documented in the CA’s CP, CPS, or combined CP/CPS MAY be present."

In particular, the sentence "Other values that the CA is allowed to use and are documented in the CA’s CP, CPS, or combined CP/CPS MAY be present." should also be added to the paragraph for id-kp-serverAuth. Without that sentence, a "default deny" interpretation of that paragraph may lead some readers to the conclusion that other EKU values are not allowed.

I don't believe this change is correct.

Having a multi-purpose server-auth certificate, even if technically constrained, seems to be a significant step back. While this is permitted for email, that is hopefully only temporary, to reflect the lack of maturity and secure design in the id-kp-emailProtection CA ecosystem. 

[Corey Bonnell]

Hi Ryan,

Comments inline.

 

> I don't believe this change is correct.

 

Well, the draft language seemingly doesn’t reflect the discussion on the associated policy thread [1]. I’d hope that even if there were a concrete prohibition (MUST NOT), it could be stated more clearly than a highly subtle “default deny” reading.

 

> Having a multi-purpose server-auth certificate, even if technically constrained, seems to be a significant step back. While this is permitted for email, that is hopefully only temporary, to reflect the lack of maturity and secure design in the id-kp-emailProtection CA ecosystem. 

 

I don’t quite follow why this is a step back, as it’s simply a restatement of the status quo (i.e., no steps taken). That’s not to say there can’t be further refinements in this area, but current language does not align with the discussion on the associated policy thread, namely [2], where it was stated there is a desire to align MRSP with the TLS BRs in this regard.

 

[1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/n1vLLXwNbuM/m/D6oEqHXgBAAJ

[2] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/n1vLLXwNbuM/m/atOa5QoFAQAJ

 

Thanks,

Corey

 

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Thursday, April 28, 2022 7:27 PM
To: Corey Bonnell <Corey....@digicert.com>

[Ryan Sleevi]

On Thu, Apr 28, 2022 at 8:47 PM Corey Bonnell <Corey....@digicert.com> wrote: 

I don’t quite follow why this is a step back, as it’s simply a restatement of the status quo (i.e., no steps taken). That’s not to say there can’t be further refinements in this area, but current language does not align with the discussion on the associated policy thread, namely [2], where it was stated there is a desire to align MRSP with the TLS BRs in this regard.

Your [2] has the context and discussion - and the related policy issue that prompted it. I realize you quoted midway from the discussion, but hopefully the further discussion clarifies?

[2] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/n1vLLXwNbuM/m/atOa5QoFAQAJ

[Ben Wilson]

Ryan and Corey,

If there are still issues, can we punt this into version 2.9?  Version 2.8 has been finalized and is going through the publication process today, which I was going to announce when it is up on the Mozilla website.

Thanks,

Ben