Re: [Trans] defining "mis-issuance"

[Stephen Kent <[e-mail]>]

Rob,
> On 01/10/14 16:05, Stephen Kent wrote:
> <snip>
>> Rick,
> <snip>
>> Still, your point is a good one.  We could push the syntax checking back
>> to Monitors, but then we loose the ability to provide immediate feedback
>> to CAs that are issuing syntactically malformed certs. I'll have to 
>> think
>> more about this issue.
>
> Stephen,
> The "ability to provide immediate feedback to CAs that are issuing 
> syntactically malformed certs" sounds like a nice idea, but surely 
> this could be implemented as a stand-alone application or web service?
> Why would you want it to be an intrinsic part of CT?
The motivation for making it part of CT arose when Ben explained that 
his definition of mis-issuance included syntactic constraints from the 
CABF context.  The notion that immediate feedback is
desirable is consistent with the overall CT goal of forcing CAs to do 
something by threatening
that there certs will be rejected by browsers, only translated to logs :-).

Still, your argument that logs ought not reject certs that fail to meet 
syntactic criteria,
so that all TLS clients can benefit from detection of mis-issued certs 
detection via
examination of logs, is compelling.

I have a suggested solution:

     - require a CA submitting a pre-cert to assert one of the following:
         1. no assertion is made wrt syntactic conformance to CABF 
guudelines
         2. the cert conforms to DV Guidelines <insert guideline version>
         3. the cert conforms to EV guidelines <insert guideline version>

     - require a log to include the CA assertion in its SCT, along with 
one of the following:
         1. this log does not check cert syntax
         2. this log cannot check the specified CABF Guidelne version 
asserted by the CA
         3. this log checked the cert against the CA's assertion and it 
passed
         4. this log checked the cert against the CA's assertion and it 
failed

This would seem to address the concern that rejecting (not logging) a 
submitted cert is
worse than logging a bad cert. It also addresses the concern that Rick 
mentioned, i.e.,
a mismatch between what Guideline version a CA is using vs. what a log 
can verify. It
does not require that every log perform ANY syntax checking, and it lets 
Monitors and
clients know whether a log has elected to no perform such checks. It 
also tells a Monitor
which set of cert syntax rules the CA says it is enforcing, so that the 
Monitor can perform
the checks. If the log doesn't perform checks, or is unable to check a 
specific version of
the syntax checks, the Monitor can step in do so. The Monitor also can 
double check the
log, to detect logs that are not doing the checks properly, e.g., 
because of errors, compromise,
or conspiracy. This provides Monitors and clients with additional info 
when choosing which logs
to use.

Would this mechanism address your concerns?

Steve