On 06/03/17 06:06, Peter Bowen wrote:
<snip>
8) The only way to get the content of a full certificate is to have a
full certificate.
Rationale: An alternative option is to have some sort of escrow key
that can "unlock" a precertificate.
In previous iterations of 6962-bis, we proposed a redaction mechanism
that envisaged replacing domains labels with ?s in precertificates.
That mechanism was deemed problematic by the Chrome team precisely
because "The only way to get the content of a full certificate is to
have a full certificate".
What recourse does a domain owner have when they discover a
precertificate for their domain space that they don't recognize? How do
they figure out whether the (pre)cert was misissued or whether it was
legitimately requested by a different team within their organization?
The redaction mechanism that's documented in
https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3
attempted to find a solution to this problem of recourse by swapping ?s
for a hash of the unredacted domain. However, this mechanism has also
been deemed problematic, because it could be trivial to determine
unredacted labels via dictionary attacks.
I think a "sort of escrow key" may be the only viable way to construct a
redaction mechanism that is deemed non-problematic by everyone.
This quickly turns into 'where do we keep the escrow key?' and 'who gets
to access the escrow key?'. If there is no such thing, then these
questions don't exist.
I think these questions will need to be both asked and answered,
although I'd be delighted to be proved wrong.
Do others agree that these are true and can be used as givens for
reviewing any proposed designs?
Your other points all LGTM.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
