Re: Policy 2.4 Proposal: Require full CP/CPS in English

[Matt Palmer]

In general, I'm in strong agreement with this change, for all the reasons
described.  One nit to pick with the proposed draft text:

On Tue, Jan 24, 2017 at 03:02:45PM +, Gervase Markham wrote:
> So the draft text might be something like:
> 
> "CAs must provide English versions of all Certificate Policy and
> Certification Practice Statement documents, with version numbers
> matching the document they are a translation of. The English version is
> not required to be authoritative in cases of dispute, but the CA must
> attest that the translation is not materially different to the original."

Is that referring to a dispute between Mozilla (or "a trust store operator",
if you prefer) and the CA, or between a relying party and the CA?  If the
former, I'm not keen on that.  I'd prefer the policy was kept simple when it
comes to assessing a CPS violation -- having to first argue whether or not
the translated CPS is "materially different" before anyone can actually get
to the real issue doesn't seem like a fun use of anyone's time.

- Matt

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

Re: Question about Baseline Requirements section #7.1.4.2

[Kurt Roeckx]

On Mon, Jan 23, 2017 at 04:01:58PM -0800, Peter Bowen wrote:
> On Mon, Jan 23, 2017 at 3:32 PM, Kathleen Wilson  wrote:
> > Does section 7.1.4.2 of the CA/Browser Forum's Baseline Requirements only 
> > apply to end-entity certificates?
> >
> > If yes, where does it specify that in the document?
> >
> > This has come up in a few CA requests, due to errors we get when we run 
> > Kurt's x509lint test.
> > Example:
> > https://github.com/kroeckx/x509lint/issues/17
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1099311#c17
> 
> Kathleen,
> 
> I believe that it does not apply to CA certificates, but I can see how
> this is not clear.
> 
> To help understand the intent of this section, it is helpful to look
> at the history of the section.  7.1.4.2 has not been substantially
> changed since BR 1.3.0, which was the version that switched from the
> old structure to the new RFC 3647 structure.  As seen in
> https://cabforum.org/wp-content/uploads/RFC3647_Comparison_Table_for_Baseline_Requirements.pdf,
> 7.1.4.2 was previously section 9.2 and 7.1.4.1 was previously section
> 9.1.
> 
> In 2015, the CA/Browser Forum passed ballot 148
> (https://cabforum.org/2015/04/02/ballot-148-issuer-field-correction/)
> which changed sections 9.1 and 9.2 and appears to clearly call out
> that the intent is to require different content in the subjects for CA
> certificates than end-entity certificates.

It seems that for all of 1.2.4, 1.2.5 and 1.4.2 it's really the
same text, just in different section numbers.

But looking at this again, the current 7.1.4.3 is about
Subordinate CA certificates, so it could make sense that 7.1.4.2
(that starts with etact the same text) is not about all
certificates.

But I see no good reason why some of the rules applied to EE
certificates shouldn't be applied to CA certificates.


Kurt

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

RE: Appropriate role for lists of algorithms and key sizes

[Jeremy Rowley]

Why not just make the changes at the CAB Forum? That's the purpose of the
CAB Forum afterall - to discuss these policies. Seems like it would be
better to add restrictions there first before creating a separate policy.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi
Sent: Tuesday, January 24, 2017 10:12 AM
To: Richard Barnes 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham

Subject: Re: Appropriate role for lists of algorithms and key sizes

I mostly agree with Richard's sentiments - that is, the BRs are likely to be
more liberal than what Mozilla may want - but not sure how 0/1 falls out
from that.

I think 2/3 are implemented the same, just different expressions of 'why' -
and I think both reasons are valid. That is, Mozilla may want to discourage
some keys because they're weak - OR because they cause interoperability
issues.

I'm not sure that it's a three-level hierarchy - that is, I don't think
you'd want to have a situation where Mozilla Policy != Firefox, if anything,
because of interoperability concerns.

This means, as a practical matter, I strongly agree with Brian Smith's
suggestion of having an explicit, enumerated list of algorithms (and
parameters) in the Mozilla policy, with the caveat/expectation that Mozilla
policy will be able to be updated in a timely fashion w/r/t this section if
need be.

On Tue, Jan 24, 2017 at 8:26 AM, Richard Barnes  wrote:

> My gut reaction is 0+1, maybe 2.
>
> - The CAB Forum should specify the overall envelope of what is 
> acceptable in the Web PKI
> - Firefox will enforce restrictions that are mores strict than the BRs 
> requirements
>
> If we do (2), then this will just be a three level hierarchy, with BRs 
> < Mozilla Policy < Firefox.
>
>
> On Tue, Jan 24, 2017 at 10:30 AM, Gervase Markham 
> wrote:
>
> > A discussion inspired by
> > https://github.com/mozilla/pkipolicy/issues/5
> >
> > Should Mozilla's root store policy contain any list of approved 
> > and/or disapproved algorithms/key sizes, or not? Possible positions 
> > include at
> > least:
> >
> > 0) No; what algorithms and/or key sizes are supported by Firefox 
> > and/or NSS is a decision for the hackers on those projects. There's 
> > no need for a separate policy about it.
> >
> > 1) No; the Baseline Requirements, section 6.1.5, specify a set of 
> > algorithms and key sizes:
> > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf .
> > If Mozilla's list is the same, there is no point; if it's different, 
> > you just end up with the intersection.
> >
> > 2) Yes; we should have a list of banned algorithms and/or key sizes 
> > which are weak and therefore dangerous for the web PKI, so we can 
> > use the power of the policy to force them out of the system. But if 
> > an algorithm or key size is not actively dangerous, anything else 
> > should be permitted.
> >
> > 3) Yes; there are advantages such as interoperability (what else?) 
> > to Mozilla using the power of the policy to define what algorithms 
> > and/or key sizes are acceptable in the Web PKI; as long as we keep 
> > the list under review, this is a good thing.
> >
> > Thoughts?
> >
> > 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: I found some SHA-1 certificates issued by Symantec

[Jeremy Rowley]

I disagree. If the CA has requested removal of the root and added it to
OneCRL, then I don't see how there is an obligation to continue operating
the root under the Mozilla policy.  If the browser doesn't update the root
store/revocation list to remove the root, then the browser is accepting the
CA as non-compliant.  If Mozilla wanted to have the root remain compliant
after the attempted removal, there'd have to be some sort of agreement with
the CA for a transition period. Afterall, a root store operator can always
add/remove a root to its program unilaterally, regardless of the root
certificate status.

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Richard Barnes
Sent: Tuesday, January 24, 2017 9:11 AM
To: Peter Bowen 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Rob Stradling
; Gervase Markham ;
w...@gmail.com
Subject: Re: I found some SHA-1 certificates issued by Symantec

On Tue, Jan 24, 2017 at 11:08 AM, Peter Bowen  wrote:

> On Tue, Jan 24, 2017 at 8:00 AM, Richard Barnes 
> wrote:
> > On Tue, Jan 24, 2017 at 10:48 AM, Gervase Markham 
> wrote:
> >>
> >> This helpful spreadsheet shows that they were removed in Firefox 47 
> >> and
> >> 51 respectively:
> >> https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateRe
> >> port Although Firefox 51 was only released yesterday, so that's a 
> >> bit concerning.
> >>
> >
> > Indeed, if they issued these before yesterday, this seems like a
problem.
>
> I'm a little surprised to read this.  This SHA-1 "private" hierarchy 
> is not new news and has been discussed in various forums over the year 
> or 18 months. At least one other CA operator has a similar hierarchy 
> that is chained back to a root formerly in the Mozilla trust store.
>
> I was under the impression Mozilla knew about this from the SHA-1 
> exceptions discussions, as one of the topics there has been "why can't 
> they use the SHA-1 certs from the pulled roots?"
>

If the root was removed in Firefox 51, and they were issuing SHA-1 off of it
before 51 shipped, then they were issuing SHA-1 certificates under a root
trusted by Firefox.

You can use SHA-1 under a pulled root, but it has to actually be pulled
first.

--Richard


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


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

Re: Misissued/Suspicious Symantec Certificates

[Andrew Ayer]

Hi Hanno,

On Tue, 24 Jan 2017 10:38:01 +0100
Hanno B__ck  wrote:

> Hello,
> 
> I have a few observations to share about this incident, not sure how
> relevant they are.

Thanks for sharing these.  I found them interesting.

> There are 4 "example.com" certificates related to this incident.
> 
> There are 114 "O=test" certificates that I assume are related to this
> incident. This includes all certificates with a "Not Before" date of
> 2016-10 and later. crt.sh finds various older certificates with O=test
> from various CAs, but I guess they are unrelated.

I count 101 distinct O=test certificates with a notBefore date of
2016-10 or later (of these, 2 also have DNS name for *test*.com; also,
there are 3 certs for *test*.com without O=Test).  Might you be
double-counting certs and their corresponding pre-certs?

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

Re: Appropriate role for lists of algorithms and key sizes

[Rob Stradling]

On 24/01/17 16:26, Richard Barnes wrote:

My gut reaction is 0+1, maybe 2.

- The CAB Forum should specify the overall envelope of what is acceptable
in the Web PKI
- Firefox will enforce restrictions that are mores strict than the BRs
requirements


The BRs say that SHA-1 has been unacceptable in the Web PKI since Jan 
1st 2017.  Firefox did not enforce that deadline, but instead set a 
later deadline.  I'd call that *less* strict than the BRs.  Wouldn't you?


EdDSA certificate signatures will be with us soon.  Is it conceivable 
that Mozilla might want to ship and enable EdDSA certificate signature 
code before the BRs have been updated to declare that EdDSA is 
acceptable in the Web PKI?  If so, then that would also be *less* strict 
than the BRs.



If we do (2), then this will just be a three level hierarchy, with BRs <
Mozilla Policy < Firefox.


On Tue, Jan 24, 2017 at 10:30 AM, Gervase Markham  wrote:


A discussion inspired by
https://github.com/mozilla/pkipolicy/issues/5

Should Mozilla's root store policy contain any list of approved and/or
disapproved algorithms/key sizes, or not? Possible positions include at
least:

0) No; what algorithms and/or key sizes are supported by Firefox and/or
NSS is a decision for the hackers on those projects. There's no need for
a separate policy about it.

1) No; the Baseline Requirements, section 6.1.5, specify a set of
algorithms and key sizes:
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf .
If Mozilla's list is the same, there is no point; if it's different, you
just end up with the intersection.

2) Yes; we should have a list of banned algorithms and/or key sizes
which are weak and therefore dangerous for the web PKI, so we can use
the power of the policy to force them out of the system. But if an
algorithm or key size is not actively dangerous, anything else should be
permitted.

3) Yes; there are advantages such as interoperability (what else?) to
Mozilla using the power of the policy to define what algorithms and/or
key sizes are acceptable in the Web PKI; as long as we keep the list
under review, this is a good thing.

Thoughts?

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



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

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

Re: I found some SHA-1 certificates issued by Symantec

[Rob Stradling]

On 24/01/17 16:19, Rob Stradling wrote:

On 24/01/17 16:11, Richard Barnes wrote:


If the root was removed in Firefox 51, and they were issuing SHA-1 off
of it before 51 shipped, then they were issuing SHA-1 certificates under
a root trusted by Firefox.

You can use SHA-1 under a pulled root, but it has to actually be pulled
first.


I think the "Class 3 Public Primary Certification Authority"
(https://crt.sh/?id=162) was already "pulled".

It may only have been removed completely in FF51, but it looks like it
had the Websites trust bit disabled some time ago:

https://bugzilla.mozilla.org/show_bug.cgi?id=936105


Yeah, https://crt.sh/?id=162 lost the Websites trust bit in NSS 3.16.3, 
the release of which was announced to m.d.s.crypto on 3rd July 2014.


https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.16.3_release_notes
"The Trust Bits were changed for the following CA certificates
...
OU = Class 3 Public Primary Certification Authority
SHA1 Fingerprint: 
74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2

Turned off websites and code signing trust bits (1024-bit root)"

--
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: I found some SHA-1 certificates issued by Symantec

[Gervase Markham]

On 24/01/17 16:08, Peter Bowen wrote:
>> Indeed, if they issued these before yesterday, this seems like a problem.
> 
> I'm a little surprised to read this.  This SHA-1 "private" hierarchy
> is not new news and has been discussed in various forums over the year
> or 18 months. At least one other CA operator has a similar hierarchy
> that is chained back to a root formerly in the Mozilla trust store.
> 
> I was under the impression Mozilla knew about this from the SHA-1
> exceptions discussions, as one of the topics there has been "why can't
> they use the SHA-1 certs from the pulled roots?"

We pulled a bunch of roots in December 2015, including some from
Symantec. This is the Firefox 42 - 44 timeframe (44 was January, but I
can accept perhaps we took some time to get the job done). So of the
Symantec roots, that would be:

VeriSign Class 4 Public Primary Certification Authority - G3
UTN-USERFirst-Network Applications

There's also, of course Thawte Server CA and Thawte Premium Server CA,
pulled in Firefox 36, and some TC TrustCenter roots as well. I had
assumed that when people talked about "pulled roots", they were talking
about roots which actually had been pulled. I did not expect to see a
SHA-1 hierarchy cross-signed by a root still trusted by Firefox until
yesterday.

Gerv

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

Re: I found some SHA-1 certificates issued by Symantec

[Rob Stradling]

On 24/01/17 16:11, Richard Barnes wrote:


If the root was removed in Firefox 51, and they were issuing SHA-1 off
of it before 51 shipped, then they were issuing SHA-1 certificates under
a root trusted by Firefox.

You can use SHA-1 under a pulled root, but it has to actually be pulled
first.


I think the "Class 3 Public Primary Certification Authority" 
(https://crt.sh/?id=162) was already "pulled".


It may only have been removed completely in FF51, but it looks like it 
had the Websites trust bit disabled some time ago:


https://bugzilla.mozilla.org/show_bug.cgi?id=936105

--
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: I found some SHA-1 certificates issued by Symantec

[Richard Barnes]

On Tue, Jan 24, 2017 at 11:08 AM, Peter Bowen  wrote:

> On Tue, Jan 24, 2017 at 8:00 AM, Richard Barnes 
> wrote:
> > On Tue, Jan 24, 2017 at 10:48 AM, Gervase Markham 
> wrote:
> >>
> >> This helpful spreadsheet shows that they were removed in Firefox 47 and
> >> 51 respectively:
> >> https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport
> >> Although Firefox 51 was only released yesterday, so that's a bit
> >> concerning.
> >>
> >
> > Indeed, if they issued these before yesterday, this seems like a problem.
>
> I'm a little surprised to read this.  This SHA-1 "private" hierarchy
> is not new news and has been discussed in various forums over the year
> or 18 months. At least one other CA operator has a similar hierarchy
> that is chained back to a root formerly in the Mozilla trust store.
>
> I was under the impression Mozilla knew about this from the SHA-1
> exceptions discussions, as one of the topics there has been "why can't
> they use the SHA-1 certs from the pulled roots?"
>

If the root was removed in Firefox 51, and they were issuing SHA-1 off of
it before 51 shipped, then they were issuing SHA-1 certificates under a
root trusted by Firefox.

You can use SHA-1 under a pulled root, but it has to actually be pulled
first.

--Richard


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

Re: Question about Baseline Requirements section #7.1.4.2

[Peter Bowen]

On Tue, Jan 24, 2017 at 8:05 AM, Gervase Markham  wrote:
> On 24/01/17 15:48, Peter Bowen wrote:
>> I think it would be completely reasonable for Mozilla to require a
>> commonName in an update to the policy.  I thought it was there, but a
>> CA pushed back on a cablint error about not having one a while ago and
>> I wasn't able to find any proof it was required by any existing
>> program policy.
>
> So, require commonName for all non-EE certificates?

Yes.  All certificates with basicConstraints:cA having a true value
must have a commonName type attribute in the subject (and only one
attribute of the type commonName, to preempt end another discussion).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: I found some SHA-1 certificates issued by Symantec

[Peter Bowen]

On Tue, Jan 24, 2017 at 8:00 AM, Richard Barnes  wrote:
> On Tue, Jan 24, 2017 at 10:48 AM, Gervase Markham  wrote:
>>
>> This helpful spreadsheet shows that they were removed in Firefox 47 and
>> 51 respectively:
>> https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport
>> Although Firefox 51 was only released yesterday, so that's a bit
>> concerning.
>>
>
> Indeed, if they issued these before yesterday, this seems like a problem.

I'm a little surprised to read this.  This SHA-1 "private" hierarchy
is not new news and has been discussed in various forums over the year
or 18 months. At least one other CA operator has a similar hierarchy
that is chained back to a root formerly in the Mozilla trust store.

I was under the impression Mozilla knew about this from the SHA-1
exceptions discussions, as one of the topics there has been "why can't
they use the SHA-1 certs from the pulled roots?"

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

Re: Question about Baseline Requirements section #7.1.4.2

[Gervase Markham]

On 24/01/17 15:48, Peter Bowen wrote:
> I think it would be completely reasonable for Mozilla to require a
> commonName in an update to the policy.  I thought it was there, but a
> CA pushed back on a cablint error about not having one a while ago and
> I wasn't able to find any proof it was required by any existing
> program policy.

So, require commonName for all non-EE certificates?

Gerv

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

Re: I found some SHA-1 certificates issued by Symantec

[Gervase Markham]

On 24/01/17 16:00, Richard Barnes wrote:
> Except of course the non-zero slice of users that haven't updated yet.

True, although I think it's unreasonable to give CAs a dependency on the
quality of our automatic update infrastructure. We can have a discussion
about whether "checked into master" or "shipped in Firefox" is the right
point to allow them to say a root is no longer trusted and act
accordingly, but pushing it out past the ship date seems unreasonable to
me. (Not sure we have a policy on this...)

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

Re: I found some SHA-1 certificates issued by Symantec

[Richard Barnes]

On Tue, Jan 24, 2017 at 10:48 AM, Gervase Markham  wrote:

> On 24/01/17 14:11, w...@gmail.com wrote:
> > I was searching on crt.sh and I found something confusing by accident.
> > View this page : https://crt.sh/?Identity=%25=7198
> > I can see many SHA-1 certificates issued in 2016 and one is issued in
> 2017.
>
> Your list is a list of certificates issued by "C=US, O=Symantec
> Corporation, CN=Symantec Private SSL SHA1 CA". If you view the page
> about that CA, you will see that it is not trusted by Mozilla:
> https://crt.sh/?caid=7198
>
> That's because it chains up to the following two roots:
>
> 1) OU=Class 3 Public Primary Certification Authority
> https://crt.sh/?caid=25
>
> 2) OU=Class 3 Public Primary Certification Authority - G2
> https://crt.sh/?caid=963
>
> This helpful spreadsheet shows that they were removed in Firefox 47 and
> 51 respectively:
> https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport
> Although Firefox 51 was only released yesterday, so that's a bit
> concerning.
>

Indeed, if they issued these before yesterday, this seems like a problem.



>
> Rob: is the "Trusted by Mozilla" stuff based on the root store on
> Mozilla's master branch?
>
> Symantec representatives: was this "Private" SHA-1-issuing CA supposed
> to chain up to roots trusted by Mozilla until very recently?
>
> > I think it was banned before so someone could tell me why they can issue
> these SHA-1 certificates?
> > SHA-1 certificate issued in 2017 : https://crt.sh/?id=71625342
>
> What makes you think that certificate was issued in 2017?
>
> Validity
> Not Before: Jul  7 00:00:00 2016 GMT
> Not After : Dec 31 23:59:59 2017 GMT
>
> However, I do see this one issued in 2017:
> https://crt.sh/?id=7847
>
> Symantec reps? Is the idea that this is OK because no browser trusts
> this part of your PKI any more?
>

Except of course the non-zero slice of users that haven't updated yet.

--Richard


>
> 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: I found some SHA-1 certificates issued by Symantec

[Rob Stradling]

On 24/01/17 15:48, Gervase Markham wrote:


Rob: is the "Trusted by Mozilla" stuff based on the root store on
Mozilla's master branch?


Hi Gerv.  Yes, I aim to keep crt.sh's view of "Trusted by Mozilla" in 
sync with mozilla-central [1].  [1] was last updated a few days ago, and 
I pushed the changes to crt.sh yesterday.



[1] 
https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt


--
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: I found some SHA-1 certificates issued by Symantec

[Gervase Markham]

On 24/01/17 14:11, w...@gmail.com wrote:
> I was searching on crt.sh and I found something confusing by accident.
> View this page : https://crt.sh/?Identity=%25=7198 
> I can see many SHA-1 certificates issued in 2016 and one is issued in 2017.

Your list is a list of certificates issued by "C=US, O=Symantec
Corporation, CN=Symantec Private SSL SHA1 CA". If you view the page
about that CA, you will see that it is not trusted by Mozilla:
https://crt.sh/?caid=7198

That's because it chains up to the following two roots:

1) OU=Class 3 Public Primary Certification Authority
https://crt.sh/?caid=25

2) OU=Class 3 Public Primary Certification Authority - G2
https://crt.sh/?caid=963

This helpful spreadsheet shows that they were removed in Firefox 47 and
51 respectively:
https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport
Although Firefox 51 was only released yesterday, so that's a bit concerning.

Rob: is the "Trusted by Mozilla" stuff based on the root store on
Mozilla's master branch?

Symantec representatives: was this "Private" SHA-1-issuing CA supposed
to chain up to roots trusted by Mozilla until very recently?

> I think it was banned before so someone could tell me why they can issue 
> these SHA-1 certificates?
> SHA-1 certificate issued in 2017 : https://crt.sh/?id=71625342

What makes you think that certificate was issued in 2017?

Validity
Not Before: Jul  7 00:00:00 2016 GMT
Not After : Dec 31 23:59:59 2017 GMT

However, I do see this one issued in 2017:
https://crt.sh/?id=7847

Symantec reps? Is the idea that this is OK because no browser trusts
this part of your PKI any more?

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

Re: Question about Baseline Requirements section #7.1.4.2

[Peter Bowen]

On Tue, Jan 24, 2017 at 12:28 AM, Inigo Barreira  wrote:
> Yes, I´m also agree. This was also taken into account when writting the ETSI
> standards, and for the CA certs, the minumun is what Peter has indicated
> plus the common name. We indicate that "... shall contain at least the
> following attributes ": countryName, organizationName and commonName
> according to ITU-T X.520

I think it would be completely reasonable for Mozilla to require a
commonName in an update to the policy.  I thought it was there, but a
CA pushed back on a cablint error about not having one a while ago and
I wasn't able to find any proof it was required by any existing
program policy.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

I found some SHA-1 certificates issued by Symantec

[wwwww818]

I was searching on crt.sh and I found something confusing by accident.
View this page : https://crt.sh/?Identity=%25=7198 
I can see many SHA-1 certificates issued in 2016 and one is issued in 2017.
I think it was banned before so someone could tell me why they can issue these 
SHA-1 certificates?
SHA-1 certificate issued in 2017 : https://crt.sh/?id=71625342
Hopefully
Liu
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: I found some SHA-1 certificates issued by Symantec

[Rob Stradling]

On 24/01/17 14:11, w...@gmail.com wrote:

I was searching on crt.sh and I found something confusing by accident.
View this page : https://crt.sh/?Identity=%25=7198
I can see many SHA-1 certificates issued in 2016 and one is issued in 2017.
I think it was banned before so someone could tell me why they can issue these 
SHA-1 certificates?
SHA-1 certificate issued in 2017 : https://crt.sh/?id=71625342


Hi Liu.

The "Symantec Private SSL SHA1 CA" intermediate CA chains only to roots 
that are no longer trusted by Mozilla.  (However, those roots are still 
trusted by Microsoft, Apple and (for EV) Chrome).


See the "Trust" matrix on https://crt.sh/?caid=7198

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

Appropriate role for lists of algorithms and key sizes

[Gervase Markham]

A discussion inspired by
https://github.com/mozilla/pkipolicy/issues/5

Should Mozilla's root store policy contain any list of approved and/or
disapproved algorithms/key sizes, or not? Possible positions include at
least:

0) No; what algorithms and/or key sizes are supported by Firefox and/or
NSS is a decision for the hackers on those projects. There's no need for
a separate policy about it.

1) No; the Baseline Requirements, section 6.1.5, specify a set of
algorithms and key sizes:
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf .
If Mozilla's list is the same, there is no point; if it's different, you
just end up with the intersection.

2) Yes; we should have a list of banned algorithms and/or key sizes
which are weak and therefore dangerous for the web PKI, so we can use
the power of the policy to force them out of the system. But if an
algorithm or key size is not actively dangerous, anything else should be
permitted.

3) Yes; there are advantages such as interoperability (what else?) to
Mozilla using the power of the policy to define what algorithms and/or
key sizes are acceptable in the Web PKI; as long as we keep the list
under review, this is a good thing.

Thoughts?

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

Policy 2.4 Proposal: Require full CP/CPS in English

[Gervase Markham]

The proposal is to require that all CP and CPS documents be provided in
English, in addition to whatever original language they were written in.
The reason for this is that the working language of the Mozilla root
program is English, and Mozilla's root program staff cannot be expected
to read the operating language of every CA. In addition, English is the
lingua franca of the internet and making sure the documents are in
English gives many more relying parties an opportunity to evaluate the
practices of a CA.

The Github issue suggests including this in the main root store policy;
however, perhaps it makes more sense to make it a requirement in the
Mozilla CCADB policy, because the CCADB policy deals with the provision
of audit documents.

A similar proposal was previously discussed in m.d.s.policy and achieved
a reasonable amount of support, although questions remain outstanding
about how authoritative we should require the English version to be.
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/zCrSaJSHEwQ/_w0hOujsBwAJ

There is also an open question about whether we require full
translations to be provided only on inclusion, or whether we require
them to be provided on an ongoing basis. I am in favour of the latter,
for reasons outlined in the Github issue.

So the draft text might be something like:

"CAs must provide English versions of all Certificate Policy and
Certification Practice Statement documents, with version numbers
matching the document they are a translation of. The English version is
not required to be authoritative in cases of dispute, but the CA must
attest that the translation is not materially different to the original."

We might need to update the CCADB to have fields for URLs for both the
original language version and the English language version of each document.

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

---

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

Policy 2.3 (current version):
https://github.com/mozilla/pkipolicy/blob/2.3/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.4 Proposal: Codify requirements relating to Common CA Database into the policy

[Gervase Markham]

Mozilla has started using the Common CA Database to track root
certificates in its root program, and the intermediate certificates
which chain up to those roots. This has led to substantial changes to
the practical processes that CAs must follow. In addition, it is hoped
and anticipated that other root stores will take advantage of the CCADB.

It is proposed that we dealing with this from a policy perspective by
doing the following:

1) drafting a "Common CCADB Policy", which explains what CAs who are
required by their root stores to use the CCADB must do. (This is as
distinct from how they do it, which would be in some
separately-maintained manual on how to use the system.) Although no
other root store has yet signed on to this document, the idea would be
that it would be agreed and shared across all root stores using the
CCADB, so that CAs would not need to deal with multiple
differently-worded sets of requirements on what they were required to do
in the system.

2) In addition, each root store would have a store-specific CCADB
Policy, which would detail the store-specific requirements on CAs using
the CCADB. Examples might include giving store contact information, or
defining special processes to follow for a security incident in addition
to those in the main CCADB policy.

3) The CCADB policy would be incorporated by reference into the main
root store policy, using wording something like this:

> RootStoreName uses the Common CA Database (CCADB). CAs in the
> program are required to use the CCADB, and are bound by the Common
> CCADB Policy v.X.X and the RootStoreName CCADB Policy
> v.Y.Y, which are incorporated here by reference.

4) The Mozilla root store policy also needs updating to remove any
content which is duplicated in the CCADB policies. We must also remove
out-of-date processes and procedures (e.g. Bugzilla-based ones) for
making updates, and replace those with references to the CCADB. (Note,
however, that the process for initial inclusion is still Bugzilla-based.)

5) We will need to update the CCADB-related pages on the Mozilla wiki to
disentangle and remove policy bits from the operational bits, and turn
it solely into a manual for how to use the system. (This has not yet
been attempted.)

There is a branch in the Github repo which adds a draft of the Common
CCADB Policy (again note that, despite the name, only Mozilla has signed
up to this document for now), the Mozilla CCADB Policy, and makes the
necessary changes to the main root store policy. You can find all of
that here:

https://github.com/mozilla/pkipolicy/compare/issue-9

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

---

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

Policy 2.3 (current version):
https://github.com/mozilla/pkipolicy/blob/2.3/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: Certificate validation phishing

[Gervase Markham]

On 24/01/17 09:08, Nick Lamb wrote:
> That's absolutely key to understanding why this trick works. Such an
> understanding is completely absent from the patent, because the
> patent isn't describing what the Baseline Requirements call a Request
> Token but only a Random Value which it calls the "Pass String".

No-one has actually come forward and said this to me, but I suspect that
doing patent analysis in this group will lead some members to be wary of
reading messages or participating, because of various effects that might
have on their "knowledge" of patents, which is relevant in patent law in
some jurisdictions.

While I would like this group to be a central meeting point for WebPKI
issues in general, can we please avoid patent analysis, at least without
saying first that you'd like to do some and explaining why it's
important for it to be done in this particular venue?

Thanks :-)

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

Re: Incident Report – Certificates issued without proper domain validation

[kanepyork]

On Thursday, January 19, 2017 at 6:05:22 PM UTC-8, Jakob Bohm wrote:
> On 20/01/2017 00:35, Nick Lamb wrote:
> > On Thursday, 19 January 2017 20:20:24 UTC, Jakob Bohm  wrote:
> >> Google's CT initiative in its current form has serious privacy problems
> >> for genuine certificate holders.  I applaud any well-run CA that stands
> >> up to this attack on the Internet at large.
> >
> > I notice that you have not specifically identified which Certificate 
> > Authorities you believe are "well-run", perhaps your argument would have 
> > more force if you could name some market leaders in that category.
> >
> 
> Presumably most that haven't been distrusted by Mozilla or otherwise
> publicly shamed for massive misissuance.
You presume a lot, I fear. "No disasters yet" is not proof of disaster 
prevention.

Apologies for the late reply and this diversion from the thread, but I felt I 
should respond to some of this.

> > As a Relying Party for the Web PKI I think Google's initiative makes a 
> > sensible trade off, you can't have privacy while also delivering oversight. 
> > The public CAs are clearly in need of oversight. This did not happen in a 
> > vacuum but as a consequence of trusted Certificate Authorities exhibiting 
> > incompetence and greed over many years.
> >
> 
> As both a relying party and a certificate holder, I see no reason for
> public listing of most of the details in the CT logs, and I do take
> specific measures to not get public certificates for a number of things
> (such as my e-mail addresses) that I don't want listed in Google
> searches or attacked by spammers.
> 
> So far, I have not seen any good uses for CT logging stuff such as:
> 
> - (list cut)

I don't really see the point of putting a Citizen ID number in a website 
certificate, either. If you don't put it in the certificate, it doesn't need to 
be logged.

Remember that CT as specified is only for WebPKI website validation 
certificates, not S/MIME certificates (though I suspect you could submit them).

> What is really needed for most non-malicious CT uses are the relevant
> 2nd/3rd level domain (1 level below public suffix), country, state and
> organization names (or CN if not an internet name and no O name part),
> slow one way hash of full name entries (e.g.
> SHA-512**65536("someu...@gmail.com"),
> full issuer details, cryptographic algorithm and strength, plus serial
> number and technical details such as EKUs and other non-special cased
> items.

This has enormous complexity requirements above "log the full certificate". 
History shows us this would result in even less adoption than we have right now.

> For example, to check if someone issued a fraudulent certificate for
> any domain or address under google.com, Google Inc could check the list
> of redacted CT entries for *@*.google.com, then compare it against an
> in-house non-public database of such certificates authorized by their
> internal management procedures.
>
> To check for certificates issued to non-existent / suspect domains such
> as example.com and/or test[1-9].com (recent Symantec related post in
> this group), this would still be fully visible too.  So would SHA-1
> certificates issued in 2016, duplicate serial numbers, etc.  Someone
> getting a misissued wildcard cert for a semi-public suffix such as
> "sf.net" or "blogblog.com" would also show up.

Disregarding the issue of S/MIME certificates, what do you propose for Honest 
Achmed's Car Dealership, whom do not need nor have rigorous management 
procedures for SSL certificates? (Replying to the first 3 items in your list 
here.)

Hypothetical: A monitoring service says "We saw a certificate logged for 
.honestachmedcars.com. It came from [CA name], SHA256, serial number 
xx."

  Achmed asks around the office and nobody's quite sure why this certificate 
was created. It would help a lot if the monitor delivered the full list of 
subject names for the certificate, because if it did they would've seen it was 
issued for mail.honestachmedcars.com, which would point them to questioning 
their managed e-mail provider (who just did a scheduled renewal of all customer 
certificates).

> 
> For a service such as gmail.com, the information suggested above would
> allow someone knowing a specific e-mail address such as
> "someu...@gmail.com" to check if a certificate was misissued for that
> address, but would not provide an easy way for a third party (such as a
> spammer) to extract a list of all @gmail.com user names that happen to
> have S/MIME certificates (Of cause Google has the original list of
> their users already, but no one else should).
Again, disregarding this because CT was never meant for e-mail certificates.

~Kane York
Speaking as an individual.

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

Re: Misissued/Suspicious Symantec Certificates

[Hanno Böck]

Hello,

I have a few observations to share about this incident, not sure how
relevant they are.

There are 4 "example.com" certificates related to this incident.

There are 114 "O=test" certificates that I assume are related to this
incident. This includes all certificates with a "Not Before" date of
2016-10 and later. crt.sh finds various older certificates with O=test
from various CAs, but I guess they are unrelated.

Issuers
===

The affected certificates were issued by three different intermediates
owned by Symantec:
Symantec Class 3 Secure Server CA - G4
thawte SSL CA - 
GeoTrust SSL CA - G3

Now Symantec told us these certificates were issued by one of their
WebTrust partners. This got me curious if it's usual that Symantec
gives their partners access to their systems in a way that they can use
various different intermediates related to different brand names.

This document here
https://cert.webtrust.org/SealFile?seal=2168=pdf
indicates that Korea Electronic Certification Authority Inc.
("CrossCert"), which is probably the partner Symantec is talking about,
is allowed to issue certificates with these intermediates
VeriSign Class 3 Secure Server CA - G3
VeriSign Class 3 International Server CA - G3
Symantec Class 3 Secure Server CA - G4
Which - as can be obviously seen - don't match.

(nitpick: It seems the PDF doc has a bogus document title which looks
like some changelog entry)


Revocations
===

The 4 example certs were already revoked when Andrew Ayer made this
incident public.
From the 114 "O=test" certificates 62 were revoked at some point in
2016, so before the incident became public. 52 were revoked at some
point in 2017. 37 of those were revoked on 2017-01-20, so directly
afterthe incident got public.
(I've counted this because in a statement sent to the media Symantec
said that when they learned about this incident "most" certificates
were already revoked. I feel I have a different definition of the word
"most".)


Other O=test certificates
=

A quick run through other "O=test" certs:
* "Cybertrust Japan Co.. Ltd." seems to have issued a large number of
  them, but a few checks indicate they are issued to domains they own.
  Not sure if that's still considered a problem, as "O=test" is
  obviously a bogus org, but at least they seem to not issue certs for
  other people's domains.
* There's one cert issued by "SHECA" which is itself an intermediate
  signed by "UniTrust". It's issued for a public IP. UniTrust seems to
  be accepted by Apple+Microsoft, but not by Mozilla+Chrome.
  https://crt.sh/?id=32335050




-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate validation phishing

[Nick Lamb]

On Tuesday, 24 January 2017 04:40:12 UTC, Jeremy Rowley  wrote:
> And why wouldn't a request token fit the patent's interpretation of a "Pass
> String"? The only definition I saw in the patent was something generated by
> the validating entity and forwarded to the requester.

The digest of the key authorization, which I identified as the Request Token in 
the Baseline Requirements terminology is _not_ generated by the validating 
entity. They couldn't if they wanted to. Do you see why?

Even if you squint very hard indeed this digest isn't "the Pass String", but it 
is a Request Token because it binds this demonstration of control to this 
request, something a "Pass String" can't do.

That's absolutely key to understanding why this trick works. Such an 
understanding is completely absent from the patent, because the patent isn't 
describing what the Baseline Requirements call a Request Token but only a 
Random Value which it calls the "Pass String".

Whether a lawyer can be paid to pretend otherwise in a Western District of 
Texas specialist patent court remains to be seen. But meanwhile the plain truth 
is discernible to us non-lawyers.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Question about Baseline Requirements section #7.1.4.2

[Inigo Barreira]

Yes, I´m also agree. This was also taken into account when writting the ETSI
standards, and for the CA certs, the minumun is what Peter has indicated
plus the common name. We indicate that "... shall contain at least the
following attributes ": countryName, organizationName and commonName
according to ITU-T X.520

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Peter Bowen
Sent: martes, 24 de enero de 2017 1:02
To: Kathleen Wilson 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Question about Baseline Requirements section #7.1.4.2

On Mon, Jan 23, 2017 at 3:32 PM, Kathleen Wilson 
wrote:
> Does section 7.1.4.2 of the CA/Browser Forum's Baseline Requirements only
apply to end-entity certificates?
>
> If yes, where does it specify that in the document?
>
> This has come up in a few CA requests, due to errors we get when we run
Kurt's x509lint test.
> Example:
> https://github.com/kroeckx/x509lint/issues/17
> https://bugzilla.mozilla.org/show_bug.cgi?id=1099311#c17

Kathleen,

I believe that it does not apply to CA certificates, but I can see how this
is not clear.

To help understand the intent of this section, it is helpful to look at the
history of the section.  7.1.4.2 has not been substantially changed since BR
1.3.0, which was the version that switched from the old structure to the new
RFC 3647 structure.  As seen in
https://cabforum.org/wp-content/uploads/RFC3647_Comparison_Table_for_Baselin
e_Requirements.pdf,
7.1.4.2 was previously section 9.2 and 7.1.4.1 was previously section 9.1.

In 2015, the CA/Browser Forum passed ballot 148
(https://cabforum.org/2015/04/02/ballot-148-issuer-field-correction/)
which changed sections 9.1 and 9.2 and appears to clearly call out that the
intent is to require different content in the subjects for CA certificates
than end-entity certificates.

I agree that the BRs could be clearer, but it seems to me that the only
requirements are country and organization name.

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


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