[cabfpub] Fwd: question on 17.9 of baseline

[Ryan Sleevi]

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

> See question below:
>
>
> -------- Original message --------
> From: "Sheehy, Don (CA - Toronto)" <dosheehy at deloitte.ca>
> Date: 01/21/2014 11:42 AM (GMT-07:00)
> To: 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.


>
>    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.

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.
>
>
>
> 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 | Main: 416-601-6500
> Fax: 416-601-6400 | Mobile: 416-301-2350
> *dosheehy at deloitte.ca* <name at deloitte.ca> | *www.deloitte.ca*<http://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
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140121/c3f46f14/attachment-0001.html