[cabfpub] Defining BR scope

[Rob Stradling]

Do any modern browsers still match domain names and IP addresses against 
the Subject Common Name?  If so, are we anywhere near the point where 
they could stop doing this?

I'm wondering if we could define the scope of the BRs to consider not 
just the EKU extension, but also the SAN extension.  (I forget if this 
has been proposed previously - apologies if it has).

My suggestion is:
   - In scope if the EKU extension is present and contains 
"serverAuthentication".
   - In scope if the EKU is "unconstrained" (i.e. the EKU extension is 
absent, or the EKU extension is present and contains 
"anyExtendedKeyUsage") *AND* at least one SAN.dNSName and/or one 
SAN.iPAddress is present.
   - Out of scope otherwise.

Presumably certs that "aren't intended" for server authentication won't 
contain any dNSName(s) and/or iPAddress(es)?

On 26/01/16 21:55, Jeremy Rowley wrote:
> Agreed – and a very poor statement of inclusion since the proof is
> completely subjective on whether the user intended the cert for server
> authentication.  We’ve already seen cases where the cert is clearly able
> to be used for server authentication even if the intent wasn’t
> originally there. Sure the proposal I made was deficient, but it at
> least gave a date when all certs would be compliant (even if it is 5
> years down the roead). Right now there is no future date when all certs
> would be compliant.
>
> *From:*public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> *On Behalf Of *Peter Bowen
> *Sent:* Monday, January 25, 2016 7:45 PM
> *To:* Ryan Sleevi
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] Defining BR scope
>
>     On Jan 25, 2016, at 1:39 PM, Ryan Sleevi <sleevi at google.com
>     <mailto:sleevi at google.com>> wrote:
>
>     On Fri, Jan 22, 2016 at 8:07 AM, Peter Bowen <pzb at amzn.com
>     <mailto:pzb at amzn.com>> wrote:
>
>         I don’t disagree with this assessment, but the current state of
>         affairs, as I understand it, is that any end-entity certificate
>         that is clearly not for server authentication is already
>         excluded.  Many browsers (or should I say ASSes to be BR
>         compliant?) already operate trust stores that recognize a single
>         root to be trusted to issue various kinds of certificates.
>         Mozilla recognizes kp-emailProtection in addition to
>         kp-serverAuth (and still includes kp-codeSigning for many
>         roots), Microsoft recognizes six key purposes other than
>         kp-serverAuth (and includes another four for many roots), and
>         Apple seems to have many recognized key purposes.
>
>     I'm not sure I understand your remark that "any end-entity
>     certificate that is clearly not for server authentication is already
>     excluded.", and was hoping you could explain you see how that flows.
>     I can speculate the reasoning, but would probably explain it poorly,
>     so I was hoping you could expand on where you see the non-BR
>     compliance carveouts being.
>
> The BRs state:
>
> "These Requirements only address Certificates intended to be used for
> authenticating servers accessible through the Internet. Similar
> requirements for code signing, S/MIME, time‐stamping, VoIP, IM, Web
> services, etc. may be covered in future versions.”
>
> This language is in v1.3.1 and was in v1.0.  Based on the wording, I
> think it is clear that it is a statement of inclusion rather than a
> statement of exclusion, meaning that the default state is not covered by
> BR and Certificates are only covered by BR when they are "intended to be
> used for authenticating servers accessible through the Internet”.
>
> Thanks,
>
> Peter
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>

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