[cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.

Tom Albertson tomalb at microsoft.com
Thu Jul 18 18:23:38 UTC 2013


I wanted to comment on the question of industry support for Section 13.2.6, which this ballot builds upon. We may want to consider amending it now instead of proceeding further with the language in 13.2.6, as this ballot does.  In fact ballot 105 compounds our earlier error in dictating product design details to OCSP responder vendors without thinking very heavily about the impact. It's our collective mistake - let's not make it worse.

The section 13.2.6 amendment proposed by Ballot 105 reads as follows:


13.2.6 Response for non-issued certificates

If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. The CA SHOULD monitor the responder for such requests as part of its security response procedures.


Effective 1 August 2013, OCSP responders for MUST NOT CAs which are not Technically Constrained in line with Section 9.7 MUST NOT respond with a "good" status for such certificates.

The current version of Section 13.2.6 requires OCSP responders to not respond with a Good status for non-issued certificates.  OCSP responder that couldn't comply had to be modified by the 1 August 2013 deadline.    The amendment in this ballot 105 provides a limitation on the earlier restriction: it says OCSP responders for CAs which are not Technically Constrained must not respond with a Good status for non-issued certificates.  Let's untwist the double negative to ensure we understand the meaning: OCSP responders with Technical Constraints applied are exempt from the requirement in Section 13.2.6.   OCSP responders without Technical Constraints still must not respond with a Good status for non-issued certificates.

The Microsoft OCSP responder is part of Windows Server, commercial software targeting enterprises, not commercial CAs.  It is deployed by and large by enterprises worldwide. To date, only a very few enterprises have embraced or adopted Technical Constraints.  Many enterprises deploy a large number and variety of domains that rapidly scales beyond effective control via the Technical Constraints approach.

When asked to modify the OCSP responder in Windows Server to conform to Section 13.2.6, the response was that the request adds very little value to enterprise scenarios, and added certain risks to enterprise PKI deployment.   OCSP responders are generally kept outside the corporate network, and due to this requirement the OCSP responder would need to access the Certificate Server database.  This means exposing the Certificate Server box outside the company's network. We might curb this, put up firewalls etc. to reduce the risks, but still the requirement creates complexity and risk.  If the Certificate Server key gets compromised, the attacker can issue certificates with serial numbers that already exist in the Certificate server database, and show as Good. And if the Certificate Server box is compromised, the attacker can issue the certificates they want to issue, and have them come out as "Good". An attacker can engineer their way around any protection to enforce this OCSP Good requirement.

The current Section 13.2.6 didn't close a very big hole in our view, and it could open another one for enterprise customers.  The new language introduced in ballot 105 would have us add an advisory to our customers that they can comply with Section 13.2.6 if only they Technically Constrain their enterprise PKI.  Which few enterprises have done.

As a group CAB Forum member CAs implement proprietary OCSP responders that they can amend at will, and by deadline.  That is not the case in the commercial software world, or for many enterprise customers.  We should reconsider adding new language that has such a broad impact on customers and enterprises.  We didn't anticipate very well the impact on OCSP responder vendors, and assertions that this language can have a positive effect on enterprise security should be examined.  It seems to me that this language in section 13.2.6 will throw more fire on deployment of enterprise PKIs subordinated to publicly trusted CAs without doing anything to address underlying issues and conflicts. We think the majority of enterprises are more secure with a design methodology that doesn't implement the OCSP Good proposal as currently specified.

Perhaps we should consider an exemption from this Section 13.2.6 requirement for enterprise CAs.  Or delete the last sentence entirely.

All the best,

Tom


From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Steve Roylance
Sent: Thursday, July 18, 2013 12:40 AM
To: kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Cc: public at cabforum.org<mailto:public at cabforum.org>
Subject: Re: [cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.

Hi Kirk.

I did update the Wiki Ballot text correctly but failed to update the example PDF.  Attached is the new one.

Steve


From: "kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>" <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>>
Date: Wednesday, 17 July 2013 18:20
To: "public at cabforum.org<mailto:public at cabforum.org>" <public at cabforum.org<mailto:public at cabforum.org>>
Subject: Re: [cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.

In reading Ballot 105, our technical team has a question about Section 9.7, particularly this paragraph


If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName as follows:-



(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of section 11.1



(b) For each iPAddress range in permittedSubtrees, the CA MUST confirm that the Applicant has been assigned the iPAddress range or has been authorized by the assigner to act on the assignee's behalf.



(c) For each DirectoryName in permittedSubtrees the CA MUST confirm the Applicants and/or Subsidiary's Organizational name and location such that end entity certificates issued from the subordinate CA will be in compliancy with section 9.2.4 and 9.2.5.

The wording "then the Subordinate CA MUST include the Name Constraints X.509v3 extension" is not clear as to whether the constraints are applied to the sub CA certificate or to an EE certificate the sub CA is going to issue.  Should it read "then the Subordinate CA *certificate* MUST include the Name Constraints X.509v3 extension ***" for clarity?  Is that the intention?


TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential

and may be subject to copyright or other intellectual property protection.

If you are not the intended recipient, you are not authorized to use or

disclose this information, and we request that you notify us by reply mail or

telephone and delete the original message from your mail system.


_______________________________________________ Public mailing list Public at cabforum.org<mailto:Public at cabforum.org> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130718/fc9b9dda/attachment-0003.html>


More information about the Public mailing list