Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

[袁剑波 via dev-security-policy]

thanks


发自网易邮箱大师


在2017年05月03日 10:15，Jakob Bohm via dev-security-policy 写道：
On 02/05/2017 12:46, Gervase Markham wrote:
> On 02/05/17 01:55, Peter Kurrasch wrote:
>> 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
>
> Clearly, we have rules for vetting (in particular, EV) which try and
> avoid such things happening. It's not like we are indifferent. But
> stolen CC numbers, for example, are a factor for which each CA has to
> put in place whatever measures they feel appropriate, just as any
> business does. It's not really our concern.
>
>> - requesting and obtaining certs for the furtherance of fraudulent activity
>>
>> Regarding 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.
>
> It exists, in the same way that cars are used for bank robbery getaways,
> but the Highway Code doesn't mention bank robberies.
>
> Gerv
>

However a highway code may mention the authority of the highway police
to establish roadblocks and stop vehicles in relation to general
criminal issues.  (But it is obviously not against any law for the
police to not establish roadblocks and vehicle searches for every bank
robbery ever committed, just as there is no requirements for CAs to
revoke certificates for every allegedly fraudulent use possible).


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
___
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

[Jakob Bohm via dev-security-policy]

On 02/05/2017 17:30, Rob Stradling wrote:

On 02/05/17 16:11, Alex Gaynor via dev-security-policy wrote:

I know several CAs are using certlint
(https://github.com/awslabs/certlint)
as a pre-issuance check that the cert they're about to issue doesn't have
any programmatically detectable deficiencies; if it doesn't already cover
some of these cases, it'd be great to add them as a technical means for
ensuring that this doesn't regress -- things like N/A should be an easy
enough check to add I'd think.


Simple project idea (perhaps for https://github.com/cabforum):

A CSV file that contains 2 items per line:
1. An optional comma-separated list of Subject attribute shortnames.
2. A string that a CA should probably not encode as a complete Subject
attribute.

e.g.,
"OU,ST,L","N/A"
,"."
"O","Internet Widgits Pty Ltd"

Anyone (CA representatives, industry researchers, etc, etc) would be
able to submit PRs, CAs would be invited to consult this list when
evaluating certificate requests, and certlint would be able to report on
"violations".



For simplicity and consistency with usual best development practices
("3rd normal form"), perhaps at most one attribute shortname in column
1.


e.g. Your example would be written as:

"OU","N/A"
"ST","N/A"
"L","N/A"
,"."
"O","Internet Widgits Pty Ltd"




...




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: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Jakob Bohm via dev-security-policy]

On 01/05/2017 10:55, Gervase Markham wrote:

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?




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



Some cases to consider:

  If the permittedSubtrees specifies a public suffix, the SubCA should
  not be considered a TCSC.  It could however be a public SubCA
  dedicated to some part of the Internet, such as a country.

  If the permittedSubtrees ends with, but isn't, a public suffix, then
  the ability to issue under the TCSC should be limited to a single
  entity which has been validated to have full authority over each
  domain specified.

  If the permittedSubtrees specifies a domain that is *not* a public
  suffix, but is an IANA TLD (The classic example would be a
  hypothetical .cocacola. TLD), then the ability to issue under the
  TCSC should be limited to a single entity which has been validated to
  have full authority over each domain specified.

Thus perhaps it would be more appropriate to require that in a TCSC,
the permittedSubtrees must NOT list any public suffix or a suffix of a
public suffix.  And that control of the TCSC must be exclusively by
someone properly validated to act on behalf of each domain listed in
permittedSubtrees.

I am using the phrase "control" as a placeholder for whatever phrase
would be consistent with wording elsewhere in the policy for someone
who either:

- Is in exclusive possession of the TCSC private key material and makes
 their own decisions regarding issuance

OR

- Holds exclusive RA authority for non-technical certificates issued
 under the TCSC, while the private key is stored elsewhere (e.g. at the
 parent CA or at some other CA outsourcing facility).

OR

- Holds blocking RA authority for the TCSC such that all non-technical
 certificates issued under the TCSC require approval by the entity, but
 that additional policy requirements may be checked/enforced by some
 other entity (for example the CA outsourcing provider may be doing
 some/all of the same automated checks it would have done for an EE
 cert issued from a public SubCA).  This would be a common case where
 the private key is hosted by the parent CA under some "Enterprise
 customer" user interface.

I am using the phrase "technical certificates" as a placeholder for
whatever phrase would be consistent with wording elsewhere in the
policy for  for such things as OCSP signing certificates, CRL signing
certificates, time stamping certificates and other such CA operational
certificate types now known or yet to be invented.




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: [EXT] Re: Symantec: Draft Proposal

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> wizard--- via dev-security-policy
> Sent: Tuesday, May 02, 2017 7:10 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Re: Symantec: Draft Proposal
>
>
> Also, in the responses, Symantec claims that MSC Trustgate is no longer an
> RA (but could be a reseller). I did a quick search on crt.sh for recent
> certificates that have supplied by MSC Trustgate:
>
> [link]
>
> Going back to April 2013, this is the *only* "supplied by MSC trustgate"
> certificate in crt.sh that chains off a Symantec root; all others are 
> Globalsign.
> Can Symantec confirm that they vetted this (OV) certificate in-house? While I
> suppose MSC could supply certs from multiple CAs, I find it odd that
> everything in the logs since April 2013 is Globalsign except this one outlier 
> --
> and am concerned it means there was some mechanism for MSC to issue /
> have issued a cert off a Symantec chain -- and this concerns me given the
> higher nominal level of validation.

MSC Trustgate is an approved reseller of Symantec certificates. They are no 
longer operating as an SSL/TLS RA. This certificate was authenticated and 
issued by Symantec after having been properly submitted to us by MSC Trustgate.
___
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 – 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 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 

RE: CA Validation quality is failing

[Jeremy Rowley via dev-security-policy]

Thanks!

The revocation timeline changes are coming today/tomorrow morning.

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, May 2, 2017 4:55 AM
To: r...@sleevi.com; Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Validation quality is failing

On 02/05/17 00:01, Ryan Sleevi wrote:
> 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

I echo Ryan's comments here. I'm happy with your remediation plan, and think 
there's enough wiggle room in the BRs and Mozilla policy that revocation of 
the certs with "N/A" etc. is avoidable.

I still think we need to address that 24-hour revocation requirement to be a 
bit more nuanced, but that's a separate discussion :-)

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: [EXT] Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

Hi Steve,

On 02/05/17 18:39, Steve Medin wrote:
> Gerv- Thank you for the thoughtful analysis. We are reviewing and intend to 
> respond to your latest proposal shortly.

Please understand that this is not (yet) Mozilla's response to Symantec.
If we were a closed root program, this would be an internal discussion
draft. As we do everything in the open you get to read it now, but it
may change before we make a formal decision on our position. You are
welcome to participate in the discussion, but it is probably too early
for a formal response to the document as a whole.

If there are errors of fact in it, I would particularly appreciate
correction.

Gerv



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

RE: [EXT] Symantec: Draft Proposal

[Steve Medin via dev-security-policy]

Gerv- Thank you for the thoughtful analysis. We are reviewing and intend to 
respond to your latest proposal shortly.

> -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: Monday, May 01, 2017 10:16 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Symantec: Draft Proposal
>
> Here is my analysis and proposal for what actions the Mozilla CA Certificates
> module owner should take in respect of Symantec.
>
> https://clicktime.symantec.com/a/1/embmpyHl0xYIotG8R33Pcl_WmrsRKtG6
> UZVWv_jadWg=?d=977fUDFLd45Mc01kdDpFIhp6BGh6E7vHhynhAdgYKc7LS5
> -IW4PMfwwNk44IWsf3kg5SL1bzVN-
> 8qX842oWjKLUf2m0Opcf9ODVHP1yk400fxZY5ty4Y7BHrKRTStgnQaIyPPxl9e3l
> AN-
> M5fnM7v_3sviEmWrjTcLDXrkH6P3_FhoZEWwOu7_SX_QsCYpqcwNH3EeXWn
> 8BVLk1qqeWV5Bif1bTaL7Tt5x_6O96V7wmSpo0fuZsKDynd5LRJ5avq6ktSx2zc6
> BxeiHPXpDkIDzTHojYMzatcb0laJUTi5E44JYuI814oUpBm5xZoXoYGsUEwyOjur
> brIcHHkAb_putgEp4COnDlh3Hs74FPlR6WYnSOOiCdCydUdXVYLK3_OMlBomq
> iTSb6W4q8rG_2GPMwHZCk0nBrDFZ0Ncr6WDZU%3D=https%3A%2F%2Fd
> ocs.google.com%2Fdocument%2Fd%2F1RhDcwbMeqgE2Cb5e6xaPq-
> lUPmatQZwx3Sn2NPz9jF8%2Fedit%23
>
> 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: CA Validation quality is failing

[Rob Stradling via dev-security-policy]

On 02/05/17 16:11, Alex Gaynor via dev-security-policy wrote:

I know several CAs are using certlint (https://github.com/awslabs/certlint)
as a pre-issuance check that the cert they're about to issue doesn't have
any programmatically detectable deficiencies; if it doesn't already cover
some of these cases, it'd be great to add them as a technical means for
ensuring that this doesn't regress -- things like N/A should be an easy
enough check to add I'd think.


Simple project idea (perhaps for https://github.com/cabforum):

A CSV file that contains 2 items per line:
1. An optional comma-separated list of Subject attribute shortnames.
2. A string that a CA should probably not encode as a complete Subject 
attribute.


e.g.,
"OU,ST,L","N/A"
,"."
"O","Internet Widgits Pty Ltd"

Anyone (CA representatives, industry researchers, etc, etc) would be 
able to submit PRs, CAs would be invited to consult this list when 
evaluating certificate requests, and certlint would be able to report on 
"violations".



Cheers,
Alex

On Tue, May 2, 2017 at 11:07 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


(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 
*Cc:* Gervase Markham ; mozilla-dev-security-policy@
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 <
dev-security-policy@lists.mozilla.org> 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

Re: CA Validation quality is failing

[Alex Gaynor via dev-security-policy]

I know several CAs are using certlint (https://github.com/awslabs/certlint)
as a pre-issuance check that the cert they're about to issue doesn't have
any programmatically detectable deficiencies; if it doesn't already cover
some of these cases, it'd be great to add them as a technical means for
ensuring that this doesn't regress -- things like N/A should be an easy
enough check to add I'd think.

Cheers,
Alex

On Tue, May 2, 2017 at 11:07 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> (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-policy@
> > 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 <
> > dev-security-policy@lists.mozilla.org> 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 

Cert pinning mismatch investigation

[Gervase Markham via dev-security-policy]

Group participants may be interested in David Keeler's analysis of why
Firefox seemed to be seeing cert pinning mismatches for Mozilla properties:
https://people-mozilla.org/~dkeeler/deployment-checker-analysis.html

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

Re: Symantec: Draft Proposal

[wizard--- via dev-security-policy]

This seems like a very reasonable stance for Mozilla to take: strongly 
encourage a new Symantec PKI so they start with a clean slate, otherwise staged 
distrust of all existing certificates with the requirement that Symantec 
produce a full document/diagram of how the components of their PKI are 
connected so that the non-BR-compliant bits can be "chopped off" from trust via 
OneCRL.

Given Symantec's propensity for responding right at deadlines, might I suggest 
that, should Symantec not choose to stand up a new PKI, that you set a 
reasonable deadline for the production of the document described above? Perhaps 
May 12th?

Also, in the responses, Symantec claims that MSC Trustgate is no longer an RA 
(but could be a reseller). I did a quick search on crt.sh for recent 
certificates that have supplied by MSC Trustgate:

https://crt.sh/?Identity=%25MSC+Trustgate.com+Sdn+Bhd

It looks to me like MSC is now a globalsign reseller (sure, why not). But one 
certificate stood out:

https://crt.sh/?id=68658151

Going back to April 2013, this is the *only* "supplied by MSC trustgate" 
certificate in crt.sh that chains off a Symantec root; all others are 
Globalsign. Can Symantec confirm that they vetted this (OV) certificate 
in-house? While I suppose MSC could supply certs from multiple CAs, I find it 
odd that everything in the logs since April 2013 is Globalsign except this one 
outlier -- and am concerned it means there was some mechanism for MSC to issue 
/ have issued a cert off a Symantec chain -- and this concerns me given the 
higher nominal level of validation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

On 01/05/17 18:33, Alex Gaynor wrote:
> 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.

Interesting idea. Thanks for suggesting it :-) So something like:

Any certificate issued in Symantec's publicly-trusted hierarchies with
the cA boolean set to TRUE in basicConstraints must be submitted to two
public CT logs within 3 days of issuance.

Gerv

___
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

[Gervase Markham via dev-security-policy]

On 02/05/17 00:01, Ryan Sleevi wrote:
> 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

I echo Ryan's comments here. I'm happy with your remediation plan, and
think there's enough wiggle room in the BRs and Mozilla policy that
revocation of the certs with "N/A" etc. is avoidable.

I still think we need to address that 24-hour revocation requirement to
be a bit more nuanced, but that's a separate discussion :-)

Gerv

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

Re: Symantec: Draft Proposal

[Rob Stradling via dev-security-policy]

On 01/05/17 18:33, Alex Gaynor via dev-security-policy wrote:

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.


Hi Alex.  Mandatory timely CCADB submission is already planned (for the 
next version of the Mozilla Root Store Policy, I presume):


https://github.com/mozilla/pkipolicy/commit/b7d1b6c04458114fbe73fa3f146ad401235c2a1b

I keep an eye on https://crt.sh/mozilla-disclosures#unknown (which shows 
intermediates known to CCADB but not yet known to CT/crt.sh).  When an 
intermediate appears in that list, I'll grab the PEM data from CCADB, 
paste it onto https://crt.sh/gen-add-chain, and then submit it to some 
CT logs.  However, it would be great if the CAs would do this 
themselves.  :-)


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

[Gervase Markham via dev-security-policy]

On 02/05/17 03:10, Peter Kurrasch wrote:
> 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?

I see that on https://wiki.mozilla.org/CA:RootTransferPolicy , but
that's the document we are superceding. Can you see that on the new doc?
I can't...

> 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.

No, I would not be comfortable with that. I think that, as long as
security is not impacted (and if issuance is suspended, or continuing
under the old arrangements, it is not) it is fine for company deals to
remain confidential until they close. Once there is an actual change of
control and issuance restarts, clearly by that point the public must be
informed. But that is covered, for new root program entrants at least,
by the requirement that new orgs be vetted in m.d.s.p.

Do you think we should have a "public notification before issuance
(re-)begins" requirement even if e.g. existing CA B buys a root from
existing CA A?

> 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?

What different might we want? :-)

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 02/05/17 01:55, Peter Kurrasch wrote:
> 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

Clearly, we have rules for vetting (in particular, EV) which try and
avoid such things happening. It's not like we are indifferent. But
stolen CC numbers, for example, are a factor for which each CA has to
put in place whatever measures they feel appropriate, just as any
business does. It's not really our concern.

> - requesting and obtaining certs for the furtherance of fraudulent activity
> 
> Regarding 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.

It exists, in the same way that cars are used for bank robbery getaways,
but the Highway Code doesn't mention bank robberies.

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

[Gervase Markham via dev-security-policy]

On 01/05/17 18:53, Lee wrote:
> You seem to be replacing a "meets or exceeds" requirement with a
> "strictly meets" requirement.

That is not particularly the intention. I think that the Baseline nature
of the Baseline Requirements means that CAs know it's generally OK to go
above and beyond what it requires.

> 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.

Well, CAs are not audited to the Mozilla Policy, they are audited to the
BRs. :-)

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