[cabfpub] Defining BR scope

[Jeremy Rowley]

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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160126/f49e68ed/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160126/f49e68ed/attachment-0001.p7s>