Stephen, Some comments inline.
-Rick From: Trans [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Thursday, October 09, 2014 2:21 PM To: [email protected] Subject: [Trans] Goals and generic mis-issuance fgramework In response to some of the issues Paul and others have raised, I have generated some text that tries to characterize the goal of CT, establishes a generic framnework for defining checks for mis-issuance, and sets the stage for references to two RFcs that will define syntactic and semantic checks for Web PKI certs claiming to conform to CABF DV or EV guidelines. Note that this text do not require a log to perform any checks; it allows a log to indicate if has performed applicable checks, and the results of such checking. Steve ------- 1. Certificate Transparency Goals and Mechanisms The goals of Certificate Transparency (CT) are threefold: detection, deterrence, and enabling remediation of mis-issuance of certificates. The initial focus of CT is the Web PKI context, (The Web PKI context refers to the use of a set of Certification Authorities (CAs) that issue X.509 certificates to web servers to enable TLS-protected access by clients [cite WPKOPS?].) In the future, it is anticipated that addition *additional* operational contexts may be supported. As a result, mis-issuance is defined in an fashion that accommodates a range of types of certificates used in a range of contexts. CT supports detection of mis-issuance using logs of certificates, populated by the CAs that issue them or by the Subjects of certificates. Monitors (described in Section X) are the primary elements of the CT system that check certificates for syntactic and semantic mis-issuance, on behalf of Subjects. A Monitor may be operated by a third party on behalf of Subjects, or may be operated by a Subject on its own behalf. (The latter is referred to as "self-monitoring".) Logs may optionally perform syntactic checks for some classes of certificates, but a log is not required to offer certificate checking. The first sentence needs to be more broad, since anyone can send a cert to a log. But it's most likely to be the CAs or the Subjects, so I would suggest "CT supports detection of mis-issuance using logs of certificates, populated by the CAs that issue them, by the Subjects of certificates, or by anyone with knowledge of the entire certificate chain.". To enable Monitors (and, optionally, logs) to perform an appropriate set of checks, the (pre-) a CCID MUST be provided to a log when a certificate is submitted by a CA or Subject. This CCID MUST appear in the log entry and in the SCT generated by the log. By providing the CCID in logs and SCTs, both Monitors and clients are empowered to perform applicable checks based on the certificate class asserted by the CA or Subject. Hmm... Since anyone can send a cert to a log, the first sentence must reflect that. But that makes me wonder what should happen if the "Reporter" (I don't want to introduce a new role) sends the wrong CCID? (By "wrong" I mean it's a valid CCID, but it's not the one that the CA would associate with the cert.) Or sends the cert multiple times with different CCIDs? I guess Monitors would have to expect multiple entries for a given certificate in a given log, with different CCIDs. I'm not sure if 6962-bis imposes any uniqueness constraint that this might violate. A log MUST generate a Syntax Verification Value (SVV) for the certificate, and include the SVV in the log entry and in the SCT. The LVV *SVV* is *a* value specified by this document (see Section Z) that indicates whether or not the log performed applicable syntactic checks, and whether the (pre-) certificate passed of *or* failed the checks. Although it is anticipated that new certificate classes will arise over time, the set of log actions with respect to syntax checking appears to be well-defined and thus need not be represented in an IANA registry. Each SCT issued by a log MUST include an SVV. Value Interpretation 0 The CCID value was 0, so not *no* checks were performed 1 This log does not perform syntax checks 2 This log does not support syntax checks for the asserted CCID 3 This log performed the syntax checks for the asserted CCID, and the certificate passed 4 This log performed the syntax checks for the asserted CCID, and the certificate failed No other SVV values are defined by this RFC.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
