[cabfpub] Fwd: question on 17.9 of baseline

Thu Jan 23 11:35:31 UTC 2014

Hi Ryan,

Some quick feedback from GlobalSign inline [Steve Roylance]

Steve

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: 21 January 2014 21:08
To: Ben Wilson
Cc: public at cabforum.org
Subject: Re: [cabfpub] Fwd: question on 17.9 of baseline

On Tue, Jan 21, 2014 at 12:08 PM, Ben Wilson <ben at digicert.com <mailto:ben at digicert.com> > wrote:

See question below:

-------- Original message --------
From: "Sheehy, Don (CA - Toronto)" <dosheehy at deloitte.ca <mailto:dosheehy at deloitte.ca> > 
Date: 01/21/2014 11:42 AM (GMT-07:00) 
To: ben at digicert.com <mailto:ben at digicert.com>  
Subject: question on 17.9 of baseline 

Can you pose this to the forum

“17.9 Regular    Quality  Assessment       of       Technically      Constrained     Subordinate     CAs     

During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the 

Subordinate CA SHALL monitor adherence to the CA’s Certificate Policy and the Subordinate CA’s Certification 

Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate 

or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing 

immediately after the previous audit sample was taken, the CA shall ensure all applicable Baseline Requirements are 

met. 

1.     Has the Forum established how they will get evidence that the population the subordinate says have issued is accurate to choose the 3%

I'm not aware of any technical means by any root program member at this time. The closest that one can come is Certificate Transparency, although it's been suggested to not require certificates issued by a technically constrained sub-CA to be publicly logged.

[Steve Roylance] GlobalSign is looking to add an auditing module to each implementation that captures details of 100% of certificates issued with the intention of auditing all 100% (rather than just the 3%), however until that’s complete we look at logs from their systems to determine totals and we have our own scanning capability to check.   I feel that it will be hard for Subordinate CA’s using commercial s/w to be able to use CT.  Only when ALL these offerings (Specifically MS AD CS and EJBCA as the most popular) are able to use CT should we discuss.

1.     What specifically will be checked since the cert is technically constrained ? – ie what are the applicable baseline Requirements that will be tested ( this sould be agreed for consistency)

The Baseline Requirements do not presently establish this, unfortunately. The 'intent' of permitting technically constrained subordinate CAs was to absolve such subordinates of many of the auditing requirements found within the BRs.

My take is that the focus should be on the conformance to the technical profile - which can be automated - while de-emphasizing focus on some of the identity-related assertions, since the technical constraints restrict those.

[Steve Roylance] +1 and why we are looking to create something that does this.

We would need a BR amendment to clarify these requirements, I believe, as none of them should _need_ to be required, given the nature of the technical constraint.

1) subjectAltNames contains only names within the registered domain namespace of the technically constrained subordinate CA certificate and conforms with the technical requirements of 9.2.1.

[Note: This intentionally precludes internal server names, for which technically constrained subCAs should not be permitted, by virtue of both technical constraints and public trust.

This is also (arguably) a defense against clients that do not support NC, since NC is not marked critical. However, we may simply to decide to leave such clients "on their own", with respect to security, and either support NC or run the risk.]

2) Validity period conformance to 9.4.1 (although not critical, as the subordinate CA cert should be constrained)

[Note: The validity period constraint on the intermediate should prevent any long-lived end-entity certs from being valid, except in the case where a customer performs an intermediate re-issuance that extends the date of the intermediate, thus allowing EE certs to continue to be valid. Then again, the only ones harmed is themselves]

3) Conformance to the Cryptographic Algorithm / Key Requirements profile in Appendix A

[Note: It could be argued that by virtue of technical constraint, it's not necessary to require this conformance, since at worst, an organization that fails to comply is only affecting their own security]

4) Conformance to the Certificate Extensions profile in Appendix B

[Note: Again, it could be argued that by virtue of technical constraint, the only ones they're harming is themselves].

1.     The evidence for the 3% checking will then need to be kept for the auditors for the baseline audit.

[Steve Roylance] Agreed.  This is a must.

Thanks 

Don

Donald E. Sheehy, CPA, CA, CISA, CRISC, CIPP/C

Partner | Enterprise Risk 

Deloitte  

30 Wellington St Wt, PO Box 400, Stn Commerce Crt, Toronto, ON M5L 1B1

Direct: 416-601-5863 <tel:416-601-5863>  | Main: 416-601-6500 <tel:416-601-6500> 

Fax: 416-601-6400 <tel:416-601-6400>  | Mobile: 416-301-2350 <tel:416-301-2350> 

 <mailto:name at deloitte.ca> dosheehy at deloitte.ca |  <http://www.deloitte.ca/> www.deloitte.ca

Deloitte is proud to be an Official Supplier 

of the Canadian Olympic team  

Please consider the environment before printing. 

Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you. 
Information confidentielle: Le présent message, ainsi que tout fichier qui y est joint, est envoyé à l'intention exclusive de son ou de ses destinataires; il est de nature confidentielle et peut constituer une information privilégiée. Nous avertissons toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci.

_______________________________________________
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/20140123/09af391d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4256 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140123/09af391d/attachment-0001.p7s>