I think Eran's proposal is a definite improvement (compared to the
current 6962-bis redaction mechanism), because it makes client
implementation simpler and more robust.
I agree that Andrew's extension of Eran's proposal is an elegant fix to
the SCT re-use attack. However, I'd like to propose an alternative...
1. When redacting a LABEL in the "redacted SAN" extension, the issuer
replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of just
"?".
2. If the client desires stronger SCT matching, it checks that each
redacted label in the redacted SAN extension matches the corresponding
label in the SAN extension, by computing HASH(SERIAL_NUMBER||LABEL),
where SERIAL_NUMBER is the serial number of the certificate.
Advantages:
- Slightly simpler than Andrew's proposal. (i.e. no SALT needs to be
generated, put into a certificate extension, then removed to reconstruct
the TBSCertificate).
- Provides a (partial) technical solution to 'un'redaction (which is
something that needs to be addressed before Chrome will ever support
redaction [1]): If a domain owner's certificate team observes an
unexpected precertificate, they can calculate HASH(SERIAL_NUMBER||LABEL)
for all of the LABELs they manage.
Disadvantages:
- A dictionary attack might reveal the LABEL. It wouldn't be
possible to compute a rainbow table to generalize this attack, because
the SERIAL_NUMBER is different for each certificate.
If there's an effective way to solve the 'un'redaction problem purely
via policy, then I'd say Andrew's proposal is superior. However, if
there isn't, then perhaps my proposal is a necessary compromise.
[1]
https://groups.google.com/a/chromium.org/d/msg/ct-policy/vsTzv8oNcws/imuC3iloBwAJ
On 17/06/16 22:33, Daniel Kahn Gillmor wrote:
On Fri 2016-06-17 07:02:12 -0400, Eran Messeri wrote:
In short: Rather than describe how the client should modify the labels in
SAN extension to get to the redacted form that was logged, the issuer will
generate the redacted SAN extension and log it, as a part of the
TBSCertificate submitted to the log.
I like this proposal.
A clarification:
It took me a second to realize that the "redacted SAN extension" is
*also* present in the issued certificate, alongside the normal SAN
extension. the SCT is only over the TBSCertificate without the normal
SAN extension.
Disadvantages:
- The commonName in the subject field cannot be redacted this way.
This is not a problem. the CA/Browser Forum Baseline requirements say
that the commonName in the Subject field is "Deprecated (Discouraged,
but not prohibited)"
A user who really cares about redaction can simply leave out the
commonName in the Subject field.
I also think Andrew Ayer's extension of this proposal (the "Redacted
Labels Salt" extension) is an elegant fix to the remaining technical
concern about redacted SCT abuse.
I would support their inclusion in 6962-bis.
--dkg
--
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
