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