Re: [Trans] Precertificates and revocation

[Rob Stradling <[e-mail]>]

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

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited