… even WITHOUT 7.1.2.3.f …

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek 
via Public
Sent: Thursday, April 12, 2018 1:25 PM
To: Ryan Sleevi <sle...@google.com>; CA/Browser Forum Public Discussion List 
<public@cabforum.org>; Jeff Ward <jw...@bdo.com>
Subject: Re: [cabfpub] Applicability of BRs to Client Authentication 
certificates

 

I think there’s a  problem with the overview, even with 7.1.2.3.f.

 

Clearly, if your certificate *can* be used for server authentication, you 
shouldn’t be able to get out of the BRs merely because you do not use or intend 
to use it that way.

 

-Tim

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, April 12, 2018 1:20 PM
To: Jeff Ward <jw...@bdo.com <mailto:jw...@bdo.com> >; CA/Browser Forum Public 
Discussion List <public@cabforum.org <mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Applicability of BRs to Client Authentication 
certificates

 

 

 

On Thu, Apr 12, 2018 at 1:11 PM, Jeff Ward via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

I am submitting this request on behalf of the WebTrust Task Force.  We would 
like to seek clarification from the CA/B Forum on the applicability of the 
Baseline Requirements for certificates that chain to a Root in a browser root 
store, which are only used for TLS Web Client Authentication (i.e. the EKU 
includes 1.3.6.1.5.5.7.3.2 and does not include 1.3.6.1.5.5.7.3.1).

 

Section 1.1 Overview states, in part, “These Requirements only address 
Certificates intended to be used for authenticating servers accessible through 
the Internet”.

 

This suggests that the BRs only apply to TLS Web Server Authentication.

 

However, Section 7.1.2.3.f, Subscriber Certificate (extKeyUsage) states, in 
part, “Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth 
[RFC5280] or both values MUST be present.

 

This is quite clear that they do apply to certificates that are only for TLS 
Web Client Authentication, but this contradicts the Overview section.

 

Additionally, the word ‘server’ is used throughout the BRs without an actual 
definition, and it is therefore unclear of the applicability of these sectiosn 
to certificates that are only for TLS Web Client Authentication.

 

For example, Section 7.1.4.2.1 Subject Alternative Name Extension:

 

“Certificate Field: extensions:subjectAltName

Required/Optional: Required

Contents: This extension MUST contain at least one entry. Each entry MUST be 
either a dNSName containing the Fully-Qualified Domain Name or an iPAddress 
containing the IP address of a server. The CA MUST confirm that the Applicant 
controls the Fully-Qualified Domain Name or IP address or has been granted the 
right to use it by the Domain Name Registrant or IP address assignee, as 
appropriate. Wildcard FQDNs are permitted.”

 

It is ambiguous as to whether this apples to a Client Authentication-only 
certificate. Additionally, there are questions on whether additional entry 
types (for example, DirName) may be acceptable in a Client Authentication-only 
certificate.

 

Our ask of the CA/B Forum would be to:

 

1.    Clarify whether or not the BRs apply to Client Authentication-only 
certificates, and update the BRs to explicitly state whether they apply or 
don’t.

2.    If they do apply, then to update the BRs to ensure there is no ambiguity 
between a ‘server’ and a ‘client’, and if any updates need to be made to 
address different requirements for Client Authentication-only certificates.

 

Thank you for your assistance.

 

Jeff

 

Hi Jeff,

 

To make sure I understand this feedback - do you believe this same confusion 
exists if we ignore 7.1.2.3.f? That is, I'm trying to understand if that is the 
*source* of the confusion, or merely contributing to it. If there are other 
contributing factors that suggest client scope, could you clarify?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to