On 29/03/14 03:24, Peter Bowen wrote:
On Fri, Mar 28, 2014 at 9:46 AM, Rick Andrews <[email protected]> wrote:
We see another potential issue with the proposed PRIVATE option. Rob’s
current proposal would have us replace a domain label with the literal
string “<PRIVATE>” (without the quotes). However, we try to encode DN
components as PrintableString where possible, and angle brackets are not
part of the PrintableString set (the lowercase letters 'a' through 'z',
uppercase letters 'A' through 'Z', the digits '0' through '9', eleven
special characters ' = ( ) + , - . / : ? and space).
As a result, the type of the DN component would be PrintableString in the
real cert but utf8String in the pre-certificate, and that would cause
problems. I suggest using parentheses instead of angle brackets.
Instead of having "<PRIVATE>", what about replacing the redacted
string with a prefixed checksum of the part?
Assuming we specify CRC-32 with "+" as the prefix,
"mail.corp.example.com" would become "+6f993bb2.example.com". This
could also allow redacting only some labels:
"mail.secret.example.gov.xx" could become
"mail.+734313b7.example.gov.xx". This has the benefit of providing
privacy while allowing stronger matching of the certificate.
Hi Peter.
The aim of the PRIVATE option is to keep sub-domain names _completely
hidden_ from the Log, so I think that revealing any information about
them is problematic.
How long would it take an attacker to perform a dictionary attack to
discover that "6f993bb2" corresponds to "mail.corp" ?
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
