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:[email protected]] On Behalf Of Peter Bowen
Sent: Monday, March 31, 2014 10:57 AM
To: Rob Stradling
Cc: [email protected]; 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 protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
