Re: Certificates with invalidly long serial numbers

[Matt Palmer via dev-security-policy]

On Wed, Aug 09, 2017 at 04:21:19PM +0200, Jakob Bohm via dev-security-policy 
wrote:
> On 08/08/2017 20:46, Alex Gaynor wrote:
> > It's from the BRs 4.9.1.1:
> > 
> >   The CA SHALL revoke a Certificate within 24 hours if one or more of
> > the following occurs:
> > 
> > It's also not a penalty on the CA, it's a remediation step for them to
> > undertake.
> > 
> 
> It is a disruption and penalty to the 3rd party certificate holder to
> have their certificate suddenly revoked due to a bureaucratic mistake at
> the CA.

If a certificate holder feels that they have been materially damaged as a
result of their CA's negligence, they should take that up with the CA.

- Matt

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

Re: Misissued certificates

[J.C. Jones via dev-security-policy]

Lee,

Different parts of Mozilla does monitor CT, both for internal IT
purposes, as well as research into the WebPKI. It seems like crt.sh does
a great job already of handling cablint/x509lint of newly-observed certs.

What are you looking for Mozilla to provide here that isn't already
being accomplished by the community (e.g., crt.sh, censys.io, and others)?

Thanks,
J.C.

On 8/9/17 9:23 PM, Lee via dev-security-policy wrote:
> What's it going to take for mozilla to set up near real-time
> monitoring/auditing of certs showing up in ct logs?
>
> Lee
>
> On 8/9/17, Alex Gaynor via dev-security-policy
>  wrote:
>> (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
>> was to IdenTrust)
>>
>> Hi,
>>
>> The following certificates appear to be misissued:
>>
>> https://crt.sh/?id=77893170=cablint
>> https://crt.sh/?id=77947625=cablint
>> https://crt.sh/?id=78102129=cablint
>> https://crt.sh/?id=92235995=cablint
>> https://crt.sh/?id=92235998=cablint
>>
>> All of these certificates have a pathLenConstraint value with CA:FALSE,
>> this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
>> pathLenConstraint field unless the cA boolean is asserted and the key usage
>> extension asserts the keyCertSign bit.
>>
>> Alex
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right to
>> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>>
>>
>>
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right to
>> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>> ___
>> 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

Re: Misissued certificates

[Lee via dev-security-policy]

What's it going to take for mozilla to set up near real-time
monitoring/auditing of certs showing up in ct logs?

Lee

On 8/9/17, Alex Gaynor via dev-security-policy
 wrote:
> (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
> was to IdenTrust)
>
> Hi,
>
> The following certificates appear to be misissued:
>
> https://crt.sh/?id=77893170=cablint
> https://crt.sh/?id=77947625=cablint
> https://crt.sh/?id=78102129=cablint
> https://crt.sh/?id=92235995=cablint
> https://crt.sh/?id=92235998=cablint
>
> All of these certificates have a pathLenConstraint value with CA:FALSE,
> this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> pathLenConstraint field unless the cA boolean is asserted and the key usage
> extension asserts the keyCertSign bit.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> ___
> 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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Lee via dev-security-policy]

On 8/9/17, Eric Mill  wrote:
> On Wed, Aug 9, 2017 at 4:28 PM, Lee  wrote:
>
>> On 8/9/17, Eric Mill via dev-security-policy
>>  wrote:
>> > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> >> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg
>> wrote:
>> >> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <
>> >> dev-security-policy@lists.mozilla.org> wrote:
>> >> > >
>> >> > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg
>> >> wrote:
>> >> > >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP
>> >> responder URL that has a HTTPS URI scheme. This is not valid, the OCSP
>> >> responder URI is required to have the plaintext HTTP scheme according
>> >> to
>> >> Baseline Requirements section 7.1.2.2(c).
>> >> > >>
>> >> > >> Here’s the list of certificates: https://misissued.com/batch/4/
>> >> > >>
>> >> > >> Jonathan
>> >> > >
>> >> > > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS
>> in
>> >> this
>> >> > > context.  That being said, we have altered our profiles for
>> >> certificates
>> >> > > issued under this Sub CA to include only HTTP OCSP URLs.  All
>> >> certificates
>> >> > > issued going forward will contain an HTTP OCSP URL.  We will also
>> >> examine all
>> >> > > other sub CA to ensure only HTTP OCSP URLs are included.  Thank
>> >> > > you
>> >> for giving
>> >> > > us an opportunity to address this with the community
>> >> >
>> >> > Thanks for the update.
>> >> >
>> >> > Can you also clarify why the subject organizationName is "U.S.
>> >> Government” for all of these certificates, despite the other subject
>> >> fields
>> >> indicating organizations that are not a component of the US
>> >> Government?
>> >> >
>> >> > Jonathan
>> >>
>> >> Yes,
>> >> IdenTrust ACES SSL Certificates are issued in accordance with the ACES
>> >> certificate policy defined by U.S. General Service Administration (
>> >> http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/docum
>> >> ents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust
>> CPS
>> >> (https://secure.identrust.com/certificates/policy/aces/IdenT
>> >> rust_ACES_CPS_v5.1_20161110.pdf)
>> >> These ACES SSL certificates are issued to either U.S. Government
>> agencies
>> >> and/or their sub-contractors in support of government
>> >> programs\projects.
>> >> The
>> >> CP requires an approved CA, such as IdenTrust, to identify U.S.
>> Government
>> >> in
>> >> subject organizationName along with other applicable organizations
>> >> (e.g.
>> >> sub-contractors, or local government agency, etc...).
>> >>
>> >
>> > If that's the case, I would expect each certificate to be
>> > authenticating
>> > hostnames that are used solely to provide such services to the U.S.
>> > Government. That doesn't appear to be the case with these.
>> >
>> > For example, one of them is for the homepage for a service provider:
>> > www.mudiaminc.com
>>
>> What am I doing wrong?  goto https://www.mudiaminc.com/
>> check the cert and it says
>> Issued To
>> Common Name (CN)*.opentransfer.com
>> Organization (O)ECOMMERCE, INC.
>>
>
> You're not doing anything wrong, that hostname is just not using that
> certificate at this time, at least not to public users. But issuance is
> what matters here.
>
> Given the capitalization of the common name, and the
> organizationalUnitName, the certificate was clearly issued to the same
> company.
>
>
>> And one of them is for what appears to be a state government revenue
>> > service's VPN: vpn.revenue.louisiana.gov
>>
>> I see that one - goto https://vpn.revenue.louisiana.gov/
>> check the cert and it says
>> Issued To
>> Common Name (CN)Vpn.revenue.louisiana.gov
>> Organization (O)U.S. Government
>>
>> > (So it's clear, "U.S. Government" only refers to the federal
>> > government,
>> > not state/local/tribal governments.)
>> >
>> > I personally (and to be clear, this is in my individual capacity and I
>> > am
>> > not representing my employer) think these are invalid
>> > organizationNames,
>> > constitute misissuance, and that Identrust should be using the "U.S.
>> > Government" only for hostnames providing services operated exclusively
>> > on
>> > behalf of the federal government.
>>
>> playing devils' advocate: how do you know that
>> https://vpn.revenue.louisiana.gov/ wasn't set up in collaboration with
>> the IRS or some other branch of the U.S. Government?
>>
>
> That wouldn't meet the definition that Identrust said in their email above,
> which is that certificates are "issued to either U.S. Government agencies

if it was a cooperative project, it seems possible/reasonable that the
USG ordered the certs.

> and/or their sub-contractors in support of government programs\projects".
> Maybe there's some very novel arrangement I'm not familiar with where the
> State 

Fwd: Misissued certificates - pathLenConstraint with CA:FALSE

[Alex Gaynor via dev-security-policy]

(Whoops, accidentally originally CC'd to m.d.s originally! Original mail
was to IdenTrust)

Hi,

The following certificates appear to be misissued:

https://crt.sh/?id=77893170=cablint
https://crt.sh/?id=77947625=cablint
https://crt.sh/?id=78102129=cablint
https://crt.sh/?id=92235995=cablint
https://crt.sh/?id=92235998=cablint

All of these certificates have a pathLenConstraint value with CA:FALSE,
this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
pathLenConstraint field unless the cA boolean is asserted and the key usage
extension asserts the keyCertSign bit.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6




-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Eric Mill via dev-security-policy]

On Wed, Aug 9, 2017 at 4:28 PM, Lee  wrote:

> On 8/9/17, Eric Mill via dev-security-policy
>  wrote:
> > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg
> wrote:
> >> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >> > >
> >> > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg
> >> wrote:
> >> > >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP
> >> responder URL that has a HTTPS URI scheme. This is not valid, the OCSP
> >> responder URI is required to have the plaintext HTTP scheme according to
> >> Baseline Requirements section 7.1.2.2(c).
> >> > >>
> >> > >> Here’s the list of certificates: https://misissued.com/batch/4/
> >> > >>
> >> > >> Jonathan
> >> > >
> >> > > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS
> in
> >> this
> >> > > context.  That being said, we have altered our profiles for
> >> certificates
> >> > > issued under this Sub CA to include only HTTP OCSP URLs.  All
> >> certificates
> >> > > issued going forward will contain an HTTP OCSP URL.  We will also
> >> examine all
> >> > > other sub CA to ensure only HTTP OCSP URLs are included.  Thank you
> >> for giving
> >> > > us an opportunity to address this with the community
> >> >
> >> > Thanks for the update.
> >> >
> >> > Can you also clarify why the subject organizationName is "U.S.
> >> Government” for all of these certificates, despite the other subject
> >> fields
> >> indicating organizations that are not a component of the US Government?
> >> >
> >> > Jonathan
> >>
> >> Yes,
> >> IdenTrust ACES SSL Certificates are issued in accordance with the ACES
> >> certificate policy defined by U.S. General Service Administration (
> >> http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/docum
> >> ents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust
> CPS
> >> (https://secure.identrust.com/certificates/policy/aces/IdenT
> >> rust_ACES_CPS_v5.1_20161110.pdf)
> >> These ACES SSL certificates are issued to either U.S. Government
> agencies
> >> and/or their sub-contractors in support of government programs\projects.
> >> The
> >> CP requires an approved CA, such as IdenTrust, to identify U.S.
> Government
> >> in
> >> subject organizationName along with other applicable organizations (e.g.
> >> sub-contractors, or local government agency, etc...).
> >>
> >
> > If that's the case, I would expect each certificate to be authenticating
> > hostnames that are used solely to provide such services to the U.S.
> > Government. That doesn't appear to be the case with these.
> >
> > For example, one of them is for the homepage for a service provider:
> > www.mudiaminc.com
>
> What am I doing wrong?  goto https://www.mudiaminc.com/
> check the cert and it says
> Issued To
> Common Name (CN)*.opentransfer.com
> Organization (O)ECOMMERCE, INC.
>

You're not doing anything wrong, that hostname is just not using that
certificate at this time, at least not to public users. But issuance is
what matters here.

Given the capitalization of the common name, and the
organizationalUnitName, the certificate was clearly issued to the same
company.


> And one of them is for what appears to be a state government revenue
> > service's VPN: vpn.revenue.louisiana.gov
>
> I see that one - goto https://vpn.revenue.louisiana.gov/
> check the cert and it says
> Issued To
> Common Name (CN)Vpn.revenue.louisiana.gov
> Organization (O)U.S. Government
>
> > (So it's clear, "U.S. Government" only refers to the federal government,
> > not state/local/tribal governments.)
> >
> > I personally (and to be clear, this is in my individual capacity and I am
> > not representing my employer) think these are invalid organizationNames,
> > constitute misissuance, and that Identrust should be using the "U.S.
> > Government" only for hostnames providing services operated exclusively on
> > behalf of the federal government.
>
> playing devils' advocate: how do you know that
> https://vpn.revenue.louisiana.gov/ wasn't set up in collaboration with
> the IRS or some other branch of the U.S. Government?
>

That wouldn't meet the definition that Identrust said in their email above,
which is that certificates are "issued to either U.S. Government agencies
and/or their sub-contractors in support of government programs\projects".
Maybe there's some very novel arrangement I'm not familiar with where the
State of Louisiana can act as a subcontractor to the federal government,
but in both of these cases, the burden is on Identrust to identify how it
could have been appropriate to put "U.S. Government" as the
organizationName for these certificates.

For the other 3 in the batch, there are more plausible reasons why the
hostname might 

RE: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

No objection to 72 hours v. 1 business day.  I agree it should be short and
72 hours seems perfectly reasonable . 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Paul Kehrer via dev-security-policy
Sent: Wednesday, August 9, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
> All CAS are required to maintain the capability to process and receive
revocation requests 24x7 under the baseline requirements. The headache is
not with the CA. Rather, it's notifying the customer that their certificate
will be revoked before the start of the next business day. Having a one to
two business day rule  instead of 24 hours for non compromise issues gives
the end entity time to receive the notification and replace their
certificate with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it
does sound like a good solution. However, I think it's another example of
the general difference of opinion between people on this list around whether
we should be holding CAs to the highest standards or not. These mis-issued
certificates are typically not a security concern, but they speak to either
ignorance on the part of CA operators or a pattern of lackadaisical controls
within the issuance systems. Neither of these is acceptable behavior at this
juncture. Conformance with the BRs has been mandatory for over 5 years now.
Customers need to be made aware of the failures of their chosen providers
and the responsibilities incumbent upon them as subscribers, and if their
own certificate installation/replacement processes are sufficiently archaic
as to make it difficult to replace a certificate in an automated fashion
then they should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business days"
really mean?Does the CA get 1-2 business days followed by 1-2 for the
customer? What if there's a holiday in the CA's country of operations
followed by a holiday in the customer's home country? How quickly does this
window extend to 2+ weeks? If you were to go down this path I'd strongly
prefer it to be a hard deadline (e.g. 72 hours) and not anything related to
business days.

-Paul
___
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: Certificates with metadata-only subject fields

[Jonathan Rudenberg via dev-security-policy]

> On Aug 9, 2017, at 18:34, David E. Ross via dev-security-policy 
>  wrote:
> 
> On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>> 
>>> On Aug 9, 2017, at 17:50, Peter Bowen  wrote:
>>> 
>>> The point of certlint was to help identify issues.  While I appreciate
>>> it getting broad usage, I don't think pushing for revocation of every
>>> certificate that trips any of the Error level checks is productive.
>> 
>> I agree, and I don’t really have a position on the revocation of 
>> certificates with errors that do not appear to have any security impact like 
>> these.
>> 
>> Jonathan
>> 
>> 
> 
> I strongly disagree.  Errors like this make me question whether the
> certification authority is sufficiently competent to be trusted.  Small
> errors can indicate an increased likelihood of serious errors.

I’m not saying the errors are okay. They aren’t. All I’m saying is that for 
this batch I’m not requesting revocation directly from CAs using their problem 
reporting contact details, as I’ve done with other more serious issues.

Jonathan

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

Re: Certificates with invalidly long serial numbers

[Paul Kehrer via dev-security-policy]

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
> All CAS are required to maintain the capability to process and receive 
> revocation requests 24x7 under the baseline requirements. The headache is not 
> with the CA. Rather, it's notifying the customer that their certificate will 
> be revoked before the start of the next business day. Having a one to two 
> business day rule  instead of 24 hours for non compromise issues gives the 
> end entity time to receive the notification and replace their certificate 
> with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it does 
sound like a good solution. However, I think it's another example of the 
general difference of opinion between people on this list around whether we 
should be holding CAs to the highest standards or not. These mis-issued 
certificates are typically not a security concern, but they speak to either 
ignorance on the part of CA operators or a pattern of lackadaisical controls 
within the issuance systems. Neither of these is acceptable behavior at this 
juncture. Conformance with the BRs has been mandatory for over 5 years now. 
Customers need to be made aware of the failures of their chosen providers and 
the responsibilities incumbent upon them as subscribers, and if their own 
certificate installation/replacement processes are sufficiently archaic as to 
make it difficult to replace a certificate in an automated fashion then they 
should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business days" 
really mean?Does the CA get 1-2 business days followed by 1-2 for the customer? 
What if there's a holiday in the CA's country of operations followed by a 
holiday in the customer's home country? How quickly does this window extend to 
2+ weeks? If you were to go down this path I'd strongly prefer it to be a hard 
deadline (e.g. 72 hours) and not anything related to business days.

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

Re: Certificates with metadata-only subject fields

[David E. Ross via dev-security-policy]

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
> 
>> On Aug 9, 2017, at 17:50, Peter Bowen  wrote:
>>
>> The point of certlint was to help identify issues.  While I appreciate
>> it getting broad usage, I don't think pushing for revocation of every
>> certificate that trips any of the Error level checks is productive.
> 
> I agree, and I don’t really have a position on the revocation of certificates 
> with errors that do not appear to have any security impact like these.
> 
> Jonathan
> 
> 

I strongly disagree.  Errors like this make me question whether the
certification authority is sufficiently competent to be trusted.  Small
errors can indicate an increased likelihood of serious errors.

-- 
David E. Ross


President Trump demands loyalty to himself from Republican members
of Congress.  I always thought that members of Congress -- House
and Senate -- were required to be loyal to the people of the
United States.  In any case, they all swore an oath of office
to be loyal to the Constitution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Phishing detection from FQDN's as prefixes

[Adam Shannon via dev-security-policy]

Has anyone looked into what some use cases are for using a FQDN as a prefix
in a hostname? (Or even how common such names in use are?) I could imagine
setting up a proxy or archival service with such a scheme:

www.google.com.corp.com/search?q=flowers

www.myblog.net.proxy.com?rev=2017-08-09

If a large percentage of hostnames with a FQDN prefix are phishing related
it might be an initial pool for further research by agencies.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with metadata-only subject fields

[Jonathan Rudenberg via dev-security-policy]

> On Aug 9, 2017, at 17:50, Peter Bowen  wrote:
> 
> The point of certlint was to help identify issues.  While I appreciate
> it getting broad usage, I don't think pushing for revocation of every
> certificate that trips any of the Error level checks is productive.

I agree, and I don’t really have a position on the revocation of certificates 
with errors that do not appear to have any security impact like these.

Jonathan


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

Re: Certificates with metadata-only subject fields

[Peter Bowen via dev-security-policy]

The point of certlint was to help identify issues.  While I appreciate
it getting broad usage, I don't think pushing for revocation of every
certificate that trips any of the Error level checks is productive.
This reminds of me of people trawling a database of known
vulnerabilities then reporting them to the vendors and asking for a
reward, which happens all too often in bug bounty programs.

I think it would be much more valuable to have a "score card" by CA
Operator that shows absolute defects and defect rate.

Thanks,
Peter

On Wed, Aug 9, 2017 at 2:21 PM, Jeremy Rowley via dev-security-policy
 wrote:
> And this is exactly why we need separate tiers of revocation. Here, there is 
> zero risk to the end user.  I do think it should be fixed and remediated, but 
> revoking all these certs within 24 hours seems unnecessarily harsh.  I think 
> there was a post about this a while ago, but I haven't been able to find it.  
> If someone remembers where it was, I'd appreciate it.
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
>  On Behalf Of Jonathan Rudenberg via dev-security-policy
> Sent: Wednesday, August 9, 2017 10:08 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Certificates with metadata-only subject fields
>
> Baseline Requirements section 7.1.4.2.2(j) says:
>
>> All other optional attributes, when present within the subject field, MUST 
>> contain information that has been verified by the CA. Optional attributes 
>> MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, 
>> and/or any other indication that the value is absent, incomplete, or not 
>> applicable.
>
> There are 522 unexpired unrevoked certificates known to CT issued after 
> 2015-11-01 that are trusted by NSS for server authentication and have at 
> least one subject field that only contains ASCII punctuation characters.
>
> The full list can be found here: https://misissued.com/batch/5/
>
> Since there are so many, I have included a list of the CCADB owner, 
> intermediate commonName, and count of certificates for the 311 certificates 
> in this batch that were issued in the last 365 days so that the relevant CAs 
> can add the appropriate technical controls and policy to comply with this 
> requirement in the future. Please let me know if there is any additional 
> information that would be useful.
>
> Jonathan
>
> —
>
> DigiCert (131)
> Cybertrust Japan Public CA G3 (64)
> DigiCert SHA2 Extended Validation Server CA (36)
> DigiCert SHA2 High Assurance Server CA (12)
> TERENA SSL CA 3 (7)
> DigiCert SHA2 Secure Server CA (6)
> Cybertrust Japan EV CA G2 (6)
>
> GlobalSign (62)
> GlobalSign Organization Validation CA - SHA256 - G2 (46)
> GlobalSign Extended Validation CA - SHA256 - G2 (8)
> GlobalSign Extended Validation CA - SHA256 - G3 (8)
>
> Symantec / VeriSign (35)
> Symantec Class 3 Secure Server CA - G4 (32)
> Symantec Class 3 EV SSL CA - G3 (2)
> Wells Fargo Certificate Authority WS1 (1)
>
> Symantec / GeoTrust (34)
> GeoTrust SSL CA - G3 (25)
> GeoTrust SHA256 SSL CA (5)
> RapidSSL SHA256 CA (2)
> GeoTrust Extended Validation SHA256 SSL CA (2)
>
> Comodo (19)
> COMODO RSA Organization Validation Secure Server CA (11)
> COMODO RSA Extended Validation Secure Server CA (8)
>
> Symantec / Thawte (17)
> thawte SSL CA - G2 (12)
> thawte SHA256 SSL CA (3)
> thawte EV SSL CA - G3 (2)
>
> T-Systems International GmbH (Deutsche Telekom) (6)
> Zertifizierungsstelle FH Duesseldorf - G02 (3)
> TeleSec ServerPass Class 2 CA (2)
> Helmholtz-Zentrum fuer Infektionsforschung (1)
>
> QuoVadis (3)
> QuoVadis EV SSL ICA G1 (2)
> QuoVadis Global SSL ICA G2 (1)
>
> SECOM Trust Systems Co. Ltd. (2)
> NII Open Domain CA - G4 (2)
>
> SwissSign AG (1)
> SwissSign Server Gold CA 2014 - G22 (1)
>
> Entrust (1)
> Entrust Certification Authority - L1K (1) 
> ___
> 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

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

And this is exactly why we need separate tiers of revocation. Here, there is 
zero risk to the end user.  I do think it should be fixed and remediated, but 
revoking all these certs within 24 hours seems unnecessarily harsh.  I think 
there was a post about this a while ago, but I haven't been able to find it.  
If someone remembers where it was, I'd appreciate it.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Wednesday, August 9, 2017 10:08 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Certificates with metadata-only subject fields

Baseline Requirements section 7.1.4.2.2(j) says:

> All other optional attributes, when present within the subject field, MUST 
> contain information that has been verified by the CA. Optional attributes 
> MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, 
> and/or any other indication that the value is absent, incomplete, or not 
> applicable.

There are 522 unexpired unrevoked certificates known to CT issued after 
2015-11-01 that are trusted by NSS for server authentication and have at least 
one subject field that only contains ASCII punctuation characters.

The full list can be found here: https://misissued.com/batch/5/

Since there are so many, I have included a list of the CCADB owner, 
intermediate commonName, and count of certificates for the 311 certificates in 
this batch that were issued in the last 365 days so that the relevant CAs can 
add the appropriate technical controls and policy to comply with this 
requirement in the future. Please let me know if there is any additional 
information that would be useful.

Jonathan

—

DigiCert (131)
Cybertrust Japan Public CA G3 (64)
DigiCert SHA2 Extended Validation Server CA (36)
DigiCert SHA2 High Assurance Server CA (12)
TERENA SSL CA 3 (7)
DigiCert SHA2 Secure Server CA (6)
Cybertrust Japan EV CA G2 (6)

GlobalSign (62)
GlobalSign Organization Validation CA - SHA256 - G2 (46)
GlobalSign Extended Validation CA - SHA256 - G2 (8)
GlobalSign Extended Validation CA - SHA256 - G3 (8)

Symantec / VeriSign (35)
Symantec Class 3 Secure Server CA - G4 (32)
Symantec Class 3 EV SSL CA - G3 (2)
Wells Fargo Certificate Authority WS1 (1)

Symantec / GeoTrust (34)
GeoTrust SSL CA - G3 (25)
GeoTrust SHA256 SSL CA (5)
RapidSSL SHA256 CA (2)
GeoTrust Extended Validation SHA256 SSL CA (2)

Comodo (19)
COMODO RSA Organization Validation Secure Server CA (11)
COMODO RSA Extended Validation Secure Server CA (8)

Symantec / Thawte (17)
thawte SSL CA - G2 (12)
thawte SHA256 SSL CA (3)
thawte EV SSL CA - G3 (2)

T-Systems International GmbH (Deutsche Telekom) (6)
Zertifizierungsstelle FH Duesseldorf - G02 (3)
TeleSec ServerPass Class 2 CA (2)
Helmholtz-Zentrum fuer Infektionsforschung (1)

QuoVadis (3)
QuoVadis EV SSL ICA G1 (2)
QuoVadis Global SSL ICA G2 (1)

SECOM Trust Systems Co. Ltd. (2)
NII Open Domain CA - G4 (2)

SwissSign AG (1)
SwissSign Server Gold CA 2014 - G22 (1)

Entrust (1)
Entrust Certification Authority - L1K (1) 
___
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: Microsoft to remove WoSign and StartCom certificates in Windows 10

[Itzhak Daniel via dev-security-policy]

This blog post is very vague, one can understood from it that Microsoft will 
not trust any new certificates from these two CAs:

"Microsoft will begin the natural deprecation of WoSign and StartCom 
certificates by setting a “NotBefore” date ... Windows 10 will not trust any 
new certificates from these CAs after September 2017."

But this probably not the case; I guess the article refer to removal of the old 
roots of StartCom and WoSign as they [probably] didn't go through Microsoft 
Audit process again (required annually) for these certs [1]. 'Microsoft Trusted 
Root Certificate' [2] isn't open to public comments/review, so we can't really 
tell what exactly is that status, probably StartCom and WoSign will file a 
request for the new roots to be included.

Links:
1. http://aka.ms/auditreqs
2. https://technet.microsoft.com/en-us/library/cc751157.aspx
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: High traffic on this list, and Mozilla root program involvement

[Jeremy Rowley via dev-security-policy]

I was thinking you should just have the Cas add them all for you.  Makes it
easier on you and demonstrates they are tracking and remediating these
issues.  If I were going to create a bug for these in Mozilla would you
prefer to see one bug per issue on one bug per CA. For example, should there
be a bug for all DigiCert issues or should there be one that describes too
long of serial number and another that says the field contains meta-data? 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Wednesday, August 9, 2017 9:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: High traffic on this list, and Mozilla root program involvement

On 09/08/17 00:12, Jeremy Rowley wrote:
> Do you want that added as a new bug for all the issues listed?

I'm not sure I follow. Do I want what added?

I will be filing any additional appropriate bugs when I get around to
triaging all the messages in this forum.

Gerv
___
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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Lee via dev-security-policy]

On 8/9/17, Eric Mill via dev-security-policy
 wrote:
> On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote:
>> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> > >
>> > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg
>> wrote:
>> > >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP
>> responder URL that has a HTTPS URI scheme. This is not valid, the OCSP
>> responder URI is required to have the plaintext HTTP scheme according to
>> Baseline Requirements section 7.1.2.2(c).
>> > >>
>> > >> Here’s the list of certificates: https://misissued.com/batch/4/
>> > >>
>> > >> Jonathan
>> > >
>> > > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in
>> this
>> > > context.  That being said, we have altered our profiles for
>> certificates
>> > > issued under this Sub CA to include only HTTP OCSP URLs.  All
>> certificates
>> > > issued going forward will contain an HTTP OCSP URL.  We will also
>> examine all
>> > > other sub CA to ensure only HTTP OCSP URLs are included.  Thank you
>> for giving
>> > > us an opportunity to address this with the community
>> >
>> > Thanks for the update.
>> >
>> > Can you also clarify why the subject organizationName is "U.S.
>> Government” for all of these certificates, despite the other subject
>> fields
>> indicating organizations that are not a component of the US Government?
>> >
>> > Jonathan
>>
>> Yes,
>> IdenTrust ACES SSL Certificates are issued in accordance with the ACES
>> certificate policy defined by U.S. General Service Administration (
>> http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/docum
>> ents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust CPS
>> (https://secure.identrust.com/certificates/policy/aces/IdenT
>> rust_ACES_CPS_v5.1_20161110.pdf)
>> These ACES SSL certificates are issued to either U.S. Government agencies
>> and/or their sub-contractors in support of government programs\projects.
>> The
>> CP requires an approved CA, such as IdenTrust, to identify U.S. Government
>> in
>> subject organizationName along with other applicable organizations (e.g.
>> sub-contractors, or local government agency, etc...).
>>
>
> If that's the case, I would expect each certificate to be authenticating
> hostnames that are used solely to provide such services to the U.S.
> Government. That doesn't appear to be the case with these.
>
> For example, one of them is for the homepage for a service provider:
> www.mudiaminc.com

What am I doing wrong?  goto https://www.mudiaminc.com/
check the cert and it says
Issued To
Common Name (CN)*.opentransfer.com
Organization (O)ECOMMERCE, INC.


> And one of them is for what appears to be a state government revenue
> service's VPN: vpn.revenue.louisiana.gov

I see that one - goto https://vpn.revenue.louisiana.gov/
check the cert and it says
Issued To
Common Name (CN)Vpn.revenue.louisiana.gov
Organization (O)U.S. Government

> (So it's clear, "U.S. Government" only refers to the federal government,
> not state/local/tribal governments.)
>
> I personally (and to be clear, this is in my individual capacity and I am
> not representing my employer) think these are invalid organizationNames,
> constitute misissuance, and that Identrust should be using the "U.S.
> Government" only for hostnames providing services operated exclusively on
> behalf of the federal government.

playing devils' advocate: how do you know that
https://vpn.revenue.louisiana.gov/ wasn't set up in collaboration with
the IRS or some other branch of the U.S. Government?

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

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Eric Mill via dev-security-policy]

On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote:
> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg
> wrote:
> > >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP
> responder URL that has a HTTPS URI scheme. This is not valid, the OCSP
> responder URI is required to have the plaintext HTTP scheme according to
> Baseline Requirements section 7.1.2.2(c).
> > >>
> > >> Here’s the list of certificates: https://misissued.com/batch/4/
> > >>
> > >> Jonathan
> > >
> > > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in
> this
> > > context.  That being said, we have altered our profiles for
> certificates
> > > issued under this Sub CA to include only HTTP OCSP URLs.  All
> certificates
> > > issued going forward will contain an HTTP OCSP URL.  We will also
> examine all
> > > other sub CA to ensure only HTTP OCSP URLs are included.  Thank you
> for giving
> > > us an opportunity to address this with the community
> >
> > Thanks for the update.
> >
> > Can you also clarify why the subject organizationName is "U.S.
> Government” for all of these certificates, despite the other subject fields
> indicating organizations that are not a component of the US Government?
> >
> > Jonathan
>
> Yes,
> IdenTrust ACES SSL Certificates are issued in accordance with the ACES
> certificate policy defined by U.S. General Service Administration (
> http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/docum
> ents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust CPS
> (https://secure.identrust.com/certificates/policy/aces/IdenT
> rust_ACES_CPS_v5.1_20161110.pdf)
> These ACES SSL certificates are issued to either U.S. Government agencies
> and/or their sub-contractors in support of government programs\projects.
> The
> CP requires an approved CA, such as IdenTrust, to identify U.S. Government
> in
> subject organizationName along with other applicable organizations (e.g.
> sub-contractors, or local government agency, etc...).
>

If that's the case, I would expect each certificate to be authenticating
hostnames that are used solely to provide such services to the U.S.
Government. That doesn't appear to be the case with these.

For example, one of them is for the homepage for a service provider:
www.mudiaminc.com

And one of them is for what appears to be a state government revenue
service's VPN: vpn.revenue.louisiana.gov

(So it's clear, "U.S. Government" only refers to the federal government,
not state/local/tribal governments.)

I personally (and to be clear, this is in my individual capacity and I am
not representing my employer) think these are invalid organizationNames,
constitute misissuance, and that Identrust should be using the "U.S.
Government" only for hostnames providing services operated exclusively on
behalf of the federal government.

-- Eric



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



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

Re: Symantec Update on SubCA Proposal

[Devon O'Brien via dev-security-policy]

Hello m.d.s.p.,

I'd just like to give the community a heads up that Chrome’s plan remains to 
put up a blog post echoing our recent announcement on blink-dev [1], but in the 
meantime, we are reviewing the facts related to Symantec’s sale of their PKI 
business to DigiCert [2].

Recently, it has come to our attention that Symantec may have selected DigiCert 
from the RFP process to become a Managed CA Partner. As defined in Google’s 
first Managed CA proposal [3], then supported by Symantec’s commitment to 
“[cover] all aspects of the SubCA proposal” [4], and finally reiterated in 
Google’s final proposal [1], the requirement has always been that the Managed 
Partner Infrastructure be operated by an independent and non-affiliated CA 
while Symantec worked to rebuild the web community's confidence. 

Based on this information, we have a series of questions that we’d like 
Symantec to address for public discussion:

1. Just to confirm, Did Symantec select DigiCert to be Managed CA Partner under 
the RFP process? If so, in light of DigiCert’s acquisition of Symantec’s PKI 
business and Symantec’s substantial equity investment in DigiCert, can you 
explain how you believe selecting DigiCert as the Managed CA Partner meets the 
stated requirement of being an independent and non-affiliated organization? 

2. Were any additional CAs selected to be a Managed CA Partner from the list of 
trusted CAs that Symantec “felt best met the browser requirements”?

[1]https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ
[2]http://investor.symantec.com/About/Investors/press-releases/press-release-details/2017/DigiCert-to-Acquire-Symantecs-Website-Security-and-Related-PKI-Solutions/default.aspx
[3]https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
[4]https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/6iZUc7kOCAAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates with metadata-only subject fields

[Jonathan Rudenberg via dev-security-policy]

Baseline Requirements section 7.1.4.2.2(j) says:

> All other optional attributes, when present within the subject field, MUST 
> contain information that has been verified by the CA. Optional attributes 
> MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, 
> and/or any other indication that the value is absent, incomplete, or not 
> applicable.

There are 522 unexpired unrevoked certificates known to CT issued after 
2015-11-01 that are trusted by NSS for server authentication and have at least 
one subject field that only contains ASCII punctuation characters.

The full list can be found here: https://misissued.com/batch/5/

Since there are so many, I have included a list of the CCADB owner, 
intermediate commonName, and count of certificates for the 311 certificates in 
this batch that were issued in the last 365 days so that the relevant CAs can 
add the appropriate technical controls and policy to comply with this 
requirement in the future. Please let me know if there is any additional 
information that would be useful.

Jonathan

—

DigiCert (131)
Cybertrust Japan Public CA G3 (64)
DigiCert SHA2 Extended Validation Server CA (36)
DigiCert SHA2 High Assurance Server CA (12)
TERENA SSL CA 3 (7)
DigiCert SHA2 Secure Server CA (6)
Cybertrust Japan EV CA G2 (6)

GlobalSign (62)
GlobalSign Organization Validation CA - SHA256 - G2 (46)
GlobalSign Extended Validation CA - SHA256 - G2 (8)
GlobalSign Extended Validation CA - SHA256 - G3 (8)

Symantec / VeriSign (35)
Symantec Class 3 Secure Server CA - G4 (32)
Symantec Class 3 EV SSL CA - G3 (2)
Wells Fargo Certificate Authority WS1 (1)

Symantec / GeoTrust (34)
GeoTrust SSL CA - G3 (25)
GeoTrust SHA256 SSL CA (5)
RapidSSL SHA256 CA (2)
GeoTrust Extended Validation SHA256 SSL CA (2)

Comodo (19)
COMODO RSA Organization Validation Secure Server CA (11)
COMODO RSA Extended Validation Secure Server CA (8)

Symantec / Thawte (17)
thawte SSL CA - G2 (12)
thawte SHA256 SSL CA (3)
thawte EV SSL CA - G3 (2)

T-Systems International GmbH (Deutsche Telekom) (6)
Zertifizierungsstelle FH Duesseldorf - G02 (3)
TeleSec ServerPass Class 2 CA (2)
Helmholtz-Zentrum fuer Infektionsforschung (1)

QuoVadis (3)
QuoVadis EV SSL ICA G1 (2)
QuoVadis Global SSL ICA G2 (1)

SECOM Trust Systems Co. Ltd. (2)
NII Open Domain CA - G4 (2)

SwissSign AG (1)
SwissSign Server Gold CA 2014 - G22 (1)

Entrust (1)
Entrust Certification Authority - L1K (1)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: High traffic on this list, and Mozilla root program involvement

[Gervase Markham via dev-security-policy]

On 09/08/17 00:12, Jeremy Rowley wrote:
> Do you want that added as a new bug for all the issues listed?

I'm not sure I follow. Do I want what added?

I will be filing any additional appropriate bugs when I get around to
triaging all the messages in this forum.

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

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

On Wednesday, August 9, 2017 at 12:05:32 AM UTC-4, Peter Gutmann wrote:
> Matthew Hardeman via dev-security-policy 
>  writes:
> 
> >I merely raise the point that IF the framers of the 20 bytes rule did, in
> >fact, simultaneously intend that arbitrary SHA-1 hash results should be able
> >to be stuffed into the serial number field AND SIMULTANEOUSLY that the DER
> >encoded integer field value must be a positive integer and that insertion of
> >a leading 0x00 byte to ensure that the high order bit would be 0 (thus
> >regarded as a positive value per the coding), THEN it must follow that at
> >least in the minds of those who engineered the rule, that the inserted 0x00
> >byte must not be part of the 20 byte maximum size of the value AS legitimate
> >SHA-1 values of 20 bytes do include values where the high order bit would be
> >1 and without pre-padding the proper interpretation of such a value would be
> >as a negative integer.
> 
> That sounds like sensible reasoning.  So you need to accept at least 20 + 1
> bytes, or better yet just set it to 32 or 64 bytes and be done with it because
> there are bound to be implementations out there that don't respect the 20-byte
> limit.  At the very least though you'd need to be able to handle 20 + 1.
> 
> Peter.

I see. So the solution to standards non-compliance that creates compatibility 
issues is to invent arbitrary standards (32 or 64 bytes)? How does that align 
with https://www.mozilla.org/en-US/about/manifesto/#principle-06 ?

The original language in RFC 2459 restricted it to INTEGER, and in 2459 had no 
length limit (thus, unbounded). This was reformed in RFC 3280, which introduced 
the language limiting the upper bound to 20 octets - which clearly intends to 
be the encoded value, by virtue of X.690. Similarly, when coupled with the 
'positive integer', this would hopefully have clearly limited the length to 20 
octets - there's no "20 plus padding" because the guarantee of a positive 
integer is a transformation that happens  before the conversion to octets, and 
the result is limited to 20 octets, and those octets are the result of encoding 
to the appropriate rules (BER or DER).

So no, this attempt at retro-analyzing 'large enough to fit SHA-1' does not fit 
the historic context, does not fit the text, and the argument for arbitrary 
bytes (e.g. actively ignoring 3280) is equally silly.

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

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

(Note: Top posting because Alex did so)

FYI: Last night, I posted a proposed very very rough draft overall
graduation of revocation periods for various kinds of issues in
mailman.1730.1502216764.14894.dev-security-pol...@lists.mozilla.org
(Part of this thread).

This only received a meaningless reply from a VIP bureaucrat.

On 09/08/2017 16:22, Alex Gaynor wrote:

I'm not really sure I agree that there should be multiple tiers of
revocation, but just to go along with the thought experiment..

If there were, "key compromise" is definitely not the only case I'd want on
the more aggressive schedule, I'd also want to include cases where there
was a failure in DV and the rightful owner of a domain wanted the cert
revoked.

Alex

On Wed, Aug 9, 2017 at 10:19 AM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


All CAS are required to maintain the capability to process and receive
revocation requests 24x7 under the baseline requirements. The headache is
not with the CA. Rather, it's notifying the customer that their certificate
will be revoked before the start of the next business day. Having a one to
two business day rule  instead of 24 hours for non compromise issues gives
the end entity time to receive the notification and replace their
certificate with a compliant version.


On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy <

dev-security-policy@lists.mozilla.org> wrote:



On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
24 hours is super short when it's a Saturday morning at 4 am and it’s a

European government entity. I agree that is what the policy says now, but,
for lower risk items, the policy should change, preferably to at least one
business day.




It is short, but any CA possessing global trust should already have

procedures in place for handling revocation in a prompt manner. It seems
odd that it would be onerous for them to revoke a non-compliant
certificate. The only difference is a need to confirm to the CA's
satisfaction that the given certificate is in violation of the BRs, which I
would expect any competent CA to be eminently capable of doing.





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: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

Totally agree Alex. The tiers I'm proposing are 1) subscriber requests 
revocation, cert was issued to the wrong entity, or the key was compromised and 
2) everything else

On Aug 9, 2017, at 8:22 AM, Alex Gaynor 
> wrote:

I'm not really sure I agree that there should be multiple tiers of revocation, 
but just to go along with the thought experiment..

If there were, "key compromise" is definitely not the only case I'd want on the 
more aggressive schedule, I'd also want to include cases where there was a 
failure in DV and the rightful owner of a domain wanted the cert revoked.

Alex

On Wed, Aug 9, 2017 at 10:19 AM, Jeremy Rowley via dev-security-policy 
>
 wrote:
All CAS are required to maintain the capability to process and receive 
revocation requests 24x7 under the baseline requirements. The headache is not 
with the CA. Rather, it's notifying the customer that their certificate will be 
revoked before the start of the next business day. Having a one to two business 
day rule  instead of 24 hours for non compromise issues gives the end entity 
time to receive the notification and replace their certificate with a compliant 
version.

> On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy 
> >
>  wrote:
>
>> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
>> 24 hours is super short when it's a Saturday morning at 4 am and it’s a 
>> European government entity. I agree that is what the policy says now, but, 
>> for lower risk items, the policy should change, preferably to at least one 
>> business day.
>>
>
> It is short, but any CA possessing global trust should already have 
> procedures in place for handling revocation in a prompt manner. It seems odd 
> that it would be onerous for them to revoke a non-compliant certificate. The 
> only difference is a need to confirm to the CA's satisfaction that the given 
> certificate is in violation of the BRs, which I would expect any competent CA 
> to be eminently capable of doing.
>
> -Paul
> ___
> 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

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 08/08/2017 21:24, Jeremy Rowley wrote:

I agree that the 24 hours seems excessive for some of these. Ive proposed at 
the cab forum we bifuracte the revocation periods to key compromise vs non key 
compromise. I'd love support there on the proposal. However, I think that until 
the rules change formally, CAs should be required to meet that strict period. 
It's not hard to make a change once general agreement is reached.



And I would suggest that until that has been resolved (one way or
another), we should have a moratorium on mass-filing revocation demands
for the kinds of violations which are expected to get a longer deadline
if the proposed changes go through.

For such, maybe post public descriptions, but delay on the formal filing 
that would start the 24 hour clock.



On Aug 8, 2017, at 1:02 PM, Jakob Bohm via dev-security-policy 
 wrote:

Some people seemed to require 24-hour revocation of these, which I also
find possibly excessive.


On 08/08/2017 20:28, Alex Gaynor wrote:
I think you're largely objecting to a strawman, no one is proposing
revoking trust in any of these threads.
The only CAs that have ever had _any_ penalty applied to them have been for
grotesque abuse of the trust vested in them.
Alex
On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

On 08/08/2017 18:43, Ryan Sleevi wrote:


On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:

I was not advocating "letting everyone decide".  I was advocating that
Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in the
shop and sees that some employees are taking extra breaks when there are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.



Such tools have been available for over a year. CAs have been aware of
this, the ability to run it over their own corpus and self-detect and
self-report. These tools, notably, were created by one of the newest CA
applicants - Amazon - based on a methodical study of what is required of a
CA.

Your attempts to characterize it as overzealous ignore this entirely. At
this point, it's gross negligence, and attempts to argue otherwise merely
suggest a lack of understanding or concern for standards compliance and
interoperability.

Mozilla has already communicated to CAs these tools exist and their
relevance to CAs.

Perhaps we can move on from misguided apologetics and instead focus on
how to make things better. Suggestions we ignore these, at this point, are
neither productive nor relevant. Attempts to suggest tortured metaphors are
like attempting to suggest rich people deserve to be robbed, or poor people
just need to work harder - arguments that are both hollow and borderline
offensive in their reductionism. A pattern of easily preventable
misissuance has been happening,CAs have been repeatedly told to
self-detect, and clearly, some CAs, like presumably some businesses, aren't
taking security seriously. That needs to stop.



I am questioning the fairness of applying these tools, which did not
exist when the rules were written, to enforce every rule with the same
high weight.  I am not apologizing for bad behavior, I am saying if
everybody gets scrutinized this hard, we will eventually have to
distrust pretty much all the CAs, because there is no such thing as a
perfect CA organization.

So we need to prioritize the rules instead of just saying off-with-
their-heads (revoke all affected certificates in 24 hours) whenever any
formal rule was broken without actually harming security.

An example of a graduated response:

- Deliberately issued super-interception certificate: Instant revocation
  of CA trust.
- SubCA that does no vetting at all: Instant 

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

I'm not really sure I agree that there should be multiple tiers of
revocation, but just to go along with the thought experiment..

If there were, "key compromise" is definitely not the only case I'd want on
the more aggressive schedule, I'd also want to include cases where there
was a failure in DV and the rightful owner of a domain wanted the cert
revoked.

Alex

On Wed, Aug 9, 2017 at 10:19 AM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All CAS are required to maintain the capability to process and receive
> revocation requests 24x7 under the baseline requirements. The headache is
> not with the CA. Rather, it's notifying the customer that their certificate
> will be revoked before the start of the next business day. Having a one to
> two business day rule  instead of 24 hours for non compromise issues gives
> the end entity time to receive the notification and replace their
> certificate with a compliant version.
>
> > On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
> >> 24 hours is super short when it's a Saturday morning at 4 am and it’s a
> European government entity. I agree that is what the policy says now, but,
> for lower risk items, the policy should change, preferably to at least one
> business day.
> >>
> >
> > It is short, but any CA possessing global trust should already have
> procedures in place for handling revocation in a prompt manner. It seems
> odd that it would be onerous for them to revoke a non-compliant
> certificate. The only difference is a need to confirm to the CA's
> satisfaction that the given certificate is in violation of the BRs, which I
> would expect any competent CA to be eminently capable of doing.
> >
> > -Paul
> > ___
> > 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

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 08/08/2017 20:46, Alex Gaynor wrote:

It's from the BRs 4.9.1.1:

  The CA SHALL revoke a Certificate within 24 hours if one or more of
the following occurs:

It's also not a penalty on the CA, it's a remediation step for them to
undertake.



It is a disruption and penalty to the 3rd party certificate holder to
have their certificate suddenly revoked due to a bureaucratic mistake at
the CA.

It is a disruption and penalty to relying parties encountering the
certificate to suddenly receive error messages or loose connectivity due
to a bureaucratic mistake at the CA.

It is generally bad for interoperability to have certificates randomly
disappear due to someone filing mass-bugs for violations of formalities.


Alex

On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Some people seemed to require 24-hour revocation of these, which I also
find possibly excessive.

On 08/08/2017 20:28, Alex Gaynor wrote:


I think you're largely objecting to a strawman, no one is proposing
revoking trust in any of these threads.

The only CAs that have ever had _any_ penalty applied to them have been
for
grotesque abuse of the trust vested in them.

Alex

On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

On 08/08/2017 18:43, Ryan Sleevi wrote:


On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:


I was not advocating "letting everyone decide".  I was advocating that

Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in
the
shop and sees that some employees are taking extra breaks when there
are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as
a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.


Such tools have been available for over a year. CAs have been aware of

this, the ability to run it over their own corpus and self-detect and
self-report. These tools, notably, were created by one of the newest CA
applicants - Amazon - based on a methodical study of what is required
of a
CA.

Your attempts to characterize it as overzealous ignore this entirely. At
this point, it's gross negligence, and attempts to argue otherwise
merely
suggest a lack of understanding or concern for standards compliance and
interoperability.

Mozilla has already communicated to CAs these tools exist and their
relevance to CAs.

Perhaps we can move on from misguided apologetics and instead focus on
how to make things better. Suggestions we ignore these, at this point,
are
neither productive nor relevant. Attempts to suggest tortured metaphors
are
like attempting to suggest rich people deserve to be robbed, or poor
people
just need to work harder - arguments that are both hollow and borderline
offensive in their reductionism. A pattern of easily preventable
misissuance has been happening,CAs have been repeatedly told to
self-detect, and clearly, some CAs, like presumably some businesses,
aren't
taking security seriously. That needs to stop.


I am questioning the fairness of applying these tools, which did not

exist when the rules were written, to enforce every rule with the same
high weight.  I am not apologizing for bad behavior, I am saying if
everybody gets scrutinized this hard, we will eventually have to
distrust pretty much all the CAs, because there is no such thing as a
perfect CA organization.

So we need to prioritize the rules instead of just saying off-with-
their-heads (revoke all affected certificates in 24 hours) whenever any
formal rule was broken without actually harming security.

An example of a graduated response:

- Deliberately issued super-interception certificate: Instant revocation
   of CA trust.
- SubCA that does no vetting at all: Instant revocation and adding to
   OneCRL.
- 

Re: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

All CAS are required to maintain the capability to process and receive 
revocation requests 24x7 under the baseline requirements. The headache is not 
with the CA. Rather, it's notifying the customer that their certificate will be 
revoked before the start of the next business day. Having a one to two business 
day rule  instead of 24 hours for non compromise issues gives the end entity 
time to receive the notification and replace their certificate with a compliant 
version.

> On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy 
>  wrote:
> 
>> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
>> 24 hours is super short when it's a Saturday morning at 4 am and it’s a 
>> European government entity. I agree that is what the policy says now, but, 
>> for lower risk items, the policy should change, preferably to at least one 
>> business day. 
>> 
> 
> It is short, but any CA possessing global trust should already have 
> procedures in place for handling revocation in a prompt manner. It seems odd 
> that it would be onerous for them to revoke a non-compliant certificate. The 
> only difference is a need to confirm to the CA's satisfaction that the given 
> certificate is in violation of the BRs, which I would expect any competent CA 
> to be eminently capable of doing.
> 
> -Paul
> ___
> 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: Microsoft to remove WoSign and StartCom certificates in Windows 10

[Richard Wang via dev-security-policy]

Notice to WoSign customers:

This announcement is for WoSign old roots:

1) CN=CA 沃通根证书, O=WoSign CA Limited, C=CN
2) CN=Certification Authority of WoSign, O=WoSign CA Limited, C=CN
3) CN=Certification Authority of WoSign G2, O=WoSign CA Limited, C=CN
4) CN=CA WoSign ECC Root, O=WoSign CA Limited, C=CN

This distrust action is no any relationship with the current trusted Managed 
Sub CA issued certificates, this distrust action doesn't affect all SSL 
certificates issued by the Managed Sub CA after Nov 21, 2016. WoSign have 
stopped to sell SSL certificate to customers from the above old roots that 
Microsoft plan to distrust since Oct 20, 2016.

敬告沃通用户：

微软宣布的是9月26日后不信任WoSign老根证书签发的证书，并不是指目前WoSign销售的SSL证书。目前销售的SSL证书都是从其他信任CA根证书签发的证书，不受任何影响。


Best Regards,

WoSign CA Limited



-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Percy via dev-security-policy
Sent: Wednesday, August 9, 2017 2:03 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Microsoft to remove WoSign and StartCom certificates in Windows 10

https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/

Microsoft has concluded that the Chinese Certificate Authorities (CAs) WoSign 
and StartCom have failed to maintain the standards required by our Trusted Root 
Program. Observed unacceptable security practices include back-dating SHA-1 
certificates, mis-issuances of certificates, accidental certificate revocation, 
duplicate certificate serial numbers, and multiple CAB Forum Baseline 
Requirements (BR) violations.

Thus, Microsoft will begin the natural deprecation of WoSign and StartCom 
certificates by setting a “NotBefore” date of 26 September 2017. This means all 
existing certificates will continue to function until they self-expire. Windows 
10 will not trust any new certificates from these CAs after September 2017.

Microsoft values the global Certificate Authority community and only makes 
these decisions after careful consideration as to what is best for the security 
of our users.
___
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: Certificates with invalidly long serial numbers

[Paul Kehrer via dev-security-policy]

On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
> 24 hours is super short when it's a Saturday morning at 4 am and it’s a 
> European government entity. I agree that is what the policy says now, but, 
> for lower risk items, the policy should change, preferably to at least one 
> business day. 
> 

It is short, but any CA possessing global trust should already have procedures 
in place for handling revocation in a prompt manner. It seems odd that it would 
be onerous for them to revoke a non-compliant certificate. The only difference 
is a need to confirm to the CA's satisfaction that the given certificate is in 
violation of the BRs, which I would expect any competent CA to be eminently 
capable of doing.

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

Microsoft to remove WoSign and StartCom certificates in Windows 10

[Percy via dev-security-policy]

https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/

Microsoft has concluded that the Chinese Certificate Authorities (CAs) WoSign 
and StartCom have failed to maintain the standards required by our Trusted Root 
Program. Observed unacceptable security practices include back-dating SHA-1 
certificates, mis-issuances of certificates, accidental certificate revocation, 
duplicate certificate serial numbers, and multiple CAB Forum Baseline 
Requirements (BR) violations.

Thus, Microsoft will begin the natural deprecation of WoSign and StartCom 
certificates by setting a “NotBefore” date of 26 September 2017. This means all 
existing certificates will continue to function until they self-expire. Windows 
10 will not trust any new certificates from these CAs after September 2017.

Microsoft values the global Certificate Authority community and only makes 
these decisions after careful consideration as to what is best for the security 
of our users.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy