Subject: [Trans] Precertificates and revocation

From: Rob Stradling <[email-masked]>
Date: Fri, 20 Sep 2019 13:52:27 +0000

[This topic came up on mozilla.dev.security.policy recently.  Although 
the focus there is on the currently deployed CT v1 ecosystem, ISTM that 
TRANS should consider if/how CT v2 (6962-bis) should address the same issue]

How should revocation servers behave when a precertificate exists but 
the corresponding certificate has not yet been (or will never be) issued?

Should it be possible to revoke a precertificate when the corresponding 
certificate has not been issued?

In RFC6962, precertificates are X.509 certificates, and so it's not 
unreasonable to expect OCSP responders to be able to provide their 
status.  However, 6962-bis precertificates are not X.509 certificates, 
which I think changes what might or might not be a reasonable expectation.

Andrew points out (see forwarded message below) that outside observers 
have to assume that a certificate has been issued when they see a 
corresponding precertificate (since the presumed-to-exist certificate 
may never be submitted to a log), and that outside observers will expect 
CAs to operate revocation services for the presumed-to-exist certificates.

Back to CT v1: Mozilla now requires [1] that...
"- A CA must provide OCSP services and responses in accordance with 
Mozilla policy for all certificates presumed to exist based on the 
presence of a Precertificate, 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 Mozilla policy, even if 
the certificate does not actually exist."

ISTM that we should address this topic in 6962-bis somehow, but what do 
folks think we could say without straying into "policy"?

[1] 
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

-------- Forwarded Message --------
Subject: Re: DigiCert OCSP services returns 1 byte
Date: Mon, 16 Sep 2019 10:08:00 -0700
From: Andrew Ayer <[email-masked]>
To: Rob Stradling <[email-masked]>
CC: [email-masked]

On Fri, 13 Sep 2019 08:22:21 +0000
Rob Stradling via dev-security-policy
<[email-masked]> wrote:

> Thinking aloud...
> Does anything need to be clarified in 6962-bis though?

Yes, it's long past time that we clarified what this means:

"This signature indicates the CA's intent to issue the certificate.  This
intent is considered binding (i.e., misissuance of the precertificate is
considered equivalent to misissuance of the corresponding certificate)."

The goal is that a precertificate signature creates an unrebuttable
presumption that the CA has issued the corresponding certificate. If a
CA issues a precertificate, outside observers will treat the CA as if
it had issued the corresponding certificate - whether or not the CA
really did - so the CA should behave accordingly.

It's worth explicitly mentioning the implications of this:

* The CA needs to operate revocation services for the corresponding
certificate as if the certificate had been issued.

* If the corresponding certificate would be misissued, the CA will be
treated as if it had really issued that certificate.

Are there any other implications that 6962-bis should call out
explicitly?

Regards,
Andrew

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 20 Sep 2019 12:16:07 -0400

As I mentioned elsewhere, I'm not sure this is an entirely useful or
productive concern to be raising at this time. I have also shared that I
think this is a question of policy than protocol, even though the policy
decision has implications on other protocols. Thus I think it's much more
appropriately discussed among individual implementations.

As a protocol for allowing both the pre-disclosure of a certificate and
post-disclosure of a certificate. We saw, rather extensively in the Threat
Model document, different perspectives on policies regarding how
pre-disclosure should be treated and handled. For example, using the
protocol in 6962 or -bis, it's possible to use CT as a means of detecting
and correcting certificates prior to issuance (the discussion about Logs
applying rules to certificates). Similarly, it's possible for CT as a
protocol to be used entirely internal to an organization, as part of audit
logging for external audits via a common protocol, even with the inclusion
of data that might otherwise be inappropriate for publicly-exposed logs.

So I do think that, from the point of view of the RFCs, it's a matter of
policy as to how the existence of a pre-certificate is treated, which
aligns with the particular intended deployment of the CT protocol. If a
policy (e.g. by a browser, for the Web PKI) treats the issuance of a
pre-certificate as an unrebuttable proof of an equivalent certificate,
which is certainly one of the core things CT enables policy to state, then
it naturally follows that it must be treated as such within protocols that
are keyed on the issuance of certificates.

It's an operational concern, defined by local policy, as to what impact, if
any, it has on other protocols. Just as RFC 5280 does not define, for
example, what forms of names to include within a distinguished name, I'm
not convinced that this would even belong in 6962-bis, because it covers
the operational aspects and implications of a PKI that may use, in part or
whole, these RFCs.

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 20 Sep 2019 20:03:33 +0200

In the case of a precert subordinate CA, the CRLDP and AIA:ocsp will
contain the URLs of the real CA (the one that issued the precert sub CA).
How is it supposed to work? In a CTv1 world.

Le ven. 20 sept. 2019 à 15:52, Rob Stradling <[email-masked]> a écrit :

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
-- 
Erwann.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 23 Sep 2019 11:21:13 +0000

If 6962-bis says nothing about this topic, then ISTM that the default 
effective requirement will be that a CA MUST NOT provide OCSP status for 
a (CT v2) precertificate where the corresponding certificate has not 
(yet) been issued.  This is because, whichever way you look at it, a CT 
v2 precertificate is not a "certificate" according to 
RFC5280/RFC6960/RFC5019.

I agree that a statement such as "CAs MUST provide OCSP status for CT v2 
precertificates" would not belong in 6962-bis, but would instead belong 
in a TLS client policy document.  However, I would prefer to avoid the 
situation where 6962-bis has an effective MUST NOT but where (some, but 
not necessarily all) TLS client policies have a MUST.  In order to avoid 
such a conflict, I think it would be helpful for 6962-bis to outline the 
policy space by making the following points:

1. Since issuance of a precertificate `P` is a binding commitment to 
issue a corresponding certificate `C`, monitors may reasonably assume 
that `C` has been issued.
2. It follows that monitors may wish to request status information 
(e.g., via CRL and/or OCSP) for the serial number of `P`, even though 
(unbeknownst to the monitor) `C` has not actually been issued.
3. Although `P` is not a "certificate" according to 
RFC5280/RFC6960/RFC5019, some TLS clients may have policies that require 
CAs to provide certificate status (e.g., signed OCSP responses and/or 
CRLs) for the serial number of `P`, regardless of whether or not `C` has 
been issued.

Making these points would transform 6962-bis's effective requirement 
from a MUST NOT into a MAY.  A TLS client policy could then profile that 
to a MUST without introducing any conflict.

ISTM that this approach of outlining the policy space but not setting 
policy would be consistent with, for example, 
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-33#section-6.1.

On 20/09/2019 17:16, Ryan Sleevi wrote:
> decision has implications on other protocols. Thus I think it's much 
> more appropriately discussed among individual implementations.
> 
> post-disclosure of a certificate. We saw, rather extensively in the 
> Threat Model document, different perspectives on policies regarding how 
> protocol in 6962 or -bis, it's possible to use CT as a means of 
> detecting and correcting certificates prior to issuance (the discussion 
> about Logs applying rules to certificates). Similarly, it's possible for 
> CT as a protocol to be used entirely internal to an organization, as 
> part of audit logging for external audits via a common protocol, even 
> with the inclusion of data that might otherwise be inappropriate for 
> publicly-exposed logs.
> 
> which is certainly one of the core things CT enables policy to state, 
> then it naturally follows that it must be treated as such within 
> protocols that are keyed on the issuance of certificates.
> 
> It's an operational concern, defined by local policy, as to what impact, 
> if any, it has on other protocols. Just as RFC 5280 does not define, for 
> the operational aspects and implications of a PKI that may use, in part 
> or whole, these RFCs.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

---

From: Eran Messeri <[email-masked]>
Date: Wed, 25 Sep 2019 17:58:18 +0100

Rob, what leads you to say that "6962-bis has an effective MUST NOT"
regarding the CA not having to provide status information for a 6962-bis
precertificate?

I agree it'd be helpful to add a clarification in 6962-bis regarding CAs
possibly being asked about revocation status of a not-yet-issued
certificate. I just want to understand where 6962-bis prevents CAs from
publishing revocation info for 6962-bis precerts.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 26 Sep 2019 16:40:03 +0000

Hi Eran.  OCSP (RFC6960, RFC5019) responses and CRLs (RFC5280) provide status information for certificates (RFC5280).  In CTv1 (RFC6962), precertificates are certificates; whereas in CTv2 (6962-bis), precertificates are (by design!) not certificates.

The "effective MUST NOT" is because anything that is not a certificate (be it a CTv2 precertificate, a cat GIF, or whatever) is not in scope for OCSP, as currently specified.

The fact that a CTv2 precertificate has a serial number that is intended to subsequently belong to a certificate makes it possible to imagine extending the OCSP protocol to report statuses of CTv2 precertificates.  But until the OCSP protocol is extended in this way, the fact is that...the OCSP protocol has not yet been extended in this way.

I think 6962-bis should extend the OCSP protocol in this way.  If it can be avoided, I don't think it should be left to CT client policies to extend IETF protocols.

________________________________
From: Eran Messeri <[email-masked]>
Sent: 25 September 2019 17:58
To: Rob Stradling <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Trans] Precertificates and revocation

Rob, what leads you to say that "6962-bis has an effective MUST NOT" regarding the CA not having to provide status information for a 6962-bis precertificate?

I agree it'd be helpful to add a clarification in 6962-bis regarding CAs possibly being asked about revocation status of a not-yet-issued certificate. I just want to understand where 6962-bis prevents CAs from publishing revocation info for 6962-bis precerts.

On Mon, Sep 23, 2019 at 12:21 PM Rob Stradling <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

---

From: Rob Stradling <[email-masked]>
Date: Mon, 30 Sep 2019 16:11:50 +0000

On 20/09/2019 19:03, Erwann Abalea wrote:
> contain the URLs of the real CA (the one that issued the precert sub 
> CA). How is it supposed to work? In a CTv1 world.

Hi Erwann.

In a CTv1 world, ISTM that the current situation is the same for CAs 
that do and for CAs that don't use a precert subordinate CA.

1. As far as Mozilla is concerned, it is now a "Required Practice" (but 
not yet "Policy") that a CA MUST provide OCSP status for a 
precertificate, acting as if the corresponding certificate has been 
issued (even if it hasn't actually (yet) been issued).

2. As far as other consumers of the CABForum Baseline Requirements are 
concerned, OCSP is a certificate status protocol, and (according to the 
BRs) a precertificate is not a certificate.  Therefore, CAs 
(effectively) MUST NOT provide OCSP status for a precertificate, unless 
the corresponding certificate has actually been issued.

To resolve this conflict, there is a draft ballot being discussed on the 
CABForum public list:
https://cabforum.org/pipermail/servercert-wg/2019-September/001097.html

Until this conflict is resolved, all WebPKI CAs are out of compliance 
with either 1 or 2.  :-(

> Le ven. 20 sept. 2019 à 15:52, Rob Stradling <[email-masked] 
> <mailto:[email-masked]>> a écrit :
> 
>     From: Andrew Ayer <[email-masked] <mailto:[email-masked]>>
>     To: Rob Stradling <[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>
> 
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>      > Thinking aloud...
>     [email-masked] <mailto:[email-masked]>

Email: [email-masked]
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.