Policy 2.8: MRSP Issue #138: Make it clear that RFC 9162 precertificates are covered by Mozilla policy

142 views
Skip to first unread message

Ben Wilson

unread,
Jan 16, 2022, 5:50:56 PM1/16/22
to dev-secur...@mozilla.org
All,

This email introduces discussion of Github Issue #138, which is to add section 5.4 to the Mozilla Root Store Policy to address Certificate Transparency precertificates. 

While Mozilla does not have a policy requiring pre-publication of certificates via Certificate Transparency, we consider CT precertificates to be a binding intent to issue as described in RFC 9162, which raises a number of compliance issues when not done correctly. Thus, the MRSP needs to make certain statements about precertificates, as outlined below.

Here is a redline: 

The proposed text that would be added is:  

5.4 Precertificates

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

  • if any certificates with the same serial number and issuer exist, and one cannot be verified as the precertificate matching the final certificate using the algorithms in RFC 9162, this will be considered misissuance;
  • issuance of a precertificate that does not comply with this policy is considered equal to misissuance of a final certificate;
  • 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.
Please provide any comments in this thread.

Thanks,

Ben

Andrew Ayer

unread,
Jan 16, 2022, 10:24:47 PM1/16/22
to Ben Wilson, dev-secur...@mozilla.org
Hi Ben,

Comments inline:

> - if any certificates with the same serial number and issuer
> exist, and one cannot be verified as the precertificate matching the
> final certificate using the algorithms in RFC 9162, this will be
> considered misissuance;

1. No one has implemented RFC 9162 and its algorithms for
precertificate/certificate reconstruction are not the same as RFC 6962's,
so the above reference should be changed to RFC 6962.

Although RFC 9162 does add some good clarifying language that also applies
to CT version 1 (e.g. Section 3.2.1), it is for the most part a brand new,
incompatible protocol, and in general Mozilla policy needs to reference
RFC 6962 because it describes the system that is actually deployed.

2. 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. I propose
this text instead:

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

> - issuance of a precertificate that does not comply with this
> policy is considered equal to misissuance of a final certificate;

This language is very similar to the language in RFC 6962 which has
caused a lot of confusion so I would be more explicit. I propose:

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

This is good language.

Regards,
Andrew
Reply all
Reply to author
Forward
0 new messages