See responses below.
On Tue, Apr 19, 2022 at 2:56 AM Dimitris Zacharopoulos <[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].
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.
