Re: Policy Update Proposal -- Remove Email Trust Bit

[Brian Smith]

On Tue, Oct 13, 2015 at 5:04 AM, Kathleen Wilson 
wrote:

> I believe that such a resource commitment would satisfy all of the
> arguments against the Email trust bit that Ryan so eloquently summarized.
> [3]
>
> Is this a fair assessment?
>
> Is there anything else that should be added to the "job description" above?


I think your summary of what needs to be done with respect to the email
trust bit is good.

In an earlier message, you mentioned the idea of splitting the S/MIME
policy into a separate document from the TLS policy. I think that such a
split would be good and I think it should happen early on in the process
for version 2.3 of the policy. In particular, such a split would enable us
to have simpler language in the TLS policy, especially with respect to the
Extended Key Usage (EKU) extension.

I also think it would be good to have CAs apply for the TLS trust bit
separately from the email trust bit. In particular, when it comes time for
the public review of a CA inclusion request or update, I think it would be
better to have a separate email threads for the public discussions of the
granting of the TLS trust bit and the granting of the S/MIME trust bit, for
the same CA.

Note that certificate sfor TLS and for S/MIME are much more different than
they may first appear. In particular, it is very reasonable to have a
public log of issued certificates for TLS (Certificate Transparency) and
revocation via short-lived certificates and OCSP stapling should eventually
work. However, email certificates often contain personally identifiable
information (PII) and it isn't clear how to deal with that in CT. Also, the
privacy/security trade-off for revocation checking for S/MIME is much
different--much more difficult--than for TLS. So, I expect the technical
aspects of the TLS and S/MIME policies to be quite different going forward.

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

Re: Policy Update Proposal -- Align with RFC 3647 now

[Brian Smith]

Ryan Sleevi  wrote:

> On Thu, October 15, 2015 12:30 pm, Kathleen Wilson wrote:
> >  It was previously suggested[1] that we align Mozilla's CA Certificate
> >  Policy to RFC 3647, so CAs can compare their CP/CPS side-by-side with
> >  Mozilla's policy, as well as the BRs and audit criteria (such as the
> >  forthcoming ETSI 319 411 series).
>
> Kathleen,
>
> I remain incredibly dubious and skeptical of the proposed value, and thus
> somewhat opposed. Though I've been a big proponent of adopting the 3647
> format for the CA/Browser Forum documents, I don't believe that root store
> requirements naturally fit into that form, nor should they.


I agree with Ryan. The organization of Mozilla's policy is good. The
technical requirements need to be improved. We should focus on improving
the technical requirements, not the organization.

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

Re: SECOM Request for EV Treatment

[h-kamo]

2015年8月26日水曜日 4時29分37秒 UTC+9 Ryan Sleevi:
> On Wed, August 5, 2015 2:51 pm, Kathleen Wilson wrote:
> >  SECOM has applied to enable EV treatment for the "Security Communication
> >  RootCA2" root certificate that was included in NSS via Bugzilla Bug
> >  #527419.
> >
> >  SECOM is a Japanese commercial CA that provides SSL and client
> >  certificates for e-Government and participates in several projects for
> >  financial institutions to ensure the secured on-line transactions.
> >  This begins the discussion of the request from SECOM to enable EV
> >  treatment for the "Security Communication RootCA2" root certificate that
> >  is currently included in NSS.
> >
> >  At the conclusion of this discussion I will provide a summary of issues
> >  noted and action items. If there are outstanding issues, then an
> >  additional discussion may be needed as follow-up. If there are no
> >  outstanding issues, then I will recommend approval of this request in
> >  the bug.
> 
> Hi Kathleen,
> 
> I've attempted to separately review this inclusion request and examine the
> CP and CPS.
> 
> Overall, this was the most difficult review, given the lack of
> availability of the policy documentation in English. While I attempted to
> use Google Translate for most of it, I think it may be noteworthy to
> consider requiring CAs to provide translated versions of their documents
> in a future update of the Mozilla inclusion policy.
> 
> The most recent audit information for SECOM that I can find is not the
> 1717 seal you indicated, but Seal #1907,
> https://cert.webtrust.org/SealFile?seal=1907&file=pdf
> 
> In examining that seal, we see that there are a variety of CP/CPSes
> provided as part of in scope for the audit. Relevant to this discussion,
> it appears, is the "Security Communications Root CA2 Certification
> Practice Statement" [1], the "Security Communications Root CA2 CA
> Certificate Policy" [2], and the "SECOM Passport for Web EV 2.0 CA" CP [3]
> and [4].
> 
> Given that the SECOM Root CA2 is already included in Mozilla's Root
> Program, I attempted to focus my efforts on reviewing documents [3] and
> [4], as they were deemed most relevant for EV enablement.
> 
> While there are a several positive things noted within the CP/CPS,
> overall, I'm concerned about the lack of information provided that makes
> it difficult to impossible for the community to reliably inspect SECOM's
> conformance to the relative policies, and leaves ambiguity with respect to
> Mozilla's own ability to ensure that SECOM is operating in the public
> interest.
> 
> Given that [3] largely defers to [4] for most sections, I will focus my
> primary comments on [4], and then circle back.
> 
> https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
> 
> Good things:
> - Section 1.5.2 provides contact information for the public in the event
> of the need to revoke a certificate immediately. This is quite useful for
> relying parties and members of the public to raise concern, and many CAs
> make this difficult to find.
> - Section 7.1 provides an exhaustive list of the certificate profile,
> fields, and values. This sort of documentation is what ideally all members
> of the Mozilla Root Store would provide, and provides ways for the public
> to detect non-conformance to the profile specified.
> 
> Mixed things:
> - While Section 4.1 indicates that SECOM will examine CAA records, as
> required by version 1.2.0 of the Baseline Requirements (as adopted by
> Ballot 125), SECOM does not list which CAA records it will process or what
> it would do if they mismatch. This may be seen as an incomplete adherence
> to the Baseline Requirements, but I would rather see it as a reasonable
> confusion related to expectations. An ideal resolution for this would be
> for SECOM to indicate what CAA records it will expect to find (if CAA is
> present) in order to issue, and what SECOM's process and procedures will
> be for CAA records that fail to meet that (e.g. to deny the request, to
> treat it as a High-Value request, to require some form of extended
> validation, to allow a notarized letter on company letterhead to override,
> etc)
> 
> Bad things:
> - Section 2.2 of the CP fails to provide information in the repository for
> testing certificates issued by these roots. While SECOM's audit was
> conducted against the WebTrust SSL BRs 1.1 (themselves based on the CA/B
> Forum's SSL BRs 1.1), this was required in Appendix C (normatively) of the
> BRs, and has been incorporated in Section 2.2 of the BRs 1.3.0 (providing
> a model policy for CAs to adopt). I consider this a major issue of
> non-conformance, although it may be remediated relatively easily.
> - Section 3.2.2 fails to comprehensively explain how domain name
> validation works. This is unquestionably the most important part of a CAs
> operation, and I had difficulty finding any such information provided in
> any of the attested-to documents by the auditors. While Auditors are,
> unfortunately, n

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

All,

Thank you for your patience throughout this long discussion. I 
appreciate all of your thoughtful and constructive input.


I feel confident now that we should do the following:
1) Remove reference to the code signing trust bit from version 2.3 of 
Mozilla's CA Certificate Policy.
2) When version 2.3 is published, also remove reference to the code 
signing trust bit from CA-program related wiki pages.
3) After version 2.3 of the policy is published and the change has been 
properly communicated (CA Communication, security blog, press regarding 
the policy update), turn off the Code Signing trust bits for included 
root certs, and remove any root certs that are left will all trust bits 
turned off.


Thanks,
Kathleen



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

Re: Policy Update Proposal -- Align with RFC 3647 now

[Ryan Sleevi]

On Thu, October 15, 2015 12:30 pm, Kathleen Wilson wrote:
>  All,
>
>  It was previously suggested[1] that we align Mozilla's CA Certificate
>  Policy to RFC 3647, so CAs can compare their CP/CPS side-by-side with
>  Mozilla's policy, as well as the BRs and audit criteria (such as the
>  forthcoming ETSI 319 411 series).

Kathleen,

I remain incredibly dubious and skeptical of the proposed value, and thus
somewhat opposed. Though I've been a big proponent of adopting the 3647
format for the CA/Browser Forum documents, I don't believe that root store
requirements naturally fit into that form, nor should they.

I think those arguing for such a conversion have a high bar to
demonstrate, by first attempting the conversion and showing how it maps,
before we can reasonably discuss whether or not to adopt.

For example, let's just look at
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
to see how it might map.

Items 1-3 are moved to "Introduction", presumably - there's no normative
requirement.

Item 4 would almost certainly get split over several items related to the
certificate profile, except each of these are merely illustrative examples
of reasons for non-inclusion.

Item 5 has no natural counterpart.

Item 6 will end up being split across a variety of sections. This is the
one that may be the most beneficial to being in a 3647 format, but coupled
with the larger issues, it seems hard to justify.

Item 7 equally is split across multiple sections, except this is an
exhaustive list of criteria, which, compared to Item 4, is confusing
(since Item 4 is just illustrative)

Item 8 has no natural counterpart.

Item 9 ends up being split across multiple sections, making it hard to see
the sum total of the definition of "technically constrained"

Item 10 ends up most logically in a 'weird' place (document updates &
repository info)

Items 13 & 14 simply get moved to definitions, which may be seen as
non-normative.

Items 15-19 have no natural counterpart.

This is just the inclusion process. Let's also consider the ongoing
obligations (
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
) and realize that it ends up being, at best, maybe 50% of the
requirements having counterparts to RFC 3647, with the remainder feeling
out of place and disjoint.

I feel that those who are supportive of such a change have a burden to
demonstrate that it won't be disruptive or complex to read. It's entirely
reasonable to believe I'm totally wrong here, and I may well be - but I do
want to make sure we're working to make the requirements legible and
understandable.

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

Policy Update Proposal -- Align with RFC 3647 now

[Kathleen Wilson]

All,

It was previously suggested[1] that we align Mozilla's CA Certificate 
Policy to RFC 3647, so CAs can compare their CP/CPS side-by-side with 
Mozilla's policy, as well as the BRs and audit criteria (such as the 
forthcoming ETSI 319 411 series).


I responded by postponing that work to a later policy update, because I 
do not personally have time to make this change.


However, a group of people in the CA community have volunteered to do 
this work for us, and believe they can get it done in about a month.


So, I would like to propose that we do this change (align to RFC 3647) 
now, in version 2.3 of the policy update. Then all of the other changes 
for version 2.3 will be made to the re-organized policy.


I look forward to your thoughtful and constructive feedback on this 
proposal.


Kathleen

[1]https://groups.google.com/d/msg/mozilla.dev.security.policy/aLhB5flUos8/sYdDI64xGAAJ

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

Re: Symantec Test Cert Misissuance Incident

[Rick Andrews]

Rob, Gerv - Thanks for your input. We are collating all feedback and are 
planning to publish another update soon.


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

Re: A pragmatic solution for the S/MIME trust bit

[Kathleen Wilson]

We are indeed asking for:
(1) A one time effort to define/improve policy around the Email trust
bit. (after doing some research, and understanding the situation)
(2) Occasional refinement to the policy
(3) Evaluate the requests to enable the Email trust bit
(4) Improve the S/MIME code that folks are saying has not been maintained.




Of course, these things can be distributed among different people. For 
instance, the person improving the code may not be the same person who 
works to improve the policy.



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

Re: A pragmatic solution for the S/MIME trust bit

[Kathleen Wilson]

I don't want to get bogged down into the discussion about *how* to 
write/update the policy regarding the Email trust bit at this point in 
time. If someone commits to take the time to do some research and become 
familiar with this area, their proposal for how to update policy 
regarding the Email trust bit will most likely evolve before they 
propose solutions here.


We are indeed asking for:
(1) A one time effort to define/improve policy around the Email trust 
bit. (after doing some research, and understanding the situation)

(2) Occasional refinement to the policy
(3) Evaluate the requests to enable the Email trust bit
(4) Improve the S/MIME code that folks are saying has not been maintained.



smaller amount of time?


I think that the work can be done slower with a smaller resource 
commitment. The point is that someone needs to make some sort of 
commitment to work regularly (at some level) to address the concerns 
that have been raised (and do the things listed above).




Could the CAs be required to do most of the work to
demonstrate their compliance, and only require the dedicated person to verify
the documentation for plausability?



That's basically how it works today. But we need someone to figure out 
what policy documentation and audit criteria the CA should be required 
to provide and meet.


Kathleen



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

Re: A pragmatic solution for the S/MIME trust bit

[Phillip Hallam-Baker]

On Thu, Oct 15, 2015 at 11:24 AM, David E. Ross  wrote:
> On 10/15/2015 5:27 AM, Kai Engert wrote [in part]:
>>
>> (a) Only grant the S/MIME trust bit if a CA has been granted the SSL/TLS
>> trust bit already.
>>
>> If Mozilla decides to remove a SSL/TLS trust bit, the S/MIME trust bit (and
>> potentiall all other trust bits) for that CA will get removed, too.
>>
>> This eliminates the need to work on any CAs that are for the S/MIME purpose,
>> only.
>>
>>
>> (b) Only CAs that explicitly state they'd like to be granted the S/MIME
>> trust bit might potentially get it.
>>
>> This avoids the likelyhood that any CA's root gets accidentally used for the 
>> non
>> -SSL/TLS purpose.
>
> This might be okay if applied to certification authorities but not to
> individual root certificates.  We should not block the S/MIME trust bit
> when a certification authority chooses to have separate root
> certificates for TLS and S/MIME.
>
> --
> David E. Ross

What is the problem with the current situation?

Changing process takes time and effort. Does changing the process
really save any effort over leaving things as they are?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: A pragmatic solution for the S/MIME trust bit

[David E. Ross]

On 10/15/2015 5:27 AM, Kai Engert wrote [in part]:
> 
> (a) Only grant the S/MIME trust bit if a CA has been granted the SSL/TLS
> trust bit already.
> 
> If Mozilla decides to remove a SSL/TLS trust bit, the S/MIME trust bit (and
> potentiall all other trust bits) for that CA will get removed, too.
> 
> This eliminates the need to work on any CAs that are for the S/MIME purpose,
> only.
> 
> 
> (b) Only CAs that explicitly state they'd like to be granted the S/MIME
> trust bit might potentially get it.
> 
> This avoids the likelyhood that any CA's root gets accidentally used for the 
> non
> -SSL/TLS purpose.

This might be okay if applied to certification authorities but not to
individual root certificates.  We should not block the S/MIME trust bit
when a certification authority chooses to have separate root
certificates for TLS and S/MIME.

-- 
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See .
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: A pragmatic solution for the S/MIME trust bit

[Richard Wang]

+1
S/MINE is very very important for personal email privacy protection and for 
commercial email too.


Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Kai Engert
Sent: Thursday, October 15, 2015 8:28 PM
To: mozilla-dev-security-policy 

Subject: A pragmatic solution for the S/MIME trust bit

The earlier comments on this list have shown that S/MIME is in active use 
(e.g.
in communication between different academic instutions), and that a decision 
to remove the S/MIME trust bit from the Mozilla CA list would mean a 
functional regression for those users.

In my opinion, the discussion about the quality of the S/MIME code in NSS or 
in Thunderbird should be completely separate from the discussion about the 
trust bit, because there is non-Mozilla open source software that is able to 
make use that trust bit, too (e.g. OpenSSL also has an implementation for 
S/MIME).

I don't know if we'll find sufficient resources to start a separate CA program 
for the S/MIME trust bit. It seems that the lobby for encrypted email is much 
weaker than the lobby for web site security, maybe because it isn't used to 
sell products or content to consumers.

Nevertheless, I believe that supporting privacy in communication between 
individuals is an important value. The publicly agreed list of CA certificates 
is a very helpful resource that makes it easier for any new project that wants 
to buildon upson PKI for that purpose.

Therefore I'd like to suggest that we attempt to find a pragmatic solution how 
the S/MIME trust bit could be kept alive with a minimal amount of resources on 
top of the great work for the SSL/TLS trust bit.

Here is an attempt of a starting point for a programtic solution:


(a) Only grant the S/MIME trust bit if a CA has been granted the SSL/TLS
trust bit already.

If Mozilla decides to remove a SSL/TLS trust bit, the S/MIME trust bit (and 
potentiall all other trust bits) for that CA will get removed, too.

This eliminates the need to work on any CAs that are for the S/MIME purpose, 
only.


(b) Only CAs that explicitly state they'd like to be granted the S/MIME
trust bit might potentially get it.

This avoids the likelyhood that any CA's root gets accidentally used for the 
non -SSL/TLS purpose.


(c) The community on this list works together to define what additional
requirements a CA needs to comply with, in order to obtain the
S/MIME trust bit.

The definitions of these additional requirements should be kept completely 
separate from the SSL/TLS trust bit documents, to allow participants of the 
S/MIME trust bit community to work independently.


(d) Going forward, require that no intermediate certificate will ever be used 
to
issue certificates for SSL/TLS servers and S/MIME.

This is simply an idea to address an argument that has been made in the 
discussion, that it might be problematic to mix issueing environments.

However, for practical purposes, I'd suggest it should still be allowed to 
issue certificates that can be used for both S/MIME and SSL/TLS client 
authentication.


(e) Discuss if a misissuance of S/MIME certificates can have the consequence
of losing the SSL/TLS trust bit, too.


With an approach like this, the work required to evaluate the request of a CA 
for the S/MIME trust bit would be limited to:

(1) A one time effort to define (c), and ocassionally the refinement of (c),
mainly driven by the community, and someone who will make the final call.

(2) Someone who evaluates the inclusion requests and compliance with (c).


Everyone, would a policy like this make sense?

Kathleen, do you think a policy like this would still require a half time 
position for the "someone" mentioned in (1) and (2), or could it be done with 
a smaller amount of time? Could the CAs be required to do most of the work to 
demonstrate their compliance, and only require the dedicated person to verify 
the documentation for plausability?

Thanks,
Kai

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


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

A pragmatic solution for the S/MIME trust bit

[Kai Engert]

The earlier comments on this list have shown that S/MIME is in active use (e.g.
in communication between different academic instutions), and that a decision to
remove the S/MIME trust bit from the Mozilla CA list would mean a functional
regression for those users.

In my opinion, the discussion about the quality of the S/MIME code in NSS or in
Thunderbird should be completely separate from the discussion about the trust
bit, because there is non-Mozilla open source software that is able to make use
that trust bit, too (e.g. OpenSSL also has an implementation for S/MIME).

I don't know if we'll find sufficient resources to start a separate CA program
for the S/MIME trust bit. It seems that the lobby for encrypted email is much
weaker than the lobby for web site security, maybe because it isn't used to sell
products or content to consumers.

Nevertheless, I believe that supporting privacy in communication between
individuals is an important value. The publicly agreed list of CA certificates
is a very helpful resource that makes it easier for any new project that wants
to buildon upson PKI for that purpose.

Therefore I'd like to suggest that we attempt to find a pragmatic solution how
the S/MIME trust bit could be kept alive with a minimal amount of resources on
top of the great work for the SSL/TLS trust bit.

Here is an attempt of a starting point for a programtic solution:


(a) Only grant the S/MIME trust bit if a CA has been granted the SSL/TLS
trust bit already.

If Mozilla decides to remove a SSL/TLS trust bit, the S/MIME trust bit (and
potentiall all other trust bits) for that CA will get removed, too.

This eliminates the need to work on any CAs that are for the S/MIME purpose,
only.


(b) Only CAs that explicitly state they'd like to be granted the S/MIME
trust bit might potentially get it.

This avoids the likelyhood that any CA's root gets accidentally used for the non
-SSL/TLS purpose.


(c) The community on this list works together to define what additional
requirements a CA needs to comply with, in order to obtain the
S/MIME trust bit.

The definitions of these additional requirements should be kept completely
separate from the SSL/TLS trust bit documents, to allow participants of the
S/MIME trust bit community to work independently.


(d) Going forward, require that no intermediate certificate will ever be used to
issue certificates for SSL/TLS servers and S/MIME.

This is simply an idea to address an argument that has been made in the
discussion, that it might be problematic to mix issueing environments.

However, for practical purposes, I'd suggest it should still be allowed to issue
certificates that can be used for both S/MIME and SSL/TLS client authentication.


(e) Discuss if a misissuance of S/MIME certificates can have the consequence
of losing the SSL/TLS trust bit, too.


With an approach like this, the work required to evaluate the request of a CA
for the S/MIME trust bit would be limited to:

(1) A one time effort to define (c), and ocassionally the refinement of (c),
mainly driven by the community, and someone who will make the final call.

(2) Someone who evaluates the inclusion requests and compliance with (c).


Everyone, would a policy like this make sense?

Kathleen, do you think a policy like this would still require a half time
position for the "someone" mentioned in (1) and (2), or could it be done with a
smaller amount of time? Could the CAs be required to do most of the work to
demonstrate their compliance, and only require the dedicated person to verify
the documentation for plausability?

Thanks,
Kai

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

Re: Symantec Test Cert Misissuance Incident

[Gervase Markham]

On 15/10/15 10:54, Rob Stradling wrote:
> Rick, your report [1] states that...
> 
>"...the certificates never left Symantec's secure test labs or the

A charitable reading of this might be "the private keys never left...".
But yes, it might help to have more details on what exactly is being
claimed here.

> QA test machine, and they were never visible to any end user...
> One of these test certificates with a CN=www.google.com was an
> Extended Validation (EV) test certificate and was logged to public
> Certificate Transparency (CT) log servers"
> 
> IIUC, this statement claims that, out of all the certs/precerts listed
> in [2], the www.google.com precertificate [3] is the only one that "left
> Symantec's secure test labs".

It would be helpful to know if the test certificate generation software
logged the certs it generated to CT. If so, would we not expect more of
them to be there? If not, how did some of them end up there? Were they
placed there manually as part of the test?

>   - an EV cert for 123Symantec.com - see [6].

Note that that cert has a SAN for "san2.com", which is a domain owned by
someone other than Symantec.

> Also, when I looked for evidence of any of the other certs in [2] in
> some of our historical SSL crawler logs, I was surprised to find that...

These findings are indeed surprising, although it seems more likely that
there are problems with Symantec's list than threats to the CA system.
Previous Symantec test certs I've seen have had Symantec in the O field,
which is not true for these.

Rick: how are you determining which certs to add to your list? Are the
ones Rob has found in the wild mistaken additions, or were they in fact
test certs which were supposed not to leave the lab?

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

Re: Symantec Test Cert Misissuance Incident

[Rob Stradling]

Rick, your report [1] states that...

   "...the certificates never left Symantec's secure test labs or the
QA test machine, and they were never visible to any end user...
One of these test certificates with a CN=www.google.com was an
Extended Validation (EV) test certificate and was logged to public
Certificate Transparency (CT) log servers"

IIUC, this statement claims that, out of all the certs/precerts listed 
in [2], the www.google.com precertificate [3] is the only one that "left 
Symantec's secure test labs".



So, when I looked up all of the serial numbers in [2] in crt.sh, I was 
surprised to find...


  - 2 certs for *.icns.com.au (which you've explained already).

  - 2 precertificates, and the corresponding 2 EV certificates, for 
evgabrieltest.bbtest.com - see [4].


  - an EV cert for symantec-waf01.scutum.jp - see [5].

  - an EV cert for 123Symantec.com - see [6].


Also, when I looked for evidence of any of the other certs in [2] in 
some of our historical SSL crawler logs, I was surprised to find that...


  - the certificate with serial number 14c943, issued by "Equifax 
Secure Certificate Authority", was in use when we accessed 
https://avodcdn01-a.akamaihd.net on 9th June 2011 (IP address 
184.86.230.82) and 25th June 2011 (IP address 95.101.190.82).  This 
certificate wasn't known to CT until I logged it just now - see [7].


  - the certificate with serial number 
1962f4d772f9e9c7ef2d09dd40d85a2c, issued by "VeriSign Class 3 Extended 
Validation SSL SGC CA", was in use when we accessed 
https://remote.tdsolutionscenter.com (IP address 96.243.213.32) on the 
8th, 11th, 13th and 22nd January 2013.  remote.tdsolutionscenter.com 
still resolves to that IP address today.  This certificate wasn't known 
to CT until I logged it just now - see [8].



I also found a copy of the certificate with serial number 64b32, issued 
by "GeoTrust DV SSL CA" (although for some reason I wasn't able to find 
a record of where we discovered that cert).  This certificate wasn't 
known to CT until I logged it just now - see [9].



[1] 
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf


[2] 
https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf


[3] https://crt.sh/?id=9314698

[4] https://crt.sh/?q=evgabrieltest%2Ebbtest%2Ecom&iCAID=1454

[5] https://crt.sh/?id=5934504

[6] https://crt.sh/?id=9324337

[7] https://crt.sh/?id=10162388

[8] https://crt.sh/?id=10162533

[9] https://crt.sh/?id=10162537

--
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: Symantec Test Cert Misissuance Incident

[Rob Stradling]

On 15/10/15 00:04, Rick Andrews wrote:

On Tuesday, October 13, 2015 at 5:16:10 PM UTC-7, Charles Reiss wrote:



This list of test certs for owned domains contains an entry for
a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013
22:27:16 GMT to 06/20/2015 13:57:13 GMT (last entry of the owned domains PDF).
This appears to be this certificate https://crt.sh/?id=1990400 which has:



Thanks for your post.

Symantec does not own the icns.com.au domain, but we had authorization by the 
domain owner to use the domain for testing. This icns.com.au test certificate 
was properly authenticated, and was installed and used externally by the domain 
owner.

We included this certificate on our list of certificates associated with 
domains that we do not own, which is accurate. However, because we had 
authorization from the domain owner to issue the certificate, this certificate 
did not need to be on this list but was included for completeness.


Hi Rick.

Doesn't "installed and used externally" conflict with the following 
statement from your report [1] (emphasis mine) ?

  "Through a comprehensive internal review, we confirmed this incident
   was limited only to the issuance of test certificates, which *at all
   times were fully controlled within Symantec* and never posed any
   threat to any user or organization."

BTW, [2] also lists another, older certificate for the same domain - 
*.icns.com.au:

https://crt.sh/?id=658905


[1] 
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf


[2] 
https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf


--
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: Symantec Test Cert Misissuance Incident

[Rob Stradling]

On 14/10/15 18:16, Gervase Markham wrote:

On 14/10/15 13:47, Rob Stradling wrote:

(There are actually 187 rows, but 3 certs are counted twice)


And that's not perhaps because one copy is with a CT poison extension,
and the other is with an SCT?


That's extremely unlikely.

None of those 3 are EV certs, none of them are in any of the known CT 
logs, and (looking at the Issue Dates) it looks like they were all 
issued before Symantec's CA systems had any support for CT.


The 3 duplicate rows are:

Serial Number: 27dc521a863f0921d023f5cda82b
Issuer: Thawte DV SSL CA
Issue Date: 02/13/2012 00:00:00 GMT
Expiry Date: 02/12/2013 23:59:59 GMT
Revoke Date: 10/09/15

Serial Number: 383b98e06ad18d776f2cd668200d9fef
Issuer: GeoTrust SSL CA - G2
Issue Date: 03/21/2014 00:00:00 GMT
Expiry Date: 03/21/2015 23:59:59 GMT
Revoke Date: 04/10/14

Serial Number: 402ad03afe8c3341d452a5ac6efa1462
Issuer: GeoTrust SSL CA - G2
Issue Date: 03/21/2014 00:00:00 GMT
Expiry Date: 03/21/2015 23:59:59 GMT
Revoke Date: 04/10/14

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