Re: [Trans] defining "mis-issuance"

[Ben Laurie <[e-mail]>]

On 2 October 2014 17:13, Stephen Kent <[e-mail]> wrote:
> 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

Presumably this would apply to certs as well as precerts, which is the
other reason rejecting isn't particularly helpful (certs are already
issued by the time they're logged!).

> 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
>
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans