Re: [Trans] Certificate verification

[Stephen Kent <[e-mail]>]

Matt,

Fair question. If attribution is not possible, because we choose to not 
require
chaining to a root accepted by the log (as currently called for) then 
the attack
analysis will be updated to reflect this loss of security functionality 
in those
cases.

Note that my proposal to allow (not require) logs to perform syntactic 
checks,
and to note the result of such checks, is compatible with logs that 
choose to not
perform even basic path validation. It would be another class of (non) 
checks that
can be registered in the proposed IANA registry and reported by a log. 
Also, if
basic path validation is not performed, a log should advertise that, 
just as it
should advertise the set of root CAs that it does check. This allows 
Monitors and
clients to know what the log says it is doing, so that others do not 
have to guess
or learn by some unspecified, OOB means.

I suggest another registry entry for logging self-signed certs will make 
sense
too, if 6962-bis stops excluding them.

Steve


>     Is attribution critical for the core functionality of CT?  (I know this goes
>     back to the "purpose of CT" thread that Stephen's done a lot of work
>     defining, and I've got to get around to participating in that thread)  While
>     I agree that the remediation mechanisms available increase if you know which
>     root CA to hassle to get a cert revoked, knowledge that a cert was issued
>     still has *some* value, even if there's no clear indication of who issued it
>     (in a fanciful future of infinite storage, where self-signed certs were
>     accepted in logs).
>
>     - Matt
>