Re: [cabfpub] Applicability of BRs to Client Authentication certificates
Thanks for the prompt thoughts guys, it’s in good hands! Jeff Ward, CPA, CGMA, CITP, CISA, CISSP, CEH Office Managing Partner & National Leader Third Party Attestation (SOC/WebTrust/Cybersecurity) 314-889-1220 (Direct)347-1220 (Internal) 314-889-1221 (Fax) jw...@bdo.com<mailto:jw...@bdo.com> BDO 101 S Hanley Rd, #800 St. Louis, MO 63105 UNITED STATES 314-889-1100 www.bdo.com<http://www.bdo.com> Please consider the environment before printing this e-mail From: Tim Hollebeek [mailto:tim.holleb...@digicert.com] Sent: Thursday, April 12, 2018 1:15 PM To: Ryan Sleevi ; Jeff Ward Cc: CA/Browser Forum Public Discussion List Subject: RE: [cabfpub] Applicability of BRs to Client Authentication certificates It’s a good time to do it, too, since after governance reform, we want to be able to quickly know which certificates are in scope for which working groups. We discussed this at a few F2Fs. -Tim From: Ryan Sleevi [mailto:sle...@google.com] Sent: Thursday, April 12, 2018 1:54 PM To: Jeff Ward mailto:jw...@bdo.com>> Cc: Tim Hollebeek mailto:tim.holleb...@digicert.com>>; CA/Browser Forum Public Discussion List mailto:public@cabforum.org>> Subject: Re: [cabfpub] Applicability of BRs to Client Authentication certificates On Thu, Apr 12, 2018 at 1:45 PM, Jeff Ward mailto:jw...@bdo.com>> wrote: If 7.1.2.3.f is ignored, it is less confusing, but there is still potential ambiguity as to what ‘authenticating a server accessible through the Internet’ means. It would be best if the BRs clearly specified the technical characteristics of identifying a certificate that is ‘in-scope’. In that regard, I think we're in violent agreement. Root Programs have undertaken this to some extent, but it would be good to revisit clarification, hopefully now that more CAs are aware of the problems posed. BDO USA, LLP, a Delaware limited liability partnership, is the U.S. member of BDO International Limited, a UK company limited by guarantee, and forms part of the international BDO network of independent member firms. BDO is the brand name for the BDO network and for each of the BDO Member Firms. IMPORTANT NOTICES The contents of this email and any attachments to it may contain privileged and confidential information from BDO USA, LLP. This information is only for the viewing or use of the intended recipient. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of, or the taking of any action in reliance upon, the information contained in this e-mail, or any of the attachments to this e-mail, is strictly prohibited and that this e-mail and all of the attachments to this e-mail, if any, must be immediately returned to BDO USA, LLP or destroyed and, in either case, this e-mail and all attachments to this e-mail must be immediately deleted from your computer without making any copies hereof. If you have received this e-mail in error, please notify BDO USA, LLP by e-mail immediately. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Applicability of BRs to Client Authentication certificates
It’s a good time to do it, too, since after governance reform, we want to be able to quickly know which certificates are in scope for which working groups. We discussed this at a few F2Fs. -Tim From: Ryan Sleevi [mailto:sle...@google.com] Sent: Thursday, April 12, 2018 1:54 PM To: Jeff Ward Cc: Tim Hollebeek ; CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] Applicability of BRs to Client Authentication certificates On Thu, Apr 12, 2018 at 1:45 PM, Jeff Ward mailto:jw...@bdo.com> > wrote: If 7.1.2.3.f is ignored, it is less confusing, but there is still potential ambiguity as to what ‘authenticating a server accessible through the Internet’ means. It would be best if the BRs clearly specified the technical characteristics of identifying a certificate that is ‘in-scope’. In that regard, I think we're in violent agreement. Root Programs have undertaken this to some extent, but it would be good to revisit clarification, hopefully now that more CAs are aware of the problems posed. smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Applicability of BRs to Client Authentication certificates
On Thu, Apr 12, 2018 at 1:45 PM, Jeff Ward wrote: > If 7.1.2.3.f is ignored, it is less confusing, but there is still > potential ambiguity as to what ‘authenticating a server accessible through > the Internet’ means. It would be best if the BRs clearly specified the > technical characteristics of identifying a certificate that is ‘in-scope’. > In that regard, I think we're in violent agreement. Root Programs have undertaken this to some extent, but it would be good to revisit clarification, hopefully now that more CAs are aware of the problems posed. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Applicability of BRs to Client Authentication certificates
If 7.1.2.3.f is ignored, it is less confusing, but there is still potential ambiguity as to what ‘authenticating a server accessible through the Internet’ means. It would be best if the BRs clearly specified the technical characteristics of identifying a certificate that is ‘in-scope’. Thanks guys. Jeff Ward, CPA, CGMA, CITP, CISA, CISSP, CEH Office Managing Partner & National Leader Third Party Attestation (SOC/WebTrust/Cybersecurity) 314-889-1220 (Direct)347-1220 (Internal) 314-889-1221 (Fax) jw...@bdo.com<mailto:jw...@bdo.com> BDO 101 S Hanley Rd, #800 St. Louis, MO 63105 UNITED STATES 314-889-1100 www.bdo.com<http://www.bdo.com> Please consider the environment before printing this e-mail From: Tim Hollebeek [mailto:tim.holleb...@digicert.com] Sent: Thursday, April 12, 2018 12:26 PM To: Tim Hollebeek ; CA/Browser Forum Public Discussion List ; Ryan Sleevi ; Jeff Ward Subject: RE: [cabfpub] Applicability of BRs to Client Authentication certificates … 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 mailto:sle...@google.com>>; CA/Browser Forum Public Discussion List mailto:public@cabforum.org>>; Jeff Ward mailto: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 mailto:jw...@bdo.com>>; CA/Browser Forum Public Discussion List 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 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? BDO USA, LLP, a Delaware limited liability partnership, is the U.S. member of BDO International Limited, a UK company l
Re: [cabfpub] Applicability of BRs to Client Authentication certificates
… 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 ; CA/Browser Forum Public Discussion List ; Jeff Ward 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 mailto:jw...@bdo.com> >; CA/Browser Forum Public Discussion List 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 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? smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
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 ; CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] Applicability of BRs to Client Authentication certificates On Thu, Apr 12, 2018 at 1:11 PM, Jeff Ward via Public 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? smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Applicability of BRs to Client Authentication certificates
On Thu, Apr 12, 2018 at 1:11 PM, Jeff Ward via Public 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? ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
