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

On 31/03/14 23:04, Doug Beattie wrote:
> 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)?

I sincerely hope that the end result of the CT effort is _not_ that 
"no-body will ever look at" Precertificates.

If nobody performs the Monitor role (i.e. watching the CT logs for 
Precertificates of interest) then CT won't achieve its potential as an 
effective mechanism for detecting certificate mis-issuance!

Like I said, I'm not too bothered about what string literal we end up 
using.  But since there doesn't seem to be any real need to optimize for 
size, let's prioritize clarity.

Do both "?." and "(PRIVATE)." convey the intending "private 
subdomain(s)" meaning equally well?

> 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).

I think we should support a mixture of private and non-private SANs in a 
cert.

> 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.

The Certificate needs to indicate, _for each SAN_, the number of domain 
components that are masked in the Precertificate, so that the browser is 
able to reconstruct the Precertificate precisely.

An indicator at the SCT extension level, rather than for each SAN, just 
wouldn't be enough.

> Doug
>
> -----Original Message-----
> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Peter Bowen
> Sent: Monday, March 31, 2014 10:57 AM
> To: Rob Stradling
> Cc: trans@ietf.org; Rick Andrews
> Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
>
> On Mon, Mar 31, 2014 at 7:01 AM, Rob Stradling <rob.stradling@comodo.com>
> wrote:
>> On 31/03/14 14:44, Peter Bowen wrote:
>>> 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?
>
> 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
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
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.