RE: CA Validation quality is failing

[Jeremy Rowley via dev-security-policy]

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 can look into 
separately.

 

Thank you for

1) Disclosing the details to a sufficient level of detail immediately

2) Providing regular updates and continued investigation

3) Confirming the acceptability of the plan before implementing it, and with 
sufficient detail to understand the implications

 

These are several of the factors we weighed when considering the 
implications/risk of not revoking.

 



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

[Peter Kurrasch via dev-security-policy]

  Hi Gerv,Your updates look good! One small quibble: The bottom of the Physical Relocation section mentions the code signing trust bit, but I think that is irrelevant now?Would you feel comfortable mandating that, whenever an organization notifies Mozilla about changes in ownership or operation, the organization must notify the public about any such changes? The idea here is transparency, and making sure that all parties (subscribers and relying parties alike) are made aware of the changes in case they wish to make changes of their own.For whatever it's worth, I gave the Personnel Changes section a bit of thought and wondered if further articulation of "changes" might be helpful. The example that came to mind is GTS and GlobalSign--specifically, that Google would continue to use GlobalSign's infrastructure until a transition is made in the future. Presumably, a change in personnel will take place when Google switches to its own infrastructure, so should Mozilla be notified at that time? As written, I think the answer could be yes, but is that necessarily what you want?(And, for the record, I'm not trying to rehash any past discussion of the acquisition. Rather, I thought it might be a good real-world example based on my understanding of events. If my facts are wrong, that hopefully will not nullify its value as a hypothetical example.)If you prefer to leave the personnel section as-is, I have no issue with that.From: Gervase Markham via dev-security-policySent: Monday, May 1, 2017 4:02 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Policy 2.5 Proposal: Incorporate Root Transfer PolicyMozilla has a Root Transfer Policy which sets out our expectationsregarding how roots are transferred between organizations, or whathappens when one company buys another, based on a recognition that trustis not always transferable.https://wiki.mozilla.org/CA:RootTransferPolicyIt has been reasonably observed that it would be better if this policywere part of our official policy rather than a separate wiki page.So, I have attempted to take that wiki page, remove duplication and boilit down into a set of requirements to add to the existing policy.Here is a diff of the proposed changes:https://github.com/mozilla/pkipolicy/compare/issue-57This is: https://github.com/mozilla/pkipolicy/issues/57---This is a proposed update to Mozilla's root store policy for version2.5. Please keep discussion in this group rather than on Github. Silenceis consent.Policy 2.4.1 (current version):https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.mdUpdate process:https://wiki.mozilla.org/CA:CertPolicyUpdates___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

[Peter Kurrasch via dev-security-policy]

  I was thinking that fraud takes many forms generally speaking and that the PKI space is no different. Given that Mozilla (and everyone else) work very hard to preserve the integrity of the global PKI and that the PKI itself is an important tool to fighting fraud on the Internet, it seems to me like it would be a missed opportunity if the policy doc made no mention of fraud.Some fraud scenarios that come to mind:- false representation as a requestor- payment for cert services using a stolen credit card number- malfeasance on the part of the cert issuer- requesting and obtaining certs for the furtherance of fraudulent activityRegarding that last item, I understand there is much controversy over the prevention and remediation of that behavior but I would hope there is widespread agreement that it does at least exist.From: Gervase MarkhamSent: Monday, May 1, 2017 10:49 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"On 01/05/17 16:28, Peter Kurrasch wrote:> Gerv, does this leave the Mozilla policy with no position statement regarding fraud in the global PKI?What do you mean by "in"?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: Indicate direction of travel with respect to permitted domain validation methods

[Ryan Sleevi via dev-security-policy]

On Mon, May 1, 2017 at 5:02 PM, Lee via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Maybe it's because I've worked with some incredibly bad auditors, but
> the way I read the proposal, doing anything other than one of those
> exact 10 methods is risking an audit failure.
>

Well, you can hopefully understand why requiring exactly those 10 methods
IS desired :)


> How would you word the policy to make it clear that while a CA is
> required to use one of those 10 methods, the CA is also allowed to do
> additional/stricter checks?


I wouldn't think it would be necessary, any more than a CA that adds
additional checks to identity validation (of which many do) doesn't require
additional details to permit it :)

The BRs define the minimum, not the absolute :)
___
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

[Lee via dev-security-policy]

On 5/1/17, Ryan Sleevi  wrote:
> On Mon, May 1, 2017 at 1:53 PM, Lee via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 5/1/17, Gervase Markham via dev-security-policy
>>  wrote:
>> > The last CA Communication laid down our policy of only permitting the
>> > 10
>> > Blessed Methods of domain validation. A CA Communication is an official
>> > vehicle for Mozilla Policy so this is now policy, but it's not
>> > reflected
>> > in the main policy doc. I was planning to wait until the latest version
>> > of the BRs had all 10 methods in, but that ballot (ballot 190) seems to
>> > be taking a bit of time to draft. So perhaps it would be good to add
>> > language to indicate direction of travel.
>> >
>> > This would involve replacing section 2.2.3 of the policy with:
>> >
>> > "for a certificate capable of being used for SSL-enabled servers, the
>> > CA
>> > must ensure that the applicant has registered the domain(s) referenced
>> > in the certificate or has been authorized by the domain registrant to
>> > act on their behalf. This must be done using one or more of the 10
>> > methods documented in section 3.2.2.4 of version 1.4.1 (and not any
>> > other version) of the CA/Browser Forum Baseline Requirements. The CA's
>> > CP/CPS must clearly specify the procedure(s) that the CA employs, and
>> > each documented procedure should state which subsection of 3.2.2.4 it
>> > is
>> > complying with. Even if the current version of the BRs contains a
>> > method
>> > 3.2.2.4.11, CAs are not permitted to use this method."
>>
>> You seem to be replacing a "meets or exceeds" requirement with a
>> "strictly meets" requirement.
>>
>> I'd suggest something along the lines of
>> The CA MUST use one of the allowed methods of domain validation
>> () and, in addition,
>> MAY use additional and/or stricter methods of domain validation.
>>
>> In other words, make it clear to an auditor that while the CA must
>> meet the baseline requirements, it's not an audit failure if they go
>> above & beyond the minimum requirements of domain validation.
>>
>> Regards,
>> Lee
>
>
> You can only go "above and beyond" if you're implementing those literal 10
> methods. That is, there is a real risk with that MAY that it may be
> interpreted as reintroducing the "Any other method" loophole that's
> explicitly trying to be avoided.
>
> Any CA who is "exceeding" this method strictly meets the definition.

Maybe it's because I've worked with some incredibly bad auditors, but
the way I read the proposal, doing anything other than one of those
exact 10 methods is risking an audit failure.

How would you word the policy to make it clear that while a CA is
required to use one of those 10 methods, the CA is also allowed to do
additional/stricter checks?

Regards,
Lee
___
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]

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?

Jeremy



-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Thursday, April 27, 2017 2:41 AM
To: Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Validation quality is failing

On 27/04/17 00:16, Jeremy Rowley wrote:
> We also started the revocation process for the 500 certificates 
> containing meta-data. However, we wanted to ask about the 1000 
> certificates containing data indicating the field was not applicable.
> We recognize these were not properly issued, but I am curious whether 
> revocation is required by Mozilla in this case. Should we start 
> revoking those certificates as well despite the certificate 
> information clearly not indicating a state/province? My thought is yes 
> because of BR 4.9.1.1:
> 
> 9. The CA is made aware that the Certificate was not issued in 
> accordance with these Requirements or the CA’s Certificate Policy or 
> Certification Practice Statement;

What line in your CP or CPS is violated by these certs?

> I don't think #10 applies because the information is accurate - the 
> field is not applicable: 10. The CA determines that any of the 
> information appearing in the Certificate is inaccurate or misleading;

I agree that a "." or "-" instead of a field being empty is not inaccurate or 
misleading. However, #10 also says "the CA determines", so it's your view, not 
mine, which is most relevant :-)

Gerv


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: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Ryan Sleevi via dev-security-policy]

On Mon, May 1, 2017 at 1:53 PM, Lee via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 5/1/17, Gervase Markham via dev-security-policy
>  wrote:
> > The last CA Communication laid down our policy of only permitting the 10
> > Blessed Methods of domain validation. A CA Communication is an official
> > vehicle for Mozilla Policy so this is now policy, but it's not reflected
> > in the main policy doc. I was planning to wait until the latest version
> > of the BRs had all 10 methods in, but that ballot (ballot 190) seems to
> > be taking a bit of time to draft. So perhaps it would be good to add
> > language to indicate direction of travel.
> >
> > This would involve replacing section 2.2.3 of the policy with:
> >
> > "for a certificate capable of being used for SSL-enabled servers, the CA
> > must ensure that the applicant has registered the domain(s) referenced
> > in the certificate or has been authorized by the domain registrant to
> > act on their behalf. This must be done using one or more of the 10
> > methods documented in section 3.2.2.4 of version 1.4.1 (and not any
> > other version) of the CA/Browser Forum Baseline Requirements. The CA's
> > CP/CPS must clearly specify the procedure(s) that the CA employs, and
> > each documented procedure should state which subsection of 3.2.2.4 it is
> > complying with. Even if the current version of the BRs contains a method
> > 3.2.2.4.11, CAs are not permitted to use this method."
>
> You seem to be replacing a "meets or exceeds" requirement with a
> "strictly meets" requirement.
>
> I'd suggest something along the lines of
> The CA MUST use one of the allowed methods of domain validation
> () and, in addition,
> MAY use additional and/or stricter methods of domain validation.
>
> In other words, make it clear to an auditor that while the CA must
> meet the baseline requirements, it's not an audit failure if they go
> above & beyond the minimum requirements of domain validation.
>
> Regards,
> Lee


You can only go "above and beyond" if you're implementing those literal 10
methods. That is, there is a real risk with that MAY that it may be
interpreted as reintroducing the "Any other method" loophole that's
explicitly trying to be avoided.

Any CA who is "exceeding" this method strictly meets the definition.
___
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

[Lee via dev-security-policy]

On 5/1/17, Gervase Markham via dev-security-policy
 wrote:
> The last CA Communication laid down our policy of only permitting the 10
> Blessed Methods of domain validation. A CA Communication is an official
> vehicle for Mozilla Policy so this is now policy, but it's not reflected
> in the main policy doc. I was planning to wait until the latest version
> of the BRs had all 10 methods in, but that ballot (ballot 190) seems to
> be taking a bit of time to draft. So perhaps it would be good to add
> language to indicate direction of travel.
>
> This would involve replacing section 2.2.3 of the policy with:
>
> "for a certificate capable of being used for SSL-enabled servers, the CA
> must ensure that the applicant has registered the domain(s) referenced
> in the certificate or has been authorized by the domain registrant to
> act on their behalf. This must be done using one or more of the 10
> methods documented in section 3.2.2.4 of version 1.4.1 (and not any
> other version) of the CA/Browser Forum Baseline Requirements. The CA's
> CP/CPS must clearly specify the procedure(s) that the CA employs, and
> each documented procedure should state which subsection of 3.2.2.4 it is
> complying with. Even if the current version of the BRs contains a method
> 3.2.2.4.11, CAs are not permitted to use this method."

You seem to be replacing a "meets or exceeds" requirement with a
"strictly meets" requirement.

I'd suggest something along the lines of
The CA MUST use one of the allowed methods of domain validation
() and, in addition,
MAY use additional and/or stricter methods of domain validation.

In other words, make it clear to an auditor that while the CA must
meet the baseline requirements, it's not an audit failure if they go
above & beyond the minimum requirements of domain validation.

Regards,
Lee



>
> Once the BRs are back to the way they should be, a few edits to this
> para should normalize the situation.
>
> There is a deadline associated with this change of July 21st 2017;
> traditionally, we communicate deadlines for particular requirements
> out-of-band.
>
> This is: https://github.com/mozilla/pkipolicy/issues/77
>
> ---
>
> This is a proposed update to Mozilla's root store policy for version
> 2.5. Please keep discussion in this group rather than on Github. Silence
> is consent.
>
> Policy 2.4.1 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
> Update process:
> https://wiki.mozilla.org/CA:CertPolicyUpdates 
> ___
> 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: Draft Proposal

[Alex Gaynor via dev-security-policy]

Hi Gerv,

One idea that occurred to me (maybe novel, though I doubt it), is requiring
mandatory _timely_ CT submission for intermediates/cross signatures. That
is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
less than some period, perhaps 3 days. This would ensure rapid visibility
into important changes to the WebPKI.

Alex

On Mon, May 1, 2017 at 10:16 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Here is my analysis and proposal for what actions the Mozilla CA
> Certificates module owner should take in respect of Symantec.
>
> https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-
> lUPmatQZwx3Sn2NPz9jF8/edit#
>
> Please discuss the document here in mozilla.dev.security.policy. A good
> timeframe for discussion would be one week; we would aim to finalise the
> plan and pass it to the module owner for a decision next Monday, 8th
> May. Note that Kathleen is not around until Wednesday, and may choose to
> read rather than comment here. It is not a given that she will agree
> with me, or the final form of the proposal :-)
>
> 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: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

[Peter Kurrasch via dev-security-policy]

Gerv, does this leave the Mozilla policy with no position statement regarding 
fraud in the global PKI?


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Monday, May 1, 2017 3:36 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

On 20/04/17 14:39, Gervase Markham wrote:
> So I propose removing it, and reformatting the section accordingly.

Edit made as proposed.

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: StartCom continues to sell untrusted certificates

[Henri Sivonen via dev-security-policy]

On Mon, May 1, 2017 at 11:31 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 01/05/17 07:52, Percy wrote:
>> It seems that StartCom continues to sell untrusted certs. Neither their
home page https://www.startcomca.com/ nor their announcement page
https://www.startcomca.com/index/news mentions that those certs are not
trusted.
>
> Why is this something that Mozilla should be concerned with?
>
> "Selling untrusted certs" is not a crime, or a violation of any
> standard. Mozilla is not the global authority on what certificates may
> be issued. If StartCom are providing certificates which do not do what
> their customers expect, I'm sure those customers will let them know
> about it soon enough.

What StartCom claims about compatibility is potentially more
Mozilla-relevant than what they are silent about. At the bottom of their
front page, it says "StartCom™ / StartSSL™is supported by:" followed by
icons. The icons include an early icon for Camino and the SeaMonkey icon.
Since Camino was discontinued before Mozilla's change in trust in StartCom
certificates, I guess having Camino there isn't technically incorrect, but
is about as relevant as having the Flock icon there. However, is it correct
to have the SeaMonkey icon there? The latest SeaMonkey release seems to
post-date the Mozilla root program's trust change in StartCom certificates.
(But then, it seems that there have been a number of Firefox ESR security
patch releases that post-date the SeaMonkey release. Is SeaMonkey still
active, despite appearing not to ship Gecko security updates, and does
SeaMonkey implement the same trust special-casing as Firefox? It seems to
produce nightlies still.)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

Here is my analysis and proposal for what actions the Mozilla CA
Certificates module owner should take in respect of Symantec.

https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#

Please discuss the document here in mozilla.dev.security.policy. A good
timeframe for discussion would be one week; we would aim to finalise the
plan and pass it to the module owner for a decision next Monday, 8th
May. Note that Kathleen is not around until Wednesday, and may choose to
read rather than comment here. It is not a given that she will agree
with me, or the final form of the proposal :-)

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

Re: Symantec Conclusions and Next Steps

[Alex Gaynor via dev-security-policy]

(I work for Mozilla, but this email doesn't necessarily reflect the views
of Mozilla).

Hi Steve,

I appreciate Symantec taking the time to put this together. There's a lot
of unpack here, so I wanted to zoom in on one portion of it.

When discussing the feedback you received from enterprise customers, and
the impact that Google's proposed change would have, one of the challenges
you highlight is for customers who have pinned certificates, from mobile
apps to embedded devices.

I find this a bit perplexing, Google's current proposal does not remove
trust in the existing Symantec roots, it merely accelerates the expiration
of existing end-entity certs, and caps the lifetime of future certs.

While I'm happy to grant that re-issuance can be a time consuming procedure
for large organizations which have failed to automate certificate issuance
and deployment (hopefully this is something they're working on!), this
challenge is more or less unrelated to needing to change pinned roots/trust
stores.

In short, Symantec appears to be describing potential fallout from a total
distrust, which is not what Google's Intent to Deprecate thread proposed.
Can you speak to why Symantec chose to focus on this issue?

Thanks,
Alex

On Wed, Apr 26, 2017 at 8:48 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Gervase Markham via dev-security-policy
> > Sent: Friday, April 21, 2017 6:17 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Symantec Conclusions and Next Steps
> >
> [snip]
> >
> > Symantec have also written to Mozilla to say the following:
> >
> > "We have been working hard on a thorough and thoughtful proposal that
> > responds to community questions and concerns regarding our compliance
> > and issuance practices. In drafting this proposal, we’ve thoughtfully
> > considered the feedback posted on the Mozilla forums along with comments
> > on the Google forums and other community feedback. We’ve also solicited
> > input from our customers who are the ones that would bear the impact of
> > changes, whether as a result of our proposal or any other.
> >
> > We plan to send a proposal for Mozilla’s and the community’s
> consideration
> > on Wednesday April 26th that addresses these important areas:
> >
> > * The Integrity of our EV Validation Process
> > * Validity of Existing Certificates
> > * Increased Transparency
> > * Move to Shorter Validity Certificates
> > * Continuous Improvement of our CA Operations"
> >
> > This date is in the middle of next week. We permitted WoSign to propose a
> > remediation plan; I think it is reasonable to do the same for Symantec.
> So we
> > will wait to hear what they have to say, and then discuss appropriate
> action in
> > the light of it.
> >
> > Gerv
> >
>
> Symantec CA Response to Google Proposal and Community Feedback
>
> We take our role as a key player in the trust ecosystem of the Internet
> very seriously. We believe that secure and compliant issuance of SSL/TLS
> certificates is fundamental to the security of the Internet and that we
> have a responsibility to collaborate with our customers and the broader
> community to continuously improve industry standards, and specifically our
> practices, for certificate issuance.
>
> On March 23, Google posted a blog outlining a proposal to change how
> Symantec’s SSL/TLS certificates are recognized in Chrome. Their proposal
> stemmed from prior certificate mis-issuances that occurred in our
> Certificate Authority (CA) business, which we have taken extensive
> remediation measures to correct. We have carefully reviewed Google’s
> proposal and sought input from the broader browser and user community on
> this topic, which has informed our continuous improvement planning. This
> post outlines important measures that we propose to implement in our CA
> business. We believe our proposal addresses the concerns raised by Google
> about our CA business without imposing undue business disruption on our
> customers and Chrome users that we believe would result if Google
> implements its proposal.
>
> Feedback from our Enterprise Customers
>
> In addition to our review of public commentary on these issues, we have
> also sought input and feedback from Symantec customers on the compatibility
> and interoperability impact of the significant changes that could result
> from the implementation of Google’s proposal. These customers include many
> of the largest financial services, critical infrastructure, retail and
> healthcare organizations in the world, as well as many government agencies.
> This cohort is an important constituency that we believe has been
> under-represented to date in the public commentary that has been posted to
> the Google and Mozilla boards since large organizations rarely authorize
> employees to 

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

[Gervase Markham via dev-security-policy]

The last CA Communication laid down our policy of only permitting the 10
Blessed Methods of domain validation. A CA Communication is an official
vehicle for Mozilla Policy so this is now policy, but it's not reflected
in the main policy doc. I was planning to wait until the latest version
of the BRs had all 10 methods in, but that ballot (ballot 190) seems to
be taking a bit of time to draft. So perhaps it would be good to add
language to indicate direction of travel.

This would involve replacing section 2.2.3 of the policy with:

"for a certificate capable of being used for SSL-enabled servers, the CA
must ensure that the applicant has registered the domain(s) referenced
in the certificate or has been authorized by the domain registrant to
act on their behalf. This must be done using one or more of the 10
methods documented in section 3.2.2.4 of version 1.4.1 (and not any
other version) of the CA/Browser Forum Baseline Requirements. The CA's
CP/CPS must clearly specify the procedure(s) that the CA employs, and
each documented procedure should state which subsection of 3.2.2.4 it is
complying with. Even if the current version of the BRs contains a method
3.2.2.4.11, CAs are not permitted to use this method."

Once the BRs are back to the way they should be, a few edits to this
para should normalize the situation.

There is a deadline associated with this change of July 21st 2017;
traditionally, we communicate deadlines for particular requirements
out-of-band.

This is: https://github.com/mozilla/pkipolicy/issues/77

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates   
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.5 Proposal: New version of WebTrust Criteria -- v2.2

[Gervase Markham via dev-security-policy]

There is a new version of the WebTrust criteria, version 2.2, which
references version 1.4.2 of the BRs (although the BRs themselves say
that audits should be to the latest version). We should update our
policy to reference this new version.

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 .

This is: https://github.com/mozilla/pkipolicy/issues/44

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.5 Proposal: Incorporate Root Transfer Policy

[Gervase Markham via dev-security-policy]

Mozilla has a Root Transfer Policy which sets out our expectations
regarding how roots are transferred between organizations, or what
happens when one company buys another, based on a recognition that trust
is not always transferable.

https://wiki.mozilla.org/CA:RootTransferPolicy

It has been reasonably observed that it would be better if this policy
were part of our official policy rather than a separate wiki page.

So, I have attempted to take that wiki page, remove duplication and boil
it down into a set of requirements to add to the existing policy.

Here is a diff of the proposed changes:
https://github.com/mozilla/pkipolicy/compare/issue-57

This is: https://github.com/mozilla/pkipolicy/issues/57

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
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

[Gervase Markham via dev-security-policy]

Does anyone have any thoughts about this issue, below?

I sent out a message saying that I had adopted this change as proposed,
but that was an error. It has not yet been adopted, because I am
concerned about the below.

The first option is simpler, because it does not need to get into the
details of who controls or who has issuance authority for the
intermediate, and what their relationship is with the domain names in
question. Some concrete proposed text for that option is:

"Each entry in permittedSubtrees must either be or end with a Public
Suffix." (And we'd need to link to publicsuffix.org)

The second option is harder to spec, because I don't know the uses to
which TCSCs for email are put. Is the idea that they get handed to a
customer, and so it's OK to say that the domain names have to be
validated as being owned by the entity which has authority to command
issuance? Or are there scenarios I'm missing?

Gerv

On 20/04/17 14:26, Gervase Markham wrote:
> On 12/04/17 10:47, Gervase Markham wrote:
>> "If the certificate includes the id-kp-emailProtection extended key
>> usage, it MUST include the Name Constraints X.509v3 extension with
>> constraints on rfc822Name, with at least one name in permittedSubtrees."
> 
> As worded, this would allow for a set of constraints which looked like:
> 
> ".com, .net, .edu, .us, .uk, ..."
> 
> The SSL BRs require:
> 
> "(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the
> Applicant has registered the dNSName or has been authorized by the
> domain registrant to act on the registrant's behalf in line with the
> verification practices of section 3.2.2.4."
> 
> That's not possible for e.g. ".com", so the problem is avoided.
> 
> Do we need to say that each entry in permittedSubtrees must be a Public
> Suffix? Or do we need to require that each rfc822Name is
> ownership-validated in a analogous way to the dNSNames in the BRs?
> 
> 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: Remove BR duplication: reasons for revocation

[Gervase Markham via dev-security-policy]

On 20/04/17 14:46, Gervase Markham wrote:
> So, proposed new text:
> 
> "CAs MUST revoke Certificates that they have issued upon the
> occurrence of any event listed in the appropriate subsection of section
> 4.9.1 of the Baseline Requirements (for email certificates, not
> including those events specific to the inclusion of Domain Names)."

Edit made as follows:

"CAs MUST revoke Certificates that they have issued upon the occurrence
of any event listed in the appropriate subsection of section 4.9.1 of
the Baseline Requirements, according to the timeline defined therein."

I added the note about timeline because it's possible that the Forum may
be updating those rules soon to be a bit more flexible, and I wouldn't
want it to seem like the Mozilla policy requires immediate revocation.

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: Remove the bullet about "fraudulent use"

[Gervase Markham via dev-security-policy]

On 20/04/17 14:39, Gervase Markham wrote:
> So I propose removing it, and reformatting the section accordingly.

Edit made as proposed.

Gerv

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

Re: StartCom continues to sell untrusted certificates

[Gervase Markham via dev-security-policy]

On 01/05/17 07:52, Percy wrote:
> It seems that StartCom continues to sell untrusted certs. Neither their home 
> page https://www.startcomca.com/ nor their announcement page 
> https://www.startcomca.com/index/news mentions that those certs are not 
> trusted. 

Why is this something that Mozilla should be concerned with?

"Selling untrusted certs" is not a crime, or a violation of any
standard. Mozilla is not the global authority on what certificates may
be issued. If StartCom are providing certificates which do not do what
their customers expect, I'm sure those customers will let them know
about it soon enough.

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

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Gervase Markham via dev-security-policy]

On 20/04/17 14:02, Gervase Markham wrote:
> I propose this section be removed from the document.

This section has now been removed. Regardless of other points raised,
the issuing of wildcard certs /per se/ is not a Problematic Practice.

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

StartCom continues to sell untrusted certificates

[Percy via dev-security-policy]

It seems that StartCom continues to sell untrusted certs. Neither their home 
page https://www.startcomca.com/ nor their announcement page 
https://www.startcomca.com/index/news mentions that those certs are not 
trusted. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy