Re: Symantec Response L

2017-04-13 Thread Myers, Kenneth (10421) via dev-security-policy 
I don't know if it was mentioned elsewhere but Symantec had an MOA with the 
Federal PKI which required cross-certificates. If Symantec revoked it, the MOA 
would also have been violated which would have severed the trust with the 
Federal PKI and Symantec customers.

To the particular IdenTrust CA, it was part of a different program still under 
the Federal PKI (the General Services Administration Access Certificates for 
Electronic Services Program). Coincidentally, at the same time the cross 
certificate was brought up, the ACES CP was updated to not allow 
cross-certificates. Just a coincidence which potentially led to the shorter 
timeline in revocation.

Kenneth Myers
Protiviti | Government Solutions | Manager
Alexandria | +1 571-366-6120 | 
kenneth.my...@protiviti.com
Connect: LinkedIn | Thought Leadership: 
Protiviti.com

On Apr 12, 2017, at 14:42, 
"dev-security-policy-requ...@lists.mozilla.org"
 
>
 wrote:

Re: Symantec Response L
NOTICE: Protiviti is a global consulting and internal audit firm composed of 
experts specializing in risk and advisory services. Protiviti is not licensed 
or registered as a public accounting firm and does not issue opinions on 
financial statements or offer attestation services. This electronic mail 
message is intended exclusively for the individual or entity to which it is 
addressed. This message, together with any attachment, may contain confidential 
and privileged information. Any views, opinions or conclusions expressed in 
this message are those of the individual sender and do not necessarily reflect 
the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, 
printing, copying, retention, disclosure or distribution is strictly 
prohibited. If you have received this message in error, please immediately 
advise the sender by reply email message to the sender and delete all copies of 
this message. Thank you.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Response B

2017-04-13 Thread Jeremy Rowley via dev-security-policy 
Because the certificate improperly included Symantec's BR-compliance OID. If
the cert wasn't a BR-covered certificate but included the BR compliance OID,
then the cert was still mis-issued and should be disclosed.

Jeremy 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, April 13, 2017 7:49 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Response B

Symantec's bug opens with the words:

"At the end of 2013, Symantec issued a cert to one of its customers that did
not comply with several provisions of the CA/Browser Forum Baseline
Requirements."[0]

So Symantec, at least, thought that this cert fell under the BRs. If their
case was that it did not, why did they feel a need to report?

Gerv

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=966350
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Email sub-CAs

2017-04-13 Thread 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

2017-04-13 Thread 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: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-04-13 Thread Gervase Markham via dev-security-policy 
On 12/04/17 21:39, uri...@gmail.com wrote:
> Is there an expectation of a resolution of some sort to this matter?
> Also, their most recent audit is apparently overdue (perhaps related to the 
> SHA-1 mis-issuance?)
> 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/-689uFoXBwAJ

I am actively pursuing Trustis in regard to this matter.

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

Re: Email sub-CAs

2017-04-13 Thread 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

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-04-13 Thread Rob Stradling via dev-security-policy 

Thanks Gerv.  :-)

On 13/04/17 14:46, Gervase Markham via dev-security-policy wrote:

Hi Rob,

You either have a great memory or good search-fu; well done for digging
this out!

On 12/04/17 22:14, Rob Stradling wrote:

Gerv, FYI what you're proposing here
(https://github.com/mozilla/pkipolicy/issues/69) was slated to appear in
v2.1 of the policy, but it was vetoed by Symantec.

Here's why...

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/l1BAEHjKe8Q/mey4WREKpooJ


Hmm. I note we didn't end up using Symantec's proposed text either.

I'm not sure I entirely understand their objection. They wanted to
confirm via "business controls" that the customer was authorized to
issue email certs for the domain. What sort of thing might that be, and
how is it different to a technical control? Does it just involve the
customer pinky-swearing that it's OK for them to issue such certs?

I can see that CAs might want to issue email certs for almost any
domain, if the controller of an email address comes and asks for one.
But in that sort of case, I wouldn't expect them to be using a TCSC.
TCSCs are for "Hi, I'm Company X, and have 100,000 employees with
@companyx.com email addresses, and want to issue them publicly-trusted
email certs. Give me a TCSC for @companyx.com." Whereupon the CA would
get them to prove they own that domain, then provide them with such a
certificate.

Gerv


--
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: Grace Period for Sub-CA Disclosure

2017-04-13 Thread Rob Stradling via dev-security-policy 

On 13/04/17 14:50, Gervase Markham wrote:

On 12/04/17 21:21, Rob Stradling wrote:

Mozilla also requires CAs to disclose intermediate cert revocations to
CCADB.  Should there be a corresponding time limit in the policy
regarding how soon after revocation this disclosure must occur?


There is:

"If a non-exempt intermediate certificate is revoked, the CCADB must be
updated to mark it as revoked, giving the reason why, within 24 hours
for a security incident, and within 7 days for any other reason."
https://github.com/mozilla/pkipolicy/blob/master/ccadb/policy.md


Ah, thanks Gerv.  I hadn't looked in that doc.


https://crt.sh/mozilla-disclosures#disclosedbutincrl currently shows 2
GlobalSign EV intermediates that were revoked by Google Trust Services 5
days ago, but which are still unrevoked according to CCADB.  By when
must GTS notify CCADB of these 2 revocations?


Assuming they weren't revoked because of a security incident, some time
in the next two days :-)

Gerv


--
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: Grace Period for Sub-CA Disclosure

2017-04-13 Thread Gervase Markham via dev-security-policy 
On 12/04/17 21:21, Rob Stradling wrote:
> Mozilla also requires CAs to disclose intermediate cert revocations to
> CCADB.  Should there be a corresponding time limit in the policy
> regarding how soon after revocation this disclosure must occur?

There is:

"If a non-exempt intermediate certificate is revoked, the CCADB must be
updated to mark it as revoked, giving the reason why, within 24 hours
for a security incident, and within 7 days for any other reason."
https://github.com/mozilla/pkipolicy/blob/master/ccadb/policy.md

> https://crt.sh/mozilla-disclosures#disclosedbutincrl currently shows 2
> GlobalSign EV intermediates that were revoked by Google Trust Services 5
> days ago, but which are still unrevoked according to CCADB.  By when
> must GTS notify CCADB of these 2 revocations?

Assuming they weren't revoked because of a security incident, some time
in the next two days :-)

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

Re: Symantec Response B

2017-04-13 Thread Gervase Markham via dev-security-policy 
Symantec's bug opens with the words:

"At the end of 2013, Symantec issued a cert to one of its customers that
did not comply with several provisions of the CA/Browser Forum Baseline
Requirements."[0]

So Symantec, at least, thought that this cert fell under the BRs. If
their case was that it did not, why did they feel a need to report?

Gerv

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=966350
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy