Steve and Rick: > > 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.”.
Can't anyone build the certificate chain? Since the logs are posting the supported trust anchors, anyone can build a chain for the end entity certificate. > > 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. Alternatively, a log could check to see if the reported certificate is already present, and if so, return the older entry to the party that reports the certificate. I seem to recall reading this idea at some point, buy I admit I did not look into the current I-D to see if that was where i read it. > > 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. If the log performs some validation checks, are you suggesting that a relying party can leverage the work already done by the log? If so, it puts the log checking at a different place in the certificate validation than I was imagining. Russ
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
