[cabfpub] Ballot 168: Baseline Requirements Corrections (Revised)

Tue May 3 09:48:25 MST 2016

Patrick,

As was discussed at the Scottsdale face to face, there are many cases when the Subscriber named in the certificate is not the same entity that runs the servers hosting their website.  As it stands today, the process of a company getting an OV certificate for their domain, then handing this to their marketing company to use on their website could be considered a violation of their Subscriber Agreement  This in turn makes the Certificates subject to revocation under section 4.9.1.1(5).  This change clarifies that the Subscriber is still responsible for the protection of their key but allows them to control it via legal relationship.  

From the F2F minutes (https://cabforum.org/2016/02/17/2016-02-17-minutes-of-f2f-meeting-37/#What_should_be_represented_in_the_.22O.22_Field.3F_Definition_of_Applicant):

"Geoff – The Subscriber can maintain control of the Private Key, even if someone else has it, as long as you have suitable relationships with them to ensure that they don’t misuse it. It happens often. There are lots of ways that you can have Private Keys in HSMs in clouds or whatever. What it means is to control it with the right kinds of legal relationships.
Peter – can the person claim “sole” control of the Private Key if they didn’t generate it?
Robin – you can assert control, even if you authorize someone else to operate it.""

Similarly, I've been told that there are companies who contract other entities to operate their CAs, or portions of their CA, but the company is still the one named as the CA.  This can be anything from using a colocation provider to host their HSMs and servers to using Iron Mountain for offsite backup to completely outsourcing the whole CA operation to a third party.  The BRs already require that the CA store the private key in a secured environment under dual control of persons in trusted roles (sect 5.2.2) and that the security implementation prevent disclosure of the Private Key (section 6.2).  The clarification that a CA can authorize archival by someone that is not the CA does not change these security requirements, it just clarifies that CAs that use a offsite vaulting or records storage company, or contract some of their CA operations to a third party, are not violating the BRs.

Thanks,
Peter

> On May 3, 2016, at 6:10 AM, Patrick Tronnier <Patrick.Tronnier at oati.net> wrote:
> 
> Hi Peter and Dimitris, corrections and clarifications to the BR's were sorely needed so thanks for this ballot.
>  
> Everyone, I want to make sure we are all on the same page regarding the proposed changes to archiving and control of private keys.
>  
> 1.       Existing BR’s prevent the archive of Subscriber and Subordinate CA Private Keys. Adding the proposed “without authorization by the Subscriber” to section 6.1.2 Private key delivery to Subscriber (i.e. Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.) and adding “without authorization by the Subordinate CA” to section 6.2.5 Private key archival (i.e. Parties other than the Subordinate CA SHALL NOT archive the Subordinate CA Private Keys without authorization by the Subordinate CA.) seem to reverse the status quo. Is this the intent?
>  
> 2.       Existing BR’s grant the Applicant sole control of his/her private key. In section 9.6.3 Subscriber representations and warranties, item 2 (Protection of Private Key), replacing "maintain sole control" with "assure control" seems to reverse the Applicants sole control of his/her Private Key to “assuring control” by anyone the Applicant deems worthy. Is this the intent?
>  
> Thanks
>  
> With kind regards,
>  
> Patrick Tronnier
> Principal Security Architect &
> Sr. Director of Quality Assurance & Customer Support
> Phone: 763.201.2000 
> Fax: 763.201.5333 
> Direct Line: 763.201.2052
> Open Access Technology International, Inc. 
> 3660 Technology Drive NE, Minneapolis, MN 55418 
>  
> “Human action can be modified to some extent, but human nature cannot be changed.” – Abraham Lincoln
>  
> CONFIDENTIAL INFORMATION: This email and any attachment(s) contain confidential and/or proprietary information of Open Access Technology International, Inc. Do not copy or distribute without the prior written consent of OATI. If you are not a named recipient to the message, please notify the sender immediately and do not retain the message in any form, printed or electronic.
>  
>  
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Peter Bowen
> Sent: Monday, May 02, 2016 2:11 PM
> To: CABFPub <public at cabforum.org>
> Subject: Re: [cabfpub] Ballot 168: Baseline Requirements Corrections (Revised)
>  
> {External email message: This email is from an external source. Please exercise caution prior to opening attachments, clicking on links, or providing any sensitive information.}
>  
> Just a reminder that the ballot review period is coming to an end.  Hopefully everyone has had a chance to review the ballot below and the questions and answers posted.
>  
> Any more items for the review period?
>  
> Thanks,
> Peter
>  
> > On Apr 26, 2016, at 9:44 AM, Peter Bowen <pzb at amzn.com> wrote:
> > 
> > Ballot 168: Baseline Requirements Corrections (Revised)
> > 
> > The following motion has been proposed by Peter Bowen of Amazon and endorsed by Dimitris Zacharopoulos of HARICA and Rich Smith of Comodo:
> > 
> > Background:
> > 
> > A number of small corrections and clarifications to the Baseline Requirements have been identified.  These are, in general, changes that reflect the existing understanding of the Baseline Requirements by the Forum.  Due to the understanding that these primarily represent existing practice, they are combined for efficiency.
> > 
> > -- MOTION BEGINS --
> > 
> > Effective the date of passage, the following modifications to the Baseline Requirements are adopted:
> > 
> > In Section 1.6.1:
> > * In the definition of "Applicant Representative", replace "and agrees to the Certificate Terms of Use" with "the Terms of Use" and append "or is the CA" at the end of the definition;
> > * In the definition of "Country", replace "sovereign nation" with "Sovereign State";
> > * In the definition of "Terms of Use", append "or is the CA" at the end of the definition;
> > 
> > In Section 1.6.3:
> > * Delete RFC2560;
> > * Insert "RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Santesson, Myers, Ankney, Malpani, Galperin, Adams, June 2013.";
> > * Delete X.509v3
> > * Insert "X.509, Recommendation ITU-T X.509 (10/2012) | ISO/IEC 9594-8:2014 (E), Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks."
> > 
> > Move the content in section 3.3.1 to section 4.2.1 to become the third paragraph in 4.2.1 and leave section 3.3.1 blank.
> > 
> > In section 4.9.9, replace all occurrences of "RFC2560" with "RFC6960".
> > 
> > In section 5.2.2, insert "CA" immediately before "Private Key".
> > 
> > In section 6.1.2, append "without authorization by the Subscriber" to the end of the first sentence.
> > 
> > In section 6.1.6, update the last citation to read: "[Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 56A: Revision 2]"
> > 
> > In section 6.2, in the second sentence, insert "CA" immediately before both instances of "Private Key".
> > 
> > In section 6.2.5, append "without authorization by the Subordinate CA" to the end of the sentence.
> > 
> > 
> > In sections 7.1.2.1(e) and 7.1.2.2(h) change the organizationName line to read:
> >  -  organizationName (OID 2.5.4.10): This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section 3.2.2.2. The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.
> > 
> > In section 7.1.2.3(d), replace the text with “The cA field MUST NOT be true."
> > 
> > Replace "Subordiate" with "Subordinate" in the title of 7.1.6.3.
> > 
> > In section 9.6.1 item 6:
> > * Insert "are the same entity or" immediately prior to "are Affiliated";
> > * Remove "and accepted".
> > 
> > In section 9.6.3, replace "agreement to the Terms of Use agreement." with "acknowledgement of the Terms of Use."
> > 
> > In section 9.6.3 item 2, replace "maintain sole control" with "assure control".
> > 
> > In the following sections, replace all occurrences of "Subscriber or Terms of Use Agreement" with "Subscriber Agreement or Terms of Use".
> > * Section 1.6.1, in the definition of "Subscriber"
> > * Section 4.1.2
> > * Section 4.9.1.1
> > * Section 4.9.11
> > * Section 9.6.1
> > * Section 9.6.3
> > 
> > -- MOTION ENDS --
> > 
> > The review period for this ballot shall commence at 1740 UTC on 26 April 2016, and will close at 2200 UTC on 3 May 2016. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 10 May 2016. Votes must be cast by posting an on-list reply to this thread.
> > 
> > A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/
> > 
> > _______________________________________________
> > 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