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

From: Rick Andrews <[email-masked]>
Date: Fri, 28 Mar 2014 09:46:41 -0700

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.

-Rick

---

From: Peter Bowen <[email-masked]>
Date: Fri, 28 Mar 2014 20:24:57 -0700

On Fri, Mar 28, 2014 at 9:46 AM, Rick Andrews <[email-masked]> 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.

Thanks,
Peter

---

From: Rob Stradling <[email-masked]>
Date: Mon, 31 Mar 2014 10:57:00 +0100

Rick, thanks for this.  Good catch!

Yes, parentheses would definitely be better.

On 28/03/14 16:46, Rick Andrews wrote:
> 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.
> -Rick

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Rob Stradling <[email-masked]>
Date: Mon, 31 Mar 2014 11:10:39 +0100

> 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" ?

---

From: Peter Bowen <[email-masked]>
Date: Mon, 31 Mar 2014 06:44:35 -0700

On Mon, Mar 31, 2014 at 3:10 AM, Rob Stradling <[email-masked]> wrote:
>> "mail.corp.example.com" would become "+6f993bb2.example.com".  [...]
>> This has the benefit of providing
> 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.
On a related note, is there any plan to support blinding other general
name options?  Can email addresses in rfc822Name or ipAddresses be
blinded?

Thanks,
Peter

---

From: Rob Stradling <[email-masked]>
Date: Mon, 31 Mar 2014 15:01:16 +0100

> not be adequate?  I don't think you will ever find '?' in a real

"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?

> name options?  Can email addresses in rfc822Name or ipAddresses be

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.

---

From: Peter Bowen <[email-masked]>
Date: Mon, 31 Mar 2014 07:57:13 -0700

On Mon, Mar 31, 2014 at 7:01 AM, Rob Stradling <[email-masked]> wrote:
> "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.
>

I guess it does not really matter.  I was thinking about the future,
when CT is used for the CDN certificates with hundreds of SANs.
Moving "www" -> "(PRIVATE)" for 200 names increases the size 1200
bytes.  Maybe additional size is not a big deal.

Thanks,
Peter

---

From: Rob Stradling <[email-masked]>
Date: Mon, 31 Mar 2014 22:05:16 +0100

> bytes.  Maybe additional size is not a big deal.

"(PRIVATE)" will appear in some Precertificates.  Precertificates will 
be generated by CAs, stored by CT Logs, and dynamically reconstructed by 
TLS Clients.

"(PRIVATE)" will _not_ appear in Server Certificates sent by TLS Servers 
to TLS Clients.  So if you're concerned about the impact of "(PRIVATE)" 
on TLS handshake sizes, you needn't be.

---

From: "Doug Beattie" <[email-masked]>
Date: Mon, 31 Mar 2014 18:04:57 -0400

I agree with Peter on this one, why are we making a long human readable
string for a cert that basically no-body will ever look at and will be used
only by the browser to validate the SCT (and the CA to create the SCT
extension)?  When the browser tries to validate an SSL certificate they need
an indication that the SCTs were computed normally or via the Private
algorithm. Aren't all the SANs either private or not in a cert, and not a
mix?  (sorry if this is in a spec or an email that I missed).

It seems like the indicator to the browser should be at the SCT extension
level, not on every SAN entry (there could be hundreds), so we could omit
any indication of private at the per-san level.  If it needs to be at the
SAN level (for some reason), then put in a valid PrintableString character
(maybe 2) we'd never expect to see in the wild.

I'm sure I'm missing a key point.

Doug

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Peter Bowen
Sent: Monday, March 31, 2014 10:57 AM
To: Rob Stradling
Cc: [email-masked]; Rick Andrews
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)

On Mon, Mar 31, 2014 at 7:01 AM, Rob Stradling <[email-masked]>
wrote:
> "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.
>

I guess it does not really matter.  I was thinking about the future, when CT
is used for the CDN certificates with hundreds of SANs.
Moving "www" -> "(PRIVATE)" for 200 names increases the size 1200 bytes.
Maybe additional size is not a big deal.

Thanks,
Peter

_______________________________________________
Trans mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trans