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