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.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
