In that case, how about including the CCID and the results of the checks the log performed in the get-sth response, but not in the SCT itself?
The log could still sign the complete get-sth reply so submitters get a confirmation it is indeed the log which performed the checks, and TLS clients will not be burdened with handling another field in the SCT there's no immediate use for. As I said, I see the value in getting an "independent opinion" on the validity of a chain submitted to the log (both in syntactic and semantic compliance perspectives) and is much more useful than the current error handling approach (where the log returns a vague error). I just like to exclude this information from being embedded in the SCT if it's not useful for TLS clients. On Tue, Oct 28, 2014 at 7:27 PM, Santosh Chokhani <[email protected]> wrote: > Eran, > > > > See in-line below. > > > > *From:* Eran Messeri [mailto:[email protected]] > *Sent:* Tuesday, October 28, 2014 12:46 PM > *To:* Santosh Chokhani > *Cc:* Rick Andrews; Russ Housley; Steve Kent; [email protected] > *Subject:* Re: [Trans] Goals and generic mis-issuance fgramework > > > > Overall the mechanism described seems reasonable. Can you help me > understand the benefits from the TLS client's perspective? > > *[Santosh] The primary benefit would have come if the log had enforced and > not registered a mal-formed certificate. Log acceptance of certificate > seems to what the WG prefers. In that case, benefits to the client are > reduced. * > > > > IIUC, the log will never refuse to include a certificate, it will merely > indicate it failed syntactic checks. > > Are you suggesting that TLS clients will reject an otherwise-valid > certificate chain which has a CCID that matches the TLS client's desired > use of the certificate, because the log indicated it failed syntactic > checks? > > *[Santosh] That could be one thing. What I was saying in the thread is > that even if the Log said that the certificate passed the checks, client > must do its own path validation unless the client and log are using the > same chain and same 5280 path validation initialization variables.* > > > > *One advantage of logs doing checking and rejecting the certificates is > that the human user will not go through the error-prone decision making > about the security ramification of failed path validation.* > > > > It's not a bad thing, it does place additional burden on logs though. > Monitors will have to verify the log's honest behaviour on this aspect as > well. > > > > The other question is - aren't certificate classes different enough to > merit running different logs, where the log's identity (or some other > metadata) indicates which CCID it's good for? > > I'm a bit weary of specifying a behaviour for the general case where I > don't have concrete examples for more than one particular case. > > *[Santosh] To my knowledge, lot of path checks are the same. Different > classes of certificates may warrant checking KU, EKU and extracting and > matching names from different fields (say Subject DN or SAN).* > > > > On Tue, Oct 28, 2014 at 2:09 AM, Santosh Chokhani <[email protected]> > wrote: > > Relying parties relying on the checks made by log server may be > problematic if both do not have the same trust store if the initialization > variables are different. > > > > My primary motivation in log doing checks is nip the problem in the bud > and reduce the probability of relying parties having to decide on > exceptions. The relying parties still should validate the certification > path. > > > > *From:* Trans [mailto:[email protected]] *On Behalf Of *Rick Andrews > *Sent:* Monday, October 27, 2014 6:33 PM > *To:* Russ Housley; Steve Kent > > > *Cc:* [email protected] > *Subject:* Re: [Trans] Goals and generic mis-issuance fgramework > > > > Russ, comments inline. > > > > -Rick > > > > *From:* Trans [mailto:[email protected] <[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 > > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
