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

Steve Roylance steve.roylance at globalsign.com
Fri Jul 19 07:01:44 UTC 2013


Hi Kelvin. 

We tried this but unfortunately the ballot failed to gain support (ballot 100) so we had to take the advice given and try again.

If you are saying that you wanted to allow more time for non Name constrained CAs then I'm confused as to why there was no feedback to Ballot 100?

Am I missing something?

Sent from my iPhone

On 19 Jul 2013, at 02:32, Kelvin Yiu <kelviny at exchange.microsoft.com> wrote:

> [I am filling in for Tom while he is enjoying some well-deserved time off.]
>  
> It is unfortunate that ballot 105 combined the OCSP issue with the clarification of audit requirements for subCAs. If one of the goals of ballot 105 is to provide some “breathing space” to the August deadline on the OCSP issue, then it must address the OCSP problem for all CAs, not just those who are able to take advantage of name constraints.
>  
> I think it is great that the CAB Forum is driving the use of name constraints to reduce the burden for many customers who manages a stable set of domains and reduce the risks for the entire PKI eco-system. It is even more important for the CAB Forum to produce guidelines that can be fairly applied to all CAs, even when there is an arbitrary self-imposed deadline looming over us.  
>  
> Kelvin
>  
>  
>  
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Steve Roylance
> Sent: Thursday, July 18, 2013 2:39 PM
> To: Stephen Davidson
> Cc: Rick Andrews; public at cabforum.org
> Subject: Re: [cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.
>  
> Hi Tom. 
>  
> I agree with Stephen that we need to let 105 run its course and amend the wording now, as a number of  enterprise CAs will immediately fail to deliver on the BR requirements (fully) come August 1st, yet they've been willing to limit their domain exposure through name constraints.  
>  
> I'm fully behind additional language tweaks above and beyond this ballot to help, and as you recall I was an advocate of reaching out to CA platform  and OCSP providers, 18 months ago as all these companies have a vested interest to be members of the CABForum.
>  
> Lets get this Ballot implemented and then discuss at length what makes sense for the industry at large.  There are so many moving parts with CRLs, OSCP stapling etc that we need to consider all but we need to consider in a timely fashion and the ballot was written to allow us some breathing space...... as August is here now.
> 
> Sent from my iPhone
> 
> On 18 Jul 2013, at 22:01, Stephen Davidson <S.Davidson at quovadisglobal.com> wrote:
> 
> 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] On Behalf Of Tom Albertson
> Sent: Thursday, July 18, 2013 11:24 AM
> To: 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] On Behalf Of Steve Roylance
> Sent: Thursday, July 18, 2013 12:40 AM
> To: kirk_hall at trendmicro.com
> Cc: 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" <kirk_hall at trendmicro.com>
> Date: Wednesday, 17 July 2013 18:20
> To: "public at cabforum.org" <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 https://cabforum.org/mailman/listinfo/public
> _______________________________________________
> Public mailing list
> 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/20130719/edc36c9d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4041 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130719/edc36c9d/attachment-0001.p7s>


More information about the Public mailing list