> 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: [email protected] <[email protected]> on behalf of Ben Wilson <[email protected]> Sent: 19 April 2022 21:11 To: Dimitris Zacharopoulos <[email protected]> Cc: [email protected] <[email protected]> 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. See responses below. On Tue, Apr 19, 2022 at 2:56 AM Dimitris Zacharopoulos <[email protected]<mailto:[email protected]>> 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. -- -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCA%252B1gtaYpMY%253DaqVz%252Bm7s%253DodvmLjGfgkstyO3Gjvg%252BsyJC23rfGg%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C01%7Crob%40sectigo.com%7C2a437dcf76d24a9cc72908da2240d756%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637859959146704860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=memvN1A0JMrT%2FCOoZRNO7xhcmqOuAoFfyiokWpEus2U%3D&reserved=0>. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB472940B74AB5413969505583AAF29%40MW4PR17MB4729.namprd17.prod.outlook.com.
