Re: Email sub-CAs

[Gervase Markham via dev-security-policy]

Hi Doug,

On 18/05/17 12:03, Doug Beattie wrote:
> I'm still looking for audit guidance on subordinate CAs that have EKU
> of Server auth and/or Secure Mail along with name constraints.  Do
> these need to be audited?
> 
> I'm looking at this:
> https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
> 
> Section 1.1, item #2 implies yes, that these CAs are in scope of this
> policy and thus must be audited - correct me if I'm wrong if being in
> the policy means they need to be audited.

Being in scope of the policy means that you need to read the rest of the
policy as applicable. It doesn't necessarily mean they need to be
audited - whether they do or not depends on what the Audit section says
about what needs to be audited. If these certs weren't in the scope of
the policy, then whatever the Audit section said would be irrelevant.

> Section 5.3.1 and 5.3.2 imply no audit is needed

At the moment, if a server-auth intermediate is properly
name-constrained according to the BRs, it's a TCSC and does not require
an audit. As you know, there's a bug in the latest version of the policy
regarding email intermediates, but the intent is that is an email
intermediate is properly rfc822name-constrained, with the constraints
being domain-ownership-validated to be owned by your customer, it also
doesn't require an audit, otherwise it does.

> Prior versions of the policy (at least 1.3 and before), did not
> require audits for technically constrained CAs like the ones
> referenced above.  Further, it used to be OK if the "Name
> Constraints" applied for Secure Mail CAs was done via contractual
> methods, vs. in the CA certificate at a technical NC.  We have one
> remaining customer with a CA like this and we're not sure on how new
> policy requirements apply to this existing customer.  Your guidance
> is appreciated.

Contractual constraints are not considered sufficient under the current
version of the policy.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Email sub-CAs

[Doug Beattie via dev-security-policy]

Hi Gerv,

I'm still looking for audit guidance on subordinate CAs that have EKU of Server 
auth and/or Secure Mail along with name constraints.  Do these need to be 
audited?

I'm looking at this:  
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md

Section 1.1, item #2 implies yes, that these CAs are in scope of this policy 
and thus must be audited - correct me if I'm wrong if being in the policy means 
they need to be audited.

Section 5.3.1 and 5.3.2 imply no audit is needed

Prior versions of the policy (at least 1.3 and before), did not require audits 
for technically constrained CAs like the ones referenced above.  Further, it 
used to be OK if the "Name Constraints" applied for Secure Mail CAs was done 
via contractual methods, vs. in the CA certificate at a technical NC.  We have 
one remaining customer with a CA like this and we're not sure on how new policy 
requirements apply to this existing customer.  Your guidance is appreciated.

Doug


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Doug
> Beattie via dev-security-policy
> Sent: Monday, May 8, 2017 12:47 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Email sub-CAs
> 
> Hi Gerv,
> 
> I wanted to get the latest Mozilla thoughts on the audit requirements for
> TCSCs based on the discussion we started last month.  I understand the BR
> requirement if the CA can issue server auth certificates, this was discussed
> here:
> 
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ZMUjQ6
> xHrDA/ySofsF_PAgAJ
> 
> For TCSCs that can issue secure email certs, what are the requirements in the
> new policy, 2.4?  I think they were excluded from audit requirement before,
> but in the latest Mozilla policy these CAs need to have a WT for CA audit even
> if they are Name Constrained.
> 
> So here my questions:
> 
> Was this an intentional change?
> 
> Is the same true for TCSCs that can issue server auth certificates (even NC 
> CAs
> need a webtrust for CA audit)?
> 
> Are previously issued TCSCs exempt, if not, when would the audit period for
> them start?
> 
> Do these CAs need to be publicly disclosed?
> 
> Related tickets:
>https://github.com/mozilla/pkipolicy/issues/36
> 
>https://github.com/mozilla/pkipolicy/issues/69
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> > douglas.beattie--- via dev-security-policy
> > Sent: Thursday, April 13, 2017 12:33 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Email sub-CAs
> >
> > On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham
> wrote:
> > > On 13/04/17 14:23, Doug Beattie wrote:
> > > > In 3.2 the term Technically Constrained is not defined to be any
> > > > different than the BRs (or perhaps even less restrictive).
> > >
> > > You mean 2.3, right?
> >
> > Yes, 2.3.
> >
> > > I would say Inclusion section, bullet 9 gives the definition of
> > > technically constrained. For email certs, because of the bug
> > > described in issue #69, it basically just says that it has to have
> > > the id-kp-emailProtection EKU. It should say more, but it doesn't.
> > > That's problematic, because just having an EKU isn't really a
> > > technical constraint in the "TCSC" sense.
> > >
> > > > In 3.2
> > > > this is all I can find regarding CAs that are capable of signing
> > > > secure email certificates, section 9: "If the certificate includes
> > > > the id-kp-emailProtection extended key usage, then all end-entity
> > > > certificates MUST only include e-mail addresses or mailboxes that
> > > > the issuing CA has confirmed (via technical and/or business
> > > > controls) that the subordinate CA is authorized to use."
> > > >
> > > > There is no statement back to scope or corresponding audits.  Were
> > > > secure email capable CAs supposed to be disclosed and audited to
> > > > Mozilla under 2.3?
> > >
> > > If they did not include id-kp-serverAuth, I would not have faulted a
> > > CA for not disclosing them if they met the exclusion criteria for
> > > email certs as written.
> >
> > OK.
> >
> > > > and how it applies to Secure email, I don't see how TCSCs with
> > > > secure email EKU fall within the sco

RE: Email sub-CAs

[Doug Beattie via dev-security-policy]

Hi Gerv,

I wanted to get the latest Mozilla thoughts on the audit requirements for TCSCs 
based on the discussion we started last month.  I understand the BR requirement 
if the CA can issue server auth certificates, this was discussed here:
  
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ

For TCSCs that can issue secure email certs, what are the requirements in the 
new policy, 2.4?  I think they were excluded from audit requirement before, but 
in the latest Mozilla policy these CAs need to have a WT for CA audit even if 
they are Name Constrained.  

So here my questions:

Was this an intentional change?  

Is the same true for TCSCs that can issue server auth certificates (even NC CAs 
need a webtrust for CA audit)?

Are previously issued TCSCs exempt, if not, when would the audit period for 
them start?

Do these CAs need to be publicly disclosed?

Related tickets:
   https://github.com/mozilla/pkipolicy/issues/36

   https://github.com/mozilla/pkipolicy/issues/69









> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> douglas.beattie--- via dev-security-policy
> Sent: Thursday, April 13, 2017 12:33 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Email sub-CAs
> 
> On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:
> > On 13/04/17 14:23, Doug Beattie wrote:
> > > In 3.2 the term Technically Constrained is not defined to be any
> > > different than the BRs (or perhaps even less restrictive).
> >
> > You mean 2.3, right?
> 
> Yes, 2.3.
> 
> > I would say Inclusion section, bullet 9 gives the definition of
> > technically constrained. For email certs, because of the bug described
> > in issue #69, it basically just says that it has to have the
> > id-kp-emailProtection EKU. It should say more, but it doesn't. That's
> > problematic, because just having an EKU isn't really a technical
> > constraint in the "TCSC" sense.
> >
> > > In 3.2
> > > this is all I can find regarding CAs that are capable of signing
> > > secure email certificates, section 9: "If the certificate includes
> > > the id-kp-emailProtection extended key usage, then all end-entity
> > > certificates MUST only include e-mail addresses or mailboxes that
> > > the issuing CA has confirmed (via technical and/or business
> > > controls) that the subordinate CA is authorized to use."
> > >
> > > There is no statement back to scope or corresponding audits.  Were
> > > secure email capable CAs supposed to be disclosed and audited to
> > > Mozilla under 2.3?
> >
> > If they did not include id-kp-serverAuth, I would not have faulted a
> > CA for not disclosing them if they met the exclusion criteria for
> > email certs as written.
> 
> OK.
> 
> > > and how it applies to Secure email, I don't see how TCSCs with
> > > secure email EKU fall within the scope of the Mozilla Policy 2.3.
> > > Can you help clarify?
> >
> > I think this is basically issue #69.
> > https://github.com/mozilla/pkipolicy/issues/69
> 
> OK, I look forward to a conclusion on that.  I hope that name constraining a
> secure email CA (either technically in the CA certificate or via business
> controls) is sufficient to avoid WebTrust Audits.  If Public disclosure helps 
> get
> us there then that would be acceptable.
> 
> > I don't think it was supposed to be the case that intermediates with
> > id-kp-emailProtection alone were supposed to be considered TCSCs.
> > After all, certs with id-kp-serverAuth alone are not TCSCs; they need
> > to have Name Constraints as well. But you are right, that's what the policy
> says.
> >
> > > OK, you're right, the number of negatives in that section got me.
> > > So, even when EKU permits just secure email, having name constraints
> > > does not exempt a CA from the Mozilla policy.  It does for BRs since
> > > email is not within scope (and discussed on the link you included in
> > > the response).  When I saw TCSC references I personally didn't
> > > realize that this was different than the BR definition of TCSC
> > > (maybe should have called this something different).
> > >
> > > Section 3.1.2.1 specifies that any CA capable of issuing secure
> > > email certificates must have a "WebTrust for CAs" audit (or
> > > corresponding ETSI audit).  This is a huge change from 3.2 and I
> > > wonder if all CAs understand this.  Even the Blog about this version
> > > doe

Re: Email sub-CAs

[Gervase Markham via dev-security-policy]

On 05/05/17 18:58, Peter Bowen wrote:
>> Right now the policy does not require disclosure of CA-certificates
>> that the CA deems are technically constrained.  

I believe this was made the case for some mix of the following reasons:

a) the CA did not want to reveal every customer it had;
b) this would significantly increase the volume of disclosure required;
c) we didn't think we needed to know about these.

>> We have seen numerous
>> cases where the CA misunderstood the rules or where the rules had
>> unintentional gaps an disclosing the certificate as constrained will
>> allow discovery of these problems.  For example the current policy
>> says "an Extended Key Usage (EKU) extension which does not contain
>> either of the id-kp-serverAuth and id-kp-emailProtection EKUs" which
>> means a certificate that has EKU extension with only the
>> anyExtendedKeyUsage KeyPurposeId fall outside of the scope.  This is
>> obviously wrong, but would not be discovered today.

Is it obviously wrong? Firefox doesn't respect anyEKU. OTOH, Kathleen
recently told me that she feels that because the Mozilla root store is
used by others, we should continue to keep anyEKU intermediates in
scope. But do you think Mozilla also needs to know about these for
Firefox/Thunderbird purposes? If so, why?

>> The flow chart at https://imagebin.ca/v/3LRcaKW9t2Qt shows my proposal for 
>> disclosure; it is a
>> revised version from the one I posted to the CA/Browser Forum list and
>> depends on the same higher level workflow

Apologies that your message got held up.

Looking at that flowchart:

* Does "Log certificate" mean "in CT"?
* The "Subject/Key list" is the list of intermediate certs which need to
  be disclosed?
* This diagrem represents your proposal, not the status quo?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Email sub-CAs

[Peter Bowen via dev-security-policy]

(Resending as the attached file was too large)

On Fri, May 5, 2017 at 10:46 AM, Peter Bowen  wrote:
> On Thu, Apr 20, 2017 at 3:01 AM, Gervase Markham via
> dev-security-policy  wrote:
>> On 15/04/17 17:05, Peter Bowen wrote:
>>> Should the Mozilla policy change to require disclosure of all CA
>>> certificates issued by an unconstrained CA (but not necessarily
>>> require audits, CP/CPS, etc)? This would help identify unintentional
>>> gaps in policy.
>>
>> https://github.com/mozilla/pkipolicy/issues/73
>>
>> I think I understand your point but if you could expand a bit in the
>> bug, that would be most welcome.
>
> Right now the policy does not require disclosure of CA-certificates
> that the CA deems are technically constrained.  We have seen numerous
> cases where the CA misunderstood the rules or where the rules had
> unintentional gaps an disclosing the certificate as constrained will
> allow discovery of these problems.  For example the current policy
> says "an Extended Key Usage (EKU) extension which does not contain
> either of the id-kp-serverAuth and id-kp-emailProtection EKUs" which
> means a certificate that has EKU extension with only the
> anyExtendedKeyUsage KeyPurposeId fall outside of the scope.  This is
> obviously wrong, but would not be discovered today.
>
> The flow chart at https://imagebin.ca/v/3LRcaKW9t2Qt shows my proposal for 
> disclosure; it is a
> revised version from the one I posted to the CA/Browser Forum list and
> depends on the same higher level workflow
> (https://cabforum.org/pipermail/public/attachments/20170430/0e692c4d/attachment-0002.png
> ).
>
> Thanks,
> Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Email sub-CAs

[Gervase Markham via dev-security-policy]

On 15/04/17 17:05, Peter Bowen wrote:
> Should the Mozilla policy change to require disclosure of all CA
> certificates issued by an unconstrained CA (but not necessarily
> require audits, CP/CPS, etc)? This would help identify unintentional
> gaps in policy.

https://github.com/mozilla/pkipolicy/issues/73

I think I understand your point but if you could expand a bit in the
bug, that would be most welcome.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Email sub-CAs

[Rob Stradling via dev-security-policy]

On 15/04/17 17:05, Peter Bowen via dev-security-policy wrote:

On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via
dev-security-policy  wrote:

On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:

On 13/04/17 14:23, Doug Beattie wrote:

There is no statement back to scope or corresponding audits.  Were
secure email capable CAs supposed to be disclosed and audited to
Mozilla under 2.3?


If they did not include id-kp-serverAuth, I would not have faulted a CA
for not disclosing them if they met the exclusion criteria for email
certs as written.


OK.


and how it applies to Secure email, I don't see how TCSCs with secure
email EKU fall within the scope of the Mozilla Policy 2.3.  Can you
help clarify?


I think this is basically issue #69.
https://github.com/mozilla/pkipolicy/issues/69


OK, I look forward to a conclusion on that.  I hope that name constraining a 
secure email CA (either technically in the CA certificate or via business 
controls) is sufficient to avoid WebTrust Audits.  If Public disclosure helps 
get us there then that would be acceptable.


Should the Mozilla policy change to require disclosure of all CA
certificates issued by an unconstrained CA (but not necessarily
require audits, CP/CPS, etc)? This would help identify unintentional
gaps in policy.


+1

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Email sub-CAs

[Peter Bowen via dev-security-policy]

On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via
dev-security-policy  wrote:
> On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:
>> On 13/04/17 14:23, Doug Beattie wrote:
>> > There is no statement back to scope or corresponding audits.  Were
>> > secure email capable CAs supposed to be disclosed and audited to
>> > Mozilla under 2.3?
>>
>> If they did not include id-kp-serverAuth, I would not have faulted a CA
>> for not disclosing them if they met the exclusion criteria for email
>> certs as written.
>
> OK.
>
>> > and how it applies to Secure email, I don't see how TCSCs with secure
>> > email EKU fall within the scope of the Mozilla Policy 2.3.  Can you
>> > help clarify?
>>
>> I think this is basically issue #69.
>> https://github.com/mozilla/pkipolicy/issues/69
>
> OK, I look forward to a conclusion on that.  I hope that name constraining a 
> secure email CA (either technically in the CA certificate or via business 
> controls) is sufficient to avoid WebTrust Audits.  If Public disclosure helps 
> get us there then that would be acceptable.

Should the Mozilla policy change to require disclosure of all CA
certificates issued by an unconstrained CA (but not necessarily
require audits, CP/CPS, etc)? This would help identify unintentional
gaps in policy.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Email sub-CAs

[douglas.beattie--- via dev-security-policy]

On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:
> On 13/04/17 14:23, Doug Beattie wrote:
> > In 3.2 the term Technically Constrained is not defined to be any
> > different than the BRs (or perhaps even less restrictive).
> 
> You mean 2.3, right?

Yes, 2.3.

> I would say Inclusion section, bullet 9 gives the definition of
> technically constrained. For email certs, because of the bug described
> in issue #69, it basically just says that it has to have the
> id-kp-emailProtection EKU. It should say more, but it doesn't. That's
> problematic, because just having an EKU isn't really a technical
> constraint in the "TCSC" sense.
> 
> > In 3.2
> > this is all I can find regarding CAs that are capable of signing
> > secure email certificates, section 9: "If the certificate includes
> > the id-kp-emailProtection extended key usage, then all end-entity
> > certificates MUST only include e-mail addresses or mailboxes that the
> > issuing CA has confirmed (via technical and/or business controls)
> > that the subordinate CA is authorized to use."
> > 
> > There is no statement back to scope or corresponding audits.  Were
> > secure email capable CAs supposed to be disclosed and audited to
> > Mozilla under 2.3? 
> 
> If they did not include id-kp-serverAuth, I would not have faulted a CA
> for not disclosing them if they met the exclusion criteria for email
> certs as written.

OK.

> > and how it applies to Secure email, I don't see how TCSCs with secure
> > email EKU fall within the scope of the Mozilla Policy 2.3.  Can you
> > help clarify?
> 
> I think this is basically issue #69.
> https://github.com/mozilla/pkipolicy/issues/69

OK, I look forward to a conclusion on that.  I hope that name constraining a 
secure email CA (either technically in the CA certificate or via business 
controls) is sufficient to avoid WebTrust Audits.  If Public disclosure helps 
get us there then that would be acceptable.

> I don't think it was supposed to be the case that intermediates with
> id-kp-emailProtection alone were supposed to be considered TCSCs. After
> all, certs with id-kp-serverAuth alone are not TCSCs; they need to have
> Name Constraints as well. But you are right, that's what the policy says.
> 
> > OK, you're right, the number of negatives in that section got me.
> > So, even when EKU permits just secure email, having name constraints
> > does not exempt a CA from the Mozilla policy.  It does for BRs since
> > email is not within scope (and discussed on the link you included in
> > the response).  When I saw TCSC references I personally didn't
> > realize that this was different than the BR definition of TCSC (maybe
> > should have called this something different).
> > 
> > Section 3.1.2.1 specifies that any CA capable of issuing secure email
> > certificates must have a "WebTrust for CAs" audit (or corresponding
> > ETSI audit).  This is a huge change from 3.2 and I wonder if all CAs
> > understand this.  Even the Blog about this version does not highlight
> > this substantial change: 
> > https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/
> 
> I didn't realise it _was_ a substantial change. Are you saying that you
> used to think it was fine for email-only sub-CAs to have no audits at
> all? Is this because you considered all such CAs to be TCSCs (by the
> Mozilla definition)?

Yes, we've been working hard to technically constrain all CAs and especially 
those operated outside of our infrastructure.  We've been following the BR 
definition: Include EKUs in all CAs, and for those that include server auth or 
secure email, include name constraints. 

> Even if we didn't require it in our policy, I'm very surprised that
> no-one else does. Which other root store policies have requirements on
> email-only sub-CAs?

Not that I know of.

> > Obviously there are a lot of technically constrained CAs issued to
> > organizations to run their own CAs for issuing secure email and
> > client auth certificates.  In order for them to continue operations
> > they now every organization needs to be publicly reported and audited
> > (a new requirement for 2.4.1 as far as I can tell), is that right?
> 
> This is issue #36 :-)
> https://github.com/mozilla/pkipolicy/issues/36
> 
> Do the CAs you are thinking of in this category have name constraints,
> or not (either actually in the cert, or via business controls)?

Yes - they are all either name constrained either via the certificate name 
constraints or via business controls.

> > When did (does) this take effect?   Is this for new CAs, existing or
> > both?   When would the Audit Period for these CAs need to begin?
> > 
> > This is a side question, but does the Mozilla policy require that
> > these CAs meet the Network Security Requirements?
> 
> https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment.

OK

> > Section 5.3.2 says that all CAs of the type I'm discussing must be in
> > the CCADB.  

Re: Email sub-CAs

[Ryan Sleevi via dev-security-policy]

On Thu, Apr 13, 2017 at 10:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > Section 3.1.2.1 specifies that any CA capable of issuing secure email
> > certificates must have a "WebTrust for CAs" audit (or corresponding
> > ETSI audit).  This is a huge change from 3.2 and I wonder if all CAs
> > understand this.  Even the Blog about this version does not highlight
> > this substantial change:
> > https://blog.mozilla.org/security/2017/04/04/mozilla-
> releases-version-2-4-ca-certificate-policy/
>
> I didn't realise it _was_ a substantial change. Are you saying that you
> used to think it was fine for email-only sub-CAs to have no audits at
> all? Is this because you considered all such CAs to be TCSCs (by the
> Mozilla definition)?
>
> Even if we didn't require it in our policy, I'm very surprised that
> no-one else does. Which other root store policies have requirements on
> email-only sub-CAs?
>

https://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-trusted-root-certificate-program-audit-requirements.aspx
(aka http://aka.ms/auditreqs)

S/MIME trust bit requires either "WebTrust Principles and Criteria for
Certification Authorities - WebTrust for CAs 2.0" or the combination of the
following: "WebTrust Principles and Criteria for Certification Authorities
- WebTrust for CAs 2.0" "ETSI TS 102 042 V2.4.1 or later (LCP, NCP, NCP+
policies) - Electronic Signatures and Infrastructures (ESI); Policy
requirements for certification authorities issuing public key certificates"
and "ETSI TS 101 456 V1.4.3 or later - Electronic Signatures and
Infrastructure (ESI); Policy requirements for certification authorities
issuing qualified certificates"




>
> > Obviously there are a lot of technically constrained CAs issued to
> > organizations to run their own CAs for issuing secure email and
> > client auth certificates.  In order for them to continue operations
> > they now every organization needs to be publicly reported and audited
> > (a new requirement for 2.4.1 as far as I can tell), is that right?
>
> This is issue #36 :-)
> https://github.com/mozilla/pkipolicy/issues/36
>
> Do the CAs you are thinking of in this category have name constraints,
> or not (either actually in the cert, or via business controls)?
>
> > When did (does) this take effect?   Is this for new CAs, existing or
> > both?   When would the Audit Period for these CAs need to begin?
> >
> > This is a side question, but does the Mozilla policy require that
> > these CAs meet the Network Security Requirements?
>
> https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment.
>
> > Section 5.3.2 says that all CAs of the type I'm discussing must be in
> > the CCADB.  What's the timeline for CAs to upload them?
>
> Well, let's figure out what the right thing to do is first. If it turns
> out we've created new normative requirements accidentally, the first
> thing to do is to decide whether that's what we meant. Only then will we
> set some sort of sane implementation timeline.
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Email sub-CAs

[Gervase Markham via dev-security-policy]

On 13/04/17 14:23, Doug Beattie wrote:
> In 3.2 the term Technically Constrained is not defined to be any
> different than the BRs (or perhaps even less restrictive).

You mean 2.3, right?

I would say Inclusion section, bullet 9 gives the definition of
technically constrained. For email certs, because of the bug described
in issue #69, it basically just says that it has to have the
id-kp-emailProtection EKU. It should say more, but it doesn't. That's
problematic, because just having an EKU isn't really a technical
constraint in the "TCSC" sense.

> In 3.2
> this is all I can find regarding CAs that are capable of signing
> secure email certificates, section 9: "If the certificate includes
> the id-kp-emailProtection extended key usage, then all end-entity
> certificates MUST only include e-mail addresses or mailboxes that the
> issuing CA has confirmed (via technical and/or business controls)
> that the subordinate CA is authorized to use."
> 
> There is no statement back to scope or corresponding audits.  Were
> secure email capable CAs supposed to be disclosed and audited to
> Mozilla under 2.3? 

If they did not include id-kp-serverAuth, I would not have faulted a CA
for not disclosing them if they met the exclusion criteria for email
certs as written.

> and how it applies to Secure email, I don't see how TCSCs with secure
> email EKU fall within the scope of the Mozilla Policy 2.3.  Can you
> help clarify?

I think this is basically issue #69.
https://github.com/mozilla/pkipolicy/issues/69

I don't think it was supposed to be the case that intermediates with
id-kp-emailProtection alone were supposed to be considered TCSCs. After
all, certs with id-kp-serverAuth alone are not TCSCs; they need to have
Name Constraints as well. But you are right, that's what the policy says.

> OK, you're right, the number of negatives in that section got me.
> So, even when EKU permits just secure email, having name constraints
> does not exempt a CA from the Mozilla policy.  It does for BRs since
> email is not within scope (and discussed on the link you included in
> the response).  When I saw TCSC references I personally didn't
> realize that this was different than the BR definition of TCSC (maybe
> should have called this something different).
> 
> Section 3.1.2.1 specifies that any CA capable of issuing secure email
> certificates must have a "WebTrust for CAs" audit (or corresponding
> ETSI audit).  This is a huge change from 3.2 and I wonder if all CAs
> understand this.  Even the Blog about this version does not highlight
> this substantial change: 
> https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/

I didn't realise it _was_ a substantial change. Are you saying that you
used to think it was fine for email-only sub-CAs to have no audits at
all? Is this because you considered all such CAs to be TCSCs (by the
Mozilla definition)?

Even if we didn't require it in our policy, I'm very surprised that
no-one else does. Which other root store policies have requirements on
email-only sub-CAs?

> Obviously there are a lot of technically constrained CAs issued to
> organizations to run their own CAs for issuing secure email and
> client auth certificates.  In order for them to continue operations
> they now every organization needs to be publicly reported and audited
> (a new requirement for 2.4.1 as far as I can tell), is that right?

This is issue #36 :-)
https://github.com/mozilla/pkipolicy/issues/36

Do the CAs you are thinking of in this category have name constraints,
or not (either actually in the cert, or via business controls)?

> When did (does) this take effect?   Is this for new CAs, existing or
> both?   When would the Audit Period for these CAs need to begin?
> 
> This is a side question, but does the Mozilla policy require that
> these CAs meet the Network Security Requirements?

https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment.

> Section 5.3.2 says that all CAs of the type I'm discussing must be in
> the CCADB.  What's the timeline for CAs to upload them?

Well, let's figure out what the right thing to do is first. If it turns
out we've created new normative requirements accidentally, the first
thing to do is to decide whether that's what we meant. Only then will we
set some sort of sane implementation timeline.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy