Re: Symantec Issues List

[Peter Bowen via dev-security-policy]

On Fri, Mar 31, 2017 at 4:38 PM, Ryan Sleevi via dev-security-policy
 wrote:
> On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham wrote:
>
>> As we continue to consider how best to react to the most recent incident
>> involving Symantec, and given that there is a question of whether it is
>> part of a pattern of behaviour, it seemed best to produce an issues list
>> as we did with WoSign. This means Symantec has proper opportunity to
>> respond to issues raised and those responses can be documented in one
>> place and the clearest overayll picture can be seen by the community.
>
> (Wearing a Google hat)

(Wearing my normal personal non-work hat)

> In March of last year, Symantec provided us a list of five sub-CAs which
> they termed GeoRoots: Apple, Google, Unicredit, Aetna, NTT Docomo - and
> requested they be excluded from this requirement. We asked Symantec to
> provide current audit statements for each of these CAs.
>
> Symantec indicated that the audit information for these sub-CAs would be
> added to the CCADB. This was on 3/29.
>
> We then followed-up with Symantec, again, because as of 6/28, there were
> several outstanding issues with Symantec's disclosures:
>
> - Apple IST CA 3 was not covered by the general set of Apple audits
> - No audit information for Aetna was provided, and its CPS was dated in 2011
> - No audit information for Unicredit was provided
> - NTT Docomo (DKHS and DKHS CA2) were disclosed as being part of Symantec's
> audit
>
> Upon follow-up, Symantec provided Aetna's WebTrust for BRs audit. On it,
> there were 15 qualifications, some of which would have spanned the totality
> of operation.
>
> Regarding Unicredit, Google requested that Symantec place us in direct
> contact with Unicredit. We had several calls with Unicredit's management
> team regarding the issues, attempting to find a path to see if they would
> be able to complete a Baseline Requirements audit.
>
> I want to share these details so that a fuller picture of the GeoRoot
> issues can be noted. Particularly concerning is the seriousness of the
> Aetna issues and the failure to remedy them, and the failure to identify
> the NTT Docomo (DKHS) roots as part of Symantec's infrastructure.
(some portions of the quoted text omitted)

Ryan,

I haven't reviewed the audit reports myself, but I'll assume all you
wrote is true.  However, I think it is important to consider it in the
appropriate context.

The GeoRoot program was very similar to that offered by many CAs a few
years ago.  CyberTrust (then Verizon, now DigiCert) has the OmniRoot
program, Entrust has a root signing program[1], and GlobalSign Trusted
Root[2] are just a few examples.

In almost every case the transition to requiring complete unqualified
audits of the subordinates by a licensed practitioner was a rocky one.
See DigiCert's thread
(https://groups.google.com/d/msg/mozilla.dev.security.policy/tHUcqnWPt3o/U2U__7-UBQAJ)
about the OmniRoot program or look at the audits available for some of
the Entrust subordinates.

I'm not suggesting that the GeoRoot subordinate issues should not be
considered, but it seems the GeoRoot program was not notably
exceptional a few years ago.

Thanks,
Peter

[1] 
https://web-beta.archive.org/web/20140818191044/http://www.entrust.net/about/third-party-sub-ca.htm
[2] https://www.globalsign.com/en/certificate-authority-root-signing/
and 
https://web-beta.archive.org/web/20101008151742/http://globalsign.com/certificate-authority-root-signing/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Peter Bowen via dev-security-policy]

> On Mar 31, 2017, at 6:01 PM, Daniel Baxter via dev-security-policy 
>  wrote:
> 
> On Saturday, April 1, 2017 at 6:27:27 AM UTC+11, Jakob Bohm wrote:
>> Oh, come on, if that's her job title, that's her job title, and at any
>> CA, that is actually an important job that /someone/ should have.
> 
> I meant the content of her reply, not her job title.

Hi there,

I’m Peter.  I am a Principal Security Engineer at Amazon and Vice President of 
Amazon Trust Services (the certification authority).  I’ve been participating 
in this group for several years, mostly in an individual capacity. One of the 
part of the Mozilla CA program I value the most is open and transparent 
communication.  To that end, I appreciate the direct and clear email from Tarah 
to the group.

As the mozilla.dev.security.policy name indicates, this is a netnews (i.e. 
Usenet) group which is gatewayed to an email list and Google Group.  It is part 
of the Mozilla Forums, which are primarily a place for technical discussions.  
I would hope that anyone looking for a formal statement from any organization 
whose employees participate in this group would reach out to the appropriate PR 
team.

I'm glad to see posts that help keep a high signal-to-noise ratio in this 
fourm, as long as they fall within the etiquette rules 
(https://www.mozilla.org/en-US/about/forums/etiquette/).

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

Re: Grace Period for Sub-CA Disclosure

[Ryan Sleevi via dev-security-policy]

On Fri, Mar 31, 2017 at 12:24 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> As previously stated, I think this will be too short if the issuance
> happens at a time when a non-CCADB root program (or the CCADB
> infrastructure) is closed for holidays, such as the following:
>

I'm not sure I've heard of many web pages being closed for the holidays.
Are yours?

I think Rob Stradling's suggestion more than addresses this - within 1 week
of the intermediate being issued or the CA being granted access to the
CCADB, whichever is the later?

Considering CAs must have 24/7 uptime and be able to review and respond to
certificate problem reports within 24 hours, I think the suggestion of how
to define holidays is unnecessary.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[aractuspuphlicus--- via dev-security-policy]

On Saturday, April 1, 2017 at 6:51:30 AM UTC+11, Vincent Lynch wrote:
>
> It is simply a bug, related to an OID included in the certificate. This has
> been documented by Chrome
> .

OK, I'll update that, thanks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Daniel Baxter via dev-security-policy]

On Saturday, April 1, 2017 at 6:27:27 AM UTC+11, Jakob Bohm wrote:
> Oh, come on, if that's her job title, that's her job title, and at any
> CA, that is actually an important job that /someone/ should have.

I meant the content of her reply, not her job title.

> Unfortunately, when initially establishing encryption certificates, one
> generally has to start from some kind of unencrypted connection, such
> as an unencrypted phone call or an unencrypted e-mail, or an
> unencrypted paper mail.

Not the private key though. And besides, it doesn't matter if your CSR and 
Certificate are duplicated, they're not a secret only the private key is.

> But a password or random secret string in a URL /is/ authentication.
> And in an e-mail, it is behind whatever authentication you (not
> Symantec) have set up for that e-mail (and Symantec obviously didn't
> know about the Yahoo undisclosed breach at the time).

I don't know how to say this any other way - but that's unbelievably sloppy. 
That's like saying you'll let your customers email their credit card numbers to 
you. You don't put anything that sensitive into an email address, ever. Any 
time I get a password emailed to me I change it immediately.

Besides this is passing the blame to the customers. And there is a big 
difference of how informed each party was. Symantec knew about this exploit, 
customers didn't. They knew to take extra precautions, customers didn't have 
that knowledge.

> They need to only assume that whatever e-mail account people provide
> for signup is secure enough for the people choosing what e-mail to
> provide /and only on the day or week where they provide that e-mail
> address/.

So since December 2016 they banned all Yahoo! emails, right?

> But was he, or did you simply exaggerate something in your blog?

He says it on his facebook post: "for some third party vendors, depending on 
the type of certificate, and how the certificate was issued, you could also 
retrieve private keys."

> The Google issue is *microscopic* except Google is using it as a lame
> excuse to threaten Symantec big time.

I believe the 30,000 number they talked about relates to the same security 
issue that Chris Byrne identified. If it didn't then here's my question: how 
many certificates were affected by the Chris Byrne issue?

On Saturday, April 1, 2017 at 9:11:00 AM UTC+11, tarah.s...@gmail.com wrote:
> 
> So sorry, but I don't know what you're referring to. Did you tweet me a link 
> to a blog post? Blame Jack if so; all of us are dealing with hugely 
> problematic threading today due to the Twitter @ changes. If you reply here 
> with what you are talking about, I can take a look, though unfortunately I 
> might not be able to get to it today. I always like hearing opposing 
> viewpoints.

Sure, it's no secret: https://blog.aractus.com/the-symantec-ssl-shitstorm/

That page I'm pretty sure wasn't even indexed in google when I posted. Even it 
it was, my viewership is only small. I was here reading these threads, and 
gathering more information so that I can fix up all the errors I've made - 
that's how we all learn, by making mistakes and fixing them. Anyway, I only 
used primary sourced material (ie, the google groups discussions, Chris's 
facebook post, and the Symantec website), I haven't read anything on Twitter.

Again, I obviously can't speak for others, but any confusion over the facts 
here could have been easily avoided had Symantec made a full public statement 
about the Chris Byrne vulnerability the moment that it no longer posed a threat 
to customers.

Where I will agree with you is that from the description, it would have 
involved a fairly sophisticated attack to steal private keys from the 
"incompetent resellers", and that they were equally culpable.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Issues List

[Ryan Sleevi via dev-security-policy]

On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> As we continue to consider how best to react to the most recent incident
> involving Symantec, and given that there is a question of whether it is
> part of a pattern of behaviour, it seemed best to produce an issues list
> as we did with WoSign. This means Symantec has proper opportunity to
> respond to issues raised and those responses can be documented in one
> place and the clearest overayll picture can be seen by the community.
>
> So I have prepared:
> https://wiki.mozilla.org/CA:Symantec_Issues
>
> I will now be dropping Symantec an email asking them to begin the
> process of providing whatever comment, factual correction or input they
> feel appropriate.
>
> If anyone in this group feels they have an issue which it is appropriate
> to add to the list, please send me email with the details.
>

(Wearing a Google hat)

Gerv,

Thanks for organizing this information, as much of it was related to and
relevant to Google's recent announcement. I want to take this opportunity
to share additional details regarding the interactions for UniCredit, which
I believe may be useful and relevant both for understanding that issue and
the GeoTrust audits.

As the Chrome team announced at
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
, we made steps to require that all Symantec-issued certificates be
disclosed via Certificate Transparency.

In March of last year, Symantec provided us a list of five sub-CAs which
they termed GeoRoots: Apple, Google, Unicredit, Aetna, NTT Docomo - and
requested they be excluded from this requirement. We asked Symantec to
provide current audit statements for each of these CAs.

Symantec indicated that the audit information for these sub-CAs would be
added to the CCADB. This was on 3/29.

We then followed-up with Symantec, again, because as of 6/28, there were
several outstanding issues with Symantec's disclosures:

- Apple IST CA 3 was not covered by the general set of Apple audits
- No audit information for Aetna was provided, and its CPS was dated in 2011
- No audit information for Unicredit was provided
- NTT Docomo (DKHS and DKHS CA2) were disclosed as being part of Symantec's
audit

Upon follow-up, Symantec provided Aetna's WebTrust for BRs audit. On it,
there were 15 qualifications, some of which would have spanned the totality
of operation. If Symantec is not willing or able to provide this audit, we
would be happy to, in the interest of public transparency.

This audit was dated May 11, 2016, but covered the period January 1, 2015
through December 31, 2015. I highlight this, because this means it was
provided 132 days after the close of the period, or 42 days after provided
for by the Baseline Requirements. This audit was performed by Symantec's
auditors, KPMG, and thus demonstrates the pattern of delayed audits that
KPMG has shown a tendency for, and extends beyond just Symantec.

I want to highlight some of the qualifications on this audit:
"It was noted that:
 physical access to the cage housing the CA system was not logged;
 event logs for the CA prior to July 2015 were not available; and
 logs are not reviewed periodically."
"It was noted that no training programs were in place for Trusted Role
personnel."
"It was noted that a security risk assessment of the Aetna CA operations
was not performed during the examination period."
"It was noted that a security risk assessment of the Aetna CA operations
was not performed during the examination period."
"It was noted that penetration testing was not performed on the PKI
environment during the examination period."

Symantec's proposed remediation for this was to allow their contract to
expire, and proposed revoking this certificate in October. Note that this
was still nearly 3 months later.

Regarding NTT Docomo, Symantec repeatedly asserted they controlled issuance
for these CAs. However, I highlight this, because the Geotrust audits note
5 sub-CAs, so the fifth sub-CA, if not NTT Docomo, remains unknown and
unidentified by Symantec during the same time as their audit. If NTT Docomo
was issued and managed by Symantec, then their auditor (KPMG) did not
examine this.

Regarding Apple's IST CA 3 (and subsequently issued by Symantec, IST CA 8 -
G1), Apple requested and Google accepted a discussion with their CA
operations team. After discussions with the team, we received suitable
assurances from Apple that these two CAs were operated in accordance with
their CP/CPS and would be part of the next audit. As has been discussed in
other threads, there is a natural period of time where the scope of the
audit does not cover any newly issued intermediates, but we ensured that
these were listed within Apple's next CP/CPS, and thus scoped for the next
audit. Because of this reason alone, we excluded these sub-CAs from our CT
requirement.

Regarding Unicredit, Google requested that 

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[mono.riot--- via dev-security-policy]

Maybe I'm alone in this but, while entertaining, I'm taken aback a bit if this 
is official Symantec communication in a forum like m.d.s.p. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[tarah.symantec--- via dev-security-policy]

> 
> Yeah OK, I got a few things wrong on my blog post, I can fix that shortly. 
> It's no big deal. At least I'm informing people about security - claiming 
> that we're just "looking for hits" is ridiculous. Most people pay no 
> attention to security, I can't speak for others but I'm trying to inform.
> 

So sorry, but I don't know what you're referring to. Did you tweet me a link to 
a blog post? Blame Jack if so; all of us are dealing with hugely problematic 
threading today due to the Twitter @ changes. If you reply here with what you 
are talking about, I can take a look, though unfortunately I might not be able 
to get to it today. I always like hearing opposing viewpoints.

I feel like Jakob basically covered every other point.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

[Kathleen Wilson via dev-security-policy]

I have moved the draft of the April 2017 CA Communication to production, so the 
link has changed to:

https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o03WrzBC

It is also available here:
https://wiki.mozilla.org/CA:Communications#April_2017

Note to CAs: The survey is now visible in the CCADB via the "CA Communications 
(Page)" tab, but DO NOT TAKE THE SURVEY YET. You will not be able to submit 
your survey answers until I update the "Expiration Date" to a date in the 
future. I will do this when the survey is ready to be sent.


Notable changes in this version:

1) Added free text Comments boxes to many of the action items.

2) Added ACTION 14: CERTIFICATE VALIDITY PERIODS IN TLS/SSL CERTS

3) Updated the last two bullet points in ACTION 5...
+ The word "clean" must be included in audit statements for which no problems 
were noted.
+ For ETSI - the attestation should additionally state that the audit was a 
full audit, and must indicate which parts of the criteria applied (e.g. DVCP, 
OVCP, NCP, NCP+, LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), Part 2 
(Requirements for trust services Providers issuing EU qualified certificates)). 

4) Moved the "respond by" date to April 28.


Please let me know asap if you see any problems, typos, etc. in this version.

I would like to send this CA Communication next week.

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Vincent Lynch via dev-security-policy]

>
> Finally, what have you actually done to address EV revocation? You clearly
> didn't bother to tell Commonwealth Bank:
>
> https://www.commbank.com.au/
>
> One of the largest banks in Australia that their EV status would evaporate
> in Chrome. So what did you do to inform your customers about this?



As Jacob Bohm has said in his reply, Google's proposal to remove EV status
for Symantec certificates has *nothing* to do with this report.

Furthermore, the issue you have brought up with Commonwealth Bank has
*nothing* to do with *either* of the two separate issues Symantec is
currently dealing with. It also has nothing to do with Commbank.com.au
being "hacked," as you have written on your website
.

It is simply a bug, related to an OID included in the certificate. This has
been documented by Chrome
.

You can test this by visiting https://www.commbank.com.au/ in Chrome
Canary, which has fixed the bug, and returned the green address bar to the
site.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

The revised example is not entirely what I had in mind (more on that in a 
minute) but as written now is mostly OK by me. I do have a question as to 
whether the public discussion as mentioned must take place before the actual 
transfer? In other words, will Mozilla require that whatever entity is trying 
to purchase the root must be fully admitted into the root program before the 
transfer takes place?

Also, let me state that I did not intend to besmirch the names of either HARICA 
or WoSign and I appreciate their indulging my use of their names in what turned 
out to be a sloppy illustration. Based on my review of HARICA's CPS some months 
ago, I was left with the impression of them as a tightly-focused ‎organization 
that, by all appearances, is well-run. And that was the image I had mind and 
had hoped to convey in using their name. By mentioning WoSign I was really 
thinking of only the state of their reputation at the moment--and I think it's 
fair to say it's been tarnished? The reasons for WoSign being in the position 
they are in were totally irrelevant to what I had in mind.

So what was my point? In essence, I wanted to suggest that not every company 
seeking to purchase a root from another company will necessarily have good 
intentions and even if they do, their intentions might not be in the interest 
of the public good. I think it's important to at least acknowledge that 
possibility and try to have policies in place that encourage the good and limit 
the bad.

I don't know if people are on board with this notion or if some hypothetical 
scenarios are needed at this point? For now I'll just pause and let others 
either ask or comment away.


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Friday, March 31, 2017 12:28 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 31/03/17 17:39, Peter Bowen wrote:
>>> For example, how frequently should roots
>>> be allowed to change hands? What would Mozilla's response be if
>>> GalaxyTrust (an operator not in the program)
>>> were to say that they are acquiring the HARICA root?
>>
>> From the above URL: "In addition, if the receiving company is new to the
>> Mozilla root program, there must also be a public discussion regarding
>> their admittance to the root program."
>>
>> Without completing the necessary steps, GalaxyTrust would not be admitted to
>> the root program.
> 
> I've modified the quoted text a little to try to make this example
> clearer, as I think the prior example conflated multiple things and
> used language that did not help clarify the situation.
> 
> Is the revised example accurate?

The revised example is accurate.

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

Symantec Issues List

[Gervase Markham via dev-security-policy]

As we continue to consider how best to react to the most recent incident
involving Symantec, and given that there is a question of whether it is
part of a pattern of behaviour, it seemed best to produce an issues list
as we did with WoSign. This means Symantec has proper opportunity to
respond to issues raised and those responses can be documented in one
place and the clearest overayll picture can be seen by the community.

So I have prepared:
https://wiki.mozilla.org/CA:Symantec_Issues

I will now be dropping Symantec an email asking them to begin the
process of providing whatever comment, factual correction or input they
feel appropriate.

If anyone in this group feels they have an issue which it is appropriate
to add to the list, please send me email with the details.

Thanks,

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[tarah.symantec--- via dev-security-policy]

> Yep, but there must have been an API (at some level) for generating or
> processing the QuickInvite URL.  That was what I was suggesting might
> have been the issue.

So, it's hard for me to answer this question because I didn't see any POC, but 
1) it's not physically possible for private keys to be revealed in the 
interface as described to me and in which I've spent the last few days 
completely submerged, and 2) there's still the validation process which isn't 
simply bypassed with this URL.

I have to be cautious here in a couple of my answers, and I hope you appreciate 
why: as soon as I found out Symantec wasn't affected any more by this reseller, 
I found out who was. I have to responsibly disclose that information first and 
get a confirmation from them. I've already notified everyone I had contact info 
for there, and I'll stay on them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Jakob Bohm via dev-security-policy]

On 31/03/2017 19:31, tarah.syman...@gmail.com wrote:

On Friday, March 31, 2017 at 9:51:03 AM UTC-7, Jakob Bohm wrote:

Dear Tarah,

Below some friendly speculation as to what the parts that some bloggers
claimed was included (if those claims were somehow true) might have
been (i.e. where *you* might look for it in internal Symantec
systems/records).




Thank you.






Could this be about some other URLs in the (now hopefully closed) RA
interface?  Such as an interface for requesting the QuickInvite URL for
later forwarding to the subscriber?

Perhaps an interface that takes only "known/guessable" parameters, such
as subscriber e-mail or order number?  This would explain the claim
that an URL sent to one subscriber by an incompetent RA could be
edited to retrieve the data for another subscriber.



Nope. That QuickInvite URL was/is hashed and salted. I have personally seen the 
code for generating it. Just editing stuff in that URL without being able to 
crack it wouldn't give any useful information or lead anywhere. Although now 
I'm kinda wanting to create a specific error page for people who try. Nah. It'd 
be funny to me and anyone trying to hack those but the customers wouldn't get 
my jokes, likely. Brute forcing the URL would take too long, which is why I 
agree with the original decision to decrease the URL validity timespan. It 
helps prevent brute force attacks too.



Yep, but there must have been an API (at some level) for generating or
processing the QuickInvite URL.  That was what I was suggesting might
have been the issue.


Also, just was chatting with Chris. I just found out that the reseller in 
question was dropped from our Symantec a while back. Details to follow, but 
suffice to say that they are no longer a problem for us.



Great!

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[tarah.symantec--- via dev-security-policy]

On Friday, March 31, 2017 at 9:51:03 AM UTC-7, Jakob Bohm wrote:
> Dear Tarah,
> 
> Below some friendly speculation as to what the parts that some bloggers
> claimed was included (if those claims were somehow true) might have
> been (i.e. where *you* might look for it in internal Symantec
> systems/records).
> >

Thank you. 

> 
> Did Symantec ever offer Symantec-generated private keys (e.g. PKCS#12
> files) via that or a similar mechanism?  That would explain the
> "private key" claim without an additional PoC.

That was available for 1 or 2 customers, but it was not via the QuickInvite 
interface . It took a downloaded Java app (dear lord) to make that happen, and 
my belief is that this practice ended around the same time as this initial 
report but was not related to this issue. I don't think anyone can do this 
anymore, and I'll follow up on that too, but even in that case, we would never 
have seen their private keys. Resellers should never have had the ability to 
generate key pairs and CSRs and if they said they did to Chris, I'm furious.


> Could this be about some other URLs in the (now hopefully closed) RA
> interface?  Such as an interface for requesting the QuickInvite URL for
> later forwarding to the subscriber?
> 
> Perhaps an interface that takes only "known/guessable" parameters, such
> as subscriber e-mail or order number?  This would explain the claim
> that an URL sent to one subscriber by an incompetent RA could be
> edited to retrieve the data for another subscriber.
> 

Nope. That QuickInvite URL was/is hashed and salted. I have personally seen the 
code for generating it. Just editing stuff in that URL without being able to 
crack it wouldn't give any useful information or lead anywhere. Although now 
I'm kinda wanting to create a specific error page for people who try. Nah. It'd 
be funny to me and anyone trying to hack those but the customers wouldn't get 
my jokes, likely. Brute forcing the URL would take too long, which is why I 
agree with the original decision to decrease the URL validity timespan. It 
helps prevent brute force attacks too. 

Also, just was chatting with Chris. I just found out that the reseller in 
question was dropped from our Symantec a while back. Details to follow, but 
suffice to say that they are no longer a problem for us.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

On 31/03/17 17:39, Peter Bowen wrote:
>>> For example, how frequently should roots
>>> be allowed to change hands? What would Mozilla's response be if
>>> GalaxyTrust (an operator not in the program)
>>> were to say that they are acquiring the HARICA root?
>>
>> From the above URL: "In addition, if the receiving company is new to the
>> Mozilla root program, there must also be a public discussion regarding
>> their admittance to the root program."
>>
>> Without completing the necessary steps, GalaxyTrust would not be admitted to
>> the root program.
> 
> I've modified the quoted text a little to try to make this example
> clearer, as I think the prior example conflated multiple things and
> used language that did not help clarify the situation.
> 
> Is the revised example accurate?

The revised example is accurate.

Gerv

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

Re: Criticism of Google Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

On Fri, Mar 31, 2017 at 8:18 AM, Gervase Markham via
dev-security-policy  wrote:
> On 30/03/17 15:01, Peter Kurrasch wrote:
>> By "not new", are you referring to Google being the second(?)
>> instance where a company has purchased an individual root cert from
>> another company? It's fair enough to say that Google isn't the first
>> but I'm not aware of any commentary or airing of opposing viewpoints
>> as to the suitability of this practice going forward.
>
> As noted, I have no interest in banning this practice because I think
> the ecosystem effects would be negative.
>
>> Has Mozilla received any notification that other companies ‎intend to
>> acquire individual roots from another CA?
>
> Not to my knowledge, but they may have been communicating with Kathleen.
>
>> Also, does Mozilla have any policies (requirements?) regarding
>> individual root acquisition?
>
> https://wiki.mozilla.org/CA:RootTransferPolicy
> and
> https://github.com/mozilla/pkipolicy/issues/57
>
>> For example, how frequently should roots
>> be allowed to change hands? What would Mozilla's response be if
>> GalaxyTrust (an operator not in the program)
>> were to say that they are acquiring the HARICA root?
>
> From the above URL: "In addition, if the receiving company is new to the
> Mozilla root program, there must also be a public discussion regarding
> their admittance to the root program."
>
> Without completing the necessary steps, GalaxyTrust would not be admitted to
> the root program.

I've modified the quoted text a little to try to make this example
clearer, as I think the prior example conflated multiple things and
used language that did not help clarify the situation.

Is the revised example accurate?

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

Re: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

On 30/03/17 15:01, Peter Kurrasch wrote:
> By "not new", are you referring to Google being the second(?)
> instance where a company has purchased an individual root cert from
> another company? It's fair enough to say that Google isn't the first
> but I'm not aware of any commentary or airing of opposing viewpoints
> as to the suitability of this practice going forward.

As noted, I have no interest in banning this practice because I think
the ecosystem effects would be negative.

> Has Mozilla received any notification that other companies ‎intend to
> acquire individual roots from another CA? 

Not to my knowledge, but they may have been communicating with Kathleen.

> Also, does Mozilla have any policies (requirements?) regarding
> individual root acquisition? 

https://wiki.mozilla.org/CA:RootTransferPolicy
and
https://github.com/mozilla/pkipolicy/issues/57

> For example, how frequently should roots
> be allowed to change hands? What would Mozilla's response be if
> WoSign were to say that because of the tarnishing of their own brand
> they are acquiring the HARICA root? 

From the above URL: "In addition, if the receiving company is new to the
Mozilla root program, there must also be a public discussion regarding
their admittance to the root program."

Without completing the necessary steps, WoSign would not be admitted to
the root program.

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

Re: Criticism of Google Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

On 30/03/2017 08:08, Gervase Markham wrote:

On 29/03/17 20:42, Jakob Bohm wrote:

That goal would be equally (in fact better) served by new market
entrants getting cross-signed by incumbents, like Let's encrypt did.


Google will be issuing from Google-branded intermediates under the
ex-GlobalSign roots. So the chains would be basically the same whether
GS or GTS owned the parent root. So how does requiring them to do it by
cross-signing improve things? Requiring them to do it by cross-signing
just exposes them to business risk which they don't have if they
actually own the roots.


For example, when doing ordinary browsing with https on-by-default,
users rarely bother checking the certificate beyond "the browser says
it is not a MitM attack, good".  Except when visiting a high value
site, such as a government site to file a change in ownership of an
entire house (such sites DO exist).  Then it makes sense to click on
the certificate user interface and check that the supposed "Government
Land Ownership Registry of the Kingdom of X" site is verified by
someone that could reasonably be trusted to do so (i.e. not a national
CA of the republic of Y or the semi-internal CA of some private
megacorp).


This is what we have CAA and HPKP for.


Those only work for sites that are able to deploy those (there are
technical limitations blocking deployment on some systems).

They by no means replace due diligence in high risk situations.




With this recent transaction, the browser could show "GlobalSign" when
it should show "Google", two companies with very different security and
privacy reputations.


If Google were issuing from a Google-owned intermediate under a
GlobalSign-owned root, why would the browser show "Google"? I don't
understand how you see the chain differing in this situation.



I am (consistently) referring to situations where the user has reason
to navigate to the part of the UI that displays the full chain, not the
dubious tooltips displayed under the encryption icon.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

在 2017年3月30日星期四 UTC+8下午10:34:00，Patrick Tronnier写道：
> On Sunday, March 26, 2017 at 11:48:43 PM UTC-4, wangs...@gmail.com wrote:
> > We compiled an analysis document on our CP/CPS’s Compliance with the BRs 
> > for everyone to review and comment. You can find the document at the 
> > following address of the 
> > BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8851230
> >  
> > Your suggestions will be much appreciated.
> 
> As part of the suggestion process it would be useful to expand on the tables 
> you listed in section 2 "Compliance Analysis". Would you be able to attach an 
> editable MS Word version?

We uploaded an editable version of the comparison document in MS Word format 
for the convenience of review and comments. You can find the document at the 
following address of the 
BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8853351
The contents of the Word document are the same with that of the PDF document, 
except for the correction of a mistake in the Table of Contents part of the PDF 
document. All suggestions and comments are welcomed. Thanks. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

在 2017年3月30日星期四 UTC+8下午10:34:00，Patrick Tronnier写道：
> On Sunday, March 26, 2017 at 11:48:43 PM UTC-4, wangs...@gmail.com wrote:
> > We compiled an analysis document on our CP/CPS’s Compliance with the BRs 
> > for everyone to review and comment. You can find the document at the 
> > following address of the 
> > BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8851230
> >  
> > Your suggestions will be much appreciated.
> 
> As part of the suggestion process it would be useful to expand on the tables 
> you listed in section 2 "Compliance Analysis". Would you be able to attach an 
> editable MS Word version?

We uploaded an editable version of the comparison document in MS Word format 
for the convenience of review and comments. You can find the document at the 
following address of the 
BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8853351
The contents of the Word document are the same with that of the PDF document, 
except for the correction of a mistake in the Table of Contents part of the PDF 
document. All suggestions and comments are welcomed. Thanks. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Criticism of Google Re: Google Trust Services roots

[Richard Wang via dev-security-policy]

Qihoo 360 CSO Mr. Tan updated this in the recent CAB Forum meeting in USA : CEO 
of WoSign is NA, Richard Wang is the COO. 


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of urijah--- via dev-security-policy
Sent: Friday, March 31, 2017 2:07 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots

> and we don't think our brand is "tarnishing", we are working hard to try to 
> regain the trust and confidence in this community.

Wasn't a prerequisite for that process your stepping down as CEO of WoSign?



On Thursday, March 30, 2017 at 9:49:25 PM UTC-4, Richard Wang wrote:
> To be transparent, WoSign are NOT "acquiring the HARICA root" that we NEVER 
> contact HARICA, and we don't think our brand is "tarnishing", we are working 
> hard to try to regain the trust and confidence in this community.
> 
> 
> Best Regards,
> 
> Richard
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Peter Kurrasch via dev-security-policy
> Sent: Thursday, March 30, 2017 9:02 PM
> To: Gervase Markham via dev-security-policy ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Criticism of Google Re: Google Trust Services roots
> 
> By "not new", are you referring to Google being the second(?) instance where 
> a company has purchased an individual root cert from another company? It's 
> fair enough to say that Google isn't the first but I'm not aware of any 
> commentary or airing of opposing viewpoints as to the suitability of this 
> practice going forward.
> 
> Has Mozilla received any notification that other companies ‎intend to acquire 
> individual roots from another CA? I wouldn't ask Mozilla to violate any 
> non-disclosures but surely it's possible to let the community know if we 
> should expect more of this? Ryan H. implied as much in a previous post but I 
> wasn't sure where he was coming from on that.
> 
> Also, does Mozilla have any policies (requirements?) regarding individual 
> root acquisition? For example, how frequently should roots be allowed to 
> change hands? What would Mozilla's response be if WoSign were to say that 
> because of the tarnishing of their own brand they are acquiring the HARICA 
> root? What if Vladimir Putin were to make such a purchase? Any requirements 
> on companies notifying the public when the acquisition takes place?
> 
> Perhaps this is putting too much of a burden on Mozilla as a somewhat 
> protector of the global PKI but I'm not sure who else is in a better position 
> for that role?
> 
> 
>   Original Message
> From: Gervase Markham via dev-security-policy
> Sent: Thursday, March 30, 2017 1:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Reply To: Gervase Markham
> Subject: Re: Criticism of Google Re: Google Trust Services roots
> 
> On 29/03/17 20:46, Peter Kurrasch wrote:
> > It's not inconsequential for Google to say: "From now on, nobody can 
> > trust what you see in the root certificate, even if some of it 
> > appears in the browser UI. The only way you can actually establish 
> > trust is to do frequent, possibly complicated research." It doesn't 
> > seem right that Google be allowed to unilaterally impose that change 
> > on the global PKI without any discussion from the security community.
> 
> As others in this thread have pointed out, this is not a new thing. I 
> wouldn't say that Google is "imposing" this need.
> 
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

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

Re: Criticism of Google Re: Google Trust Services roots

[Florian Weimer via dev-security-policy]

* Peter Kurrasch via dev-security-policy:

> By "not new", are you referring to Google being the second(?) instance
> where a company has purchased an individual root cert from another
> company? It's fair enough to say that Google isn't the first but I'm
> not aware of any commentary or airing of opposing viewpoints as to the
> suitability of this practice going forward.

I think most of the DNs in the Mozilla root store still do not reflect
reality.  The restrictions on certificate naming do not apply to the
CAs themselves.  This is due to the way PKIX validation works.
Correcting the DNs would break the certificate chains.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy