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

Stephen Davidson S.Davidson at quovadisglobal.com
Thu Jul 18 21:01:56 UTC 2013


I agree that section 13.2.6 is a problem and am happy to focus attention on that.  The top CAs can readily adapt their own inhouse software - but this section created a significant cost and obstacle for CAs that use commercial software, and we may find in Q4 there are a lot of SSL small players that don't meet the requirement.



However, the intent of this ballot is to clarify the Mozilla options for technical constraints in the context of the BR, and to fill in some of the gaps on how to use them.  The link in with OCSP is a simply rattle-on from that, and I would hope not to derail the overall ballot.



The fact is that today all Enterprise CAs that are root signed must comply with 13.2.6.  With this ballot, if they are audited, they will still need to comply with 13.2.6.  If they are constrained, they will not.



I understand that the same conditions would also apply with Certificate Transparency ...









From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rick Andrews
Sent: Thursday, July 18, 2013 3:53 PM
To: Tom Albertson; public at cabforum.org
Subject: Re: [cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.



I tend to agree with Tom that the complexity and risk might outweigh the potential benefit. And I'm not saying that because I want the status quo - Symantec has moved all its certs to our OCSP system that returns "unknown" for unknown cert serial numbers.



The intent of this ballot is to allow relying parties to detect a certificate created by an attacker which has a valid signature by virtue of hash collisions (the attacker creates a fake cert that hashes to the same value as a legitimate cert, and simply copies the good signature to the fake cert). >From what I know of hash collision attacks, the attacker has some freedom in choosing the serial number of the fake cert. It should be possible, and maybe even easy, to use the serial number of a legitimate certificate and therefore avoid detection from the OCSP responder.



So I feel that OCSP responders should return "unknown" for unknown serial numbers, but we should recognize that this ballot is a very weak deterrent to attackers.



-Rick



From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Tom Albertson
Sent: Thursday, July 18, 2013 11:24 AM
To: 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.



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/3e7dd8b1/attachment-0003.html>


More information about the Public mailing list