[cabfpub] Ballot 92 - Subject Alternative Names

[Steve Roylance]

Morning Ryan,
So what you are saying below, is that because there are a few clients out
there that can only support CN  (CN = mail or CN =192.168.2.1 for example)
then it's acceptable (until Nov 2015) for CAs to offer single dimensional
'intranet' certificates with no other verified content? (This is what Rich
was first eluding to in his initial post)

Does this not mean an attacker could very easily build up a portfolio of
attack certs with various internal names and IPs and pretty much zero
traceability?

Or are you saying (unlike Rich) that other details should be added?  That's
what we are saying with ballot 92.  We are simply saying that to deter
hackers we need to know the details of the entity to add to the Subject O
field and not that they simply have control/access to an FQDN which also may
be untraceable when it comes to investigation/crunch time.

See lines 14/15/16 and 34/35/36 on my spreadsheet with the examples I
created to illustrate the situations we wish to prevent.

I hope it's clear that this is both from a security perspective and as
Jeremy already answered last night, relying party understanding perspective.

Have a great weekend and no doubt speak to you on Monday's call ;-)

Steve
      


From:  Ryan Sleevi <sleevi at google.com>
Date:  Thursday, 15 November 2012 22:26
To:  Eddy Nigg <eddy_nigg at startcom.org>
Cc:  <public at cabforum.org>
Subject:  Re: [cabfpub] Ballot 92 - Subject Alternative Names

On Thu, Nov 15, 2012 at 2:10 PM, Eddy Nigg (StartCom Ltd.)
<eddy_nigg at startcom.org> wrote:
>     
>  
>  On 11/15/2012 11:52 PM, From Rich Smith:
>>     
>>  
>> 
>> Since many clients and servers will still choke on a cert with no Common
>> Name.
>>  
>>  
>  
>  Rich, can you please give me real examples of commonly used browsers and
> servers that wouldn't work? Much appreciated.
>  
>  
>    
>  Regards   
>     
>  Signer:  Eddy Nigg, COO/CTO
>    StartCom Ltd. <http://www.startcom.org>
>  XMPP:  startcom at startcom.org
>  Blog:  Join the Revolution! <http://blog.startcom.org>
>  Twitter:  Follow Me <http://twitter.com/eddy_nigg>
>       
>  
>  
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> 
> 
> I don't know if the volume is many, but I have seen a variety of
> vendor-proprietary implementations that behave as Rich describes.
> 
> However, I don't think think the volume of affected clients matter - the whole
> point of permitting entries in the CN (in addition to the SAN) is to support
> such clients.
> 
> For any new client, which supports SAN, what benefits does this provide /
> security threats does this address?
>  - I would suggest none, since any SAN-supporting client will ignore the CN
> 
> For any old client, which does not support SAN, what benefits does this
> provide / security threats does this address?
>   - Given that internal IPs / hostnames are still permissible in the SAN, I
> would suggest none.
> 
> 
> I'm certainly sympathetic to the argument "The UI [might be] ambiguous", but I
> think that's a different problem, and arguably address[ed/able] today by
> requiring the value of the CN match one of the values of the SANs, so it
> remains unclear to me.
> _______________________________________________ Public mailing list
> Public at cabforum.orghttps://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121116/6cb2a5d1/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ballot92 alternative content spreadsheet.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 32016 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121116/6cb2a5d1/attachment-0002.xlsx>