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

[Jakob Bohm via dev-security-policy]

On 08/05/2017 12:16, Gervase Markham wrote:

On 05/05/17 22:21, Jakob Bohm wrote:

The issue would be implementations that only check the EE cert for
their desired EKU (such as ServerAuth checking for a TLS client or
EmailProtection checking for a mail client).  In other words, relying
parties whose software would accept a chain such as

root CA (no EKUs) => SubCA (EmailProtection) => EE cert (ServerAuth).


Do you know of any such implementations?


I am not sure.  I suspect such simple implementations (that only check
for the specifically desired EKU in the EE cert) were common in the
past, and I don't know if all implementations have switched to the
interpretation that CA EKUs act as constraints on child EKUs.

This simple implementation kind would correspond to interpreting the
EKUs in a CA cert to describe the abilities of the CA cert itself (i.e.
it could reasonable list only CA related uses such as CertSign,
CRLSign, OCSPSign).  (Not checked for typos).




One other question: Does your proposal allow a TCSC that covers both
ServerAuth and EmailProtection for the domains of the same organization?


I don't believe my proposal forbids this. Do you think it should?



These questions were directed at Dimitris' wording.


Does Mozilla as a Browser implementer have any policy or technical
requirements on certificates that Mozilla products can use for
ClientAuth


No policy requirements to my knowledge. There may be technical
requirements (e.g. now we've turned off SHA-1 support, I doubt that
works with ClientAuth either).





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[Kathleen Wilson via dev-security-policy]

On Tuesday, May 9, 2017 at 10:03:53 AM UTC-7, Kurt Roeckx wrote:
> 
> Do we somewhere have the official templates being used to send
> reminders of the audit requirements? 

Unofficial templates: 
https://wiki.mozilla.org/CA:Email_templates

The official templates are in Salesforce, but currently match the wiki page.


> Kathleen posts a summary of
> the email that got send, but I'm not sure if they contain more
> text or if the text changes as the period gets longer.

For directly included certs, the email changes as the period gets longer.

So far we only have one email template for intermediate certs:
https://wiki.mozilla.org/CA:Email_templates#Disclosure_Incomplete_Email_Template

I have not yet created automation around notifying CAs of overdue audit 
statements for intermediate certs.

Kathleen


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

RE: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Doug Beattie via dev-security-policy]

Gerv,

I'm not clear on what you mean by CAs must use only the 10 Blessed Methods by 
21st July 2017.  

I'm assuming this is the latest official draft:

https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md

Specifically, does this mean all new domain validations must conform to the 10 
methods, or that all new issuance must be based on domains validated with only 
these 10 methods?

Doug


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Tuesday, May 9, 2017 12:58 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Policy 2.5 Proposal: Indicate direction of travel with respect to
> permitted domain validation methods
> 
> On 01/05/17 10:13, Gervase Markham wrote:
> > This would involve replacing section 2.2.3 of the policy with:
> 
> 
> 
> Incorporated as drafted. CAs should take note (from this change and from the
> CA Communication) that Mozilla's policy is moving in the direction of 
> requiring
> the 10 Blessed Methods alone, and that the deadline is 21st July 2017.
> 
> 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: Symantec: Update

[Kurt Roeckx via dev-security-policy]

On Tue, May 09, 2017 at 04:51:12PM +0100, Gervase Markham via 
dev-security-policy wrote:
> Despite the fact that there appear to be
> numerous under-audited and unaudited publicly-trusted sub-CAs out there,
> and this fact has been known for weeks now, Symantec has not said
> anything about the situation to Mozilla, either publicly or privately.
> Would we find this acceptable in any other CA?

Do we somewhere have the official templates being used to send
reminders of the audit requirements? Kathleen posts a summary of
the email that got send, but I'm not sure if they contain more
text or if the text changes as the period gets longer.

>From the draft templates I could find, I suggest we skip the 
first one because it's about being late and there are no audit
reports here. The second template would file a removal bug and start
discussing it here.

Instead of the removal of the roots, I suggest we either ask them
to revoke all the intermediate CAs that do not have the required
audits or that Mozilla adds them to OneCRL.

Did someone try to make a list of all CA certificates that don't
have all the required audit requirements marked in the common CA
database, including other CAs? We really should do this for all
such cases.


Kurt

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

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Gervase Markham via dev-security-policy]

On 01/05/17 10:13, Gervase Markham wrote:
> This would involve replacing section 2.2.3 of the policy with:



Incorporated as drafted. CAs should take note (from this change and from
the CA Communication) that Mozilla's policy is moving in the direction
of requiring the 10 Blessed Methods alone, and that the deadline is 21st
July 2017.

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: New version of WebTrust Criteria -- v2.2

[Gervase Markham via dev-security-policy]

On 01/05/17 10:09, Gervase Markham wrote:
> This simply involves changing a "2.0" to "2.2" in section 3.1.1 and
> updating the URL labelled "WebTrust-BRs" to be
> http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf .

Done.

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: Incorporate Root Transfer Policy

[Gervase Markham via dev-security-policy]

On 01/05/17 10:02, Gervase Markham wrote:
> Here is a diff of the proposed changes:
> https://github.com/mozilla/pkipolicy/compare/issue-57

Incorporated.

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

Re: Symantec: Update

[Vincent Lynch via dev-security-policy]

Hi Gervase,

Thank you for the update on Mozilla's process.

I have one question regarding your wording. You write"I am therefore *proposing
*the following," and then you list your changes.

Does this mean that the "alternative" option is officially, 100%, off the
table? Or is this still an option Kathleen is considering?

-Vincent

On Tue, May 9, 2017 at 11:51 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi everyone,
>
> Yesterday was May 8th, which was the day I had said we would stop
> discussing my proposal of what to do about Symantec and hand it over to
> Kathleen for a decision. This didn't happen for two reasons: I had some
> personal things to deal with, and also I think the proposal needs some
> modification.
>
> Mozilla runs an open and transparent root program, and listens to the
> voice of its community. And over the past few days it's been clear that
> our community is not impressed with Symantec's engagement, or lack
> thereof, with this process. I personally am also not impressed with the
> way that getting information from Symantec feels like pulling teeth;
> questions are answered at the last possible minute, and despite there
> being major outstanding problems with compliance to Mozilla's root
> program requirements (issue Y), no effort is made from their side to
> proactively engage and start to resolve these issues. It is clear from
> the issues list that there are a number of serious concerns, and these
> are not being engaged with. Despite the fact that there appear to be
> numerous under-audited and unaudited publicly-trusted sub-CAs out there,
> and this fact has been known for weeks now, Symantec has not said
> anything about the situation to Mozilla, either publicly or privately.
> Would we find this acceptable in any other CA?
>
> I am also not happy with simply waiting for the outcome of private
> discussions between Google and Symantec in which Mozilla's interests are
> not adequately represented. I am keen to move forward, to demonstrate
> that delay is not rewarded, and (despite the fact that our process can
> be slow) to make sure that timely action is taken based on the results
> of our investigations. This is only fair, given that this is what we
> have attempted to do for other CAs which we have investigated. We should
> treat everyone the same, as far as we can.
>
> I am therefore proposing the following:
>
> * Editing the proposal to withdraw the "alternative" option, leaving
> only the "new PKI" option. I no longer have confidence that the
> alternative option represents an appropriate response. As some have
> pointed out, the "documentation" requirement is actually something
> Symantec should have done years ago as part of our intermediate
> disclosure process, and which other CAs have made great efforts to
> comply with already. The "new PKI" option represents the best way to
> reduce the risk from Symantec's under-managed and sprawling existing PKI.
>
> * Engagement here in m.d.s.p. with the community to refine and flesh out
> the "new PKI" proposal, based on the Google outline but examining it and
> enhancing it to make sure it is practical, both from an implementation
> perspective and to reduce disruption to sites as far as possible.
>
> * Discussions within Mozilla as necessary to make sure the appropriate
> parts of the organization are briefed on this process.
>
> * Submission of the proposal document to Kathleen at the earliest
> possible moment to propose that we have that plan approved as our
> requirements of Symantec. (The timeline here is dependent on other
> moving parts, but as noted above, delay is to be avoided.)
>
> We may in parallel ask further questions of Symantec, and expect timely
> answers (as this is a baseline requirement for participation in our root
> program), but this process will not wait around for those answers.
>
> I will begin work on these tasks tomorrow.
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: Not disclosed as revoked intermediate certificates

[Gervase Markham via dev-security-policy]

On 08/05/17 16:50, Kurt Roeckx wrote:
> So all of them except those from 2017-05-05 should have been marked in
> the Common CA Database as revoked but haven't been marked as such.

Thank you. I have drawn this to the attention of the 3 CAs concerned and
asked them to post here to indicate when they have found and fixed the
relevant process failure.

Gerv

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

Symantec: Update

[Gervase Markham via dev-security-policy]

Hi everyone,

Yesterday was May 8th, which was the day I had said we would stop
discussing my proposal of what to do about Symantec and hand it over to
Kathleen for a decision. This didn't happen for two reasons: I had some
personal things to deal with, and also I think the proposal needs some
modification.

Mozilla runs an open and transparent root program, and listens to the
voice of its community. And over the past few days it's been clear that
our community is not impressed with Symantec's engagement, or lack
thereof, with this process. I personally am also not impressed with the
way that getting information from Symantec feels like pulling teeth;
questions are answered at the last possible minute, and despite there
being major outstanding problems with compliance to Mozilla's root
program requirements (issue Y), no effort is made from their side to
proactively engage and start to resolve these issues. It is clear from
the issues list that there are a number of serious concerns, and these
are not being engaged with. Despite the fact that there appear to be
numerous under-audited and unaudited publicly-trusted sub-CAs out there,
and this fact has been known for weeks now, Symantec has not said
anything about the situation to Mozilla, either publicly or privately.
Would we find this acceptable in any other CA?

I am also not happy with simply waiting for the outcome of private
discussions between Google and Symantec in which Mozilla's interests are
not adequately represented. I am keen to move forward, to demonstrate
that delay is not rewarded, and (despite the fact that our process can
be slow) to make sure that timely action is taken based on the results
of our investigations. This is only fair, given that this is what we
have attempted to do for other CAs which we have investigated. We should
treat everyone the same, as far as we can.

I am therefore proposing the following:

* Editing the proposal to withdraw the "alternative" option, leaving
only the "new PKI" option. I no longer have confidence that the
alternative option represents an appropriate response. As some have
pointed out, the "documentation" requirement is actually something
Symantec should have done years ago as part of our intermediate
disclosure process, and which other CAs have made great efforts to
comply with already. The "new PKI" option represents the best way to
reduce the risk from Symantec's under-managed and sprawling existing PKI.

* Engagement here in m.d.s.p. with the community to refine and flesh out
the "new PKI" proposal, based on the Google outline but examining it and
enhancing it to make sure it is practical, both from an implementation
perspective and to reduce disruption to sites as far as possible.

* Discussions within Mozilla as necessary to make sure the appropriate
parts of the organization are briefed on this process.

* Submission of the proposal document to Kathleen at the earliest
possible moment to propose that we have that plan approved as our
requirements of Symantec. (The timeline here is dependent on other
moving parts, but as noted above, delay is to be avoided.)

We may in parallel ask further questions of Symantec, and expect timely
answers (as this is a baseline requirement for participation in our root
program), but this process will not wait around for those answers.

I will begin work on these tasks tomorrow.

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

Find a 5-year certificate

[Han Yuwei via dev-security-policy]

I have found this:
https://crt.sh/?id=6885329

I don't know whether Mozilla had allowed the certificate valid more than 39 
months, so I am here to verify it.

I have searched on Github but found nothing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Validation quality is failing

[Jeremy Rowley via dev-security-policy]

Okay - all certs were added to the CT log.  We're now working through 
revocation.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, May 2, 2017 12:09 PM
To: r...@sleevi.com
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham 

Subject: RE: CA Validation quality is failing

Okay – we’ll add them all to CT over the next couple of days.

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Tuesday, May 2, 2017 9:08 AM
To: Jeremy Rowley 
Cc: r...@sleevi.com; Gervase Markham ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Validation quality is failing

 

(Still wearing Google Hat in this context) 

 

I think sharing a list (in CT) of the certs is good and can help verify the 
assertions made here :)

 

But overall, I think this sounds right and the risk is minimal to our users, so 
not revoking still sounds good :)

 

On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley  > wrote:

Certainly happy to share more info. The search was for all EV and OV certs. Of 
the 4000 certificates detected, 101 certificates are EV. Of these EV 
certificates, 17 would be included in the proposed revocation. The rest have 
the “N/A” issue. This is just the locality/state/zip. The jurisdiction of 
incorporation processes separately and doesn’t have the same auto-populate tool.

 

More info:

78 certs had non-US states populated with US states (thanks to the 
auto-populator)

791 entities are affected by the entire range of certificates

257 entities are affected if we revoke the 1033 certs

82 entities are affected if we revoke just the 150 certs

 

What else would you like to know?

 

Jeremy

 

From: Ryan Sleevi [mailto:r...@sleevi.com  ] 
Sent: Monday, May 1, 2017 5:01 PM
To: Jeremy Rowley  >
Cc: Gervase Markham  >; 
mozilla-dev-security-pol...@lists.mozilla.org 
 
Subject: Re: CA Validation quality is failing

 

 

 

On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy 
 > wrote:

There isn't anything in our CPS directly. However, we state that we follow the 
baseline requirements in the CPS. The baseline requirements give a profile for 
the state field. We weren't sure this was strictly followed.

We finished our validation review over the weekend.   There are about 3000 
older certs with information indicating a field was not applicable (such as a 
"-", "N/A", etc). On top of this, we issued about 1000 certificates with 
mismatched validation information. The mismatched information can be divided 
into about 850 certificates with numbers in the state field. These numbers 
indicate a location code that was provided by the auto-populator.  The 
remaining 150 are certificates with "Select", a state, or a postal code 
improperly included in the certificate.  The root issue was a combination of 
the auto-populator inserting incorrect data into the cert request and our 
validation staff not properly updating the certificate information after 
completing the validation process.

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate order 
generators.
2. We already blocked this information on the CA side from included in signed 
SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.
4. We plan to let the remaining 3850 expire normally but will correct the 
certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 certificates 
because the information isn't misleading, the information is accurate, and 
there isn't a risk posed to Mozilla's users by inclusion of the numeric 
location code or not applicable indicator. Any thoughts?

 

(With a Google hat on)

 

Jeremy,

 

I think with the information you've shared so far, that sounds like a 
reasonable plan from Google's perspective for the 3000 certificates. I think 
there's at least a little concern about the EV nature for the 850 side, but 
just trying to understand more here what the implications would be. Is this 
exclusively the state, or does it also extend to the jurisdiction* fields? Or 
is this only for EV?

 

Would you be able to share a spreadsheet or details for those, in the spirit of 
transparency? I think if you can share those details, it's reasonable to avoid 
revoking, and anything specific that might represent a security/compat risk to 
an Application Software Supplier (i.e. 4.9.1.1(15) ), we