Rob,
On 20/07/15 15:20, Stephen Kent wrote:
> Rob,
>
> I'm glad we agree that rejecting a cert is protocol behavior, not
> just a UI issue.
>
> We can't assume that incremental deployment will ever be "complete."
> I've been told by one major browser vendor that they like the logging
> and Monitor aspects of CT, but do not see browser behavior as a
> critical element. Thus they do not plan to make their browsers reject
> certs (maybe not even discriminate) based on the lack of an SCT.
That's interesting, thanks.
I'm not sure how it relates to the point we're discussing though. If a
browser is never going to reject certs that are not accompanied by an
SCT, it doesn't need an incremental deployment plan that's designed to
help it get to the point where it can reject certs that are not
accompanied by an SCT.
agreed, tautologically.
> Given the history of browser behavior wrt cert revocation status
> checking, this is not a surprising perspective.
I am a bit surprised, actually. Some browsers no longer perform
out-of-band revocation checks by contacting CA revocation servers
directly, but they do still process revocation information passed
in-band (i.e. OCSP Stapling).
yes, some do. Having a server pass the OCSP data is analogous to having
it pass an
SCT, and we've been told that it will take too long for that to happen,
hence the embedded
SCT in a cert feature of CT.
SCTs are passed in-band.
Yes, but 6962-bis says that TLS clients MAY contact a log to get a proof
for the SCT,
and the gossip proposal relies on clients contacting logs to acquire
STHs. So, ...
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
