… even WITHOUT 184.108.40.206.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 <firstname.lastname@example.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 220.127.116.11.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 <email@example.com <mailto:firstname.lastname@example.org> > Subject: Re: [cabfpub] Applicability of BRs to Client Authentication certificates On Thu, Apr 12, 2018 at 1:11 PM, Jeff Ward via Public <email@example.com <mailto:firstname.lastname@example.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 18.104.22.168.22.214.171.124.2 and does not include 126.96.36.199.188.8.131.52.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 184.108.40.206.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 220.127.116.11.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 18.104.22.168.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?
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public