Russ, comments inline. -Rick
From: Trans [mailto:[email protected]] On Behalf Of Russ Housley Sent: Saturday, October 25, 2014 10:01 AM To: Rick Andrews; Steve Kent Cc: [email protected] Subject: Re: [Trans] Goals and generic mis-issuance fgramework 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. [Rick] In most cases, yes. If someone has access to the server configured with that certificate, they can do a TLS handshake and get the chain in nearly all cases. We see some web servers that are missing the intermediate CA cert, and some browsers (IE, for example) will follow the AIA extension (if it's in the cert) and fetch the intermediate. Any client can do that too. But if the CA didn't put an AIA extension in the cert and you can't find a server with that cert, it might not be possible to find the intermediate CA cert. And without the intermediate (or intermediates!) the log won't accept it. 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. [Rick] RFC 6962 and bis-04 say "If the log has previously seen the certificate, it MAY return the same SCT as it returned before." But this would have to be expanded to say "If the log has previously seen the certificate and CCID, it MAY return the same SCT as it returned before." It's a bit more complex, since the log server may not support the CCID or any checking, in which cases it would always log the entry with CCID =1 that indicates "This log does not perform syntax checks", or CCID=2 that indicates "This log does not support syntax checks for the asserted CCID". 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. [Rick] Yes, a relying party could leverage the work already done by the log server, if the RP trusted it. Google would probably advise against this, since they have been pretty consistent in saying that CT doesn't require you to trust anyone including the log server.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
