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

[Russ Housley <[e-mail]>]

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