Re: Misissued/Suspicious Symantec Certificates

[Jakob Bohm]

(continuing top posting for consistency)

In order to clarify the potential risk/damage to the Web PKI, it would
be useful to clarify the following in a later report (since this would
require additional investigation):

Were the web identities (DNS names etc.) in the category C, D, E and F
certificates properly vetted as per the CP/CPS etc., the certificates
simply replaced the vetted organization name with "test" in the X.500
distinguished name?  Or were some of those issued for insufficiently
(or actually incorrect) web identities?

To the safety of the web PKI this makes a big difference, since if the
web identities were properly and correctly vetted, then the only real
danger was relying parties seeing the word "test" in some user
interfaces instead of the real organization name, thus conferring less
trust (failing closed).  If on the other hand the web identities were
insufficiently vetted, then the certificates conferred a security claim
to relying parties not being shown or otherwise inspecting the O= field
(failing open).

On 27/01/2017 02:30, Steve Medin wrote:

Here is an attached PDF update regarding this certificate problem report.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation


-Original Message-
From: dev-security-policy [mailto:dev-security-policy-
bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Steve
Medin
Sent: Saturday, January 21, 2017 9:35 AM
To: Andrew Ayer ; mozilla-dev-security-
pol...@lists.mozilla.org
Subject: RE: Misissued/Suspicious Symantec Certificates

The listed Symantec certificates were issued by one of our WebTrust

audited

partners. We have reduced this partner's privileges to restrict further
issuance while we review this matter. We revoked all reported certificates
which were still valid that had not previously been revoked within the 24
hour CA/B Forum guideline - these certificates each had "O=test". Our
investigation is continuing.




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: Misissued/Suspicious Symantec Certificates

[Jakob Bohm]

(continuing top post for consistency)

For the certificates that are noted as "revoked on the day of
issuance", it would (both in this and the general case), be more
informative to state the revocation delay in a smaller unit of measure,
such as hours (or even smaller if less than an hour).

It is of cause noted, that most of the relevant timestamps are (or were
at the time) recorded with a precision of 1s in published PKI objects,
although parties outside the CA not have an easy way to obtain reliable
copies of the revocation responses that the CA would have issued, and
thus the timestamps of revocation becoming known to revocation-checking
relying parties (which is different from the time that the revocation
may have been also communicated to independent logging systems).

On 27/01/2017 06:36, Ryan Sleevi wrote:

The PDF that was stripped is available at
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038

On Thu, Jan 26, 2017 at 5:30 PM, Steve Medin 
wrote:


Here is an attached PDF update regarding this certificate problem report.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation


-Original Message-
From: dev-security-policy [mailto:dev-security-policy-
bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Steve
Medin
Sent: Saturday, January 21, 2017 9:35 AM
To: Andrew Ayer ; mozilla-dev-security-
pol...@lists.mozilla.org
Subject: RE: Misissued/Suspicious Symantec Certificates

The listed Symantec certificates were issued by one of our WebTrust

audited

partners. We have reduced this partner's privileges to restrict further
issuance while we review this matter. We revoked all reported

certificates

which were still valid that had not previously been revoked within the 24
hour CA/B Forum guideline - these certificates each had "O=test". Our
investigation is continuing.



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





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: Misissued/Suspicious Symantec Certificates

[Ryan Sleevi]

The PDF that was stripped is available at
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038

On Thu, Jan 26, 2017 at 5:30 PM, Steve Medin 
wrote:

> Here is an attached PDF update regarding this certificate problem report.
>
> Kind regards,
> Steven Medin
> PKI Policy Manager, Symantec Corporation
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Steve
> > Medin
> > Sent: Saturday, January 21, 2017 9:35 AM
> > To: Andrew Ayer ; mozilla-dev-security-
> > pol...@lists.mozilla.org
> > Subject: RE: Misissued/Suspicious Symantec Certificates
> >
> > The listed Symantec certificates were issued by one of our WebTrust
> audited
> > partners. We have reduced this partner's privileges to restrict further
> > issuance while we review this matter. We revoked all reported
> certificates
> > which were still valid that had not previously been revoked within the 24
> > hour CA/B Forum guideline - these certificates each had "O=test". Our
> > investigation is continuing.
> >
>
> ___
> 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/Suspicious Symantec Certificates

[Kathleen Wilson]

On Thursday, January 26, 2017 at 9:27:52 PM UTC-8, Steve Medin wrote:
> Here is an attached PDF update regarding this certificate problem report.
> 
> Kind regards,
> Steven Medin
> PKI Policy Manager, Symantec Corporation
> 


The PDF file provided by Steven has been attached to this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1334377

Direct link to pdf file:
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038

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

RE: Misissued/Suspicious Symantec Certificates

[Steve Medin]

Here is an attached PDF update regarding this certificate problem report.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Steve
> Medin
> Sent: Saturday, January 21, 2017 9:35 AM
> To: Andrew Ayer ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: RE: Misissued/Suspicious Symantec Certificates
> 
> The listed Symantec certificates were issued by one of our WebTrust
audited
> partners. We have reduced this partner's privileges to restrict further
> issuance while we review this matter. We revoked all reported certificates
> which were still valid that had not previously been revoked within the 24
> hour CA/B Forum guideline - these certificates each had "O=test". Our
> investigation is continuing.
> 


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

Re: Misissued/Suspicious Symantec Certificates

[Ryan Sleevi]

Steve,

Have you had a chance to review these questions? Considering that these are
all about existing practices, and as a CA should be readily available and
easy to answer, I'm hoping you can reply by end of day.

Please consider this a formal request from Google as part of investigating
this incident.

On Mon, Jan 23, 2017 at 5:58 PM, Ryan Sleevi  wrote:

> Steve,
>
> While I understand that your investigation is ongoing, this does seem
> extremely similar, if not identical, to Symantec's previous misissuance.
>
> In that previous incident, Symantec took a number of steps - beginning
> with reportedly immediately terminating the employees responsible and then
> continuing to a comprehensive system overhaul, as detailed at
> https://www.symantec.com/page.jsp?id=test-certs-update#
>
> What is particularly concerning here is that your current explanations
> suggest that either they are incomplete, or that Symantec's previous
> answers were either misleading or incorrect. This is extremely concerning,
> and I'm hoping you can clarify with answers to the following questions,
> independent of your ongoing investigation and as soon as possible:
>
> 1) In response to the previous incident, Symantec indicated they hold a
> "no compromise" bar for such breaches in the post titled "A tough day as
> leaders". [1]
>   a) Do you believe that the steps to "reduce privileges" represent a
> consistent application of that standard?
>   b) If not, what additional steps are you taking, consistent with your
> "no compromise" standard?
>
> 2) In response to the previous incident, Symantec indicated that the use
> of any privileged test tool would require senior leader justification from
> both QA and Production Operations teams and approvals from the heads of
> Engineering and Policy Compliance. [2]
>   a) Did Symantec mean that this was limited to validations performed by
> Symantec, and not that of Registration Authorities fulfilling the duties
> pursuant to Section 1.3.2 of the Baseline Requirements?
>   b) At the time Symantec made this statement, did Symantec have any
> Registration Authorities fulfilling the duties pursuant to Section 1.3.2 of
> the Baseline Requirements?
>   c) If such a statement was meant to be limited to Symantec, and not that
> of Registration Authorities, why did Symantec not feel it was appropriate
> to highlight that it did not extend to activities performed by Registration
> Authorities?
>   d) If such a statement was not meant to be limited to Symantec, was such
> a justification provided, and approvals granted, for the tool that allowed
> such Registration Authorities to issue these certificates?
>
> 3) In response to the previous incident, Symantec indicated a
> comprehensive review of issuance privileges was conducted to ensure only
> authorized personnel have the ability to issue certificates, and that a
> quarterly access review would be conducted to ensure this. [2]
>   a) Did such comprehensive review include that of Registration
> Authorities?
>   b) If not, why did Symantec not disclose that Registration Authorities
> were excluded?
>   c) Is Symantec currently performing access reviews of Registration
> Authorities?
>   d) If so, when does Symantec expect this to be completed?
>
> 4) In response to the previous incident, Symantec indicated it updated its
> internal policies and procedures for test certificates as used for
> commercial certificates. Further, it indicated that QA engineers and
> authentication personnel were trained on updated practices for test
> certificates. [2]
>   a) Did Symantec include Registration Authorities in the scope of that
> training?
>   b) If not, why did Symantec not disclose that Registration Authorities
> were excluded?
>   c) If so, why did Symantec's corrective actions for the previous
> misissuance fail to prevent this continued misissuance?
>
> 5) You have indicated that you have at least one WebTrust audited partner
> capable of causing issuance using Symantec-operated CAs.
>   a) Please provide a link to the audit results for each of these WebTrust
> audited partners.
>   b) Have you suspended the capabilities of these partners until Symantec
> completes its investigation?
>   c) If not, why not, and when do you expect to do so?
>
> 6) Does Symantec allow is Registration Authorities to deviate from the
> policies and standards set forth by its CP, CPS, and internal policies and
> controls?
>   a) If not, why did Symantec fail to detect that its Registration
> Authorities were deviating from its policies for this long?
>   b) If so, where does Symantec disclose this deviation within its CP
> and/or CPS?
>
> 7) When do you expect to provide the next update as to the ongoing
> investigation? If it is not within the next three days, why?
>
>
> Thank you for your time in answering each and every one of these questions
> and providing further details, so as to help inform the broader community
> as to the steps Symantec has taken 

Re: Policy 2.4 Proposal: Codify requirements relating to Common CA Database into the policy

[Jakob Bohm]

On 26/01/2017 10:23, Gervase Markham wrote:

On 25/01/17 18:38, Ryan Sleevi wrote:

I'm a little wary of introducing #1 until you know what #2 contains,
because to introduce #1, you want to have some way of building
consensus/agreement with different consumers, and that remains unspecified.


It does remain unspecified... However, while it would be wrong of me to
announce anyone else's plans or direction, the common policy posted here
may not have come as a _complete_ surprise to root stores who are
already signed up to use the CCADB. :-)


Mostly, I think #1 sounds like something you'd want to make as part of a
condition of signing up to the CCADB, and if you want to get sign-ups for
the CCADB from other root stores, your best bet is to make #1 as empty as
possible and put it all in #2 for now, and then work with other root stores
to figure out what #1 looks like and how it's managed, since everything in
#1 becomes a potential barrier for root stores to use.


We definitely want #1 to become a consensus document. However, it seemed
easier to make the initial draft a good stab at the common and
uncontroversial bits, rather than making it entirely empty. We can
always move bits _out_ later. But really, what it basically says now is
"there are these fields that various stores use. Keep them updated."
Hopefully, that should not be too objectionable.

Gerv



Given that Mozilla has been reducing the scope and generality of their
root store over the past few years, I would suggest reaching out to
those organizations that base their public root stores on the Mozilla
store, but have a slightly different focus.  Such organizations may
wish, either individually or together, to pick up the slack via joint
use of facilities such as the CCADB and perhaps this newsgroup.

An obvious example would be the Debian root store, which used to
contain independently vetted CAs in addition to the Mozilla store, but
currently only contains Debian's own root beyond the Mozilla ones.
The primary contact/information page for that root store is
https://packages.debian.org/sid/ca-certificates


Enjoy

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

Re: Policy 2.4 Proposal: Codify requirements relating to Common CA Database into the policy

[Gervase Markham]

On 25/01/17 18:38, Ryan Sleevi wrote:
> I'm a little wary of introducing #1 until you know what #2 contains,
> because to introduce #1, you want to have some way of building
> consensus/agreement with different consumers, and that remains unspecified.

It does remain unspecified... However, while it would be wrong of me to
announce anyone else's plans or direction, the common policy posted here
may not have come as a _complete_ surprise to root stores who are
already signed up to use the CCADB. :-)

> Mostly, I think #1 sounds like something you'd want to make as part of a
> condition of signing up to the CCADB, and if you want to get sign-ups for
> the CCADB from other root stores, your best bet is to make #1 as empty as
> possible and put it all in #2 for now, and then work with other root stores
> to figure out what #1 looks like and how it's managed, since everything in
> #1 becomes a potential barrier for root stores to use.

We definitely want #1 to become a consensus document. However, it seemed
easier to make the initial draft a good stab at the common and
uncontroversial bits, rather than making it entirely empty. We can
always move bits _out_ later. But really, what it basically says now is
"there are these fields that various stores use. Keep them updated."
Hopefully, that should not be too objectionable.

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

Re: Suspicious test.com Cert Issued By GlobalSign

[Gervase Markham]

On 25/01/17 17:36, Andrew Ayer wrote:
> I found another certificate for www.test.com that I believe was
> mis-issued by GlobalSign:
> 
>   
> https://crt.sh/?sha256=9d503e7c6c4fb6e6d7436c07ff445b95214871ea13ac1cb3b0d7abbce9be6cfb

Yes, that looks mis-issued. I realise this was some time ago now, but do
the Globalsign reps on the list have any comment?

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