Eran,
...
> In principle that's true, but in practice we have seen many
instances where client software
> fails to perform checks established by standards. Thus logs
represent an opportunity to
> do a better job (since they are new code) and perhaps help save
clients from bad code.
Can we put the extra checks logs may do in the CtExtensions field of
the SCT? That way the additional checks can be defined in a separate
document.
In principal I agree that providing extra information to TLS clients
about the certificates they receive is useful. Given it's not entirely
clear what clients do with this information (and complicates the log
implementation) my only suggestion is we make this an extension rather
than a mandatory part of the spec.
I identified two reasons for including cert type assertion in the log
request and
adding that plus cert syntactic validation results in the SCT. One,
noted above,
is that many TLS clients have, historically, not done a good job of cert
syntax checking,
and this represents an opportunity to help improve that situation.
Second, the current
(and previous) text is vague about what checks a log does perform when
performing
cert path validation. Using the cert type assertion and allowing a log
to advertise
what types of checks it performs (based on IANA-registered values)
removes this ambiguity
for submitters.
I think the cert type marking and checking info should be included in
the base spec, if only to
address the second problem
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
