Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)

[Rob Stradling <[e-mail]>]

On 31/03/14 14:44, Peter Bowen wrote:
> On Mon, Mar 31, 2014 at 3:10 AM, Rob Stradling <[e-mail]> 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