On 13/4/2022 8:18 μ.μ., Ben Wilson 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
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.
--
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/ecb2348f-deca-7089-dc64-fb3b1a2d79a2%40it.auth.gr.
