[cabfpub] Technically Constrained BR amendments

[Steve Roylance]

Dear all.

Please see the attached suggestion to modify 1.1.4 of the Baseline
Requirements with a PDF and Word copy.

I'm waiting for final endorsement from the folks who helped me on this but
given the impending deadline of August 1st 2013 for OCSP responses it's
prudent to send prior to the weekend and gain on more day (US time).

Some background:-
* The current wording of the BRs specifically around auditing is somewhat
confusing with respect to SubCA requirements so I'm hoping this helps to
clarify the rules.  I've had various people give me different opinions both
internally and externally to GlobalSign.  Here's what I'm trying to
clarify:-
> * I'm trying to align the Mozilla program and the Baseline Requirements with
> respect to auditing dependent on wether you are a Technically Constrained
> SubCA or not.  i.e.
>> * If the SubCA is NOT constrained all rules apply and parent CAs are
>> responsible to flow down the BRs to SubCAs who implement and are audited
>> fully to Section 17 by an external body to prove compliance.
>> * If the SubCA is constrained then the damage possible through a compromise
>> is limited to the domain space of the SubCA in much the same way that a
>> password compromise on an Enterprise account would allow an attacker to issue
>> within the domain space of the account.  (Of course the fact that not ALL
>> platforms protect their user base with Name Constraints is different, but
>> hopefully that will be sorted soon as Name Constraint usage grows and
>> platform add compliance)
> * In all cases SubCAs must be audited by their parent CAs (3% or higher) such
> that the parent CA ensures compliance for minimum key size, inclusion of
> CRL/OCSP etc.   This applies to all and regardless of wether SubCAs are
> externally audited or not.  Mistakes will happen and corrective actions will
> be required but constant improvement is our goal and auditing helps.
* Following the logic of Certificate Transparency where Name Constrained CAs
are not required to support CT, we are suggesting that Name Constrained CAs
also do not need to respond with Database based OCSP responses.  Again for
the reasons above, damage is limited to the domain space of the SubCA.
* An example is given to show how IP address space is excluded in NC.
* Wording is added to ensure that good practice is undertaken in adding
Directory Name Constraints that allow end entity certificates to meet the
vetting requirements. i.e. The parent CA of the Constrained SubCA is
involved and vetting practices are therefore consistent between parties.
* Appendix B is modified to highlight the use of EKUs (Again for alignment
with Mozilla) but leaves it open to allow other EKUs as SubCAs will not be
limited to SSL and therefore other EKUs are sometimes necessary.
The intention is to continue to 'safely' increase the level of adoption of
PKI primarily in the enterprise space (Where domain space usage is 'fairly'
static) and to avoid situations where the additional costs from external
audits destroy the business case for PKI.

The best analogy I can give is the burglar alarm.  Up to 2012 SubCAs had no
constraints (i.e. no alarm on the house), where as now, alarms are being
fitted and year on year they are being improved.  Hackers (burglars) are not
going to focus on houses (Sub CAs) with alarms (Name Constraints) as the ROI
gets less each year.   Eventually when we are able to turn Name constraints
to critical and browsers perform more live checking of certs we'll all be
better off.   Auditing is akin to a neighbourhood watch and whilst useful
can't be active everywhere all the time, so trying door handles and testing
windows catches is good but not as good as alarms.    (I'm sure people can
pull this analogy to bits but hopefully that will not be the focus of any
reply I get ;-)  )

Have a nice weekend everyone.

Kind Regards

 

Steve Roylance

Business Development Director

 

GlobalSign






-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130628/6fd9b940/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BRv.1.1.4 - Amendments for Name Constraints and Auditing -	Updated 28th June.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 203460 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130628/6fd9b940/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BRv.1.1.4 - Amendments for Name Constraints and Auditing -	Updated 28th June.pdf
Type: application/pdf
Size: 351117 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130628/6fd9b940/attachment-0001.pdf