Re: Entropy of certificate serial number

[Alex Gaynor via dev-security-policy]

Hi Lijun,

Entropy is required in serial numbers to protect against weak hash
functions -- historically exploitation of MD5's weakness was possible
because CAs used sequential serial numbers, thus allowing an attacker to
pre-compute hash prefixes, because they could predict future data that
would be signed's prefix. The exact value of 64 comes out of a Microsoft
Root Program requirement that was later incorporated into the BRs, as I
recall.

Cheers,
Alex

On Fri, Apr 5, 2019 at 11:20 AM Lijun Liao via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> In the last days, the issue related to the 63 bit serial number by using
> the default configuration of EJBCA poped up in many forums.
>
> Could someone please explain why the BR requires the minimal entropy to be
> 64 bit?
>
> Best regards
> Lijun
> ___
> 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: DarkMatter Concerns

[Alex Gaynor via dev-security-policy]

On Tue, Mar 5, 2019 at 9:01 AM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I have addressed most if not all of the various technical comments in this
> list in respect to DarkMatter’s Roots submission and it might be helpful if
> I summarize here the raised Compliance Concerns and Risk of Misuse Concerns:
>
> 1.  Compliance
>
> Questions have been raised about DarkMatter’s compliance and I want to
> again emphasize that we have a proven compliance and clean record in the
> three years of operations and have been through two complete web trust
> audits that have verified that we are operating within industry standards.
>
> •   DM has resolved all technical and policy issues raised in the UAE
> and DM Roots submission process on Mozilla list: see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1427262
>
> •   Since the inception of the DM CA we have had two technical
> compliance issues during its three years of operation, both were addressed
> immediately and resolved.
>
> •   The first was that DM misissued 2 TLS certificates that were not
> in compliance with the BRs as reported by Rob Stradling - specifically the
> FQDN listed in the CN was not also included in the SAN. The 2 offensive
> certs were already flagged by DM and were held and revoked and were only in
> existence for approximately 18hrs and at NO TIME were they LIVE on the
> internet protecting any services. They were promptly replaced by properly
> attributed BR-compliant certificates. Comment 31 of the UAE and DM Root
> inclusion Bug is where the two misissued certs were documented see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1427262
>
> •   The second was the serialNumber entropy raised by Corey Bonnell,
> this amounted to an interpretation of the BRs standards that was known to
> CAs following the time of Ballot 164, whereas DM interpreted the BRs as
> they are written. DM was not privy to the discussions around Ballet 164 and
> the subsequent community discussions. DM analyzed the BRs post Ballot 164
> and concluded based on the definition in Section 7.1, that our platform was
> compliant with the BRs. This continued to be our position until Ryan Sleevi
> posted historical data regarding the interpretations provided to other CAs
> after the adoption of Ballet 164. At this point DM took the decision to
> align with the general community interpretation of Section 7.1 (which up to
> that point was not known to us). It was not a bug originally, our platform
> was compliant at the time it was introduced. The update to the BRs appears
> to have lost some specificity in its re-wording which existing CAs knew
> about at the time, but any new CAs coming after the change may not make the
> same conclusion without the benefit of the background information. All
> public trust TLS certs issued by DM have now been replaced and the platform
> updated as documented in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1531800
> NOTE: The Roots and Issuing CAs have not yet been re-issued at this time,
> awaiting availability of WT Audit staff. There is also an open question on
> MDSP group about the necessity to re-issue the Roots.
>
> It’s evident from the above that DM has expeditiously addressed any issues
> raised and Mozilla has already said that there is no direct evidence of
> misissuance by DarkMatter. We have adhered to the rules and satisfied all
> technical criteria to be included. And we operate entirely transparently,
> providing all our public trust TLS certificates to CT logs so that anyone
> can see all the certificates that were issued over time and in this way,
> DarkMatter goes beyond required standards.
>
> 2.  Risk of Misuse
>
> I also find it extremely troubling that speculation by members on this
> list has far exceeded the bounds of reality.
>
> Claim:  DM certifications could be issued to malicious actors who could
> then impersonate legitimate websites.
>
> Response:
> •   DM does not issue certificates that can be used for MITM as stated
> in our published policies which we are audited against.
>
> •   There is no test that we’re aware of that allows us to ascertain
> someone’s malicious intent in the future and if we find any misuse of a
> certificate in this regards we revoke it immediately. We are willing to
> engage in a dialogue with the industry on how to minimize the probability
> of malicious actors and willingly subscribe to the industry consensus on
> this.
>
>
You're right, there is no test. That's why some of us believe we should
look at proxies: such as honesty, considering root membership is ultimately
about trust. DM has made claims that I am unable to understand in any way
besides lying.


> Referenced claim: outlandish claims of DM being able to decrypt all its
> customers’ data if granted Root acceptance in Mozilla.
>
> Response:
> •   As everybody here knows, this is entirely ludicrous as commercial
> CAs never hold customer’s privat

Re: DarkMatter Concerns

[Alex Gaynor via dev-security-policy]

(Writing in my personal capacity)

On Tue, Feb 26, 2019 at 7:31 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
[...]

> All of Google, Amazon, and Microsoft are in the program.  All of these have
> or had significant business with at least the US DOD and have a significant
> core of managing executives as well as operations staff and assets in the
> United States.  As such, it is beyond dispute that each of these is
> subordinate to the laws and demands of the US Government.  Still, none of
> these stand accused of using their publicly trusted root CAs to issue
> certificates to a nefarious end.  It seems that no one can demonstrate that
> DarkMatter has or would either.  If so, no one has provided any evidence of
> that here.
>
>
>
I don't think this is well reasoned. There's several things going on here.
First, the United States government's sovereign jurisdiction has nothing to
do with any of these companies' business relationship with it. All would be
subject to various administrative and judicial procedures in any event.
Probably most relevantly, the All Writs Act (see; Apple vs FBI) -- although
it's not at all clear that it would extend to a court being able to compel
a CA to misissue. (Before someone jumps in to say "National Security
Letter", you should probably know that an NSL is an administrative subpoena
for a few specific pieces of a non-content metadata, not a magic catch all.
https://www.law.cornell.edu/uscode/text/18/2709). Again, none of which is
impacted by these company's being government contractors.

Finally, I think there's a point that is very much being stepped around
here. The United States Government, including its intelligence services,
operate under the rule of law, it is governed by both domestic and
international law, and various oversight functions. It is ultimately
accountable to elected political leadership, who are accountable to a
democracy. The same cannot be said of the UAE, which is an autocratic
monarchy. Its intelligence services are not constrained by the rule of law,
and I think you see this reflected in the targetting of surveillance
described in the Reuters article: journalists, human rights activists,
political rivals.

While it can be very tempting to lump all governments, and particularly all
intelligence services, into one bucket, I think it's important we consider
the variety of different ways such services can function.

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

Re: misissued.com FYI

[Alex Gaynor via dev-security-policy]

Great idea:
https://github.com/alex/revocation-tracker/blob/master/backups/2019-01-27.dump

It's a standard postgresql database dump.

Alex

On Mon, Jan 28, 2019 at 11:01 AM Eric Mill  wrote:

> Would you consider tossing the backup in a zip file in an S3 bucket or
> something, and sharing a link for the record here, for others finding this
> in the future?
>
> On Mon, Jan 28, 2019 at 10:05 AM Alex Gaynor via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Hi All,
>>
>> For anyone using https://misissued.com/ I wanted to provide a quick FYI
>> about some database maintenance. The database was nearing its storage
>> capacity limit, and so I deleted all certificates from it that had expired
>> before 2019. The main consequence of this is that you can't use
>> misissued.com as a complete historical record anymore.
>>
>> I captured a database backup before doing this, so if anyone does want
>> that
>> data, it hasn't been completely lost.
>>
>> Cheers,
>> Alex
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
> --
> Eric Mill
> 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

misissued.com FYI

[Alex Gaynor via dev-security-policy]

Hi All,

For anyone using https://misissued.com/ I wanted to provide a quick FYI
about some database maintenance. The database was nearing its storage
capacity limit, and so I deleted all certificates from it that had expired
before 2019. The main consequence of this is that you can't use
misissued.com as a complete historical record anymore.

I captured a database backup before doing this, so if anyone does want that
data, it hasn't been completely lost.

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

Re: AlwaysOnSSL web security issues

[Alex Gaynor via dev-security-policy]

The Mozilla policy does not prohibit backdating, except when it's used to
evade time-based policy controls.

Backdating certs by a few hours is a relatively common practice to minimize
breakages for consumers with busted clocks.

Alex

On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>  The certificate [1] seems also to be 'back-dated' by about 18 hours. What
> is Mozillas opinion about this in the light of
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date
> ?
>
> > It appears AlwaysOnSSL is not completely disabled - if we trust CT as a
> timestamping service, [1] was issued after Hanno's email.
> [...]
> > [1] https://crt.sh/?id=1097197338
> [...]
> > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > Hi,
> > >
> > > AlwaysOnSSL was a free certificate authority operated by CertCenter.
> > > I recently noticed that their main webpage was gone, but pieces of the
> > > service were still online.
> > > I immediately found a few web security issues. I reported those to
> > > certcenter and digicert (which is the root CA their intermediate
> > > chains to).
> [...]
> > > In response to this the service was completely disabled.
> [...]
> ___
> 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: Increasing number of Errors found in crt.sh

[Alex Gaynor via dev-security-policy]

A broader issue is that a lot of the certs listed on these pages are
publicly-trusted, but not by the Mozilla Root Program, that is to say,
Microsoft or Apple (or occasionally Adobe) trusts them.

misissued.com (which is currently erroring on all requests 😬)  tried to
address this by only showing certificates from CA's in the Mozilla Root
Program, since that's the extent of our jurisdiction (and CA's applying for
inclusion, which in some cases are ones which have a history of
non-compliance under other root programs, but there's no way to
programatically tell if a CA is applying for inclusion).

Alex


On Mon, Oct 1, 2018 at 10:05 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
> > Hi Adriano,
> >
> > First, I didn't mean to call you out specifically, but you happened to be
> > first alphabetically, sorry.  I find this link very helpful to list all
> CAs
> > with errors or warnings: https://crt.sh/?cablint=1+week
> >
> > Second, How do you define a "test CA"?  I thought that any CA that
> chains to
> > a public root was by definition not a test CA,
>
> I agree with that.
>
> > and since the issued cert was
> > in CT logs, I assumed that your root was publicly trusted.  Maybe I'm
> > mistaken on one of these points
>
> Actually, some non-publicly-trusted roots are accepted by some of the
> logs that crt.sh monitors.
>
> > Doug
> >
> > -Original Message-
> > From: dev-security-policy 
> On
> > Behalf Of Adriano Santoni via dev-security-policy
> > Sent: Monday, October 1, 2018 9:49 AM
> > To: dev-security-policy@lists.mozilla.org
> > Subject: Re: Increasing number of Errors found in crt.sh
> >
> > Thank you Rob!
> >
> > If I am not mistaken, it seems to me that we have just 1 certificate in
> that
> > list, and it's a non-trusted certificate (it was issued by a test CA).
> >
> >
> > Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:
> >> On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
> >>> Is it possible to filter the list https://crt.sh/?cablint=issues
> >>> based on the issuing CA ?
> >>
> >> Yes.
> >>
> >> First, visit this page:
> >> https://crt.sh/?cablint=1+week
> >>
> >> Next, click on the link in the "Issuer CN, OU or O" column that
> >> corresponds to the issuing CA you're interested in.
> >>
> >>> Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:
>  Hi Wayne and all,
> 
> 
>  I've been noticing an increasing number of CA errors,
>  https://crt.sh/?cablint=issues  Is anyone monitoring this list and
>  asking
>  for misissuance reports for those that are not compliant? There are 15
>  different errors and around 300 individual errors (excluding the SHA-1
>  "false" errors).  Some CAs are issuing certs to CNs of localhost, are
>  including RFC822 SANs, not including OCSP links and many more.
> 
>  -  Actalis,
> 
>  -  Digicert,
> 
>  -  Microsoft,
> 
>  -
> 
> 
>  There are also some warning checks that should actually be errors like
>  underscores in CNs or SANs.
> 
> 
>  Doug
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>
> ___
> 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: Google Trust Services - Minor SCT issue disclosure

[Alex Gaynor via dev-security-policy]

Hi Andy,

Just so I follow, this is something you're proactively sharing, right? As
far as I can tell, there's no violation of any Mozilla Root Program rules
here, just an issue that caused interstitials in Chrome.

Either way, I appreciate your sharing.

You mentioned the issue was do to some overly complex control flow. In
order to help other CAs out, do you think there are testing methodologies
that could have helped catch this earlier?

Alex

On Thu, Aug 23, 2018 at 8:50 AM Andy Warner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Please note, Google wrote this report for internal use immediately after
> the issue. We intended to post it to m.d.s.p at that time, but securing
> internal approvals took a while and the posting ended-up on the back burner
> for a bit. It was a minor issue, but we want the community to be aware of
> it.
>
> Summary:
>
> May 21st 2018, a new tool for issuing certificates within Google was made
> available to internal customers. Within hours we started to receive reports
> that Chrome Canary (v67) with Certificate Transparency checks enabled was
> showing warnings. A coding error led to the new tool providing Signed
> Certificate Timestamps (SCTs) from 2 Google CT logs instead of one Google
> and one non-Google log.
>
> * NOTE: Affected certs were logged at issuance to at least 2 Google CT
> logs and 2 non-Google CT logs. The embedded SCTs for affected certs only
> provided proofs from Google logs instead of Google and non-Google logs as
> required by Chrome.
>
> * NOTE: The bug was due to an 'if/else' chain fall through. The code in
> question has been refactored to be simpler and more readable.
>
> The issue was fully resolved ~14 hours after initial notification. The
> issue was mitigated within 4 hours. Triage and code fixes happened within
> 11 hours and it took ~3 hours to deploy the fixed code and confirm the
> fixed behavior in production. The new code was running in relatively few
> locations, so deployment was quick compared to some changes in our
> infrastructure.
>
> Most affected customers responded quickly to communications that they
> should replace their certificates and revoke the old ones before a given
> deadline. All certificates that were issued with an SCT set that was not
> fully compliant were revoked on 2018-06-19 if they had not already been
> revoked by the customer previously. Most users replaced certificates
> shortly after notification.
>
> Timeline:
>
> 2018-03-22 Bug introduced to codebase.
> 2018-05-21 Push including bug became available to clients.
> 2018-05-22 08:05 UTC First user reports that Chrome Canary presents a CT
> warning for a certificate.
> 2018-05-22 09:25 UTC Bug filed with initial assessment.
> 2018-05-22 12:01 UTC Frontend jobs with the bug are taken offline
> following standard CA procedures.
> 2018-05-22 15:59 UTC Issue conclusively identified.
> 2018-05-22 19:07 UTC Fix is submitted.
> 2018-05-22 21:48 UTC Fix starts to be rolled out.
> 2018-05-22 22:16 UTC Fix fully deployed and tested on test instances
> followed by deployment to production. Access to frontends restored.
> 2018-05-24 Customer communication sent to affected users to ask them to
> renew their certificates and revoke the old ones.
> 2018-06-19 The final handful of certificates that had not already been
> revoked and replaced by users were revoked by the CA.
>
> Findings:
>
> * The operational plan to halt issuance worked as expected and was
> implemented quickly.
> * The problem was quickly found, fully understood and easy to remedy.
> * Tests existed, but did not cover this failure case.
>
> Remediation Plan
> * Completed
> ** Message of the Day (MOTD) functionality was added or improved for all
> issuance systems to make it easier to communicate issues to users when
> issuance is intentionally paused.
> ** Test coverage was expanded to ensure that both the quantity and type of
> SCTs are checked.
> ___
> 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: Unrevoked/unexpired certificate with Debian Weak Key

[Alex Gaynor via dev-security-policy]

Sorry -- digging into that 500 was on my plate, but there was a logging bug
on errors... and then some poor docs for the framework I'm using... and
before you know it, the yak stack was piled high. I'll cycle around to that
again this evening.

Alex

On Mon, Jun 18, 2018 at 9:53 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/06/18 21:09, Daniel Cater via dev-security-policy wrote:
> > On Monday, 14 May 2018 15:25:43 UTC+1, Rob Stradling
> >> I'm currently running the check against all of the certs on the crt.sh
> >> DB.  I'll report back once this has completed.
> >
> > Hi Rob,
> >
> > Did your checks find anything else in the end?
>
> Hi Daniel.  Thanks for the reminder.  :-)
>
> I found a total of 1,589 certs on the crt.sh DB with Debian weak keys,
> and I did intend to publish a report.  I figured that creating a new
> batch on misissued.com would be the best way to present the data, but
> that gives me an HTTP 500 response whenever I try to submit the list of
> crt.sh IDs.
>
> Until misissued.com lets me submit the list, you can find the list of
> affected certs in a table on the crt.sh DB called "has_debian_weak_key".
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>
> ___
> 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Alex Gaynor via dev-security-policy]

Are you saying that's what actually happened, or that we should all pretend
that's what happened?

Because I don't believe anyone from GoDaddy has made such a claim, and we
ought not put words in their mouths.

Alex

On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 13/04/2018 18:07, Ryan Sleevi wrote:
>
>> Indeed, it was a public demonstration that they'll happily issue, that
>> their stated policies and guidelines disclaim responsibility for the
>> content, but that they will happily revoke anything that is publicly
>> embarassing, even if it is entirely technically correct.
>>
>> Or perhaps it demonstrates the arbitrary, capricious, and opaque nature of
>> what some CAs call "phishing", such as being anything that might be seen
>> (unreasonably so) as embarrassing to them for having issued, so they try
>> to
>> pretend by revocation that it never happened.
>>
>>
> That's not at all what I was saying.  I am saying that the security
> researchers created a (harmless) simulation of how a phishing site could
> game the systems (specifically the US company registry system and the EV
> CA system combined).
>
> The CA's then simulated how they would respond if a real phishing
> site had done the same.  Not because the simulation was embarrassing,
> but simply as the logical continuation of the simulated scenario.
>
> It's like a fire drill where the mayor "pretends" that an old school
> building is on fire, and the firemen then proceed to evacuate the
> building and douse it in enough water to put out a real fire.
>
> Everybody knows it's just a make-believe drill, but they proceed to
> demonstrate their abilities to handle the make-believe situation,
> because doing so is kind of the point of having a drill in the first
> place.
>
> On Fri, Apr 13, 2018 at 12:00 PM, Jakob Bohm via dev-security-policy <
>>
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> My point, and that of some others is that the blunt revocation was a
>>> public demonstation of how that CA would respond to a real phishing
>>> site, thus completing your public demonstration of the problematic
>>> scenario.
>>>
>>
>>
>>
>>>
>>> On 13/04/2018 02:40, James Burton wrote:
>>>
>>> We both work in the security space and yes, usually blocking a proof of
 concept is good practice but in this situation I feel that revoking this
 cert was heavy handed and unnecessary. The probability of Ian using the
 EV
 certs for deceptive purposes was extremely low.

 There are tons more ways of using EV certs for bad purposes.

 James





 On Thu, 12 Apr 2018 at 23:35, Jakob Bohm via dev-security-policy <
 dev-security-policy@lists.mozilla.org> wrote:

 On 12/04/2018 21:20, James Burton wrote:

>
> Both mine and Ian's demonstrations never harmed or deceived anyone
>> as
>>
>> they
>
> were proof of concept. The EV certs were properly validated to the
>> EV guidelines. Both companies are legitimate. So what's the issue?
>> None.
>>
>>
>>
>> In the security space, blocking a proof of concept exploit is usually
> considered the right thing to do.  But doing so in a way that is
> entirely limited to the concrete example rather than the underlying
> problem is considered cheating.
>
> Consider, as an analogy, a hypothetical freedom of speech law whose
> only
> exception was that you must not shout "fire" in a packed theater.  Then
> an actor standing on stage making speech about the silliness of that
> law
> and then shouting "fire", with full warning of the audience to avoid
> panic, should not be surprised to get charged with the specific
> offense,
> as it was a deliberate test of the law.  Of cause, such an actor might
> deserve some leniency in the punishment, such as a $1 fine, but he
> should not be surprised the law is formally upheld.
>
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Alex Gaynor via dev-security-policy]

All that proves is the entire EV model cannot possibly accomplish what CAs
claims (with respect to phishing and other similar concerns). To whit:

- Two companies can validly possess trademarks for the same name in the
United States (and I assume other jurisdictions)
- A CA, or anyone else's ability to tell if the identity collision is being
used maliciously to deceive is totally based on seeing what content is
being served under that name; the reality of trademark law means that two
organizations with the same name is not inherently deceptive
- An actually malicious entity will not broadcast their name collision!
Instead they'd probably have a benign website that normal users see, and at
particular URLs sent to their victims, they'd serve the misleading content.

In conclusion, revoking stripe.ian.sh while ignoring the broader issues WRT
the limitations of EV's binding of real world corporate identity to domain
control is security theater at its worst.

Alex

On Thu, Apr 12, 2018 at 3:23 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Apr 12, 2018 at 2:20 PM, James Burton  wrote:
>
> > Both mine and Ian's demonstrations never harmed or deceived anyone as
> > they were proof of concept. The EV certs were properly validated to the
> > EV guidelines. Both companies are legitimate. So what's the issue? None.
> >
> >
> >
>
> In as far as that they were revoked, these cases seem to demonstrate that
> the CAs wish to vigorously defend the EV "brand" by showing that they can
> and will halt problematic uses of those certificates.  No problem.
> ___
> 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Alex Gaynor via dev-security-policy]

I disagree on what this is evidence of:

It's evidence that the claimed benefits of EV (by CA, WRT phishing) do not
match the technical reality. As Ryan noted, as far as I'm aware this
certificate violates neither the BRs, nor the EVG.

Alex

On Wed, Apr 11, 2018 at 2:48 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Additionally, I think it's fair to say that I'm aghast that another CA
> (who by their inclusion in the Mozilla root program has agreed to stay
> abreast of developments on this list) has issued for the exact same entity
> and name that already led to significant controversy covered on this list
> less than a year ago.
>
> I believe that speaks to inattention to the list or failure to incorporate
> lessons learned from controversies on this list into issuance and/or
> validation practice.
>
> On Wednesday, April 11, 2018 at 1:19:03 PM UTC-5, Ryan Sleevi wrote:
>
> > Could you clarify what you're aghast at?
> ___
> 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: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Alex Gaynor via dev-security-policy]

I think (3) shouldn't be considered any different from (1) -- they're only
meaningfully different if you make a lot of assumptions about how it's
stored and transported at every point from when the HSM signs the TBS to
the certificates final resting place (on someone's disk? in their email
inbox? in a sharepoint that's accidentally publicly accessible?). Once a
cert has been issued, and even more so after it's been transmitted to the
customer, we should not presume anything about how it's stored -- if only
because that'd be a massive burden on CAs, for limited-to-no benefit.

Alex

On Fri, Apr 6, 2018 at 10:27 AM, Tim Shirley  wrote:

> #2 seems like an obvious "no" to me as, at that point, you're only
> compounding a mistake and making that mistake actually usable in the public
> PKI if you proceed to issue the certificate.  In practice I can't imagine
> this scenario coming up much, but the policy shouldn't mandate doing this.
>
> I think there's a third scenario to consider, and that is a case where the
> final certificate was issued but needed to be revoked prior to being put
> into service.  This might be because of mis-issuance, but it might just as
> easily be for another reason.  For example, after obtaining the certificate
> but before installing it, the requestor may discover that the private key
> had been exposed and thus want to get a new certificate with a different
> key.  If we required the final certificate to be CT-logged In that
> scenario, a certificate that was previously only known to the CA and the
> requestor would now be publicly-discoverable, and now the mandatory logging
> policy has made it easier for that exposed private key to be exploited.
> So, while there are certainly advantages to indiscriminately logging all
> final certificates, there are downsides to weigh as well, at least for ones
> not (yet?) deployed on publicly-accessible web servers.
>
> On 4/5/18, 3:08 PM, "dev-security-policy on behalf of Alex Gaynor via
> dev-security-policy"  trustwave@lists.mozilla.org on behalf of dev-security-policy@lists.
> mozilla.org> wrote:
>
> There's two separable questions here:
>
> 1) Should CAs log final certificates after they issue a certificate
> with
> embedded SCTs: My answer, yes.
> 2) Should CAs issue final certificates if they discover they are
> misissued
> after logging the pre-certificate.
>
> The answers to (1) and (2) do not need to be the same.
>
> Alex
>
> On Thu, Apr 5, 2018 at 3:05 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 04/04/2018 04:27, Matt Palmer wrote:
> >
> >> On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via
> >> dev-security-policy wrote:
> >>
> >>> On 02/04/2018 18:26, Tom Delmas wrote:
> >>>
> >>>> Following the discussion on
> >>>> https://scanmail.trustwave.com/?c=4062&d=l_
> TG2r42aQmbn72ySdqaNlBjW-xvJAqoIpJG1bH1_Q&s=5&u=https%3a%2f%2fcommunity%
> 2eletsencrypt%2eorg%2ft%2fnon-logging-of-final-cer
> >>>> tificates/58394
> >>>>
> >>>> What is the position of Mozilla about the submission to ct-logs
> of the
> >>>> final certificate when there is already a pre-certificate?
> >>>>
> >>>> As it helps discover bugs (
> >>>> https://scanmail.trustwave.com/?c=4062&d=l_
> TG2r42aQmbn72ySdqaNlBjW-xvJAqoIsVD1OD1_w&s=5&u=https%
> 3a%2f%2ftwitter%2ecom%2f%5fquirins%2fstatus%2f979788044994834434 ), it
> helps
> >>>> accountability of CAs and it's easily enforceable, I feel that it
> should
> >>>> be mandatory.
> >>>>
> >>>
> >>> If such a policy were to be enacted, an alternative to submitting
> the
> >>> final certificate should be to revoke the certificate in both a
> >>> published CRL and in OCSP.  It would be counter to security to
> require
> >>> issuance in the few cases where misissuance is detected between CT
> >>> Pre-cert logging and actual issuance.
> >>>
> >>
> >> Logging the precert is considered demonstration of intent to issue,
> and is
> >> considered misissuance to the exact same degree as actually issuing
> the
> >> cert.  So revoke or whatever, you still done goofed, and so you
> should be
> >> checking for misissuance *before* you log the precert, not
> afterwards.
> >&g

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Alex Gaynor via dev-security-policy]

There's two separable questions here:

1) Should CAs log final certificates after they issue a certificate with
embedded SCTs: My answer, yes.
2) Should CAs issue final certificates if they discover they are misissued
after logging the pre-certificate.

The answers to (1) and (2) do not need to be the same.

Alex

On Thu, Apr 5, 2018 at 3:05 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 04/04/2018 04:27, Matt Palmer wrote:
>
>> On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via
>> dev-security-policy wrote:
>>
>>> On 02/04/2018 18:26, Tom Delmas wrote:
>>>
 Following the discussion on
 https://community.letsencrypt.org/t/non-logging-of-final-cer
 tificates/58394

 What is the position of Mozilla about the submission to ct-logs of the
 final certificate when there is already a pre-certificate?

 As it helps discover bugs (
 https://twitter.com/_quirins/status/979788044994834434 ), it helps
 accountability of CAs and it's easily enforceable, I feel that it should
 be mandatory.

>>>
>>> If such a policy were to be enacted, an alternative to submitting the
>>> final certificate should be to revoke the certificate in both a
>>> published CRL and in OCSP.  It would be counter to security to require
>>> issuance in the few cases where misissuance is detected between CT
>>> Pre-cert logging and actual issuance.
>>>
>>
>> Logging the precert is considered demonstration of intent to issue, and is
>> considered misissuance to the exact same degree as actually issuing the
>> cert.  So revoke or whatever, you still done goofed, and so you should be
>> checking for misissuance *before* you log the precert, not afterwards.
>>
>>
> Of cause, I am just saying we should not force CAs to make a misissuance
> worse in the rare cases where they /actually/ spot the mistake between
> precert signing and actual cert signing.
>
> Remember, a precert generates only the danger that the cert might be
> issued with an embedded CT proof, all other dangers only materialize if
> and when the cert is actually issued.
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 825 days success and future progress!

[Alex Gaynor via dev-security-policy]

Hi Tim,

I'd have suggested an even shorter period, say 13 months, except I
anticipated CAs would object that it was too great a change too suddenly,
precisely as they did when this subject was last discussed!

While I appreciate that changing BRs can be difficult for customer
communications, the fact that we are doing this in multiple steps instead
of in one fell swoop is a result of CAs saying such a big leap was too
disruptive. Frankly, you can't have it both ways.

Alex

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek 
wrote:

> 18 months is not significantly different from 825 days.   So there's really
> no benefit.
>
> People have to stop wanting to constantly change the max validity period.
> It's difficult enough to communicate these changes to consumers and
> customers, and it really drives them nuts.  I can only imagine what a
> non-integral number of years will do to various company's planning
> and budgeting processes.
>
> I would propose, instead, a minimum one year moratorium on proposals
> to change the max validity period after the previous change to the max
> validity period goes into effect.  That would make much more sense.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Alex
> > Gaynor via dev-security-policy
> > Sent: Monday, April 2, 2018 1:07 PM
> > To: MozPol 
> > Subject: 825 days success and future progress!
> >
> > Afternoon all!
> >
> > A month ago a new BR rule went into effect, putting a maximum validity
> period
> > of 825 days on newly issued certificates.
> >
> > Truthfully, I was expecting tons of CAs to screw up, forget to implement
> it, or
> > have no technical controls, and there to be tons of miss-issuance.
> > To me delight, the results have been pretty good:
> > https://crt.sh/?zlint=1081&minNotBefore=2018-03-01 the majority of
> > violations have been from the US Government (whose PKI isn't remotely BR
> > compliant, nor trusted by Mozilla).
> >
> > In light of this incredible success, I think it's time to begin a
> discussion on what
> > the next in this chain is. While obviously actually encoding this in the
> BRs will
> > be a function of the CABF, as mdsp is the premier public discussion forum
> for
> > the PKI, I wanted to start here.
> >
> > I propose that our next target should be a max validity period of 18
> months
> > (~550 days), starting in ~6 months from now.
> >
> > The value of shorter-lived certificates has been discussed many times,
> but
> to
> > rehash: They afford the ecosystem significantly more agility, by allowing
> us to
> > remove mistakes in shorter periods of time without breaking valid
> certificates.
> > It also encourages subscribers to adopt more automation, which further
> helps
> > with agility.
> >
> > Alex
> > ___
> > 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

825 days success and future progress!

[Alex Gaynor via dev-security-policy]

Afternoon all!

A month ago a new BR rule went into effect, putting a maximum validity
period of 825 days on newly issued certificates.

Truthfully, I was expecting tons of CAs to screw up, forget to implement
it, or have no technical controls, and there to be tons of miss-issuance.
To me delight, the results have been pretty good:
https://crt.sh/?zlint=1081&minNotBefore=2018-03-01 the majority of
violations have been from the US Government (whose PKI isn't remotely BR
compliant, nor trusted by Mozilla).

In light of this incredible success, I think it's time to begin a
discussion on what the next in this chain is. While obviously actually
encoding this in the BRs will be a function of the CABF, as mdsp is the
premier public discussion forum for the PKI, I wanted to start here.

I propose that our next target should be a max validity period of 18 months
(~550 days), starting in ~6 months from now.

The value of shorter-lived certificates has been discussed many times, but
to rehash: They afford the ecosystem significantly more agility, by
allowing us to remove mistakes in shorter periods of time without breaking
valid certificates. It also encourages subscribers to adopt more
automation, which further helps with agility.

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

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

[Alex Gaynor via dev-security-policy]

Mozilla currently doesn't have any policy with respect to Certificate
Transparency, so I think diving in on this particular point is putting the
cart before the horse :-)

Currently Firefox does not check/require SCT presence nor does the Mozilla
root program require certificates to be logged.

Alex

On Mon, Apr 2, 2018 at 12:26 PM, Tom Delmas via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Following the discussion on https://community.letsencrypt.
> org/t/non-logging-of-final-certificates/58394
>
> What is the position of Mozilla about the submission to ct-logs of the
> final certificate when there is already a pre-certificate?
>
> As it helps discover bugs ( https://twitter.com/_quirins/s
> tatus/979788044994834434 ), it helps accountability of CAs and it's
> easily enforceable, I feel that it should be mandatory.
>
>
> ___
> 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: Trustico code injection

[Alex Gaynor via dev-security-policy]

For the Trustico folks:

While I imagine you're quite busy remediating this serious issue: Can you
state whether it would be possible to access any of the private keys you
store using this root shell?

Alex


On Thu, Mar 1, 2018 at 10:28 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> On twitter there are currently some people poking Trustico's web
> interface and found trivial script injections:
> https://twitter.com/svblxyz/status/969220402768736258
>
> Which seem to run as root:
> https://twitter.com/cujanovic/status/969229397508153350
>
> I haven't tried to reproduce it, but it sounds legit.
>
> --
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?

[Alex Gaynor via dev-security-policy]

Is it practical to remove the Symantec root certificates and (temporarily)
add the Google and Apple intermediates to the trust store? This should
facilitate removing trust in Symantec without disruption.

Alex

On Thu, Mar 1, 2018 at 10:15 AM, Kai Engert via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> In my opinion, Mozilla's and Google's plans to distrust the Thawte,
> RapidSSL, GeoTrust, Verisign, and Symantec branded CAs in the browser,
> should be interpreted as a recommendation to eventually distrust them
> for all server authentication uses.
>
> If a CA gets distrusted for https, then I think it's fair to equally
> consider it as no longer acceptable for other services like IMAPS or LDAPS.
>
> As Ryan said in another thread, migration of non-https services might
> take a longer time to migrate. However, based on Jeremy's statement in
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1437826#c3
> I'd assume that the customer certificate migration efforts driven by
> DigiCert should also cover migration of non-https services within a
> reasonable amount of time, where general purpose client software is used
> to connect to non-https services.
>
> (I'm excluding special purpose hardware with embedded restrictions, and
> also excluding manually configured server to server configurations.)
>
> I conclude that for general purpose client software, that doesn't
> implement key pinning and doesn't have restrictions on chain length, but
> which wants to retain the ability to connect to services offered by
> Apple or Google, the whitelisting for Apple/Google subCAs is the only
> hindrance for eventual full distrust of the Symantec Root CAs.
>
> Are the owners of the Apple and Google subCAs able to announce a date,
> after which they will no longer require their Symantec-issued subCAs to
> be whitelisted?
>
> Thanks
> Kai
> ___
> 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: How do you handle mass revocation requests?

[Alex Gaynor via dev-security-policy]

I would say that at the point that Trustico emailed them to DigiCert they
necessarily became compromised -- while Trustico may (or may not) have been
authorized to escrowing the keys by the subscriber, the subscriber did not
authorize them to be emailed around, presumably.

Alex

On Wed, Feb 28, 2018 at 2:29 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > Regarding to our investigation they were only able to send the private
> > keys for those certificates where the CSR / private key pair were
> generated
> > within their online private key generating tool. This has to be the 23k
> > amount of keys which Jeremy received.
> >
> > I am not aware of guidelines of the CA/B forum but keeping 23.000 (!)
> > private keys at your online platform seems more than alarming and is
> > careless and the public should be made aware of this fact.
> >
> > I agree with this sentiment, but I also think it creates another policy
> question with respect to DigiCert's decision to revoke due to key
> compromise: were these 23,000 keys really compromised? The BR definition of
> Key Compromise is:
>
> A Private Key is said to be compromised if its value has been disclosed to
> an unauthorized person, an unauthorized person has had access to it, or
> there exists a practical technique by which an unauthorized person may
> discover its value. A Private Key is also considered compromised if methods
> have been developed that can easily calculate it based on the Public Key
> (such as a Debian weak key, see http://wiki.debian.org/SSLkeys) or if
> there
> is clear evidence that the specific method used to generate the Private Key
> was flawed.
>
> In this case it might be reasonable to argue that Trustico was unauthorized
> (unless their customers agreed to key escrow when using the online key
> generation tool). However, in the case of a hosting provider reselling
> certificates for use on their platform, it's required that they hold the
> private key and we don't consider that a Key Compromise.
>
> - Wayne
> ___
> 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: Allowing WebExtensions to Override Certificate Trust Decisions

[Alex Gaynor via dev-security-policy]

If the "fail verification only" option is not viable, I personally think we
shouldn't expose this to extensions.

I don't think the ability to experiment with new trust models for the web
is worth the price we'd be paying in malicious-extension risk, in
fracturing the ecosystem risk, or in general complexity risk.

Alex

On Wed, Feb 28, 2018 at 11:54 AM, Tom Ritter  wrote:

> On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy
>  wrote:
> > A reasonable compromise that jumps out to me is allowing extensions to
> make
> > an otherwise-secure connection fail, but not allow them to rehabilitate
> an
> > insecure connection. This would allow experimenting with stricter
> controls
> > while avoiding some of the really scary risks.
>
> I'm obviously the person who filed that bug and began this discussion,
> but I think this compromise is one of those compromises where no one
> gets what they want.
>
> Firefox gets a complicated API that gets shimmed into
> security-sensitive code and can disrupt TLS handshakes.
>
> Web Extension developers get something that doesn't do the most
> valuable thing they would like to do: experiment with new Server
> Authentication modes.
>
> Of the examples I gave (Cert Patrol, Perspectives, Convergence, DANE,
> DNSSEC-Stapling) - every single one of them would not actually allow
> experimenting with Server Authentication modes if all they could do is
> reject certificates and not accept them. And in many cases, it will
> completely prevent any such experimentation, because you can't ask a
> CA to sign a cert saying "No really, I just want you to include this
> weird data under this weird not-documented/not-standardized x509
> extension".
>
>
> Unless people show up claiming that that functionality is sufficient
> for them to do things they want to do; I don't think it would be
> valuable to implement this compromise.
>
> -tom
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Alex Gaynor via dev-security-policy]

A reasonable compromise that jumps out to me is allowing extensions to make
an otherwise-secure connection fail, but not allow them to rehabilitate an
insecure connection. This would allow experimenting with stricter controls
while avoiding some of the really scary risks.

Alex

On Tue, Feb 27, 2018 at 11:20 AM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I am seeking input on this proposal:
>
> Work is underway to allow Firefox add-ons to read certificate information
> via WebExtensions APIs [1]. It has also been proposed [2] that the
> WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to
> change or ignore the normal results of certificate validation.
>
> This capability existed in the legacy Firefox extension system that was
> deprecated last year. It was used to implement stricter security mechanisms
> (e.g. CertPatrol) and to experiment with new mechanisms such as Certificate
> Transparency and DANE.
>
> When used to override a certificate validation failure, this is a dangerous
> capability, and it’s not clear that requiring a user to grant permission to
> the add-on is adequate protection. One solution that has been proposed [4]
> is to allow an add-on to affect the connection but not the certificate UI.
> In other words, when a validation failure is overridden, the page will load
> but the nav bar will still display it as a failure.
>
> I would appreciate your constructive feedback on this decision. Should this
> capability be added to the Firefox WebExtensions APIs?
>
> - Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
> [3] https://mail.mozilla.org/pipermail/dev-addons/2018-
> February/003629.html
> [4] https://mail.mozilla.org/pipermail/dev-addons/2018-
> February/003641.html
> ___
> 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: Misissuance/non-compliance remediation timelines

[Alex Gaynor via dev-security-policy]

Hey Tim,

A piece I think I'm missing is what you see as the incentive for CAs to aim
for an "A" rather than being happy to have a "B". It reminds me of the old
joke: What do you call the Dr^W CA who graduated with a C average? Dr.^W
trusted to assert www-wide identity :-)

That said, given the issues Paul highlighted in his original mail (which I
wholeheartedly concur with), it seems the place to focus is the folks who
are getting Ds right now. Therefore I think the essential part of your
email is your agreement that CAs which are persistently low performing need
to be recognized and potentially penalized for the sum total of their
behaviors.

Alex

On Tue, Feb 6, 2018 at 8:30 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Paul,
>
> I understand your frustration.  I've read some of the recent threads about
> "how long does it take to update a CPS?" and clearly there needs to be
> some stronger compliance language in either the BRs or Mozilla policy
> ("CAs MUST be able to update their CPS within 90 days").  And as you note
> such policies need to have teeth otherwise there will be some who will
> just ignore them.
>
> However  negative penalties are not the only thing that should be
> considered.
> Mozilla should also have some way of recognizing CAs that are performing
> above and beyond the minimum requirements.  I would love to see Mozilla
> encourage CAs to compete to be the best CA in Mozilla's program.
>
> To satisfy both goals, I'd like to suggest an idea I've had for a while: at
> some
> point in time (annually?), Mozilla should assess their opinion of how well
> each CA in the program is performing, and give them a letter grade.  This
> could include policy improvements like "Two consecutive failing grades,
> or three consecutive C or lower grades and you're out of the Mozilla
> program."
>
> This would not preclude other actions as Mozilla deems necessary.  But it
> would provide a regular checkpoint for CAs to understand either "Hey,
> you're great, keep up the good work!" or "Meh, we think you're ok." or
> "Your performance to date is unacceptable.  Get your sh*t together or
> you're gone."
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Paul
> > Kehrer via dev-security-policy
> > Sent: Tuesday, February 6, 2018 6:03 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Misissuance/non-compliance remediation timelines
> >
> > A bit over 5 months ago I reported a series of OCSP responders that were
> > violating BRs (section 4.9.10) by returning GOOD on unknown serial
> numbers.
> > Since that time the majority of those responder endpoints have been
> fixed,
> but
> > several are still non-compliant; either with little communication or
> continuing
> > assurances that it will be fixed "soon", where soon is a date that
> continuously
> > slides into the future.
> >
> > At the moment Mozilla possesses very few options when it comes to
> punitive
> > action and the lesson some CAs appear to be learning is that as long as
> you
> > don't rise to PROCERT levels of malfeasance/incompetence then the maximum
> > penalty is censure on bugzilla and email threads. Clearly this is not a
> deterrent.
> >
> > So, how long is too long? At what point should a CA incur consequences
> (and
> > what form can those consequences take) for failure to remediate despite
> being
> > given such immense latitude?
> >
> > As a straw man: what if we developed a set of technical constraints
> related to
> > minimizing risk associated with CAs that are deemed to be acting poorly?
> > For example, CAs deemed a risk would have their certificate maximum
> lifetime
> > constrained to some amount less than the BRs currently allow.
> > Additional penalties could include removal of EV trust indicators,
> constraining
> > trust to a limited set of domains, marking contexts as insecure, and
> finally full
> > distrust. Once a CA lands in a risk category further misissuance would
> escalate
> > their risk to the community and thus incur additional constraints. (I'm
> sure the
> > community can come up with far better tiers than I have!)
> >
> > Adding controls like this will require significant time and effort from
> Mozilla,
> > but if we want to be able to manage the significant and ongoing volume of
> > misissuance/non-compliance we're seeing I believe some level of
> granularity is
> > needed.
> >
> > -Paul (reaperhulk)
> > ___
> > 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-securi

Re: Retirement of RSA-2048

[Alex Gaynor via dev-security-policy]

If I may give a shorter answer than Peter: for authentication purposes (as
used in the WebPKI with non-RSA-key-exchange ciphersuites in TLS) there is
no current deprecation plans for 2048-bit RSA.

Alex

On Sat, Jan 20, 2018 at 12:00 PM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Sat, Jan 20, 2018 at 8:31 AM, James Burton via dev-security-policy
>  wrote:
> > Approximate date of retirement of RSA-2048?
>
> This is a very broad question, as you don't specify the usage.  If you
> look at the US National Institute of Standards and Technology's SP
> 800-57 part 1 rev 4
> (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
> NIST.SP.800-57pt1r4.pdf),
> they discuss the difference between "applying" and "processing".
> Applying would usually be either encrypting or signing and processing
> would usually be decrypting or verifying.
>
> Given that RSA is used by Mozilla products for signing long term data
> (intermediate CA certificates, for example), encrypting data (for
> example, encrypting email), as part of key exchange (in TLS), and for
> signing for instant authentication (signature during a TLS handshake),
> the appropriate retirement date may vary.
>
> That being said, the NIST publication above uses the assumption that
> RSA with a 2048-bit modulus, where the two factors are each 1024-bit
> long prime numbers, provides approximately 112-bits of strength.
> Later on it states that 112-bits of strength is acceptable until 2030.
>
> The German Federal Office for Information Security (BSI) reportedly
> recommends using a modulus length of at least 3000 bits starting in
> 2023 [1].
>
> Does that help answer your question?
>
> Thanks,
> Peter
>
> [1] My German is very poor.  If yours is better than mine, you can
> read the original doc from the BSI at
> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/
> TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile
> and confirm that Google Translate did not cause me to misunderstand
> the recommendation
> ___
> 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: TLS-SNI-01 and compliance with BRs

[Alex Gaynor via dev-security-policy]

I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01
performs a DNS lookup for the ADN, connects to that IP, and initiatives a
TLS connection with the .acme.invalid SNI value.

Certificates don't exist on Domain Names if we think really hard about it,
but servers with IPs that domain names point to can serve certificates, and
that seems like a reasonable interpretation of the intent of that sentence,
which TLS-SNI-01 fulfills.

Alex

On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Now that I'm more familiar with method 9 and 10 domain validation methods
> and heard a few side discussions about the topic, it's made me (and others)
> wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.
>
> The BRs say:
> 3.2.2.4.10. TLS Using a Random Number
> Confirming the Applicant's control over the FQDN by confirming the
> presence of a Random Value within a Certificate on the Authorization Domain
> Name which is accessible by the CA via TLS over an Authorized Port.
>
> But it's my understanding that the CA validates the presence of the random
> number on "random.acme.invalid" and not on the ADN specifically.  Is the
> validation done by confirming the presence of a random number within the
> certificate on the ADN, or some other location?  I'm probably misreading
> the ACME spec, but is sure seems like the validation is not being done on
> the ADN.
>
> Doug
>
> ___
> 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: Updating Root Inclusion Criteria

[Alex Gaynor via dev-security-policy]

Self-assessment is insufficient :-)

That's why we require audits, review issued certificates for technical
violations, and attempt to empower domain owners to identify misissuance.

As we move to a world with greater participation of public CAs in
Certificate Transparency (hopefully 100% eventually), we can increasingly
rely on objective measures to judge across CAs.

Alex


On Thu, Jan 18, 2018 at 4:23 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should
> focus less on the questions of whether a CA
> > is "appropriate" or "deserving" of participation in the Mozilla Root
> > Program, and more on whether they are willing and able to fulfill the
> > expectations of them as a steward of global trust on the internet.
>
> If you ask any applicant "are you willing and able to fulfil what is
> expected of you as a steward of global trust on the Internet?", and they
> know they have to say "Yes" to get in, they will say "Yes". So is the
> upshot of your position that anyone who wants to apply can get in?
>
> 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: Updating Root Inclusion Criteria

[Alex Gaynor via dev-security-policy]

Hi Wayne,

After some time thinking about it, I struggled to articulate what the right
rules for inclusion were.

So I decided to approach this from a different perspective: which is that I
think we should design our other policies and requirements for CAs around
what we'd expect for organizations operating towards a goal of securing the
Internet as a global public resource.

Towards that goal we should continue to focus on things like transparency
(how this list is run, visibility of audit statements, certificate
transparency) and driving technical improvements to the WebPKI (shorter
certificate lifespans, fewer allowances for non-compliant certificates or
use of deprecated formats and cryptography). If organizations wish to hold
themselves to these (presumably higher) standards for what could equally
well be a private PKI, I don't see that as a problem. On the flip side, we
should not delay improvements because CAs with limited impact on the public
internet struggle with compliance.

In summary, I think we should focus less on the questions of whether a CA
is "appropriate" or "deserving" of participation in the Mozilla Root
Program, and more on whether they are willing and able to fulfill the
expectations of them as a steward of global trust on the internet. This has
the nice benefit of aligning well with Mozilla's mission to ensure the
internet is a global public resource, open and accessible to all.

Alex

On Tue, Jan 16, 2018 at 6:45 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I would like to open a discussion about the criteria by which Mozilla
> decides which CAs we should allow to apply for inclusion in our root store.
>
> Section 2.1 of Mozilla’s current Root Store Policy states:
>
> CAs whose certificates are included in Mozilla's root program MUST:
> > 1.provide some service relevant to typical users of our software
> > products;
> >
>
> Further non-normative guidance for which organizations may apply to the CA
> program is documented in the ‘Who May Apply’ section of the application
> process at https://wiki.mozilla.org/CA/Application_Process . The original
> intent of this provision in the policy and the guidance was to discourage a
> large number of organizations from applying to the program solely for the
> purpose of avoiding the difficulties of distributing private roots for
> their own internal use.
>
> Recently, we’ve encountered a number of examples that cause us to question
> the usefulness of the currently-vague statement(s) we have that define
> which CAs to accept, along a number of different axes:
>
> * Visa is a current program member that has an open request to add another
> root. They only issue a relatively small number of certificates per year to
> partners and for internal use. They do not offer certificates to the
> general public or to anyone with whom they do not have an existing business
> relationship.
>
> * Google is also a current program member, admitted via the acquisition of
> an existing root, but does not currently, to the best of our knowledge,
> meet the existing inclusion criteria, even though it is conceivable that
> they would issue certificates to the public in the future.
>
> * There are potential applicants for CA status who deploy a large number of
> certificates, but only on their own infrastructure and for their own
> domains, albeit that this infrastructure is public-facing rather than
> company-internal.
>
> * We have numerous government CAs in the program or in the inclusion
> process that only intend to issue certificates to their own institutions.
>
> * We have at least one CA applying for the program that (at least, it has
> been reported in the press) is controlled by an entity which may wish to
> use it for MITM.
>
> There are many potential options for resolving this issue. Ideally, we
> would like to establish some objective criteria that can be measured and
> applied fairly. It’s possible that this could require us to define
> different categories of CAs, each with different inclusion criteria. Or it
> could be that we should remove the existing ‘relevance’ requirement and
> inclusion guidelines and accept any applicant who can meet all of our other
> requirements.
>
> With this background, I would like to encourage everyone to provide
> constructive input on this topic.
>
> Thanks,
>
> Wayne
> ___
> 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: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Alex Gaynor via dev-security-policy]

It would come at the expense of a more streamlined and secure approach
(e.g. the ALPN proposal on the acme-wg list), which once standardized I
assume Let's Encrypt (and other ACME CAs) would want to fully migrate to.

Alex

On Mon, Jan 15, 2018 at 9:27 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 14/01/18 21:32, jacob.hoffmanandr...@gmail.com wrote:
> > We discussed a similar approach (using CAA) on our community forum,
> > and concluded we don't want to pursue it at this time:
> > https://community.letsencrypt.org/t/tls-sni-via-caa/50172. The TXT
> > record would probably work more widely than CAA, but it would still
> > be encouraging further integration with TLS-SNI-01, when we really
> > want to encourage migration away from it. Right now it's our feeling
> > that the account and renewal whitelisting should mitigate most of the
> > pain of migrating away, but experience and feedback from subscribers
> > will help inform that over time.
>
> Why would you want to continue migrating away if it were based on a
> self-serve whitelist? Would that not re-secure the method?
>
> 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: On the value of EV

[Alex Gaynor via dev-security-policy]

Can you share what the working group has been brainstorming on?

Near as I can tell, this is a validly issued EV cert, for a valid KY
company. If "Stripe, Inc of Kentucky" were in a distinct industry from this
Stripe there wouldn't even be a trademark claim (I'm not a lawyer, etc.).

Lest anyone think "well, they should be able to tell if this was being used
maliciously", there's no reason a clever attacker couldn't make a fake
landing page for their fake Stripe, Inc, while sending phishing emails that
point to various other URLs, which show unrelated phishing contents.

Alex

On Mon, Dec 11, 2017 at 2:14 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> It turns out that the CA/Browser Validation working group is currently
> looking into how to address these issues, in order to tighten up validation
> in these cases.  We discussed it a bit last Thursday, and will be
> continuing
> the discussion on the 21st.
>
> If anyone has any good ideas, we'd be more than happy to hear them.
>
> -Tim
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+tim.hollebeek=
> digicert.com@lists.mozilla
> .org] On Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Monday, December 11, 2017 12:01 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: On the value of EV
>
> Recently, researchers have been looking into the value proposition of EV
> certificates, and more importantly, how easy it is to obtain certificates
> that may confuse or mislead users - a purpose that EV is supposedly
> intended
> to avoid.
>
> James Burton was able to obtain a certificate for "Identity Verified", as
> described in
> https://clicktime.symantec.com/a/1/UMvfjhjcKci8WaOicVRiVWm_
> NzyoAX0Pc2qXQBXjH
> nE=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_
> QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
> FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-
> 3508LqFwnMSFygeNRYQQYxQ02
> VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUV
> KrPl_t11B
> ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7N
> ZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
> yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlv
> ecDTXHAOGDfgwKo7
> DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%
> 3D%3D&u=htt
> ps%3A%2F%2F0.me.uk%2Fev-phishing%2F , which is a fully valid and legal EV
> certificate, but which can otherwise confuse users.
>
> Today, Ian Carroll disclosed how easy he was able to get a certificate for
> "Stripe, Inc", registered within the US, and being granted the full EV
> treatment as the 'legitimate' stripe.com. He's written up the explanation
> at
> https://clicktime.symantec.com/a/1/Fahzn1Xee7EnTLqF7kqdnVFVklYxzL
> F8hiDkGN7kU
> UM=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_
> QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
> FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-
> 3508LqFwnMSFygeNRYQQYxQ02
> VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUV
> KrPl_t11B
> ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7N
> ZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
> yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlv
> ecDTXHAOGDfgwKo7
> DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%
> 3D%3D&u=htt
> ps%3A%2F%2Fstripe.ian.sh%2F
>
> I suppose this is both a question for policy and for Mozilla - given the
> ability to provide accurate-but-misleading information in EV certificates,
> and the effect it has on the URL bar (the lone trusted space for security
> information), has any consideration been given to removing or deprecating
> EV
> certificates?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/kDDKlZK0leEPqVUm7AaittNvNX0qYV
> u4pVG8QnvM6
> 8E=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_
> QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
> FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-
> 3508LqFwnMSFygeNRYQQYxQ02
> VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUV
> KrPl_t11B
> ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7N
> ZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
> yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlv
> ecDTXHAOGDfgwKo7
> DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%
> 3D%3D&u=htt
> ps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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: DigiCert ROCA fingerprint incident report

[Alex Gaynor via dev-security-policy]

Hi Jeremy,

Have all these certificates been submitted to CT?

Thanks!
Alex

On Tue, Nov 7, 2017 at 1:20 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hey everyone,
>
>
>
> Here's the DigiCert incident report about the ROCA fingerprints. Note that
> these were all issued by Symantec (ie, before the transaction closed).
>
>
>
> We became aware of the issue when it was posted to the mailing list.
> However, at that time, the certs were not operated by DigiCert. We became
> aware that DigiCert needed to take action on close (Nov 1).  At that time,
> the new combined team launched an investigation to determine the impacted
> certs. Six certs were identified and revoked:
>
>
>
>
> 4a907fbfc90eb043c50c9c8ace6305a1
>
>
> 8008c178d0d4cd3d79acc09f6ac132c
>
>
> 2dab9a2d40a2f55c5d705551cf7cafe5
>
>
> 306b67f5c25ee0fd495d2be88979eb72
>
>
> 7c7b826b183093ba1e5b9850ac31d806
>
>
> 4c834767e44ecbd0cdef8e60c04dcf32
>
>
>
> These certs were all revoked around Nov 3, within 24 hours of identifying
> the impacted certs at DigiCert.
>
>
>
> Jeremy
>
>
> ___
> 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: Incident Report : GoDaddy certificates with ROCA Fingerprint

[Alex Gaynor via dev-security-policy]

Thank you for writing this up.

Do any of the other CAs with trusted server certificates intend to publish
similar reports? (Based on CT logs that'd be Comodo, Symantec, and
GlobalSign).

Alex

On Tue, Oct 24, 2017 at 12:28 PM, Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Godaddy LLC first became aware of possible ROCA vulnerability exposure on
> Monday October 16th 2017 at 9:30am. The following are the steps we took for
> detection, revocation, and the permanent fix of certificate provisioning:
>
> •   Monday October 16th 2017 AZ, first became aware of the ROCA
> vulnerability.  We downloaded and modified the open source detection tool
> to audit 100% of the non-revoked and non-expired certs we had issued.
> •   Early am Wednesday October 18th AZ we had our complete list of 7
> certs with the ROCA defect. We verified the results and proceeded to start
> the revocation process. While cert revocation was in progress we started
> researching the long-term detection and prevention of the weak CSR
> vulnerability.
> •   Early am Wednesday October 18th Rob Stradling released a list of
> certs with the vulnerability. 2/7 we revoked were on the list.
> https://misissued.com/batch/28/
> •   Thursday October 19th by 2:02am AZ, we completed the 7 cert
> revocations. Revocations included customer outreach to advise the customer
> of the vulnerability.
> •   Thursday October 19th AZ, two CSRs were submitted for commonNames “
> scada2.emsglobal.net” & “scada.emsglobal.net” and were issued. Each
> request had used the vulnerable keys for CSR generation.  We revoked the
> certs again on Thursday October 19th AZ. During this period, we reached out
> to the customer to educate them regarding the vulnerability and informing
> them they needed to generate a new keypair from an unimpacted device.
> Customer was unreachable. Friday October 20thAZ,  another cert was issued
> for commonName “scada.emsglobal.net” using a CSR generated with a weak
> key. We then took measures to prevent future certs from being issued to the
> same common name and revoked the cert on October 20th 2017 AZ.
> commonName   crt.sh-link
> scada.emsglobal.net  https://crt.sh/?id=3084867
>
> scada.emsglobal.net  https://crt.sh/?id=238721704
>
> scada.emsglobal.net  https://crt.sh/?id=238721807
>
> scada2.emsglobal.net https://crt.sh/?id=238720969
>
> scada2.emsglobal.net https://crt.sh/?id=238721559
>
> •   Saturday October 21st 2017 AZ & Sunday October 22nd 2017 AZ, we
> scanned our cert store and identified 0 vulnerable certs.
> •   Monday October 23, 2017 AZ, we have deployed a permanent fix to
> prevent future CSRs generated using weak keys from being submitted. Post
> scanning of the environment concluded 0 certificates at risk.
>
> Below is a complete list of certs under GoDaddy management impacted by
> this vulnerability.
>
> Alias  crt.sh-link
> alarms.realtimeautomation.net  https://crt.sh/?id=33966207
>
> scada.emsglobal.nethttps://crt.sh/?id=3084867
>https://crt.sh/?id=238721704
>https://crt.sh/?id=238721807
>
> www.essicorp-scada.com https://crt.sh/?id=238720405
>
> marlboro.bonavistaenergy.com   https://crt.sh/?id=238720743
>
> scada2.emsglobal.net   https://crt.sh/?id=238720969
>https://crt.sh/?id=238721559
>
> www.jointboardclearscada.com   https://crt.sh/?id=238721242
>
> *.forgenergy.com   https://crt.sh/?id=238721435
>
>
> Regards,
> Daymion Reynolds
> GoDaddy PKI
> ___
> 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

RSA key generation vulnerability in Infineon firmware

[Alex Gaynor via dev-security-policy]

Hi all,

Today researchers announced a vulnerability they discovered in RSA keys
generated by a particular piece of firmware, which allows practical
factorization of the private key given just the public key.

Full details of the research here:
https://crocs.fi.muni.cz/public/papers/rsa_ccs17

There is a publicly available tool for testing keys here:
https://github.com/crocs-muni/roca

I'd encourage CAs to proactive check all of their issued certificates,
particularly S/MIME/client certs, since this affects common smartcard
implementations.

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

Re: Issuing and using SHA-1 OCSP signing certificates

[Alex Gaynor via dev-security-policy]

It also protects consumers of the Mozilla Root Program who are not using it
with a browser -- I know it has been expressed before that that's not a
totally supported use case, but nonetheless it is _extremely_ common to use
a derivative of the Mozilla trust store with verifies like OpenSSL, which
do not limit signature hash algorithms.

Alex

On Sat, Oct 7, 2017 at 3:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 04/10/17 23:38, Nick Lamb wrote:
> > However if I understand the situation correctly, this situation is
> > already very low risk anyway with no reasonable expectation that it
> > could be exploited against a competent SSL/TLS client which for some
> > reason still accepts SHA1 and of course no risk for e.g. modern
> > Firefox which doesn't accepts SHA1 anyway. If I haven't understood
> > (please anyone jump in) then my assessment may be utterly wrong.
>
> Of course, this is an argument for ceasing to regulate SHA-1 issuance at
> all, because no modern browser accepts it, so why bother? But I don't
> think we are quite ready to go there; it does have the useful secondary
> effect of going some way to force obsolete software (like old XP) off
> the Internet.
>
> 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: Public trust of VISA's CA

[Alex Gaynor via dev-security-policy]

https://crt.sh/mozilla-certvalidations?group=version&id=896972 is a very
informative graph for me -- this is the number of validations performed by
Firefox for certs under this CA. It looks like at the absolute peak, there
were 1000 validations in a day. That's very little value for our users, in
return for an awful lot of risk.

Alex

On Tue, Sep 19, 2017 at 11:12 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> In https://bugzilla.mozilla.org/show_bug.cgi?id=1391087 , as part of
> their comments on a report of BR-non-compliant certificate issuance, a
> representative of VISA said the following:
>
> "I would like to share with you some details regarding our PKI System
> and our position within the CA/Browser Forum.  Visa is one of the oldest
> operating Certificate Authorities and is currently a non-voting member
> within the CA/Browser Forum.  Visa has been operating a closed PKI
> system prior to the inception of the Baseline Requirements, which we had
> a number of legacy processes for the issuance and fulfillment of our
> certificates to our clients.  Certificates that are issued by Visa
> public CA’s are issued only to our clients for interconnectivity
> purposes.  Unlike other CA’s and particularly those that have undergone
> your Blink Process, our core business is not PKI.  The certificates that
> were impacted with the noted issues were not issued erroneously to a bad
> actor(s) nor do we issue certificates to the open public. Due to our
> unique PKI system, we are not at liberty to divulge with the public our
> list of impacted clients and their certificates without our Legals'
> consent.
>
> Regarding BR compliance, we completed our initial BR audit in September
> of 2016.  Since that time, we have been addressing the observations
> noted by our external auditors.  This also would encompass any
> certificate issues that have been publically reported.  Understanding
> that such changes in adopting a new process will have business impact,
> it is difficult to provide an accurate timeline of complete compliance
> as we are required to assess the impact to our client and payment
> systems to avoid any operational impact.  We are committed to aligning
> with BR and Mozilla requirements as we have continuously move forward in
> making the necessary changes."
>
> From the above, we see that Visa only issues certificates to their own
> customers/clients, and not to the public. They believe that this permits
> them to keep confidential details of the certificates which they wish to
> have public trust.
>
> The Mozilla Root Store Policy, section 2.1, states:
>
> "2.1 CA Operations. CAs whose certificates are included in Mozilla's
> root program MUST:
> 1) provide some service relevant to typical users of our software
> products; ..."
>
> My memory suggests to me that this clause is normally understood to
> preclude the inclusion of companies who wish to only issue certificates
> to themselves and their customers.
>
> We also see that they are unable to provide a timeline for full BR
> compliance. This is despite various assurances of current compliance to
> Mozilla policies (and thereby the BRs) in various CA communications,
> such as April 2017 and March 2016.
>
> In the light of this, I believe it is reasonable to discuss the question
> of whether Visa's PKI (and, specifically, the VISA eCommerce Root,
> https://crt.sh/?id=896972 , which is the one includes in our store)
> meets the criteria for inclusion in Mozilla's Root Store Policy, and
> whether it is appropriate for them to continue to hold public trust.
> Your comments are welcome.
>
> 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: FW: StartCom inclusion request: next steps

[Alex Gaynor via dev-security-policy]

I'm fairly confused by your answers, if the only thing you tested in
production was CT, why was the system issuing non-compliant certs? Why did
production CT testing come before having established, tested, and verified
a compliant certificate profile?

Alex

On Fri, Sep 15, 2017 at 10:35 AM, Inigo Barreira via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > On 15/09/17 11:01, Inigo Barreira wrote:
> > > Considering that we were distrusted, that we didn´t reapply for
> > > inclussion, that CT is only required by Chrome and it´s not included
> > > in the Mozilla policy (even we were requested that all of our certs
> > > had to be CT logged) nor required by Firefox, that those certs were
> > > under our control all the time and lived for some minutes because were
> > > revoked inmediately, at that time, when we did it, we didn´t expect
> > > this reaction for sure.
> >
> > But surely CT testing is not the only sort of testing you've been doing?
>
> Yes, this is the only test we did it in production
>
> > E.g. you made some test certificates with different types of ECC curve,
> which
> > you then had to revoke some of as against browser policies.
>
> No, those weren´t tests. We allowed the use of curves permitted by the BRs
> but this issue came up in the mozilla policy (I think Arkadiusz posted) and
> I also asked about it in the last CABF F2F (I asked Ryan about it) and
> then, with that outcome and as the browsers didn´t accept them, we revoked
> and then not allow the issuance. I think the discussion is still active
> (i.e. the use of P-521).
>
> > If these had been in a testing hierarchy there would have been no
> problem.
> >
> > CAs have been heavily criticised over the past few years for issuing test
> > certificates in public hierarchies (see e.g. Symantec). The danger of
> doing so
> > should be well known to all CAs by now.
>
> Yes, I know. But the only testing we did in production was the one related
> to the CT.
> >
> > Perhaps once a test has been passed and checked in a testing system, and
> if
> > the certificates concerned do not violate any policies, it could be
> repeated on
> > a production system to deal with any possible differences between the
> two.
> > But starting with the production system is not a good idea.
>
> True, but it seems you´re understanding that we have only a production
> system in which we test everything and this is not the case. Before moving
> anything into production, we have tested in development and in the QA
> system.
> >
> > 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: Certificate with Debian weak key issued by Let's Encrypt

[Alex Gaynor via dev-security-policy]

I'd like to push a bit harder on searching for more systemic remediations.
"We forgot to get around to revoking it" is a pretty common element of CAs'
post-mortems, I think it'd be good for us to dig deeper.

For example, does Let's Encrypt have a runbook that gets used on
misissuance reports? Is one the steps creating a persistent tracking item
(e.g. a bug/ticket/issue) to revoke as required?

I created https://misissued.com/ to assist the mdsp community in tracking
these types of issues. It doesn't have any auth, so obviously anyone can
put whatever garbage they want in (please don't though :-)), but if someone
would find exposing data on a per-CA basis, or as JSON, or something else
useful, I'd be more than happy to.

These are just some off the cuff thoughts, but IMO "human error" should be
a root cause of last resort.

Alex

On Mon, Sep 11, 2017 at 11:08 AM, josh--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This was simple human error. There isn't a programmatic fix.
>
> Our team is planning to scan our database for weak keys again early this
> week. In any case, any weak key certs issued prior to our July 20 fix will
> expire in at most 37 days.
>
> On Monday, September 11, 2017 at 8:24:49 AM UTC-5, Alex Gaynor wrote:
> > Hi Josh,
> >
> > Does Let's Encrypt plan to implement any systematic or programmatic fixes
> > to ensure certificates are promptly revoked in the future?
> >
> > Did you perform a scan of all your issued certificates to see if any
> others
> > were effected?
> >
> > Alex
> >
> > On Sat, Sep 9, 2017 at 8:14 PM, josh--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > Thank you for bringing this oversight to our attention. The
> certificate in
> > > question has been revoked.
> > >
> > > The original incident report from July 16 was accidentally considered
> > > closed on the basis of a fix for our infrastructure without actually
> > > revoking the certificate that led to the report.
> > >
> > > Reading the recorded conversation, it seems we got overly focused on
> fix
> > > for our infrastructure and lost sight of the fact that the certificate
> > > itself needed to be revoked. I imagine our guard was let down a bit by
> the
> > > fact that the cert was issued specifically to test us, it wasn't a
> weak key
> > > "in the wild."
> > >
> > > Let’s Encrypt has checked for some forms of weak keys since we
> launched,
> > > and we added additional checks that would have caught this on July 20,
> > > 2017. We were already in the process of developing and deploying the
> > > additional checks before we received the original report from Hanno.
> > >
> > > On Saturday, September 9, 2017 at 2:22:07 PM UTC-5, Hanno Böck wrote:
> > > > Hi,
> > > >
> > > > A while ago I tested how some CAs would react to certificate requests
> > > > with debian weak keys.
> > > >
> > > > I was able to get a certificate from Let's Encrypt with a debian weak
> > > > key. Here is it:
> > > > https://crt.sh/?id=173588030
> > > >
> > > > I reported this to Let's Encrypt. They told me that they are aware
> they
> > > > weren't checking debian weak keys, but they were in the process of
> > > > deploying a check:
> > > > https://github.com/letsencrypt/boulder/pull/2765
> > > >
> > > > I don't know if this is active by now, but I assume so.
> > > >
> > > > Maybe notable: The certificate hasn't been revoked, despite me
> > > > reporting it. However I haven't explicitely asked for revocation
> (and I
> > > > could revoke it myself, given that I have the private key).
> > > >
> > > >
> > > > I have also tried to get a cert with a debian weak key from the
> > > > free trial offerings from Comodo and Symantec. Both rejected the
> > > > request.
> > > >
> > > > --
> > > > 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
> ___
> 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: Certificate with Debian weak key issued by Let's Encrypt

[Alex Gaynor via dev-security-policy]

Hi Josh,

Does Let's Encrypt plan to implement any systematic or programmatic fixes
to ensure certificates are promptly revoked in the future?

Did you perform a scan of all your issued certificates to see if any others
were effected?

Alex

On Sat, Sep 9, 2017 at 8:14 PM, josh--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thank you for bringing this oversight to our attention. The certificate in
> question has been revoked.
>
> The original incident report from July 16 was accidentally considered
> closed on the basis of a fix for our infrastructure without actually
> revoking the certificate that led to the report.
>
> Reading the recorded conversation, it seems we got overly focused on fix
> for our infrastructure and lost sight of the fact that the certificate
> itself needed to be revoked. I imagine our guard was let down a bit by the
> fact that the cert was issued specifically to test us, it wasn't a weak key
> "in the wild."
>
> Let’s Encrypt has checked for some forms of weak keys since we launched,
> and we added additional checks that would have caught this on July 20,
> 2017. We were already in the process of developing and deploying the
> additional checks before we received the original report from Hanno.
>
> On Saturday, September 9, 2017 at 2:22:07 PM UTC-5, Hanno Böck wrote:
> > Hi,
> >
> > A while ago I tested how some CAs would react to certificate requests
> > with debian weak keys.
> >
> > I was able to get a certificate from Let's Encrypt with a debian weak
> > key. Here is it:
> > https://crt.sh/?id=173588030
> >
> > I reported this to Let's Encrypt. They told me that they are aware they
> > weren't checking debian weak keys, but they were in the process of
> > deploying a check:
> > https://github.com/letsencrypt/boulder/pull/2765
> >
> > I don't know if this is active by now, but I assume so.
> >
> > Maybe notable: The certificate hasn't been revoked, despite me
> > reporting it. However I haven't explicitely asked for revocation (and I
> > could revoke it myself, given that I have the private key).
> >
> >
> > I have also tried to get a cert with a debian weak key from the
> > free trial offerings from Comodo and Symantec. Both rejected the
> > request.
> >
> > --
> > 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PROCERT issues

[Alex Gaynor via dev-security-policy]

I believe it's important to consider more than just the issues themselves,
and to look at a CA's response to the issues. In the past weeks, we've done
a lot of really fantastic work to push CAs on publishing more comprehensive
post-mortems, and several CAs have distinguished themselves with timely
responses and solid analysis of the underlying causes of failures.

In that frame, I want to highlight a few issues that raise serious concerns
to me:

* In responding to issue D, PROCERT displayed a failure to analyze and
understand the issues.
* In responding to issue O, PROCERT once again claimed there wasn't a
problem after evidence has already been provided of the issue. Further,
they appear to have significant challenges maintaining and updating their
PKI software.
* In responding to issue E, PROCERT made several rounds of incorrect
statements about their certificate issuance; they have not substantively
responded to the issue.

I believe that PROCERT's inability to respond to problem reports in a
timely and correct fashion, even more so than the certificate issuance
itself, represents an ongoing practice practice which is not in keeping
with the goals of the Mozilla Root Program.

Alex

On Thu, Sep 7, 2017 at 5:27 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Sep 7, 2017 at 11:17 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Mozilla has decided that there is sufficient concern about the
> > activities and operations of the CA "PROCERT" to collect together our
> > list of current concerns. That list can be found here:
> > https://wiki.mozilla.org/CA:PROCERT_Issues
> >
> > Note that this list may expand or reduce over time as issues are
> > investigated further, with information either from our or our
> > community's investigations or from PROCERT.
> >
> > We expect PROCERT to engage in a public discussion of these issues and
> > give their comments and viewpoint. We also hope that our community will
> > make comments, and perhaps provide additional information based on their
> > own investigations.
> >
> > When commenting on these issues, please clearly state which issue you
> > are addressing on each occasion. The issues have been given identifying
> > letters to help with this.
> >
> > At the end of a public discussion period between Mozilla, our community
> > and PROCERT, which we hope will be no longer than a couple of weeks,
> > Mozilla will move to make a decision about the continued trust of
> > PROCERT, based on the picture which has then emerged.
> >
>
> (Unless stated, wearing a personal hat)
>
> Hi Gerv,
>
> Do you have an anticipated time period for discussion? That is, what
> represents a time for which PROCERT may submit feedback to have it
> considered, and at what point you will consider discussion closed?
>
> Based on the information provided, Issue K represents an unconditional
> security issue, in as much as names such as "autodiscover" and "owaserver"
> are widely-used domains for Outlook Web Access. Many clients attempt to
> access resources at this (unqualified) domain, relying on the combination
> of DNS suffix search and locally-trusted certificates to ensure proper
> resolution. By issuing a publicly trusted certificate for this name - and
> then failing to revoke it - represents a critical security risk and
> arguably a dereliction of responsibility.
>
> Combined with Issue D and Issue G, it is questionable as to how it was ever
> validated, and suggest serious failings over the most critical security
> control of a CA - which is validation of a domain.
>
> Combined with Issue L, Issue Q, Issue R, Issue X, and Issue W, serious
> questions are raised about the oversight and technical ability of the
> staff, as these are indicative of serious control failures.
>
> Outside of Issue K, I would suggest that Issue O and Issue S show a lack of
> awareness of developments in the CA ecosystem, as both of these controls
> were direct responses to widely reported CA security issues. The failure to
> take appropriate steps - or to appreciate the reasons behind such steps -
> are indicative of a systematic misunderstanding of the security function of
> a CA.
>
> On the basis of the sum of these issues, it would seem that the criteria in
> Section 7.3 of Mozilla policy -
> https://www.mozilla.org/en-US/about/governance/policies/
> security-group/certs/policy/
> - is met: "Mozilla will disable or remove a certificate if the CA
> demonstrates ongoing or egregious practices that do not maintain the
> expected level of service or that do not comply with the requirements of
> this 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://

Re: Violations of Baseline Requirements 4.9.10

[Alex Gaynor via dev-security-policy]

Hi Ben,

I'm not sure it should matter that a CA _does_ only issue client certs --
in the DigiNotar-style situation for which this rule was envisioned, the
relevant thing is whether the cert is _capable_ of issuing server certs.

Alex

On Tue, Aug 29, 2017 at 12:43 PM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This CA only issues client certificates:
>
>
>
> DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de
> Certificação Electrónica do Estado, C=PT
>
>
>
>
>
> Ben Wilson, JD, CISA, CISSP
>
> VP Compliance
>
> +1 801 701 9678
>
>
>
>
>
> From: Paul Kehrer [mailto:paul.l.keh...@gmail.com]
> Sent: Tuesday, August 29, 2017 6:48 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Violations of Baseline Requirements 4.9.10
>
>
>
> I've recently completed a scan of OCSP responders with a focus on checking
> whether they are compliant with BR section 4.9.10's requirement: "Effective
> 1 August 2013, OCSP responders for CAs which are not Technically
> Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD"
> status for such certificates." This rule was put in place in the wake of
> the DigiNotar incident as an additional method of ensuring the CA is aware
> of all issuances in its infrastructure and has been a requirement for over
> 4 years now.
>
>
>
> The scan was performed by taking the list of responders (and valid issuer
> name hash/issuer key hashes) that Andrew Ayer has aggregated and making an
> OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef".
> This serial is extremely unlikely to have been issued legitimately.
>
>
>
> The following OCSP responders appear to be non-compliant with the BRs
> (they respond GOOD and are not listed as technically constrained by crt.sh)
> but are embedded in certificates issued in paths that chain up to trusted
> roots in the Mozilla store. I have grouped them by owner where possible and
> put notes about whether they've been contacted:
>
>
>
> AS Sertifitseerimiskeskuse (SK)
>
>
>
> CCADB does not list an email address. Not CC'd.
>
>
>
> DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA,
> emailAddress=p...@sk.ee 
>
> Example cert: https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91e
> aeb4f41f3da6394d78b8c43672d43f4f0f
>
> OCSP URI: http://ocsp.sk.ee/CA
>
>
>
> Autoridad de Certificacion Firmaprofesional
>
>
>
> Email sent to i...@firmaprofesional.com 
>
>
>
> DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068
>
> Example cert: https://crt.sh/?q=cd74198d4c23e4701dea579892321b
> 9e4f47a08bd8374710b899aad1495a4b35
>
> OCSP URI: http://ocsp.firmaprofesional.com
>
>
>
> DN: C=ES, emailAddress=c...@firmaprofesional.com  c...@firmaprofesional.com> , L=C/ Muntaner 244 Barcelona, OU=Consulte
> http://www.firmaprofesional.com, OU=Jerarquia de Certificacion
> Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC
> Firmaprofesional - CA1
>
> Example cert: https://crt.sh/?q=649d5190f9fff58de60313c2f05983
> 93f9dba05368b1dbfe93ec806015fb8796
>
> OCSP URI: http://ocsp.firmaprofesional.com
>
>
>
> DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la
> Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional -
> AAPP
>
> Example cert: https://crt.sh/?q=d4ef928ee32c3838d40e5756b52382
> 9b1dafcd46fd84428ba03d59330a4ae5e7
>
> OCSP URI: http://ocsp.firmaprofesional.com
>
>
>
> CA Disig a.s.
>
>
>
> Email sent to tspnot...@disig.sk 
>
>
>
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification
> Service
>
> Example cert: https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294
> de19e441dcaa6913627261752199c302a2
>
> OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
>
>
>
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification
> Service
>
> Example cert: https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1
> ce0dcfab170e007e551f63231c76975417
>
> OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2
>
>
>
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1
>
> Example cert: https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df0
> 3a507e346b9716442463ed61106aff6947
>
> OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
>
>
>
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2
>
> Example cert: https://crt.sh/?q=239ffa86d71033ba255914782057d8
> 7e8421aedd5910b786928b6a1248c3e341
>
> OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
>
>
>
> certSIGN
>
>
>
> Email sent to off...@certsign.ro 
>
>
>
> DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN
> Enterprise CA Class 3 G2
>
> Example cert: https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1
> b0bf266fa205a140b1bc1d340ff4ff6355
>
> OCSP URI: http://ocsp.certsign.ro
>
>
>
> DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA
>
> Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d
> 987c58dc4e11bbe04

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Alex Gaynor via dev-security-policy]

Hi Arno,

Tools like https://github.com/alex/ct-tools or
https://github.com/grahamedgecombe/ct-submit can be used to manually submit
specific certificates to CT logs.

Alex

On Thu, Aug 17, 2017 at 9:07 AM, Arno Fiedler via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Am Montag, 14. August 2017 18:44:59 UTC+2 schrieb Jonathan Rudenberg:
> > Hi Arno and Martin,
> >
> > > On Aug 14, 2017, at 11:44, Arno Fiedler 
> wrote:
> > >
> > > Dear Forum,
> > >
> > > since the 07-07-2017, all new issued D-TRUST TLS-Certificates have at
> least 64 bits of entropy in the serial number.
> > >
> > > Since 01-12-2016 D-TRUST TLS certificates requested via our enterprise
> platform have a serial number which includes at least 64 bits of entropy.
> We informed the CA-Program Manager about the 3 Month delay in moving the
> entropy from the "DNqualifier” to the “SerialNumber” via eMail on 27-10-16.
> >
> > Does this mean that you knew you would not be complying with Ballot 164
> / BRs 1.3.7 by the effective date of 2016-09-30? When did you realize this?
> Did you receive permission for this non-compliance from the relevant
> Application Software Suppliers, including Mozilla?
> Answer:
> We realized that there were problems with the implementation of Ballot 164
> in September 2016 and we informed the Rootstore/Browser Provider via email
> on 2016-10-27 that we  would be delayed until December 2016.
> We believed ourselves to be compliant with Ballot 164 from 2016-12-01 when
> we implemented it into our enterprise platform. However, on 2017-08-07, we
> received knowledge about the case.
>
> > > Between 2012 and 06-07-2017 we still produced a smaller number of
> certificates using our retail platform with additional entropy in the
> “DNqualifier” field instead of the serial number field, because our
> certified third party software was not able to handle long serial numbers
> earlier.  We defined this issue as minor nonconformity, because the
> requirement for entropy in the certificate was fulfilled.
> >
> > What other issues have you defined as a "minor nonconformity"?
> Answer:
> We didn´t detect any other minor nonconformity. In general we work with an
> accreditation scheme based on ISO 27 and EN 319 403 to implement the
> requirements from Root-Policies, CA/B-Forum Guidelines, eIDAS-Regulation
> and ETSI Policies, there are defined audit procedures to recognize, control
> and remediate nonconformities under the supervision of the certification
> audit body
> >
> > > On 20-07-17 Mozilla asked D-TRUST for clarification, due to the
> holiday period this message reached us on 07-08-17, AF answered on 08-08-17
> and 10-08-17: “the certificate has 64 bits of entropy in the "DNqualifier"
> field instead of the serial number field. Since 2012 we used this way of
> adding random bits to certificates to mitigate preimage attacks. From a
> security perspective the amount of Entropy in the certificate should be
> reasonable”.
> > >
> > > On 10-08-2017 we got the information, that we issued in the Individual
> Certificate Registration process a certificate with less entropy than 64
> bit, Jonathan reported “The DNqualifier appears to have a 33-bit number,
> not a 64-bit number”.
> > >
> > > On the 11-08-2017 we defined this case as a major issue, because our
> internal examinations confirmed, that just using numeric characters causes
> entropy less than 64 bit.
> > >
> > > The review with our tool “PKI-watcher” gave the following result of
> effected certificates:
> > > D-TRUST SSL Class 3 CA 1 2009 (607)
> > > D-TRUST SSL Class 3 CA 1 EV 2009 (63)
> >
> > To provide transparency, can you please add all of these certificates to
> at least one CT log and post the serial numbers, certificate fingerprints,
> or crt.sh IDs?
> Answer:
> We have implemented the CT logs into our EV production process and are
> currently unaware about how to manually export specific certificates to a
> log; we will publish the affected certificate serial numbers immediately
> via *.csv. Please advise us about the receiver.
> A new certificate – instead of “www.lbv-gis.brandenburg.de/lbvagszit” –
> has been issued, the old one is revoked.
> Arno
>
> >
> > Jonathan
>
> ___
> 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 less than 64 bits of entropy

[Alex Gaynor via dev-security-policy]

Have they fixed whatever issue there is with their PKI infrastructure that
leads to this issue? From skimming, I see this pool contains certs issued
as recently as one month ago.

Alex

On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> With regard to Siemens, given the large number of certificates and the
> disruption that massive revocations will have on their infrastructure, what
> does this community expect them to do?
>
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-bounces+ben=
> digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley via
> dev-security-policy
> Sent: Thursday, August 10, 2017 12:01 PM
> To: Jonathan Rudenberg ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Certificates with less than 64 bits of entropy
>
> Hi Jonathan,
>
> InfoCert's sub CA was revoked on August 1, 2017. We'll reach out to
> Siemens. They moved to Quovadis a while ago and are no longer issuing from
> that Sub CA.
>
> Jeremy
>
> -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: Thursday, August 10, 2017 9:26 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with less than 64 bits of entropy
>
>
> > On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > QuoVadis (560)
> >Siemens Issuing CA Internet Server 2016 (560)
> >
> > D-TRUST (224)
> >D-TRUST SSL Class 3 CA 1 2009 (178)
> >D-TRUST SSL Class 3 CA 1 EV 2009 (45)
> >D-TRUST Root Class 3 CA 2 EV 2009 (1)
> >
> > DigiCert (85)
> >Siemens Issuing CA Class Internet Server 2013 (82)
> >InfoCert Web Certification Authority (3)
> >
> > Izenpe S.A. (62)
> >EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)
> >
> > Government of The Netherlands, PKIoverheid (Logius) (55)
> >Digidentity Services CA - G2 (55)
> >
> > Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
> >Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4 (38)
>
> It looks like my summary missed one QuoVadis intermediate:
>
> Bayerische SSL-CA-2016-01 (3)
>
> ___
> 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: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

[Alex Gaynor via dev-security-policy]

Hi Josh,

Given that these were all caught by cablint, has Let's Encrypt considered
integrating it into your issuance pipeline, or automatically monitoring
crt.sh (which runs cablint) for these issues so they don't need to be
caught manually by researchers?

Alex

On Thu, Aug 10, 2017 at 11:00 PM, josh--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> At 11:30am PST on August 10, 2017, Let’s Encrypt was made aware of a
> compliance issue regarding unicode normalization of domain names. During
> the same day we were made aware of the issue, all unexpired non-compliant
> certificates were found and revoked, a fix was applied to our CA systems,
> and we communicated with our community. We consider the matter to be fully
> resolved at this point, please let us know if we missed anything.
>
> We were notified by a community member that Let's Encrypt had issued a
> number of certificates containing punycode domain names which had not
> undergone compliant unicode normalization. We confirmed that this was the
> case and began investigating our code and the relevant RFCs.
>
> We noticed that the code we added to check the validity of punycode
> encodings in CSRs when we implemented support for IDNs didn't enforce any
> form of Unicode Normalization. We started developing a fix. After seeking
> outside insight into the issue and reading the relevant reference documents
> we came to the conclusion that Normalization Form KC was required. The BRs
> reference RFC 5280, which in turn references the encoding specified in RFC
> 3490 for IDNs, which requires Normalization Form KC. We finished our fix
> and deployed it to our CA at 5:20PM PST.
>
> While developing the fix we searched our issuance databases for all
> unexpired certificates containing punycode DNS names and checked them for
> non-NFKC compliant names. We found 16, which are listed below. We revoked
> these certificates and notified the subscribers who requested them.
>
> I would like to thank the community members that discovered this issue, as
> well as the Let's Encrypt team that worked hard to resolve it quickly.
>
> --
> Josh Aas
> Executive Director
> Internet Security Research Group
> Let's Encrypt: A Free, Automated, and Open CA
>
> Serial numbers of affected and revoked certificates:
>
> 03d03877cbcec666b81340ed6a39c47556d1
> 03758d04a7816ba893847658e636a58e1f71
> 03ef82538ca2e54e97ae2b180ecb32f8cee4
> 044568f36455d8847713adb24c69e60bf123
> 033e73ebfd2f270bc6109925f1ed40edca8b
> 038295d240613cdb9367506c0d3cf8002401
> 03556fbc38b13ea3a9b7f4dd59dacc350293
> 030cfe12721e17ca02c095b4a0c5e60ca8da
> 03ca6617e634f2f5ad9224ca32ca4c835909
> 03bd090cfe0fbd07b4fc60df07bbc5770b35
> 0314017b4eab87bb0f211e9e2bb329ca4297
> 03f48a8c02c473ce971236b6407ad7d00d89
> 03bfa7b8f318a30a88894523ebd2717ea9b4
> 032d7c46b0a815faa41a1876fed4d66a9993
> 039f94badc798eea44f8c81ceb0515024871
> 038f81a32455e41b702ffb1732186be3a007
> ___
> 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

[Alex Gaynor via dev-security-policy]

This is a great point, re:automated issuance systems like ACME. I've
suggested to the Let's Encrypt folks the idea of a "should I re-issue"
endpoint that clients can poll. This would give CAs a programatic ability
to broadcast to subscribers that they should reissue now because the cert
is about to be revoked (or because they want to shift which SCTs are
embedded, or to indicate an appropriate renewal period for short lived
certs, or... turns out there are a lot of use case!) and then automatically
revoke at the end of the defined period.

Hopefully something useful comes out of that :-)

Alex

On Thu, Aug 10, 2017 at 7:11 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Not really - most CAs reuse validation information for the time period
> specified under the BRs, which is currently 825 days under section 4.2.1.
> The hardest part of the whole process is typically contacting the customer
> to start the replacement process. The problem is probably worse for fully
> automated CAs who don't necessarily have a close relationship with the
> customer, perhaps only an email address that can be used to let them know
> their website is about to go down.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=
> digicert.com@lists.mozilla
> .org] On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Thursday, August 10, 2017 3:40 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with invalidly long serial numbers
>
> But that would require the issuer of the replacement cert (which might not
> be a fast-issue DV cert) to complete validation in something like 36 hours,
> which is much shorter than the normal time taken to do proper OV and/or EV
> validation.
>
> I have previously suggested 14 days for live certificates that don't cause
> actual security issues.  This would be enough for most subscribers to
> either
> get a reissued certificate (for free) from the original CA or set up an
> account with a competing CA and get at least a basic OV cert.
>
> On 10/08/2017 03:02, Jeremy Rowley wrote:
> > 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.m
> > ozilla .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.
> >
>
>
> 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 Ma

Re: Misissued certificates

[Alex Gaynor via dev-security-policy]

My apologies, it was pointed out to me off list that two of these are
pre-certs for other certs in that batch.

Alex

On Thu, Aug 10, 2017 at 12:19 PM, Alex Gaynor  wrote:

> Hi IdenTrust,
>
> When you say that the remaining two are pre-certificates, are you
> asserting that no corresponding certificate was ever issued? Or merely that
> we can't prove one was based on what's in the existing CT logs?
>
> Alex
>
> On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee 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&opt=cablint
>> > > https://crt.sh/?id=77947625&opt=cablint
>> > > https://crt.sh/?id=78102129&opt=cablint
>> > > https://crt.sh/?id=92235995&opt=cablint
>> > > https://crt.sh/?id=92235998&opt=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
>> > >
>> We aware of this situation and had previously introduced logic into our
>> certificate authority that a pathLengthConstraint will never be set for a
>> certificate other than a CA.  We have confirmed that only the stated
>> five (5)
>> certificates contain the issue.  Three (3) of these are real certificates;
>> however, one has expired. We have revoked the other two certificates. The
>> remaining two (2) are pre-certificates.
>>
>> ___
>> 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

[Alex Gaynor via dev-security-policy]

Hi IdenTrust,

When you say that the remaining two are pre-certificates, are you asserting
that no corresponding certificate was ever issued? Or merely that we can't
prove one was based on what's in the existing CT logs?

Alex

On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee 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&opt=cablint
> > > https://crt.sh/?id=77947625&opt=cablint
> > > https://crt.sh/?id=78102129&opt=cablint
> > > https://crt.sh/?id=92235995&opt=cablint
> > > https://crt.sh/?id=92235998&opt=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
> > >
> We aware of this situation and had previously introduced logic into our
> certificate authority that a pathLengthConstraint will never be set for a
> certificate other than a CA.  We have confirmed that only the stated
> five (5)
> certificates contain the issue.  Three (3) of these are real certificates;
> however, one has expired. We have revoked the other two certificates. The
> remaining two (2) are pre-certificates.
>
> ___
> 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

[Alex Gaynor via dev-security-policy]

As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.

Without speaking to particular revocation timelines, I expect CAs to be
fixing the bugs in their issuance pipelines that allowed these
non-compliant certs to be issued, and I expect them to send post-portems to
mdsp explaining what the root cause for these issues was and how they
corrected it.

Alex

On Wed, Aug 9, 2017 at 8:37 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, 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.
> > 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.
>
> In one of the few times I think it's happened, I think I disagree with
> you, Peter.
>
> I appreciate the perspective that revocation of these certificates
> externalizes the cost of misissuance from the CA (responsible for it) onto
> the customer (who purchased the certificate), and thus a viewpoint that
> suggests this is somehow unjust (since it's the victim of misissuance who
> suffers), but I think an argument that suggests these shouldn't be revoked
> is similar to an argument that says those who purchased stolen merchandise
> should get to keep it, as long as they didn't know it was stolen.
>
> That is, if we look at it from a lens of incentives, CAs have little
> incentive to properly issue the certificates if the consequence of
> misissuance is not an immediate result, but one of potential future action.
> Sadly, humans are terrible at recognizing those potential long-term costs
> (c.f. obesity/heart disease/dental care/global warming as all examples of
> long-term costs with short-term benefits).
>
> While I don't disagree we should keep a scoreboard, I think it's also the
> right incentive - for CAs, and the overall ecosystem - to ensure that any
> misissuance is revoked in a timely fashion (which is currently 24 hours),
> because it helps encourage a market where the best step a CA can take to
> minimize risk to their subscribers, the ones actually paying them money and
> engaging in a business relationship with them, is to simply not misissue
> the certificates.
> ___
> 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

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&opt=cablint
https://crt.sh/?id=77947625&opt=cablint
https://crt.sh/?id=78102129&opt=cablint
https://crt.sh/?id=92235995&opt=cablint
https://crt.sh/?id=92235998&opt=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 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

[Alex Gaynor via dev-security-policy]

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.

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.
>>> - Certificate issued to someone who should not have it (like the github
>

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

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.
> - Certificate issued to someone who should not have it (like the github
>  certs issued by WoSign): 24 hour revocation, faster if possible.
> - Certificate that violates rules and triggers a bug preventing Mozilla
>  NSS from detecting if it is revoked: 24 hour revocation and adding
>  special case code to NSS to treat this form of certificate as not valid
>  instead of non-revocable.
> - Certificate issued in such a way as to increase the risk of
>  post-issuance attacks (such as SHA-1 cert issued in 2016 or later with
>  insufficient random bits near the start of the TBSCertificate): 24 hour
>  revocation of cert itself, issuing SubCA revoked with 2 month delay to
>  replace affected good certificates from a new clean SubCA.
> - Single Certificate that violates rules, but

Re: Miss-issuance: URI in dNSName SAN

[Alex Gaynor via dev-security-policy]

Hi all,

Following up on this thread, 8 days ago I emailed Camerfirma, I have not
heard back from them, nor have they taken any action. What is the
appropriate next step here?

Alex

On Mon, Jul 31, 2017 at 10:14 AM, Alex Gaynor  wrote:

> I've been attempting to report a bunch of miss-issued certificates this
> weekend (hobbies are important!) I've primarily been using
> https://ccadb-public.secure.force.com/mozillacommunications/
> CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC&QuestionId=
> Q00028 as my reference (without which I would be totally lost!)
>
> So far I've encountered issues with:
>
> - DocuSign (OpenTrust/Keynectis) - who neglected to fill out that field
> - StartCom - who filled out "web publication", I don't know what that means
>
> To all the CAs who included a straightforward email or webform in there,
> thank you!
>
> Alex
>
> On Mon, Jul 31, 2017 at 10:10 AM, Gervase Markham via dev-security-policy
>  wrote:
>
>> On 25/07/17 18:13, Jeremy Rowley wrote:
>> > I would also love to see a more standardized notice mechanism that is
>> > universal to all CAs. Right now, notifying CAs is a pain as some have
>> > different webforms, some use email, and some don't readily tell you how
>> to
>> > contact them about certificate problems.
>>
>> "Not readily telling" is a BR violation; if you come across a CA like
>> that, please do let us know. The info should be in the CCADB and in the
>> CAs report.
>>
>> I agree it would be nice to have something more standard, but we have
>> what we have right now.
>>
>> 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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Alex Gaynor via dev-security-policy]

Luckily we have tools like certlint, which can be run on certificates to
catch this stuff!

I'd feel very differently if CAs were starting these threads because they'd
caught issues with certlint, than the fact that independent researchers are
noticing.

Alex

On Tue, Aug 8, 2017 at 7:52 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 08/08/2017 12:54, Nick Lamb wrote:
>
>> On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm  wrote:
>>
>>> Since the CT made it possible, I have seen an increasing obsession with
>>> enforcing every little detail of the BRs, things that would not only
>>> have gone unnoticed, but also been considered unremarkable before CT.
>>>
>>
>> Even if I had no other reason to be concerned about violations of the BRs
>> (and I do have plenty, as we saw here in this case it looks like the
>> certificate can be revoked but it effectively can't) the Brown M&M Rider
>> reason is enough,
>>
>> The rider (hospitality and technical requirements for a performing
>> artist) can be pretty detailed, some venues may glance at it and agree to
>> whatever is inside without knowing the details. This is a _huge_ problem,
>> and Van Halen is famous for a clause in their rider (requiring a bowl of
>> M&Ms but with the brown ones removed) which they say existed not out of
>> spite but precisely to check that the venue had actually read the rider in
>> full and not just skimmed it, so that they would have early warning if a
>> particular venue were sloppy and might cause surprise problems with
>> technical implementation.
>>
>> We need CAs to be detail oriented. It is not enough to "kinda, mostly"
>> get this job right. If you can't do _exactly_ what it says in the BRs,
>> don't bother doing it at all. Neither Mozilla nor any other trust store
>> compel CAs to stay in this business, if they decide they'd rather sell
>> pancakes or mow lawns, that's up to them. So long as they want to be
>> trusted public CAs, they need to obey the rules that are in place to make
>> that safe for everybody.
>>
>>
> While the Brown M&M Rider argument would be good if, like the van Halen
> clause, there was only a small number of such intentional gotcha rules,
> in this case we are dealing with a large corpus of rules, some explicit,
> some in documents referenced from other documents etc.
>
> That makes the situation much more like the situation with other large
> sets of rules for people to follow, which means that there will, in
> practice, always be rules more important than others.  And hence a
> natural expectation that those tasked with enforcing the rules actually
> know the difference and don't issue large penalties for what is
> obviously minor infractions.
>
> Now in this *specific* case, it has been found that Mozilla's NSS
> doesn't handle HTTPS OCSP URLs in a good way, and thus Mozilla has a
> specific need to prevent their public use until NSS gains the ability to
> handle them safely (because there is a benefit to it).  Discussing that
> benefit and planning appropriate transition plans is an issue for
> another thread, possibly in another forum.
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

This methodology of "letting everyone decide which parts of the spec/BRs
aren't important" doesn't make sense. If there's something wrong with the
spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of
the "fetch" specification). Giving each CA unilateral authority to ignore
what they want is not how we get to a cleaner, better, more secure, spec or
PKI. BTW, the reason you know they were unilaterally ignoring things is
that this thread was started by an independent security researcher, and not
by the CAs in question!

If the CAs had noticed themselves, they could have sent an email to
m.d.s.p, "Hey, we noticed some of our certs were triggering warnings on
crt.sh, we looked into and it's because of an encoding issue with large
serials. We're revoking those certs, and looking into the bug in our
issuance code, but we're pretty sure this happened because the text in RFC
5280 is a bit vague, can we do something to make this more clear?"

Alex

On Mon, Aug 7, 2017 at 9:25 PM, Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan Sleevi via dev-security-policy 
> writes:
>
> >>Pragmatically, does anything known break on the extra byte there?
> >
> >Yes. NSS does. Because NSS properly implements 5280.
>
> I would say that's probably more a flaw in NSS then.  Does anyone's
> implementation seriously expect things to work, and by extension break if
> they
> don't, as 5280 says it should?  What happens to NSS if it sees a policy
> explicitText longer than 200 bytes?  If it sees a CRL with an unknown
> critical
> extension?  If it sees a CRL with one of the extensions where you ignore
> the
> actual contents of the CRL and instead use revocation information hidden
> in a
> sub-extension (sorry, can't remember the name of that one at the moment).
>
> That's just the first few things that came to mind, there are a million
> (well,
> thousands.  OK, maybe hundreds.  At least a dozen) bizarre, arbitrary, and
> often illogical requirements (for example with the critical extension thing
> the only sensible action is to do the opposite of what the RFC says) in
> 5280
> that I'm pretty sure NSS, and probably most other implementations as well,
> don't conform to, or are even aware of.  So saying "it happens to break our
> code" is a perfectly valid response, but claiming better standards
> conformance
> than everyone else is venturing onto thin ice.
>
> More generally, I don't think there's any PKI implementation that can
> claim to
> "properly implement 5280" because there's just too much weird stuff in
> there
> for anyone to fully comprehend and be conformant to.  As a corollary, since
> there are also things in there that are illogical, a hypothetical
> implementation that really was fully conformant could be regarded as broken
> when it does things that the spec requires but that no-one would expect an
> implementation to do.
>
> Peter.
> ___
> 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

[Alex Gaynor via dev-security-policy]

You seem to be suggesting that the thoroughness of testing is somehow
related to how long it takes.

I'd expect any serious (or even not particularly serious...) to have a
comprehensive automated test suite that can verify that the software is
regression free and correct in minutes or hours. If you can't deploy
changes of any size with confidence in less than several months, I think
you have some serious process problems.

Alex

On Mon, Aug 7, 2017 at 4:09 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 07/08/2017 18:07, Hanno Böck wrote:
>
>> On Mon, 7 Aug 2017 15:59:07 +
>> Ben Wilson via dev-security-policy
>>  wrote:
>>
>> FWIW - In the case of Telecom Italia, they have a commercial CA
>>> product has a bug in it that occasionally causes this issue.  They
>>> may need some time for the software to be fixed/replaced.
>>>
>>
>> I'm more worried by this statement than by the actual bug.
>>
>> If you're a CA and are not able to fix a bug in your product in a timely
>> manner then you probably shouldn't be a CA.
>>
>>
> If you are a CA or serious CA software vendor, you should not install
> non-essential patches without a very long and thorough testing process.
>
> Since this is (at most) a formal violation and not a security problem,
> it is better for the fix to go through many month of careful testing
> than to rush it through.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with common names not present in their SANs

[Alex Gaynor via dev-security-policy]

Sorry, you're right -- I'd misunderstood the issue with Python. (FWIW, I'm
one of the maintainers of the Python ssl module, and I anticipate us having
a fix for IDNs by the next release).

Alex

On Sun, Aug 6, 2017 at 8:38 PM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> "simply" how?
>
> If it's your belief that the Python code actually does work for IDN SANs I
> think you're going to need to do better than just asserting that it's
> "simply" so in the face of subject experts saying it's broken.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Alex Gaynor via dev-security-policy]

I think it's reasonable to consider mistakes in StartCom's new PKI of this
nature to be a part of "continuing pattern of behavior" from their previous
PKI, and not something which should be considered in isolation. In that
context, I'm not sure comparisons with other CAs which were "first time
offenders", and which were given an opportunity to clean up, make sense.

Alex

On Thu, Aug 3, 2017 at 4:43 PM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, August 3, 2017 at 9:49:41 AM UTC-7, Jonathan Rudenberg wrote:
> > Even absent the BR-violating certificates and disclosure timeline, I
> believe this cross-sign is problematic because it appears to circumvent the
> prerequisites and process described in https://bugzilla.mozilla.org/
> show_bug.cgi?id=1311832 for StartCom’s application for re-inclusion into
> the Mozilla root store. It’s not clear to me what the point of those
> requirements is if they can be avoided by obtaining cross-signatures from
> other CAs that are currently trusted by Mozilla.
>
> It is common practice for a CA to get cross-signed by a currently-included
> CA, so their cert chain is trusted while they are going through Mozilla's
> long inclusion process. This is OK, as long as the currently-included CA
> ensures that the subCA follows Mozilla's Root Store Policy.
> See section 5.3 of
> https://www.mozilla.org/en-US/about/governance/policies/
> security-group/certs/policy/
>
> I would have a problem if Certinomis cross-signed with the old StartCom
> roots for which we do not trust certs issued after October 2016. In my
> opinion, that would be grounds for removing Certinomis' roots.
>
> However, I think it is fine for Certinomis to cross-sign with new StartCom
> subCA certs, as long as Certinomis ensures that Mozilla's Root Store Policy
> is being followed.
>
>
> > As far as the misissued certificates are concerned, here are a couple
> points to consider:
> >
> > 1) Many of the certificates are improperly validated “test”
> certificates, a practice that is extremely problematic and indicates a lack
> of or circumvention of technical controls.
>
>
> Yes, this is problematic. But other CAs have also had this problem, and
> for the other CAs we have worked with them to ensure the practice is
> stopped, tools/process put in place to prevent it in the future,
> problematic certs revoked, etc. But this type of mis-issuance has not yet
> been considered grounds for adding the relevant intermediate cert to OneCRL.
>
>
> > 2) StartCom's systems are apparently new, but they have failed to
> correctly implement simple aspects of the certificate profile such as
> keyUsage bits and character encodings. These issues are trivially detected
> by running tools like certlint and should have been caught well before the
> system made it into production.
>
>
> This is the part that particularly concerns me. I would expect StartCom to
> be on their best behavior and setting up an exemplary PKI. These types of
> mistakes should not be happening. This is the main reason I am considering
> adding the two intermediate certs to OneCRL and telling the CA to start
> over, and make sure they do it right this time.
>
> Thanks,
> Kathleen
> ___
> 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: Certificate with invalid dnsName issued from Baltimore intermediate

[Alex Gaynor via dev-security-policy]

Ouch. Thanks for clarifying.

Alex

On Thu, Aug 3, 2017 at 10:46 AM, Ben Wilson  wrote:

> There are over 300 publicly visible servers, according to Censys.IO.
>
>
>
> *From:* Alex Gaynor [mailto:agay...@mozilla.com]
> *Sent:* Thursday, August 3, 2017 8:42 AM
> *To:* Ben Wilson 
> *Cc:* Nick Lamb ; mozilla-dev-security-policy@
> lists.mozilla.org
>
> *Subject:* Re: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
>
>
> If I'm reading this correctly, these certificates are for internal
> services, not publicly accessible. Could they add their intermediate
> directly to these trust stores, allowing you to revoke it?
>
>
>
> Failing that, it sounds like OneCRL would be an appropriate remedy.
>
>
>
> Alex
>
>
>
> On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> Nick and Mozilla Community,
>
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:
>
> Good Evening Ben,
>
>About the problem with the certificate you recently notified us, I
> confirm you that we have replaced the certificates today, so we have now
> revoked the wrong one.
>
> Concerning the CA revocation, first of all, I want to underline that for us
> it would be a major issue: we don't have enough time and resources to
> replace all the certificates before the end of the year and the revocation
> of the CA will cause us several critical operating problems with our
> infrastructural services.
>
> Moreover, I would like to inform you that in order to rationalize our
> infrastructure and create new synergy between our suppliers, we've planned
> to move our certificates to an Italian CA outsourcer. We have already
> started this activity and our intent is to complete the migration before
> the
> end of the year, to respect the contract we have settled, with deadline
> December, 31st 2017.
>
> Therefore I have to kindly recommend you not to revoke the CA, before the
> end of the contract, because it will cause several problems to the Bank and
> to our users (customers and colleagues).
>
> We are available to set up a call conference with you to discuss the
> matter.
> Looking forward to hear from you.
>
> Best regards,
> Riccardo D'Agostini
>
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
>
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, August 3, 2017 7:33 AM
> To: Nick Lamb ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:34 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> > Nick,
> > We are in discussions with Intesa Sanpaolo about implementing/pursuing
> > OneCRL or a similar approach (e.g. outright revocation of the CAs).
> > Thanks,
> > Ben
>
> Is there any progress on this? To be honest I was more meaning that Mozilla
> (Gerv?) should just add this subCA to OneCRL and be done with it.
>
> ___
> 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: Certificate with invalid dnsName issued from Baltimore intermediate

[Alex Gaynor via dev-security-policy]

If I'm reading this correctly, these certificates are for internal
services, not publicly accessible. Could they add their intermediate
directly to these trust stores, allowing you to revoke it?

Failing that, it sounds like OneCRL would be an appropriate remedy.

Alex

On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Nick and Mozilla Community,
>
> Here is the response from Intesa Sanpaolo concerning the disruption that
> revocation will cause to their banking operations:
>
> Good Evening Ben,
>
>About the problem with the certificate you recently notified us, I
> confirm you that we have replaced the certificates today, so we have now
> revoked the wrong one.
>
> Concerning the CA revocation, first of all, I want to underline that for us
> it would be a major issue: we don't have enough time and resources to
> replace all the certificates before the end of the year and the revocation
> of the CA will cause us several critical operating problems with our
> infrastructural services.
>
> Moreover, I would like to inform you that in order to rationalize our
> infrastructure and create new synergy between our suppliers, we've planned
> to move our certificates to an Italian CA outsourcer. We have already
> started this activity and our intent is to complete the migration before
> the
> end of the year, to respect the contract we have settled, with deadline
> December, 31st 2017.
>
> Therefore I have to kindly recommend you not to revoke the CA, before the
> end of the contract, because it will cause several problems to the Bank and
> to our users (customers and colleagues).
>
> We are available to set up a call conference with you to discuss the
> matter.
> Looking forward to hear from you.
>
> Best regards,
> Riccardo D'Agostini
>
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, August 3, 2017 7:33 AM
> To: Nick Lamb ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:34 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificate with invalid dnsName issued from Baltimore
> intermediate
>
> On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> > Nick,
> > We are in discussions with Intesa Sanpaolo about implementing/pursuing
> > OneCRL or a similar approach (e.g. outright revocation of the CAs).
> > Thanks,
> > Ben
>
> Is there any progress on this? To be honest I was more meaning that Mozilla
> (Gerv?) should just add this subCA to OneCRL and be done with it.
>
> ___
> 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: StartCom cross-signs disclosed by Certinomis

[Alex Gaynor via dev-security-policy]

From RFC6962:

The signature on the TBSCertificate indicates the certificate
authority's intent to issue a certificate.  This intent is considered
binding (i.e., misissuance of the Precertificate is considered equal
to misissuance of the final certificate).

I don't think this text could be any more clear, and I'm frankly
astounded that any CA would try to argue they shouldn't be held to
account for them.

If you wouldn't issue a cert, don't issue the pre-cert. It's really that simple.


Alex


On Thu, Aug 3, 2017 at 7:20 AM, Inigo Barreira via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We´re revoking all those unrevoked certs to avoid any more problems.
>
> Regarding the pre-certs, yes, I was aware of the discussion. As Gerv says
> there´s a binding statement of "intent" ... the problem with these is that
> we generated the pre-certs and logged in the CT log, where crt.sh looks or
> monitor, but those weren´t finally issued, so there are not such certs.
> In any case, as said, we´re revoking all of those listed and will update
> the
> bugzilla accordingly
>
> Best regards
>
> Iñigo Barreira
> CEO
> StartCom CA Limited
>
> -Original Message-
> From: Patrick Figel [mailto:patrick@figel.email]
> Sent: jueves, 3 de agosto de 2017 13:07
> To: Inigo Barreira ; Franck Leroy
> ; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: StartCom cross-signs disclosed by Certinomis
>
> On 03/08/2017 10:47, Inigo Barreira via dev-security-policy wrote> 1.
> The un-revoked test certificates are those pre-sign ones with uncompleted
> > ctlog. So they are not completed certificates.
> > https://crt.sh/?opt=cablint&id=134843670
> > https://crt.sh/?opt=cablint&id=134843674
> > https://crt.sh/?opt=cablint&id=134843685
> > https://crt.sh/?opt=cablint&id=139640371
>
> My understanding of Mozilla's policy is that misissued precerts are
> considered misissuance nonetheless[1].
>
> [1]:
> https://groups.google.com/d/msg/mozilla.dev.security.
> policy/6pBLHJBFNts/kM3k
> EJKMAgAJ
>
> ___
> 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: DigiCert-Symantec Announcement

[Alex Gaynor via dev-security-policy]

Hi Jeremy,

Will the certificates being issued for Symantec starting December 1st be
issued under the existing DC roots, or under new roots?

Alex

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi everyone,
>
>
>
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
> will validate and issue all Symantec certs as of Dec 1, 2017.  We are
> committed to meeting the Mozilla and Google plans in transitioning away
> from
> the Symantec infrastructure. The deal is expected to close near the end of
> the year, after which we will be solely responsible for operation of the
> CA.
> From there, we will migrate customers and systems as necessary to
> consolidate platforms and operations while continuing to run all issuance
> and validation through DigiCert.  We will post updates and plans to the
> community as things change and progress.
>
>
>
> I wanted to post to the Mozilla dev list to:
>
> 1.  Inform the public,
> 2.  Get community feedback about the transition and concerns, and
> 3.  Get an update from the browsers on what this means for the plan,
> noting that we fully commit to the stated deadlines. We're hoping that any
> changes
>
>
>
> Two things I can say we plan on doing (following closing) to address
> concerns are:
>
> a.  We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from
> different roots. We also plan on limiting the number of organizations on
> each issuing CA.  We hope this will help address the "too big to fail"
> issue
> seen with Symantec.  By segregating end entities into roots and sub CAs,
> the
> browsers can add affected Sub CAs to their CRL lists quickly and without
> impacting the entire ecosystem.  This plan is very much in flux, and we'd
> love to hear additional recommendations.
> b.  Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to issue the
> cert. This way the entire community can readily identify which method was
> used when issuing a cert and take action if a method is deemed weak or
> insufficient.  We think this is a huge improvement over the existing
> landscape, and I'm very excited to see that OID rolled out.
>
>
>
> Thanks a ton for any thoughts you offer.
>
>
>
> Jeremy
>
>
> ___
> 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: Miss-issuance: URI in dNSName SAN

[Alex Gaynor via dev-security-policy]

I've been attempting to report a bunch of miss-issued certificates this
weekend (hobbies are important!) I've primarily been using
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC&QuestionId=Q00028
as my reference (without which I would be totally lost!)

So far I've encountered issues with:

- DocuSign (OpenTrust/Keynectis) - who neglected to fill out that field
- StartCom - who filled out "web publication", I don't know what that means

To all the CAs who included a straightforward email or webform in there,
thank you!

Alex

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

> On 25/07/17 18:13, Jeremy Rowley wrote:
> > I would also love to see a more standardized notice mechanism that is
> > universal to all CAs. Right now, notifying CAs is a pain as some have
> > different webforms, some use email, and some don't readily tell you how
> to
> > contact them about certificate problems.
>
> "Not readily telling" is a BR violation; if you come across a CA like
> that, please do let us know. The info should be in the CCADB and in the
> CAs report.
>
> I agree it would be nice to have something more standard, but we have
> what we have right now.
>
> 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: Final Decision by Google on Symantec

[Alex Gaynor via dev-security-policy]

Frankly I was surprised to see Chromium reverse course on this -- they have
a history of aggressive leadership in their handling of CA failures, it's a
little disappointing to see them abandon that.

I'd strongly advocate for us perusing an earlier date -- December 1st at
the latest. Reasons:

1) Chromium's stated reason for avoiding dates around the holidays makes no
sense -- organizations with change freezes they need to adhere to have a
simple solution: obtain and deploy a new certificate at an earlier date!
They have 4 months between now and December 1st, if you can't deploy a cert
in 4 months, I submit you have larger problems.

2) It is important that CAs not be rewarded for the length of time this
process takes. CAs should be encouraged and rewarded for active
participation and engagement in this list.

3) Mandatory CT (well, mandatory for trust in Chromium) is a significant
win for security and transparency. At the moment, even discussing the
parameters of the distrust is complicated by the fact that we have limited
visibility into the iceberg of their PKI before June 1st, 2016 (see the
other thread where I attempt to discuss the count they provide of
outstanding certs that would be impacted). Given the challenges we know
exist in their legacy PKI, I think it's fair to say that continuing to
trust these certs represents real risk for our users's security.

Alex


On Fri, Jul 28, 2017 at 2:14 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
>
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
>
> Gerv
>
>  Forwarded Message 
> Subject:Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date:   Thu, 27 Jul 2017 17:16:06 -0700
> From:   Darin Fisher 
> To: Darin Fisher 
> CC: blink-dev 
>
>
>
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
>
>
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
>
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> proposal of August 2017 and Mozilla’s proposal for late 2017
>  y7IRQALJBgAJ>,
> we think it hits an appropriate balance between the security risk to
> Chrome users and minimizing disruption to the ecosystem. This time will
> allow clear messaging and scheduling for site operators to update
> certificates.
>
>
> We considered a number of alternative dates for distrusting this subset
> of ex

Re: Symantec Update on SubCA Proposal

[Alex Gaynor via dev-security-policy]

Just to be explicit: your count includes certificates which, with high
probability have already been replaced, because it does not subtract names
for which new certificates have been issued?

I realize it may seem like I'm putting a lot of emphasis on this one
number, but given that it's the basis for your assertion about the relative
difficulty for different distrust dates, I think it's quite significant.
Given that your methodology appears to over-count (to the advantage of
laxer distrust policies!), and cannot be independently verified, it really
boils down to "trust us to do right by the security of the WebPKI". Not to
put too fine a point on it, but we're in this situation because of
Symantec's history of _not_ acting in the interests of the security of the
WebPKI. It seems to me you could improve the transparency of this process
by logging all DV certs from this time frame to CT.

Alex

On Thu, Jul 27, 2017 at 11:53 AM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, July 26, 2017 at 10:20:08 AM UTC-7, Alex Gaynor wrote:
> > On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy
> > wrote:
> >
> > > Symantec has proposed timing changes that are consistent with the
> scope of
> > > distrust of the original SubCA proposal as proposed by Google and
> endorsed
> > > by Mozilla, which requires premature replacement of over 234,000
> > > certificates based on our proposed May 1, 2018 distrust date for
> > > certificates issued before June 1, 2016, and optimizes for replacement
> > > certificates to be issued off the new Managed CA(s) infrastructure
> > > (avoiding the requirement for double early replacement for the same
> > > original validity period). We believe our proposal minimizes
> disruption to
> > > websites and web end-users while meeting the spirit of Google’s and
> > > Mozilla’s prior commentary on their intent regarding the SubCA
> proposal,
> > > which is to limit the issuance of Symantec certificates under
> Symantec’s
> > > existing infrastructure and governance.
> > >
> >
> > Hi Rick,
> >
> > Given the importance of this 234,000 number, I was curious to explore.
> > Using the list of certificates Peter Bowen previously put together (
> > https://groups.google.com/a/chromium.org/d/msg/blink-dev/
> eUAKwjihhBs/aQqYZX6oBgAJ),
> > I ran a small script to filter out ones that expire before May 2018, or
> > were issued after June 2016. Using this methodlogy, I got a count of
> 166k,
> > a deviation of ~70k from your number. My 166k includes any certificates
> > that have been replaced since Peter put together the list in April, so in
> > that sense it likely reflects an over estimate of the number of certs
> > needing to be replaced.
> >
> > Can you say a little more on how you came to this number?
> >
> > Cheers,
> > Alex
>
> Our reference to over 234,000 certificates is based on our internal
> records of all active, unrevoked certificates that we issued prior to June
> 1, 2016 that expire after May 1, 2018. The dataset you reference relies on
> CT logs, which includes all active EV certificates Symantec has issued
> before June 1, 2016, but does not include all active, unrevoked OV and DV
> certificates Symantec has issued before June 1, 2016.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Update on SubCA Proposal

[Alex Gaynor via dev-security-policy]

On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Symantec has proposed timing changes that are consistent with the scope of
> distrust of the original SubCA proposal as proposed by Google and endorsed
> by Mozilla, which requires premature replacement of over 234,000
> certificates based on our proposed May 1, 2018 distrust date for
> certificates issued before June 1, 2016, and optimizes for replacement
> certificates to be issued off the new Managed CA(s) infrastructure
> (avoiding the requirement for double early replacement for the same
> original validity period). We believe our proposal minimizes disruption to
> websites and web end-users while meeting the spirit of Google’s and
> Mozilla’s prior commentary on their intent regarding the SubCA proposal,
> which is to limit the issuance of Symantec certificates under Symantec’s
> existing infrastructure and governance.
>

Hi Rick,

Given the importance of this 234,000 number, I was curious to explore.
Using the list of certificates Peter Bowen previously put together (
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/aQqYZX6oBgAJ),
I ran a small script to filter out ones that expire before May 2018, or
were issued after June 2016. Using this methodlogy, I got a count of 166k,
a deviation of ~70k from your number. My 166k includes any certificates
that have been replaced since Peter put together the list in April, so in
that sense it likely reflects an over estimate of the number of certs
needing to be replaced.

Can you say a little more on how you came to this number?

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

Re: dNSName containing '/' / low serial number entropy

[Alex Gaynor via dev-security-policy]

Hi Mark,

Are you saying you do intend to revoke all of these certificates in the
next 24 hours?

While subscribers are allowed to continue using bad certificates as long as
they desire, the BRs require CAs to revoke non-compliant certificates
within 24 hours of becoming aware of them.

Alex

On Tue, Jul 25, 2017 at 3:20 PM, Policy Authority PKIoverheid via
dev-security-policy  wrote:

> Op woensdag 19 juli 2017 00:26:16 UTC+2 schreef Charles Reiss:
> > - Digidentity Services CA - G2 (https://crt.sh/?caid=868 ; chains to
> > Staat der Nederlanden Root CA - G2) has issued certificates which serial
> > numbers that appear to be of the form 0x1000 + sequential counter
> > with notBefores as recent as 8 June 2017.
>
>
> Hi Charles,
>
> Many thanks for bringing this to our attention. We have looked into this
> matter immediately. Meanwhile the Policy Authority PKIoverheid has
> prohibited Digidentity (one of the Trusted Service Providers within the
> PKIoverheid/Staat der Nederlanden hierarchy) from issuing new certificates.
>
> After investigation it emerged that a total of 777 certificates were issued
> from September 30th 2016 that are not compliant with BR ballot 164
> (https://cabforum.org/2016/07/08/ballot-164/) echoed by the same
> requirement
> in version 2.4 (Compliance date: February 28, 2017) from the Mozilla CA
> Certificate Policy. Digidentity will revoke and
> replace these non-compliant certificates. This wil take place on or before
> 31 August 2017. However this action requires the cooperation from
> subscribers. As you know we are in the midst of the Holiday Season so we
> can't completly rule out that some certificates will be replaced a couple
> of days after August the 31th. Nevertheless Digidentity will do her utmost
> to revoke and replace all certs before the 31th.
>
> As evidence that Digidentity is now compliant with regard to the
> certificate
> serial number requirement from the BR check the new issued SSL cert on this
> website: https://www.digidentity.eu/nl/home/
>
> The Policy Authority PKIoverheid has judged that Digidentity can resume
> issuing certificates now that they are in compliance with Ballot 164 and
> the Mozilla CA Policy.
>
> Please let me know if you have any questions.
>
> Further questions could also be answered by my collegaues Jorik van 't Hof
> or Jochem van den Berge.
>
> Thanks.
>
> Regards,
> Mark Janssen
> ___
> 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: Miss-issuance: URI in dNSName SAN

[Alex Gaynor via dev-security-policy]

Following up on this (and really several other threads). The BRs require
mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
are required to track m.d.s.p. per the Mozilla Root Policy, so really
notifying this list _ought_ to qualify as notifying the CAs.

In any event, here are some certificates, by CA, that have been mis-issued
and linked on this list many days ago at this point:

PSCProcert - https://crt.sh/?id=124094761 - dNSName is a URI
PSCProcert - https://crt.sh/?id=175466182 - dNSName is for a .local domain
Camerfirma AAPP II - 2014 - https://crt.sh/?id=42531587 - dNSName is a URI
AC CAMERFIRMA AAPP - https://crt.sh/?id=5129200 - dNSName is a URI
StartCom Class 2 Primary Intermediate Server CA -
https://crt.sh/?id=10714112 - incorrect wildcard "*g10.net-lab.net"
StartCom Class 3 OV Server CA - https://crt.sh/?id=17295812 - incorrect
wildcard "*dev02.calendar42.com"
StartCom Class 1 DV Server CA - https://crt.sh/?id=78248795 - invalid
dNSName "-1ccenter.777chao.com"
TI Trust Technologies Global CA - https://crt.sh/?id=48682944 - invalid
wildcard "*nuvolaitaliana.it"
UniCredit Subordinate External - https://crt.sh/?id=44997156 - invalid
wildcard "*.*.rnd.unicredit.it"
Swisscom Smaragd CA 2 - https://crt.sh/?id=5982951 - invalid wildcard "*.*.
int.swisscom.ch"
Swisscom Smaragd CA 2 - https://crt.sh/?id=175444569 - dNSName is for a
.local domain
Verizon Public SureServer CA G14-SHA2 - https://crt.sh/?id=33626750 -
dNSName is for a .test domain
Verizon Public SureServer CA G14-SHA2 - https://crt.sh/?id=12344381 -
dNSName is for a .local domain
CLASS 2 KEYNECTIS CA - https://crt.sh/?id=42475510 - dNSName is for a .corp
domain
EC-SectorPublic - https://crt.sh/?id=98706307 - dNSName is for a .local
domain


Should there be some penalty for the failure of CAs to revoke within the
time period required by the BRs?

Alex

On Sat, Jul 22, 2017 at 10:11 AM, alex.gaynor--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> It has now been several days, does Camerafirma intend to revoke these
> certificates, as required by the BRs (within 24 hours of being notified)?
> ___
> 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: [EXT] Symantec Update on SubCA Proposal

[Alex Gaynor via dev-security-policy]

On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin 
wrote:

> 1)  *December 1, 2017 is the earliest credible date that any RFP
> respondent can provide the Managed CA solution proposed by Google, assuming
> a start date of August 1, 2017. Only one RFP respondent initially proposed
> a schedule targeting August 8, 2017 (assuming a start date of June 12,
> 2017). We did not deem this proposal to be credible, however, based on the
> lack of specificity around our RFP evaluation criteria, as compared to all
> other RFP responses which provided detailed responses to all aspects of the
> RFP, and we have received no subsequent information from this bidder to
> increase our confidence.*
>
>
Hi Steve,

Given that this represents nearly a 4 month difference in timelines, can
you give us any more insight here as why you see such a large delta?

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

Re: [EXT] Symantec Update on SubCA Proposal

[Alex Gaynor via dev-security-policy]

Hi Steve,

Thank you for this update on Symantec's progress. I have a few follow-up
questions:

1) Did any of the RFP respondents indicate that they could provide the
Managed
   CA solution in the timeframe originally proposed by Google? (August 8th)
   Alternatively, is December 1st, 2017 the earliest date that any RFP
   respondents can achieve?

2) What selection criteria is Symantec using in considering RFP responses?

3) On June 1st, Symantec wrote that "we are in the midst of a rigorous RFP
   process"
   (
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
).
   In this mail you wrote that "Last month, we released a Request for
Proposal
   (RFP)". How do you reconcile those?

4) There are currently rumors that Symantec is considering a sale of its CA
   business
   (https://www.reuters.com/article/us-symantec-divestiture-idUSKBN19W2WI).
Do
   these timelines reflect that possibility, or should we expect requests to
   amend this timeline in the event of a change of ownership?

Thank you,
Alex

On Tue, Jul 18, 2017 at 3:37 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Correction: Summary item #3 should read:
>
> 3. May 1, 2018
>a. Single date of distrust of certificates issued prior to 6/1/2016.
> (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
> from January 18, 2018 for certificates issued prior to 6/1/2016).
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Steve Medin via dev-security-policy
> > Sent: Tuesday, July 18, 2017 2:23 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Symantec Update on SubCA Proposal
> >
> > *Progress Update on SubCA RFP, Partner Selection, and Execution*
> >
> >
> >
> > Since June 1, Symantec has worked in earnest to operationalize the SubCA
> > proposal outlined by Google and Mozilla and discussed in community
> > forums.  The core of this proposal is to transfer the authentication and
> > issuance of certificates to a set of new SubCAs that are operated by
> > "Managed CAs", with the eventual end state being a move from the existing
> > Symantec PKI to a modernized platform. We are providing this update to
> > share our initial findings of our efforts to implement the SubCA
> proposal,
> > and as previously posted, propose aggressive but achievable dates for
> > certain aspects of the SubCA proposal.
> >
> >
> >
> > Last month, we released a Request for Proposal (RFP) that covered all
> > aspects of the SubCA proposal, including key management, technical
> > integration, staffing, training, compliance, support, and the end-to-end
> > coordination of operations. This RFP was sent to the CAs that we felt
> best
> > met the browser requirements and had the potential to successfully
> fulfill
> > the scope and volume of our CA authentication and issuance activities.
> >
> >
> >
> > After receiving RFP responses, we met with the prospective Managed CAs
> > to discuss and refine their proposed approach, clarify intent and answer
> > questions impacting their proposals, which addressed their approach to
> > and schedule for integration, staffing, compliance, support, and other
> > operational aspects.  Over the last two weeks, we have continued to
> receive
> > detailed responses from RFP respondents and hold meetings with the
> > prospective Managed CAs to review their proposals in order to select the
> > final Managed CA partner(s) that will be able to best execute on the plan
> > proposed by Google and Mozilla. We appreciate the CAs who have replied
> > and recognize that drafting the proposals required a tremendous amount
> > of time and effort as part of this accelerated process.
> >
> >
> >
> > We continue to work through implementation details with our prospective
> > Managed CA partners, to understand the depth of analysis that has gone
> > into their development schedules and staffing plans, and to assess the
> > feasibility of those plans.  We expect to complete the selection process
> > within the next 2 weeks. After selecting the final Managed CA
> partner(s), we
> > will work aggressively towards the execution of an agreement and
> > integration plan.
> >
> >
> >
> > As we finalize the selection process, our development team is actively
> > working towards the transition.  Currently, we are shifting from design
> to
> > implementation of a common set of APIs across platforms to simplify the
> > integration with one or more Managed CAs.
> >
> >
> >
> > Based on the RFP responses, internal planning, and discussions with RFP
> > respondents to date, we are still concerned with the implementation
> > timing. Based on both our own internal scoping and the RFP responses, we
> > see a practical, aggressive transition being achievable between early-
> > December and late-February, depending on the specific Managed CA(s) and

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Alex Gaynor via dev-security-policy]

I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.

Alex

On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:
> 
>
>> (Due to limitations in the search methodology - scraping crt.sh
>> search results and looping through tlds - I only searched for ..tld. It
>> would certainly be valuable to search further.)
>>
>
> Here's a report of all "double dot" certs known to crt.sh that are useable
> for server authentication and chain to a root trusted by Mozilla:
>
> https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
> QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing
>
>
> P.S.
> For anyone interested, here's the SQL I executed on the crt.sh DB to
> produce this report:
>
> SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
> array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
>   FROM certificate_identity ci, ca, certificate c
>   WHERE ci.NAME_VALUE LIKE '%..%'
> AND ci.NAME_TYPE IN ('dNSName', 'commonName')
> AND ci.ISSUER_CA_ID = ca.ID
> AND ci.CERTIFICATE_ID = c.ID
> AND EXISTS (
>   SELECT 1
> FROM ca_trust_purpose ctp
> WHERE ci.ISSUER_CA_ID = ctp.CA_ID
>   AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
>   AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
> )
> AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
>   GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
> x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
>   ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;
>
> --
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Miss-issuance: URI in dNSName SAN

[Alex Gaynor via dev-security-policy]

Morning all,

I'd like to report the following instance of miss-issuance:

All of the following contain a URI in a dNSName SAN entry. These
certificates are neither revoked, nor expired, and all are from CAs
currently trusted by the Mozilla Root Program.

https://crt.sh/?id=124094761&opt=cablint
Issuer: 
commonName= PSCProcert
countryName   = VE
organizationName  = Sistema Nacional de
Certificacion Electronica
organizationalUnitName= Proveedor de Certificados PROCERT
stateOrProvinceName   = Miranda
localityName  = Chacao
emailAddress  = conta...@procert.net.ve

https://crt.sh/?id=42531587&opt=cablint
Issuer: 
commonName= Camerfirma AAPP II - 2014
localityName  = Madrid (see current address at
https://www.camerfirma.com/address)
serialNumber  = A82743287
organizationName  = AC Camerfirma S.A.
organizationalUnitName= AC CAMERFIRMA
countryName   = ES

https://crt.sh/?id=5129200&opt=cablint
Issuer: 
commonName= AC CAMERFIRMA AAPP
serialNumber  = A82743287
organizationalUnitName= AC CAMERFIRMA
localityName  = MADRID (Ver en
https://www.camerfirma.com/address)
organizationName  = AC CAMERFIRMA S.A.
countryName   = ES



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

Re: Leaking private keys through web servers

[Alex Gaynor via dev-security-policy]

On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > So there are several questions and possible situations here.
> >
> > I think it's relatively clear that a CA could prevent reissuance of
> > certs if they know about a key compromise.
> >
>
> I actually don't think it's clear, that's why I was trying to highlight the
> challenges.
>
> That is, I think we can all agree that for situations where you reported
> directly to the CA, it was clear that the CA had knowledge that the
> associated private key was compromised. Presumably, a requirement to
> prevent issuance would mean that the CA maintains a blacklist of
> 'compromised keys' and refuses to issue certificates for them.
>
> However, if we say that the CA shall not prevent for situations of
> compromise, the following interpretations exist, and we should try to
> figure out first what we want (from an ecosystem) and then how to specify
> that.
> - Are we expecting the CA to maintain a database of compromised private
> keys (I believe the implied answer is 'yes' - but today, they only need
> maintain the database of revoked certificates, which is different)
> - Is the CA obligated to check other sources of compromise information
> prior to issuing the certificate.
>   - Example: Should they check other CAs' CRLs? The CRLs themselves don't
> provide information about the key, so one would presumably _also_ need to
> check sources like Certificate Transparency.
>   - Tortured example: What happens if a (different CA's) cert is not logged
> in CT, revoked in the CRL (for keyCompromise), and then subsequently
> disclosed to first CA. Are they obligated to revoke (under 4.9.1.1 #3)? Are
> they obligated to not issue (under the proposed change)?
>
> The reason I highlight this is that preventing CA "Foo" from issuing a
> second cert for (compromised) key X doesn't prevent CA "Bar" from doing the
> same. Because of this, it's a reasonable question about what security value
> we're obtaining, if the party with Key X can simply go to another CA to get
> the cert.
>
> From a CA perspective, requiring that Foo reject a request that Bar can
> accept would be unappealing to Foo - it's effectively giving business to
> Bar (whether or not this is actually the case, and however illogical it is,
> there are plenty of CAs who think this way)
>
> From a security perspective, requiring that Foo not issue for key X doesn't
> ensure that a cert for key X will not be introduced, not unless we make the
> requirement of all CAs.
>
> So that's why I'm not sure how much value we'd get from such a requirement
> - and wanted to highlight the challenges in finding a way to establish it
> for all CAs, and why it's important (for CAs and relying parties) for a
> consistent requirement.
>
>
> > Ultimately I'm inclined to say that there really shouldn't be any good
> > reason at all to ever reuse a key. (Except... HPKP)
>
>
> I see. I think I'd strongly disagree with that assertion. There are lots of
> good reasons to reuse keys. The most obvious example being for
> shorter-lived certificates (e.g. 90 days), which allow you to rotate the
> key in case of compromise, but otherwise don't require you to do so.
> Considering revocation information is no longer required to be provided
> once a certificate expires, it _also_ means that in the CA Foo case, with
> Key X compromised, the subscriber could get another cert for it once the
> original cert has expired (and thus revocation information no longer able
> to be provided)
>

What you described is a case where it's not harmful to reuse a key, not a
case in which it's a good reason to. Indeed defaulting to rotating your key
on every new certificate is probably the safest choice, as it ensures that
"key compromise" is no different from any other rotation, and keeps that
hinge well oiled.

Alex


> ___
> 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: How long to resolve unaudited unconstrained intermediates?

[Alex Gaynor via dev-security-policy]

Hey Ben,

Take a look at the thread "Disclosing unconstrained emailProtection
intermediates to CCADB" by Rob, it explains the change and has the relevant
dates by which CAs must comply.

Alex

On Tue, Jul 11, 2017 at 3:21 PM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> By the way, I just noticed on https://crt.sh/mozilla-
> disclosures#undisclosed
> that CA certificates with an EKU of eMailProtection (1.3.6.1.5.5.7.3.4) are
> now listed when they weren't required to be listed previously.  Presumably
> CAs will be given ample time to update these entries.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Tuesday, July 11, 2017 7:57 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: How long to resolve unaudited unconstrained intermediates?
>
> On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx  wrote:>
> > So at least some of them have been notified more than 3 months ago,
> > and a bug was filed a month later. I think you already gave them too
> > much time to at least respond to it, and suggest that you sent a new
> > email indicating that if they don't respond immediately that they will
> > get added to OneCRL.
>
> Agreed. It may also make sense to add telemetry that allows Mozilla to
> determine whether listing such subCAs in the OneCRL are ever actually
> blocking anything. This makes  a difference in my opinion as to the
> severity
> of the breach of policy by the CA in question.
> ___
> 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: WoSign new system passed Cure 53 system security audit

[Alex Gaynor via dev-security-policy]

Is this a correct summary:

- The report included here is supposed to fulfill the network security test
portion of the BRs
- This report does not attest to BR compliance (or non-compliance)
- To complete an application for the Mozilla Root Program, WoSign would be
required to additionally provide a WebTrust audit (or equivalent, as
described in the Mozilla PKI Policy section 3.1)
- Based on your reading of the complete network security test, you would
not expect WoSign to be able to pass a BR Audit without qualifications

Alex

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

> On Tue, Jul 11, 2017 at 11:16 AM, Jonathan Rudenberg via
> dev-security-policy  wrote:
>
> >
> > > On Jul 11, 2017, at 06:53, okaphone.elektronika--- via
> > dev-security-policy  wrote:
> > >
> > > On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang  wrote:
> > >>
> > >> Please note this email topic is just for releasing the news that
> WoSign
> > new system passed the security audit, just for demonstration that we
> > finished item 5:
> > >> " 5. Provide auditor[3] attestation that a full security audit of the
> > CA’s issuing infrastructure has been successfully completed. "
> > >> " [3] The auditor must be an external company, and approved by
> Mozilla.
> > "
> > >
> > > It also seems a bit strange to report item 5 "successfully completed"
> > before we hear anything about the other items. How about starting with
> item
> > 1? What are your plans voor fixing the problems?
> >
> > It’s worth noting that the problems have not stopped yet. There are a
> > bunch of certificates issued over the past few months that do not comply
> > with the Baseline Requirements issued from the new "StartCom BR SSL ICA”,
> > for example:
> >
> > https://crt.sh/?opt=cablint&q=8BDFE4A526BFB35C8A417B10F4D0AB
> > E9E1D60D28A412539D5BC71C19B46FEF21
> > https://crt.sh/?opt=cablint&q=124AAD38DAAC6B694D65F45226AB51
> > 52FC46D229CBC203E0814D175F39977FF3
> > https://crt.sh/?opt=cablint&q=9B78C78B32F4AC717B3DEFDABDACC4
> > FEFA61BFD17782B83F75ADD82241147721
> > https://crt.sh/?opt=cablint&q=AAB0B5A08F106639A5C9D720CD37FD
> > B30E7F337AEBAF9407FD854B5726303F7B
> > https://crt.sh/?opt=cablint&q=9DCE6A924CE837328D379CE9B7CDF4
> > A2BA8A0E8EC01018B9DE736EBC64442361
> > https://crt.sh/?opt=cablint&q=62A9A9FDCDC04A043CF2CB1A5EAFE3
> > 3CF9ED8796245DE4BD5250267ADEFF005A
> > https://crt.sh/?opt=cablint&q=6A72FA5DCC253D2EE07921898B9A9B
> > B263FD1D20FE61B1F52F939C0C1C0DCFEE
> > https://crt.sh/?opt=cablint&q=238E2E96665748D2A05BAAEEC8BAE6
> > AFE7B7EF4B1ADA4908354C855C385ECD81
> > https://crt.sh/?opt=cablint&q=C11C00EB0E14EEB30567D749FFD304
> > 45E0B490D1DCA7B7E082FD1CB0A40A71C0
> > https://crt.sh/?opt=cablint&q=4DEF4CFD21A969E8349E4428FDEC73
> > 767C01DE6127843312511B71029F4E3836
>
>
> It's worth noting that, on the basis of the security audit report full
> details shared by WoSign, the system that was security audited does not
> comply with the Baseline Requirements, nor, as designed, can it. The system
> would need to undergo non-trivial effort to comply with the Baseline
> Requirements.
> ___
> 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

How long to resolve unaudited unconstrained intermediates?

[Alex Gaynor via dev-security-policy]

Hi all,

I wanted to call some attention to a few intermediates which have been
hanging out in the "Audit required" section for quite a while:
https://crt.sh/mozilla-disclosures#disclosureincomplete

Specifically, the TurkTrust and Firmaprofesional ones. Both have issues
open in Bugzilla:

- https://bugzilla.mozilla.org/show_bug.cgi?id=1367842
- https://bugzilla.mozilla.org/show_bug.cgi?id=1368171

However, neither appears to have seen any attention from the CAs in the
past two months.

Section 5.3.2 of the Mozilla Root Policy says they have a week to disclose
the cert, however I'm a bit less clear on on what timeline they're required
to provide the audit statements.

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

Re: FW: P-521

[Alex Gaynor via dev-security-policy]

On Wed, Jul 5, 2017 at 7:51 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I agree crypto algorithms are not "gotta catch 'em all", but the
> algorithm is ECDH, which NSS must implement anyway to support P-256 and
> P-384, and a curve is just another set of parameters to it. I also think
> that there is little value and there is potential confusion (as we have
> seen) in Mozilla mandating a more restrictive set than the BRs and than
> Microsoft:
>

Is it really true that additional curves are just additional parameters? I
haven't gone source-diving in NSS recently, but my understanding is that
most crypto libraries provide optimized assembly routines for scalar
multiplication on a per-curve basis -- OpenSSL appears to have over 10,000
lines of assembly-generating-perl for P256 alone (
https://github.com/openssl/openssl/tree/master/crypto/ec/asm).

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

Re: P-521

[Alex Gaynor via dev-security-policy]

I'll take the opposite side: let's disallow it before it's use expands :-)
P-521 isn't great, and there's really no value in proliferation of crypto
algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't
try to catch 'em all". There's no real use cases P-521 enables, and not
supporting it means one less piece of code to drag around as we move
towards better curves/signature algorithms like Ed25519 and co.

Alex

On Tue, Jun 27, 2017 at 2:40 PM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, Jun 27, 2017 at 10:41:49AM -0700, Gervase Markham wrote:
> > On 27/06/17 07:17, Kurt Roeckx wrote:
> > > I suggest you keep it for now.
> >
> > An opinion without a rationale is not all that useful :-)
>
> A lot of software supports it, including NSS / Firefox. It's not
> an ideal curve, and it should get replaced, but it's currently
> better to have it then not.
>
> I currently only count 222 certificate using P-521 that chain to
> the Mozilla root store, and I guess some of those would fall back
> to RSA.
>
> I see no reason to say that they shouldn't be used at this time.
>
>
> Kurt
>
> ___
> 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: Unknown Intermediates

[Alex Gaynor via dev-security-policy]

I definitely consider increased visibility into the vast iceberg that is
the public PKI to be a good thing!

What set of intermediates are you using? If it's reasonably complete, I
doubt we'll do any better than you, though maybe someone here has a
particularly clever technique for processing these.

As these are all from PDFs, an interesting follow-up project for someone
might be to look at S/MIME signatures sent to public mailing lists and
seeing what interesting certificates can be found there.

Alex

On Thu, Jun 22, 2017 at 10:45 AM, Tavis Ormandy  wrote:

> I think you're right, it was probably me submitting my corpus - I hope
> that's a good thing! :-)
>
> I only submitted the ones I could verify, would you be interested in the
> others? Many are clearly not interesting, but others seem like they may be
> interesting if I had an intermediate I haven't seen.
>
> Tavis.
>
>
> On Thu, Jun 22, 2017 at 6:15 AM, Alex Gaynor  wrote:
>
>> One of my hobbies is keeping track of publicly trusted (by any of the
>> major root programs) CAs, for which there are no logged certificates.
>> There's over 1000 of these. In the last day, presumably as a result of
>> these efforts, 50-100 CAs were removed from the list.
>>
>> Cheers,
>> Alex
>>
>> On Thu, Jun 22, 2017 at 5:51 AM, Rob Stradling 
>> wrote:
>>
>>> On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:
>>>
 Thanks Alex, I took a look, it looks like the check pings crt.sh - is
 doing
 that for a large number of certificates acceptable Rob?

>>>
>>> Hi Tavis.  Yes, Alex's tool uses https://crt.sh/gen-add-chain to find a
>>> suitable cert chain and build the JSON that can then be submitted to a
>>> log's /ct/v1/add-chain.  It should be fine to do that for a large number of
>>> certs.  crt.sh exists to be used.  ;-)
>>>
>>> I made a smaller set, the certificates that have 'SSL server: Yes' or
 'Any
 Purpose : Yes', there were only a few thousand that verified, so I just
 checked those and found 551 not in crt.sh.

 (The *vast* majority are code signing certificates, many are individual
 apple developer certificates)

 Is this useful? if not, what key usage is interesting?

 https://lock.cmpxchg8b.com/ServerOrAny.zip

>>>
>>> Thanks for this, Tavis.  I pointed my certscraper (
>>> https://github.com/robstradling/certscraper) at this URL a couple of
>>> days ago.  This submitted many of the certs to the Dodo and Rocketeer logs.
>>>
>>> However, it didn't manage to build chains for all of them.  I haven't
>>> yet had a chance to investigate why.
>>>
>>>
>>> Tavis.

 On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor 
 wrote:

 If you're interested in playing around with submitting them yourself, or
> checking if they're already submitted, I've got some random tools for
> working with CT: https://github.com/alex/ct-tools
>
> Specifically ct-tools check  will get what
> you
> want. It's all serial, so for 8M certs you probably want to Bring Your
> Own
> Parallelism (I should fix this...)
>
> Alex
>
> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy
> <
> dev-security-policy@lists.mozilla.org> wrote:
>
> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>>
>> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>>>
>>> 
>>
>> Is there an easy way to check which certificates from my set you're
>>>
 missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
 for fuzzing).

 I collected these from public sources, so can just give you my whole
 set if you already have tools for importing them and don't mind
 processing them, I have around ~8M (mostly leaf) certificates, the
 set with isCa will be much smaller.


>>> Please do post the whole set.  I suspect there are several people on
>>> this list (including myself and Rob) who have the tools and
>>> experience
>>> to process large sets of certificates and post them to public
>>> Certificate Transparency logs (whence they will be fed into crt.sh).
>>>
>>> It would be useful to include the leaf certificates as well, to catch
>>> CAs which are engaging in bad practices such as signing non-SSL certs
>>> with SHA-1 under an intermediate that is capable of issuing SSL
>>> certificates.
>>>
>>> Thanks a bunch for this!
>>>
>>>
>> +1
>>
>> Tavis, please do post the whole set.  And thanks!
>>
>
>>> --
>>> 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: Unknown Intermediates

[Alex Gaynor via dev-security-policy]

One of my hobbies is keeping track of publicly trusted (by any of the major
root programs) CAs, for which there are no logged certificates. There's
over 1000 of these. In the last day, presumably as a result of these
efforts, 50-100 CAs were removed from the list.

Cheers,
Alex

On Thu, Jun 22, 2017 at 5:51 AM, Rob Stradling 
wrote:

> On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:
>
>> Thanks Alex, I took a look, it looks like the check pings crt.sh - is
>> doing
>> that for a large number of certificates acceptable Rob?
>>
>
> Hi Tavis.  Yes, Alex's tool uses https://crt.sh/gen-add-chain to find a
> suitable cert chain and build the JSON that can then be submitted to a
> log's /ct/v1/add-chain.  It should be fine to do that for a large number of
> certs.  crt.sh exists to be used.  ;-)
>
> I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any
>> Purpose : Yes', there were only a few thousand that verified, so I just
>> checked those and found 551 not in crt.sh.
>>
>> (The *vast* majority are code signing certificates, many are individual
>> apple developer certificates)
>>
>> Is this useful? if not, what key usage is interesting?
>>
>> https://lock.cmpxchg8b.com/ServerOrAny.zip
>>
>
> Thanks for this, Tavis.  I pointed my certscraper (
> https://github.com/robstradling/certscraper) at this URL a couple of days
> ago.  This submitted many of the certs to the Dodo and Rocketeer logs.
>
> However, it didn't manage to build chains for all of them.  I haven't yet
> had a chance to investigate why.
>
>
> Tavis.
>>
>> On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor  wrote:
>>
>> If you're interested in playing around with submitting them yourself, or
>>> checking if they're already submitted, I've got some random tools for
>>> working with CT: https://github.com/alex/ct-tools
>>>
>>> Specifically ct-tools check  will get what you
>>> want. It's all serial, so for 8M certs you probably want to Bring Your
>>> Own
>>> Parallelism (I should fix this...)
>>>
>>> Alex
>>>
>>> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:

 On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>
> 

 Is there an easy way to check which certificates from my set you're
>
>> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
>> for fuzzing).
>>
>> I collected these from public sources, so can just give you my whole
>> set if you already have tools for importing them and don't mind
>> processing them, I have around ~8M (mostly leaf) certificates, the
>> set with isCa will be much smaller.
>>
>>
> Please do post the whole set.  I suspect there are several people on
> this list (including myself and Rob) who have the tools and experience
> to process large sets of certificates and post them to public
> Certificate Transparency logs (whence they will be fed into crt.sh).
>
> It would be useful to include the leaf certificates as well, to catch
> CAs which are engaging in bad practices such as signing non-SSL certs
> with SHA-1 under an intermediate that is capable of issuing SSL
> certificates.
>
> Thanks a bunch for this!
>
>
 +1

 Tavis, please do post the whole set.  And thanks!

>>>
> --
> 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: Unknown Intermediates

[Alex Gaynor via dev-security-policy]

If you're interested in playing around with submitting them yourself, or
checking if they're already submitted, I've got some random tools for
working with CT: https://github.com/alex/ct-tools

Specifically ct-tools check  will get what you
want. It's all serial, so for 8M certs you probably want to Bring Your Own
Parallelism (I should fix this...)

Alex

On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>
>> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>>
> 
>
>> Is there an easy way to check which certificates from my set you're
>>> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
>>> for fuzzing).
>>>
>>> I collected these from public sources, so can just give you my whole
>>> set if you already have tools for importing them and don't mind
>>> processing them, I have around ~8M (mostly leaf) certificates, the
>>> set with isCa will be much smaller.
>>>
>>
>> Please do post the whole set.  I suspect there are several people on
>> this list (including myself and Rob) who have the tools and experience
>> to process large sets of certificates and post them to public
>> Certificate Transparency logs (whence they will be fed into crt.sh).
>>
>> It would be useful to include the leaf certificates as well, to catch
>> CAs which are engaging in bad practices such as signing non-SSL certs
>> with SHA-1 under an intermediate that is capable of issuing SSL
>> certificates.
>>
>> Thanks a bunch for this!
>>
>
> +1
>
> Tavis, please do post the whole set.  And thanks!
>
> --
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec response to Google proposal

[Alex Gaynor via dev-security-policy]

It was also pointed out to me that as Symantec have indicated they sent out
an RFP, any companies which are considering responding may be hesitant to
post.

Alex

On Tue, Jun 6, 2017 at 10:16 AM, Gervase Markham  wrote:

> On 06/06/17 15:12, Alex Gaynor wrote:
> > I suspect many of us are a bit exhausted by the discussion :-).
>
> That's fair enough! :-) I can understand that.
>
> Gerv
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec response to Google proposal

[Alex Gaynor via dev-security-policy]

On Tue, Jun 6, 2017 at 10:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 02/06/17 15:53, Gervase Markham wrote:
> > https://www.symantec.com/connect/blogs/symantec-s-
> response-google-s-subca-proposal
>
> I'm slightly surprised to see no engagement here. Perhaps it would be
> help to break it down. Symantec's specific requests for modification are
> as follows (my interpretation):
>

I suspect many of us are a bit exhausted by the discussion :-).
Particularly since at this point it feels like there's some divergence
between our goals of protecting security and not breaking the web. It's
clear that Symantec's actions for a much smaller CA would have resulted in
complete distrust (perhaps over time). That's not being pursued because
Symantec is too big too fail.

I'll try to engage on some specific points.


>
> 1) Scope of Distrust
>
> Google proposal: existing CT-logged certificates issued after 1st June
> 2016 would continue to be trusted until expiry.
> Symantec proposal: all CT-logged certificates should continue to be
> trusted until expiry.
> Rationale for change: if transparency is enough to engender trust, that
> principle should be applied consistently. This also significantly
> reduces the revalidation burden.
>

Transparency is not a magic solution to trust, though it is helpful. We
know that it primarily acts as a canary-in-the-coalmine, not perfect
coverage. Distrusting older certs issued under a less strict validation
regime makes sense.


>
> 2) Timeline
>
> Google proposal: a set of dates by which certain milestones must be
> achieved.
> Symantec proposal: no specific alternative dates (more info by the end
> of June), but the Google dates are too aggressive.
> Rationale: need to establish business relationships; capacity issues at
> Managed CAs; international requirements further complicate things; the
> revalidation burden is very large; writing solid code takes time.
>
>
I'm concerned that a lack of commitment to any particular date reflects a
lack of urgency for this process. Fundamentally, the legacy Symantec PKI
reflects risk for relying parties. Taking additional months or years to
move away from it is all time that RPs bear that risk.


> 3) SubCA Audit Type
>
> Google proposal: SubCAs are audited with the standard audits.
> Symantec proposal: treat SubCAs as Delegated Third Parties and so give
> them BR section 8 audits (an audit by the CA not an auditor; 3% sampling).
> Rationale: none given.
>
> 4) Validation Task Ownership
>
> Google proposal: Symantec and its affiliates must not participate in any
> of the information verification roles permitted under the Baseline
> Requirements. They may, however, collect and aggregate information.
> Symantec proposal: Symantec currently uses a 2-step process - validation
> and review. Symantec should be allowed to do the first, with the SubCA
> doing the second (with 100% review, not samplingh).
> Rationale: reducing the burden on the SubCA, reducing the time for them
> to ramp up, and (presumably) to allow the Symantec personnel to continue
> to have jobs.
>
> 5) Use of DTPs by SubCA
>
> Google proposal: SubCAs may not use Delegated Third Parties in the
> validation process for domain names or IP addresses.
> Symantec proposal: SubCAs should be allowed to continue to use them in
> situations where they already do.
> Rationale: SubCAs should not be required to rejig their processes to
> work with Symantec.
>
> 6) SubCA Audit Timing
>
> Google proposal: SubCAs are audited at 3 month intervals in the 1st
> year, 6 months intervals in the 2nd year, and then yearly.
> Symantec proposal: after the initial audit, only yearly audits should be
> required.
> Rationale: Because SubCAs are established CAs, once an audit has been
> done to validate the transition, the subsequent audit schedule should be
> the standard yearly one, not the high-frequency 3/6 month one proposed.
>
> 7) Detailed Audits
>
> Google proposal: Symantec may be requested to provide "SOC2" (more
> detailed) audits of their new infrastructure prior to it being ruled
> acceptable for use.
> Symantec proposal: such audits should be provided only under NDA.
> Rationale: they include detailed information of a sensitive nature.
>

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

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

Re: New undisclosed intermediates

[Alex Gaynor via dev-security-policy]

On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 05/06/17 14:29, Alex Gaynor wrote:
> > > As I've expressed before, I find it baffling that this still happens.
> >
> > I am also disappointed. I have half a mind to keep track of how often
> > this happens per CA, and impose a mandatory delay of 1 month per
> > incident to that CA's next attempt to include a new root or get a trust
> > bit or EV change in our store. :-)
> >
>
> A potential downside to that is that it favors incumbents, who often can
> continue to utilize existing root certificates, while new entrants would
> face a barrier to entry.
>
> That said, it absolutely should be getting tracked, per CA, as incident
> reports in Bugzilla and provided to the community.
>
> Alex, do you have the specific list of CAs at the time of your posting?
>
>
Yes, it was:

* QuoVadis
* AC Camerfirma, S.A.
* Chunghwa Telecom Corporation
* Start Commercial (StartCom) Ltd.

QuoVadis disclosed their intermediate within a few hours of my email, the
others still have not.


>
> > Aside from taking a note of how often this happens and it perhaps
> > appearing in a future CA investigation as part of evidence of
> > incompetence, does anyone else have ideas about how we can further
> > incentivise CA compliance with a requirement which was promulgated some
> > time ago, for which all the deadlines have passed, and which should be a
> > simple matter of paperwork?
> >
>
> Short of disabling trust bits on a 'go forward' basis (e.g. no new issuance
> after date X), most of the ideas favor existing legacy CAs at the expense
> of newer CAs.
>
> This is why I suggested the broader proposal of only adding root CAs with a
> defined 'shutdown' period (e.g. after 3-5 years), and requiring the
> frequent rotation of included root certificates. This ensures that the
> ability to distrust certificates on a go-forward basis is built into the
> ecosystem as the steady state, such that non-compliance, stalling tactics,
> incomplete disclosures, incomplete remediations, lack of addressing
> community questions and feedback, etc can all be appropriately addressed as
> the default state, with the only CAs continuing participation being those
> that are active and engaged with the community and the issues.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

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

New undisclosed intermediates

[Alex Gaynor via dev-security-policy]

Happy Monday!

Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
https://crt.sh/mozilla-disclosures#undisclosed

There are four intermediates here, and with exception of the StartCom one,
they were all issued more than a year ago.

As I've expressed before, I find it baffling that this still happens. To
approach this more productively, I'd be very appreciative if someone from a
CA could describe how they approach disclosing intermediates, where it fits
into their process, how they track progress, etc.

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

Fewer round trips, if you can include everything in a single response.

Alex

On Tue, May 16, 2017 at 11:11 AM, Ryan Sleevi  wrote:

>
>
> On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
>> 
>>
>>> The important point in this is that there should not be a non-linear path
>>> of trust (which is implied, I think, by the reading of "group of
>>> cross-certs"). But yes, there would be a linearized path.
>>>
>>
>> If you *rely* on AIA, then why not set the AIA->caIssuers content to be a
>> PKCS#7 "group of cross-certs" ?
>
>
> 1) Clients don't widely support PKCS#7
> 2) LOL PKCS#7 is a tirefire
> 3) Because that's an added/unnecessarily complexity to the PKI which is
> pretty detrimental compared to a linearized path.
>
> I presume, but perhaps you can clarify, that the 'group of cross-certs' is
> meant to cover the case where you have roots A, B, C, where A was created a
> T-6, B at T-3, and C at T0, with an intermediate I issuing leaf L
>
> I presume that your goal is that rather than expressing:
> L -> I -> C -> B -> A
>
> That you want to express
>
> L -> I -> C
>  -> C2 (via AIA) -> B
>  -> C3 (via AIA) -> A
>
> Is that correct? What is the advantage of that, given that PKCS#7 involves
> BER, it introduces C/C2/C3, and you're still supplying the same number of
> certs?
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

While the internet is moderately good at handling a single cross-sign
(modulo the challenges we had with 1024-bit root deprecation due to a bug
in OpenSSL's path building -- now fixed), as we extend the chains, it seems
evident to me that server operators are unlikely to configure their servers
to serve a chain which works on all clients -- the likely result is clients
will need AIA chasing. Most (all?) non-browsers do not implement AIA
chasing. This isn't an objection, just a flag and a potential action item
on the "non-browser" side of this.

Alex

On Tue, May 16, 2017 at 10:27 AM, Rob Stradling 
wrote:

> On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote:
>
>> Ryan,
>>
>> If you look at the wide range of user agents accessing google.com today
>> you'd see many legacy applications and older versions of browsers and
>> custom browsers built from variants of the commercial browsers.  By the
>> time all/most users upgraded to new browsers, it would be time to change
>> the roots out again and this will impact the ability for web site operators
>> to enable TLS for all visitors.
>>
>> Before we can implement a short Root usage policy we'd need to convince
>> all browsers to follow a process for rapid updates of root stores.
>>
>
> Hi Doug.
>
> Imagine a root cert A, valid for a short duration; and a root cert B,
> valid for a long duration.
>
> Under Ryan's proposal, Mozilla would put A (but not B) in NSS, whereas
> other less agile root stores would contain B.
>
> A doesn't have to be in every root store, because B can cross-certify A.
> (Let's call the cross-certificate A').
>
> A widely compatible cert chain would therefore look like this:
> B -> A' -> Intermediate -> Leaf
>
> If you're already cross-certifying from an older root C, then an even more
> widely compatible cert chain would look like this:
> C -> B' -> A' -> Intermediate -> Leaf
>
>
> --
> 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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

Hi Ryan,

I've lost the thread on how this addresses Cory's original problem
statement, if you could spell that out that'd be very helpful.

Alex

On Tue, May 16, 2017 at 10:22 AM, Ryan Sleevi  wrote:

>
>
> On Tue, May 16, 2017 at 7:58 AM, Peter Gutmann 
> wrote:
>
>> Ryan Sleevi  writes:
>>
>> >I can't help but feel you're raising concerns that aren't relevant.
>>
>> CAs issue roots with effectively infinite (20 to 40-year) lifetimes
>> because
>> it's too painful to do otherwise.  You're proposing instead:
>>
>
> That's not an appropriate summary of the issues, but equally, as I already
> described, and perhaps could work through with you if you had further
> questions (rather than criticisms), that the 'too painful' scenario is
> still meaningfully addressed.
>
>
>>
>>   require that all CAs must generate (new) roots on some interval (e.g. 3
>>   years) for inclusion.
>>
>> (that's quoted from the original message I replied to).  How do you
>> propose
>> that Mozilla is going to get every commercial CA on earth to do this?
>>
>
> The same way we in the Mozilla community have made progress for the past
> decade - https://www.mozilla.org/en-US/about/governance/policies/
> security-group/certs/policy/
>
> It's fairly easy to submit PRs to https://github.com/mozilla/pkipolicy
> and discuss. Perhaps we can discuss the substance of the proposal, and work
> through any confusion or misunderstanding, rather than suggesting it's not
> possible because it's hard (of which both are not correct)
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

That's not an appropriate way to participate in a mailing list, please
communicate civilly.

Alex

On Tue, May 16, 2017 at 8:53 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 11/05/2017 18:42, Ryan Sleevi wrote:
>
>> On Thu, May 11, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> Ryan,
>>>
>>> I think you've correctly highlighted that there's a problem -- the
>>> Mozilla
>>> CA store is "designed" to be consumed from NSS, and CA-specific
>>> remediations are a part of that (hash algorithms, maximum certificate
>>> lifetimes, and any number of other important technical controls).
>>>
>>> Unfortunately, we're currently in a position where near as I can tell,
>>> most
>>> code (except Go code :P) making HTTPS requests are using a
>>> Mozilla-derived
>>> CA store, and OpenSSL's verifier, which only provides a subset of the
>>> technical controls browsers implement. This is unfortunate, particular
>>> because these clients also do not check CT, so it's entirely possible to
>>> serve them certs which are not publicly visible. In a large sense,
>>> browsers
>>> currently act as canaries-in-the-coalmine, protecting non-browser
>>> clients.
>>>
>>> Like Cory, I help maintain non-browser TLS clients. To that end, I think
>>> it'd be outstanding if as a community we could find a way to get more of
>>> these technical controls into non-browser clients -- some of this is just
>>> things we need to do (e.g. add hash algorithm and lifetime checking to
>>> OpenSSL or all consumers of it),
>>>
>>
>>
>> Yes :) There's a significant amount that needs to happen in the
>> third-party
>> verifiers to understand and appreciate the risk of certain behaviours ;)
>>
>>
>> other's need coordination with Mozilla's
>>> root program, and I think Cory's proposal highlights one way of making
>>> that
>>> happen.
>>>
>>
>>
>> Right, but these already flow into the NSS trust store - when appropriate.
>> I'm sure you can understand when a piece of logic is _not_ implemented in
>> NSS (e.g. because it's not generic beyond the case of browsers), that it
>> seems weird to put it in/expose it in NSS :)
>>
>> To be clear: I'm not trying to suggest it's an entirely unreasonable
>> request, merely an explanation of the constraints around it and why the
>> current approach is employed that tries to balance what's right for
>> Mozilla
>> users and the overall NSS using community :)
>>
>>
> Can you please get it into your thick skull that this thread is NOT
> ABOUT NSS, IT IS ABOUT ALL THE OTHER X.509 LIBRARIES that can be
> configured to use a copy of the Mozilla Root store!
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

Once upon a time I would said "yes, we should totally encourage people to
lovingly craft their perfect trust store, to reduce their risk profile".
Now, not so much.

As we've seen in numerous discussions, customers of CAs, particularly large
enterprises and vendors (think payment terminals) love to pick out one or
two roots, ship them to a billion devices with no update capability, and
then use this as an argument against improvements to the WebPKI ecosystem
(e.g. SHA-1) or CA distrust (e.g. take a wild guess :-P). Hand crafted
trust stores are significantly less likely to have any hope of getting an
update than just shipping the whole Mozilla bundle. Further, with CT
enforcement, you can get basically the same security guarantee (only certs
I intend; +/- 24 hours) without burdening the ecosystem with your lack of
agility.

Cheers,
Alex

On Mon, May 15, 2017 at 9:19 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 12/05/17 09:18, Cory Benfield wrote:
> > I try not to decide whether there is interest in features like this:
> > if they’re easy I’d just implement them and let users decide if they
> > want it. That’s what I’d be inclined to do here. If Mozilla added
> > such a flag, I’d definitely be open to adding an extra certifi
> > bundle. Certifi currently already ships with two bundles (one
> > labelled “weak”, which includes 1024-bit roots to work around
> > problems with older OpenSSLs), so we could easily add a third called
> > “strong” or “pedantic” or “I hate CAs” or something that removes any
> > CA that is subject to graduated trust in Firefox.
>
> If people actually care enough to make a root store choice, should we be
> encouraging them instead to use a store containing only the CA they care
> about for the connection they are making (and perhaps a backup)? In
> other words, is some sort of easy-to-use root store filtering/splitting
> tool a better solution to this issue?
>
> 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: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

I think you left this a bit implicit Cory, so I figured it's worth spelling
out: the strength of Mozilla's CA program, as a tool for making the web
stronger, comes from having people using it, that's the carrot that forces
people to meet our standards (also the fact that as a transparent, root
program, we serve as a model for the industry!). If we can get better at
including the non-browser clients, who are already using the "raw" trust
store, it only strengthens our ability to secure the web -- I think we can
all agree that's a good goal :-)

As you point out though, a huge challenge, is that historically CA-specific
remediations have been unique to the circumstances, which means any
remediaton we invent a syntax for may be used only once, and any new CA
misbehavior may necessitate a remediation we don't have a syntax for yet.

I'm not smart enough to come up with a solution for this, other than that
maybe if we repeat the process enough times, we'll eventually standardize
on a small set of core remediations -- hopefully we never get there though
:-)

Alex

On Thu, May 11, 2017 at 2:30 PM, Cory Benfield  wrote:

>
> > On 11 May 2017, at 19:27, Gervase Markham  wrote:
> >
> > On 11/05/17 18:05, Alex Gaynor wrote:
> >> I don't think Cory's arguing against browsers making use of these types
> of
> >> remediations, he just wants the non-browser clients to be able to
> >> participate as well :-)
> >
> > Sure. I'm just heading off that argument at the pass :-)
>
> Yeah, Alex is right. I’m *extremely* supportive of the graduated trust
> proposals: indeed, I think MDSP’s behaviour and remedies have been
> exemplary. I was just feeling out the possibility of Mozilla turning into a
> force multiplier.
>
> Cory
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

On Thu, May 11, 2017 at 1:03 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Cory,
>
> On 11/05/17 15:21, Cory Benfield wrote:
> > While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can follow very easily.
>
> Unfortunately, this is not a good enough reason to remove graduate trust
> proposals from our arsenal of possible remedies for issues. Because if
> the choice is only "trust everything" or "do not trust anything" from a
> particular root, we have no mitigations for the Too Big To Fail problem.
>

I don't think Cory's arguing against browsers making use of these types of
remediations, he just wants the non-browser clients to be able to
participate as well :-)


>
> > If Mozilla is interested in doing a substantial public service, this
> situation could be improved by having Mozilla and MDSP define a static
> configuration format that expresses the graduated trust rules as data, not
> code.
>
> The trouble with this is that the vocabulary of such a format is almost
> unbounded. It effectively has to be code, rather than data, because we
> could in the future make any number of rules about certificates based on
> any number of criteria.
>
> So we decided to use English instead, which is why this exists:
> https://wiki.mozilla.org/CA/Additional_Trust_Changes
>
> Gerv
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

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

Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

Ryan,

I think you've correctly highlighted that there's a problem -- the Mozilla
CA store is "designed" to be consumed from NSS, and CA-specific
remediations are a part of that (hash algorithms, maximum certificate
lifetimes, and any number of other important technical controls).

Unfortunately, we're currently in a position where near as I can tell, most
code (except Go code :P) making HTTPS requests are using a Mozilla-derived
CA store, and OpenSSL's verifier, which only provides a subset of the
technical controls browsers implement. This is unfortunate, particular
because these clients also do not check CT, so it's entirely possible to
serve them certs which are not publicly visible. In a large sense, browsers
currently act as canaries-in-the-coalmine, protecting non-browser clients.

Like Cory, I help maintain non-browser TLS clients. To that end, I think
it'd be outstanding if as a community we could find a way to get more of
these technical controls into non-browser clients -- some of this is just
things we need to do (e.g. add hash algorithm and lifetime checking to
OpenSSL or all consumers of it), other's need coordination with Mozilla's
root program, and I think Cory's proposal highlights one way of making that
happen.

Alex

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

> But if you use the trust database without using NSS, you no longer fit into
> any of the assumptions or security models with the discussions here on
> m.d.s.p.
>
> A good example of this would be EKU related misissuance. NSS, like
> CryptoAPI and several other platforms, has for the past 15 or so years
> enforced a constraint that EKUs in intermediates are subsets of their
> issuer's, and can be used to reduce the scope of capabilities for issuance.
>
> As a result, a certificate with an S/MIME EKU issued from an intermediate
> that only has id-kp-serverAuth is not at risk of being trusted for S/MIME.
>
> In many ways, and across the industry, the trust Store is a function of the
> consuming and implementing libraries. As features change and are
> implemented - for example, support for Certificate Transparency - that
> naturally changes the risk calculus in the trust store.
>
> That's not to say what you request is apriori unreasonable, simply that
> it's unwise, which is why the FAQ covers this -
> https://wiki.mozilla.org/CA:FAQ
>
> There's also the reality that some changes are entirely appropriate for
> browser clients, but since Mozilla themselves are not using NSS in
> non-browser clients, but are aware that others are, they allow these other
> organizations and clients to make the decisions appropriate for their
> products and the risks and compatibility issues to their clients.
>
> The historic process is generally that a change is first made to Firefox,
> and then if it is generally desired by the ecosystem, trust status flags
> are introduced to NSS and added to the root store and library code. For
> example, the constraints for ANSSI followed this pattern.
>
> Microsoft follows a similar pattern - all "less than trusted" statuses are
> captured as extended attributes in the publicly available authroot.stl
>
> However, for both NSS and CryptoAPI, unless you are using the library
> itself to do verification, it's caveat emptor as the consumer. And even if
> you are using the library, you still have to be responsible for the
> security of your users as relevant to your products needs, and that's
> something Mozilla doesn't necessarily have insight into and naturally can't
> consider unless you participate here (ideally with commenting on proposals
> or sharing what your product would do). Although I suspect since most
> non-browser clients are more stable/less likely to update, and have less UI
> affordances, the general answer would be biased conservatively towards
> doing nothing than the steps necessary to protect browser users.
>
> On Thu, May 11, 2017 at 7:33 AM Cory Benfield via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote:
> >
> > > While I’m very supportive of this kind of remediation, it is not a
> > remediation that non-browser implementations can follow very easily. For
> > example, I run a downstream non-browser HTTP client[1] that by default
> uses
> > a processed version of the Mozilla CA database[2] to define its list of
> > trusted roots. This is very convenient, as it allows me to delegate the
> job
> > of running a CA program to Mozilla and MDSP, a collection of people much
> > better equipped to handle the job. This is a common approach throughout
> the
> > open source ecosystem: for example, curl also makes available a processed
> > version of the Mozilla trust database.
> >
> > I find it's useful to actually provide the footnotes you say you will:
> >
> > [1]: http://docs.python-requests.org/en/master/
> > [2]: https://github.com/c

Re: Draft further questions for Symantec

[Alex Gaynor via dev-security-policy]

Thanks Kurt.

Alex

On Mon, May 8, 2017 at 11:22 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2017-05-08 15:31, Alex Gaynor wrote:
>
>> I'm not the best way to phrase this, so please forgive the bluntness, but
>> I
>> think it'd be appropriate to ask at this point if Symantec has disclosed
>> all necessary intermediates (I believe this would be defined as: chain to
>> their roots in our trust store, are not expired, are not revoked, and are
>> not technically constrained), and would they be willing to state that if
>> new intermediate CAs are discovered beyond that point, it would reflect
>> either dishonesty or serious mismanagement of their PKI.
>>
>
> This was part of the March 2016 action 2. In
> https://mozillacaprogram.secure.force.com/Communications/CAC
> ommResponsesOnlyReport?CommunicationId=a05o00iHdtx&QuestionId=Q4
> you can see that their response was "2016 Apr 18"
>
> And confirmed in the April 2017 response to action 8, see:
> https://mozillacaprogram.secure.force.com/Communications/CAC
> ommRespWithTextAndTotalsReport?CommunicationId=a05o03Wrz
> BC&QuestionId=Q00020&QuestionIdForText=Q00026
>
>
>
> Kurt
>
> ___
> 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: Draft further questions for Symantec

[Alex Gaynor via dev-security-policy]

I'm not the best way to phrase this, so please forgive the bluntness, but I
think it'd be appropriate to ask at this point if Symantec has disclosed
all necessary intermediates (I believe this would be defined as: chain to
their roots in our trust store, are not expired, are not revoked, and are
not technically constrained), and would they be willing to state that if
new intermediate CAs are discovered beyond that point, it would reflect
either dishonesty or serious mismanagement of their PKI.

Alex


On Mon, May 8, 2017 at 9:20 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2017-05-08 14:24, Gervase Markham wrote:
>
>>
>> 1) Did any of the RAs in your program (CrossCert and co.) have the
>> technical ability to independently issue EV certificates? If they did
>> not not, given that they had issuance capability from intermediates
>> which chained up to EV-enabled roots, what technical controls prevented
>> them from having this capability?
>>
>
> It has a duplicate "not" there.
>
> Issue Y
>> ---
>>
>> 3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2"
>> and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which
>> are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign
>> Universal Root Certification Authority") and yet do not have BR audits?
>>
>
> I'm wondering if the intermediate CA certificates recently published in CT
> should have it's own issue. As far as I know they should have been
> disclosed much earlier. It seems that (at least now) they're all either
> revoked by CRL on the 5th of May (but not disclosed as revoked) or expired
> except for one (https://crt.sh/?id=132854209).
>
> I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2 or
> G3, except that one that's not revoked.
>
> 4) These two intermediates have a number of sub-intermediates. Does
>> Symantec agree that not all of these sub-intermediates are within the
>> scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how
>> many are in scope and how many are out of scope? If they are all in
>> scope, why are they not listed in the audit document?
>>
>
> The audit document says: "and the Symantec Non-Federal SSP – customer
> specific CAs (collectively referred to as the “Non-Federal SSP CAs”)."
>
> For which it then says that "our examination did not extend to the
> controls of external registration authorities."
>
> The management assertion also says:
> "Controls have inherent limitations, including the possibility of  human
> error and the circumvention or overriding of controls. Accordingly, even
> effective controls can provide only reasonable  assurance with respect to
> Symantec’s Non-Federal SSP CA operations. Furthermore, because of changes
> in conditions, the effectiveness of controls may vary over time."
>
>
> Kurt
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

Hi Rick,

Does Symantec plan to introduce new facts into the conversation, or is all
the information we are currently considering accurate and complete?

If there's no new information, I don't see why the community of
participants in m.d.s.p. should pause. I think it's a point of pride for
many of us that Mozilla operates a transparent root program, with strong
community input, and we want to continue that strong tradition.

Alex

On Sun, May 7, 2017 at 6:09 PM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I'm posting this on behalf of Symantec:
>
> We would like to update the community about our ongoing dialogue with
> Google.
>
> Following our May 4th post, senior executives at Google and Symantec
> established a new dialogue with the intention to arrive at a new proposal
> for the community that addresses the substantial customer impact that would
> result from prior proposals. We urge Symantec customers and the browser
> community to pause on decisions related to this matter until final
> proposals are posted and accepted. The intent of both Google and Symantec
> is to arrive at a proposal that improves security while minimizing business
> disruption across the community.
>
> We want to reassure the community that we are taking these matters and the
> impact on the community very seriously.
> ___
> 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: [EXT] Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

It is clear to me from reading this that there is a significant gap between
Symantec's perspective on the severity of the issues discussed and the
perspective of many m.d.s.p. participants. Hopefully this email will serve
to highlight some specific areas that contribute to this gap, and which
leads many of us to find Symantec's proposal insufficient.

Quoting:
> Moreover, the additional transparency we are already providing by logging
all certificates issued to Certificate Transparency logs – including DV and
OV – is a practice that the rest of the industry has yet to adopt.

Given that Symantec's CT logging was imposed as a requirement for continued
trust in Chrome, it is misleading to state that this reflects an effort by
Symantec to go above and beyond (particularly given that some other CAs
_voluntarily_ log all certs to CT).

That is, however, a question of style. To ask a substantive question, you
have asserted that all certificates issued have been logged to CT; this
Symantec CA currently has no publicly logged issued certificates:
https://crt.sh/?sha256=68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798&opt=mozilladisclosure.
Can you confirm that this CA has _never_ been used to issue a certificate?
(There are several other similar Symantec intermediates for which there are
no publicly logged certs about which I have the same question).

Some of Symantec's assertions (particularly those about re-auditing issued
certificates) seem to largely revolve around distinguishing the level to
which their practices resulted in mis-issuance and the level of risk they
represented for relying parties. To use an analogy, if I have a publicly
trusted CA certificate and private key on a USB stick in my apartment, this
represents a _massive_ risk for relying parties everywhere, even I never
issue a single certificate from it. I would expect the WebPKI community to
treat this with the utmost severity, even if I never (mis-)issued a single
a certificate!

Finally, Symantec states "we have put forward a proposal [1] that provides
the highest level of transparency and reassurance of trust in active
SSL/TLS certificates available in the industry" and "we believe our
proposal provides the most open and transparent posture of any CA in the
industry and reassures trust in active Symantec certificates and our
current issuance practice". To help bridge the gap between Symantec and
many other participants understanding, if Symantec were to propose an _even
more_ aggressive remediation plan, aiming to achieve even higher levels of
reassurance, what is the next additional change you would propose?

Alex


On Thu, May 4, 2017 at 11:30 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Gervase Markham via dev-security-policy
> > Sent: Monday, May 01, 2017 10:16 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Symantec: Draft Proposal
> >
> > Here is my analysis and proposal for what actions the Mozilla CA
> Certificates
> > module owner should take in respect of Symantec.
> >
> [snip]
>
> > Please discuss the document here in mozilla.dev.security.policy. A good
> > timeframe for discussion would be one week; we would aim to finalise the
> > plan and pass it to the module owner for a decision next Monday, 8th May.
> > Note that Kathleen is not around until Wednesday, and may choose to read
> > rather than comment here. It is not a given that she will agree with me,
> or
> > the final form of the proposal :-)
> >
> > Gerv
>
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-continues
> -public-dialogue
> .
>
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

Hi all,

This morning Symantec disclosed ~20 new intermediate certs. I went through
these and identified 7 of them which are a) not revoked, b) not expired, c)
lack a BR audit:

https://crt.sh/?q=54EFD2977D89EDE24DDC3797CEB5A80668B3905788B58FB1AC6893EF4B78A24A
https://crt.sh/?q=D7D90D0FCFB5CDEC5754D663EEB3915D53703E1A29FAEEB398DCE0E22B5D4F9A
https://crt.sh/?q=58FED89E47BC48DDC659419BB64BD0862A448FCB25842F8A3FA3671FF6468F42
https://crt.sh/?q=9127783BF5190D85BC5248364145AA683EC49CD63F344721B3914E2CAF61D7A0
https://crt.sh/?q=CC6D4E8FD20599A8CC23E739774EAFB70D03B24A824C0E05D94666F5E29FC5CA
https://crt.sh/?q=DEEE5527B753A18D02BA2DAD6DFFB674CED0AF657BC0F430D4B32D97580F4D0E
https://crt.sh/?q=BC983BE6435622EF64C8EFD23084D6F8E5DCFBE9D7BCFCE6A5E51C75A29D549A

I believe this further underscores finding Y, and others related to lack of
visibility into and BR-compliance of Symantec's intermediates.

The fact that we can still be finding new intermediates leaves me to wonder
if this is really the last of them, or there are still more. Personally, I
think this highlights the value of my earlier proposal, and I think it's
worth considering if, before any long term remediation strategies are
considered, such a rule requiring full disclosure and CT submission of all
Symantec CA certificates be implemented.

Cheers,
Alex



On Thu, May 4, 2017 at 2:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 01/05/2017 16:16, Gervase Markham wrote:
>
>> Here is my analysis and proposal for what actions the Mozilla CA
>> Certificates module owner should take in respect of Symantec.
>>
>> https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lU
>> PmatQZwx3Sn2NPz9jF8/edit#
>>
>> Please discuss the document here in mozilla.dev.security.policy. A good
>> timeframe for discussion would be one week; we would aim to finalise the
>> plan and pass it to the module owner for a decision next Monday, 8th
>> May. Note that Kathleen is not around until Wednesday, and may choose to
>> read rather than comment here. It is not a given that she will agree
>> with me, or the final form of the proposal :-)
>>
>>
> Some notes on the text now in the document:
>
> 1. Issue D actually seems to conflate three *completely different*
>   issues:
>
>   D1) MisIssuance of actual test certificates for real world domains
>  that had not approved that issuance.  I think this was mostly the
>  old issue involving a very small number of improper in-house test
>  certs by Symantec.
>
>   D2) Dubious / non-permitted substitution of the word "test" for the
>  organization name in otherwise fully validated OV certificates as
>  a service to legitimate domain holders wanting to test Symantec
>  certificates before paying for final issuance of certs with their
>  actual name.  This was much less harmful, but was done in large
>  numbers by the CrossCert RA.
>
>   D3) Dubious and actual misussance of certificates for some domains
>  containing "test" as a substring under the direction of the
>  CrossCert RA.  These vary in seriousness but I think their total
>  number is much smaller than those in category D2.
>
>   Splitting these three kinds of "test" certificates will properly give
>   a much clearer issue of what was going on and how serious it was.
>
> 2. If the remaining unconstrained SubCAs are operated by Symantec and
>   subject to (retroactive if necessary) compliance audits showing that
>   they don't issue certs that could not (under the BR and Mozilla
>   policies) be issued from a public Symantec CA by an "Enterprise RA"
>   (as defined in the BRs), could those SubCAs not simply be
>   reclassified as "public SubCAs" for Mozilla/BR policy purposes while
>   remaining further usage limited by actual Symantec practices and
>   contractual arrangements beyond the BR/Mozilla policies?
>
> 3. The plan involving a new hierarchy outsourced to a Symantec
>   competitor leaves some big questions when seen from outside the
>   Google perspective:
>
>- Is it really necessary to outsource this to bring the Symantec PKI
> under control?  Or was this simply copy/pasted from the
> WoSign/StartCom situation?
>
>- If this is outsourced as suggested, how can/should Symantec
> continue to serve customers wanting certificates that chain to
> older CA certs in the old hierarchy.  For example some brands of
> Smartphones require that all apps installed are signed by specific
> old Symantec hierarchies via exclusivity deals that were in place
> when those Smartphones were manufactured, and no changes to that
> requirement are feasible at this point for the already sold phones.
>  Similar issues may exist in the WebPKI for jobs such as providing
> HTTPS downloads of Firefox to machines whose existing browser is
> outdated and contains an outdated root store.
>
>- Should Symantec be allowed to cross-sign SubCAs of the new roots
> direc

Re: CA Validation quality is failing

[Alex Gaynor via dev-security-policy]

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

Cheers,
Alex

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

> (Still wearing Google Hat in this context)
>
> I think sharing a list (in CT) of the certs is good and can help verify the
> assertions made here :)
>
> But overall, I think this sounds right and the risk is minimal to our
> users, so not revoking still sounds good :)
>
> On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley  >
> wrote:
>
> > Certainly happy to share more info. The search was for all EV and OV
> > certs. Of the 4000 certificates detected, 101 certificates are EV. Of
> these
> > EV certificates, 17 would be included in the proposed revocation. The
> rest
> > have the “N/A” issue. This is just the locality/state/zip. The
> jurisdiction
> > of incorporation processes separately and doesn’t have the same
> > auto-populate tool.
> >
> >
> >
> > More info:
> >
> > 78 certs had non-US states populated with US states (thanks to the
> > auto-populator)
> >
> > 791 entities are affected by the entire range of certificates
> >
> > 257 entities are affected if we revoke the 1033 certs
> >
> > 82 entities are affected if we revoke just the 150 certs
> >
> >
> >
> > What else would you like to know?
> >
> >
> >
> > Jeremy
> >
> >
> >
> > *From:* Ryan Sleevi [mailto:r...@sleevi.com]
> > *Sent:* Monday, May 1, 2017 5:01 PM
> > *To:* Jeremy Rowley 
> > *Cc:* Gervase Markham ; mozilla-dev-security-policy@
> > lists.mozilla.org
> > *Subject:* Re: CA Validation quality is failing
> >
> >
> >
> >
> >
> >
> >
> > On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > There isn't anything in our CPS directly. However, we state that we
> follow
> > the baseline requirements in the CPS. The baseline requirements give a
> > profile for the state field. We weren't sure this was strictly followed.
> >
> > We finished our validation review over the weekend.   There are about
> 3000
> > older certs with information indicating a field was not applicable (such
> as
> > a "-", "N/A", etc). On top of this, we issued about 1000 certificates
> with
> > mismatched validation information. The mismatched information can be
> > divided into about 850 certificates with numbers in the state field.
> These
> > numbers indicate a location code that was provided by the auto-populator.
> > The remaining 150 are certificates with "Select", a state, or a postal
> code
> > improperly included in the certificate.  The root issue was a combination
> > of the auto-populator inserting incorrect data into the cert request and
> > our validation staff not properly updating the certificate information
> > after completing the validation process.
> >
> > Based on these results, we propose the following remediation plan:
> > 1. We already removed the auto-populator from our CSR and certificate
> > order generators.
> > 2. We already blocked this information on the CA side from included in
> > signed SSL/TLS objects.
> > 3. We will revoke the 150 certificates with mismatched information.
> > 4. We plan to let the remaining 3850 expire normally but will correct the
> > certificate for all future orders (including rekeys).
> >
> > Is this an acceptable plan? We are proposing not revoking the 3850
> > certificates because the information isn't misleading, the information is
> > accurate, and there isn't a risk posed to Mozilla's users by inclusion of
> > the numeric location code or not applicable indicator. Any thoughts?
> >
> >
> >
> > (With a Google hat on)
> >
> >
> >
> > Jeremy,
> >
> >
> >
> > I think with the information you've shared so far, that sounds like a
> > reasonable plan from Google's perspective for the 3000 certificates. I
> > think there's at least a little concern about the EV nature for the 850
> > side, but just trying to understand more here what the implications would
> > be. Is this exclusively the state, or does it also extend to the
> > jurisdiction* fields? Or is this only for EV?
> >
> >
> >
> > Would you be able to share a spreadsheet or details for those, in the
> > spirit of transparency? I think if you can share those details, it's
> > reasonable to avoid revoking, and anything specific that might represent
> a
> > security/compat risk to an Application Software Supplier (i.e.
> 4.9.1.1(15)
> > ), we can look into separately.
> >
> >
> >
> > Thank you for
> >
> > 1) Disclosing the details to a sufficient level of detail immediately
> >
> > 2) Providing regular updates and continued investigation
> >
> > 3) Confirming the accep

Re: Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

Hi Gerv,

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

Alex

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

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

Re: Symantec Conclusions and Next Steps

[Alex Gaynor via dev-security-policy]

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

Hi Steve,

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

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

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

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

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

Thanks,
Alex

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

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

Re: Symantec Conclusions and Next Steps

[Alex Gaynor via dev-security-policy]

On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Your post made me realize that we never publicly posted the status of these
> last few CAs. Sorry about that.  Here's the plan:
>
> 1. ABB - ABB was supposed to be technically constrained (and is restricted
> to certain names). However, the technical constraints were added
> incorrectly
> and didn't exclude IPv6.  We're working with them to update the
> intermediate
> with a properly constrained sub CA.
>
> 2. Bechtel - The Bechtel intermediates are scheduled for revocation the
> last
> day of April.
>
> 3. Nets Norway - This intermediate lacked an EKU but was constrained to
> certain domain names under Nets Norway's control. Nets Norway is no longer
> using the intermediate but would like to leave the intermediate active
> until
> the certs expire. I'm not sure what to do on this one. Any thoughts?
>
>
To save everyone else 3 minutes of search crt.sh, the oldest cert that I
saw under this intermediate was November 2019.

Alex


> 4. Belgium Roots - The Belgium roots have audits now. We are waiting on the
> audit report publication to change the status. The reports were provided to
> the browsers but aren't available publicly yet. The Belgium CAs only issue
> client certificates.
>
> Jeremy
>
>
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=
> digicert.com@lists.mozilla
> .org] On Behalf Of Rob Stradling via dev-security-policy
> Sent: Thursday, April 27, 2017 4:38 AM
> To: mozilla-dev-security-policy
> 
> Subject: Re: Symantec Conclusions and Next Steps
>
> On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:
> 
> > (Note: A few of the non-Symantec entries currently listed by
> > https://crt.sh/mozilla-disclosures#undisclosed are false positives, I
> > think.  It looks like Kathleen has marked some roots as "Removed" on
> > CCADB ahead of the corresponding certdata.txt update on mozilla-central).
>
> Ah, I take that back.  The March certdata.txt update did hit
> mozilla-central
> on 11th April, but I missed an alert.  I've just pushed that update to
> crt.sh.
>
> https://crt.sh/mozilla-disclosures#undisclosed is currently free of false
> positives.  It shows that DigiCert, StartCom and Symantec are currently
> out-of-compliance with Mozilla's disclosure requirement.
>
> --
> 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
>
> ___
> 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