On 06/03/17 21:22, Ben Laurie wrote:
I think you can waste a lot of brainpower on redaction, but really the
answer is: if you don't want to publish your names, then don't use a
mechanism that requires you to.
I agree that that's the ideal answer, but as we've seen, there is
resistance to that answer from various participants in the CT ecosystem.
There are alternatives: name-constrained sub-CAs.
We removed that option from 6962-bis. It's now in
draft-strad-trans-redaction, but IIRC the Chrome team hinted that
they're unlikely to ever support it (at least in its current form).
Private CAs. You can even have private CT to go along with them.
Private CAs don't suit every use case, AFAIK.
Why mess up a protocol whose intent is to show everything?
Because Security and Useability aren't always in perfect harmony?
Much as I'd love to stop wasting brainpower on redaction, I think it's a
conversation that needs to continue for now (although not indefinitely!)
On 6 March 2017 at 21:16, Rob Stradling wrote:
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
<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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/trans
<https://www.ietf.org/mailman/listinfo/trans>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
