Re: [Trans] Goals and generic mis-issuance fgramework

[Santosh Chokhani <[e-mail]>]

Eran,

See in-line below.

From: Eran Messeri [mailto:[e-mail]]
Sent: Tuesday, October 28, 2014 12:46 PM
To: Santosh Chokhani
Cc: Rick Andrews; Russ Housley; Steve Kent; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Rick Andrews
Sent: Monday, October 27, 2014 6:33 PM
To: Russ Housley; Steve Kent

Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

Russ, comments inline.

-Rick

From: Trans [mailto:[e-mail]] On Behalf Of Russ Housley
Sent: Saturday, October 25, 2014 10:01 AM
To: Rick Andrews; Steve Kent
Cc: [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/trans