On 31/03/14 14:44, Peter Bowen wrote:
On Mon, Mar 31, 2014 at 3:10 AM, Rob Stradling <[email protected]> wrote:
On 29/03/14 03:24, Peter Bowen wrote:
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 has the benefit of providing
privacy while allowing stronger matching of the certificate.
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.
If _completely_hidden_ is the requirement, then I agree that any
option that is no f(x) = 1 (for fixed values of 1) fails.
Why have the long string "(PRIVATE)" at all then? Would a single '?'
not be adequate? I don't think you will ever find '?' in a real
dNSName.
"PRIVATE" seemed a good choice of string literal from the point of view
of explaining the idea clearly, but I'm not bothered what string literal
we end up using.
Why does the length of the string literal concern you?
On a related note, is there any plan to support blinding other general
name options? Can email addresses in rfc822Name or ipAddresses be
blinded?
What part(s) of an IP Address could reasonably be blinded?
I think blinding part of an rfc822Name value could be useful, although
I'm not sure it's really in scope for RFC6962-bis.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
