Re: Misissued/Suspicious Symantec Certificates

[Peter Bowen via dev-security-policy]

"auditing standards that underlie the accepted audit schemes found in
Section 8.1"

This is obviously a error in the BRs.  That language is taken from
Section 8.1 and there is no list of schemes in 8.1.

8.4 does have a list of schemes:
1. WebTrust for Certification Authorities v2.0;
2. A national scheme that audits conformance to ETSI TS 102 042/ ETSI
EN 319 411-1;
3. A scheme that audits conformance to ISO 21188:2006; or
4. If a Government CA is required by its Certificate Policy to use a
different internal audit scheme, it MAY use such scheme provided that
the audit either (a) encompasses all requirements of one of the above
schemes or (b) consists of comparable criteria that are available for
public review.

1. is slight problematic as no scheme exists by that name, but "Trust
Service Principles and Criteria for Certification Authorities Version
2.0" does exist, which is what I assume is meant.

If we assume that audit scheme, my understanding is that the "auditing
standards that underlie" the scheme is one of the following (which one
depends on the date of the audit and the licensure of the auditor):
(1) AT sec. 101 from SSAE No. 10/11/12 (AICPA)
(2) AT-C sec. 205 from SSAE No. 18 (AICPA)
(3) Section 5025 (CPA Canada)
(4) CSAE 3000 (CPA Canada)
(5) ISAE 3000 (IFAC)

There should be no lack of auditing standards that underlie the Trust
Service Principles and Criteria for Certification Authorities Version
2.0 audit scheme found in section 8.4.

Thanks,
Peter

On Thu, Feb 23, 2017 at 1:19 AM, Ryan Sleevi via dev-security-policy
 wrote:
> I'm sorry, I'm still a little confused about how to understand your
> response.
>
> I can't tell if you're discussing in the abstract - as in, you don't know
> how an Delegated Third Party would ever meet that definition, due to the
> absence of "auditing standards that underlie the accepted audit schemes
> found in Section 8.1" therefore you don't think what Symantec has been
> doing since 2010 is permitted by the Baseline Requirements at all, and they
> should have stopped five years ago. That implies you read through the links
> provided by Symantec so far of the four RAs that they assert were operating
> as Delegated Third Parties (which is the only way this could have been
> acceptable to begin with), but that you disagree that they're evidence of
> compliance with the restrictions on the Delegated Third Parties. Is this
> what you meant?
>
> Or if you mean something concrete - that is, that you literally are
> interested and curious, without any subtext. In that case, it implies you
> may not have checked the links in the message you were replying to yet, and
> this was more of an aside, rather than a direct question. If this was the
> case, do you think it's reasonably clear the question I'd asked of Steve?
>
> Or am I completely off the mark? I just want to make sure that the question
> I asked is clear and unambiguous, as well as making sure I'm not
> misunderstanding anything.
>
> On Wed, Feb 22, 2017 at 9:21 PM, Jeremy Rowley 
> wrote:
>
>> I am aware of the requirements but am interested in seeing how an RA that
>> doesn't have their own issuing cert structures the audit report. It
>> probably looks the same, but I've never seen one (unless that is the case
>> with the previously provided audit report).
>>
>> On Feb 22, 2017, at 8:48 PM, Ryan Sleevi  wrote:
>>
>>
>>
>> On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley > > wrote:
>>
>>> Webtrust doesn't have audit criteria for RAs so the audit request may
>>> produce interesting results. Or are you asking for the audit statement
>>> covering the root that the RA used to issue from? That should all be public
>>> in the Mozilla database at this point.
>>
>>
>> Hi Jeremy,
>>
>> I believe the previous questions already addressed this, but perhaps I've
>> misunderstood your concern.
>>
>> "Webtrust doesn't have audit criteria for RAs so the audit request may
>> produce interesting results."
>>
>> Quoting the Baseline Requirements, v.1.4.2 [1] , Section 8.4
>> "If the CA is not using one of the above procedures and the Delegated
>> Third Party is not an Enterprise RA, then the
>> CA SHALL obtain an audit report, issued under the auditing standards that
>> underlie the accepted audit schemes
>> found in Section 8.1, that provides an opinion whether the Delegated Third
>> Party’s performance complies with
>> either the Delegated Third Party’s practice statement or the CA’s
>> Certificate Policy and/or Certification Practice
>> Statement. If the opinion is that the Delegated Third Party does not
>> comply, then the CA SHALL not allow the
>> Delegated Third Party to continue performing delegated functions. "
>>
>> Note that Symantec has already provided this data for the four RA partners
>> involved for the 2015/2016 (varies) period, at [2]. Specifically, see the
>> response to Question 5 at [3].
>>
>> "Or are 

Re: Misissued/Suspicious Symantec Certificates

[Ryan Sleevi via dev-security-policy]

On Wed, Feb 22, 2017 at 8:32 PM, Ryan Sleevi  wrote:

> Hi Steve,
>
> Thanks for your continued attention to this matter. Your responses open
> many new and important questions and which give serious question as to
> whether the proposed remediations are sufficient. To keep this short, and
> thereby allow Symantec a more rapid response:
>
> 1) Please provide the CP, CPS, and Audit Letter(s) used for each RA
> partner since the acquisition by Symantec of the VeriSign Trust Services
> business in 2010.
>

Hi Steve,

Have you had the opportunity to review and complete this? This is hopefully
a simple task for your compliance team, given the critical necessity of
maintaining of records, so I'm hoping that you can post within the next
business day.

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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

[Gervase Markham via dev-security-policy]

On 24/02/17 07:08, blake.mor...@trustis.com wrote:
> Certificates for the HMRC SET Service are issued from the SHA-1 “FPS
> TT Issuing Authority”, which is now only used for this service.  The
> replacement server certificate for hmrcset.trustis.com was issued
> from the FPS TT IA, via a manual process under the mistaken belief
> that this was necessary for this particular service to operate
> correctly.

And presumably under the further mistaken belief that "necessary for
this particular service to operate correctly" was a good enough reason
to disregard the SHA-1 ban?

> Trustis has some time ago, migrated all TLS certificate production to
> SHA-256 Issuing Authorities.  The small number of previously issued
> SHA-1 TLS certificates issued from “FPS TT”, that had lifetimes
> extending beyond 1 Jan 2017, were revoked towards the end of 2016.

Except the one in use on hmrcset.trustis.com? It's not clear how the
certificate-nearing-expiry for that domain fits into the last sentence
of the paragraph above.

> As a result of the investigation the security management committee
> has made a number of recommendations.  Principal amongst these is
> enhanced training and oversight for technical staff that deal with
> unique certificates or certificate management in complex
> circumstances that are not part of standard operations.

Have you deleted, locked or otherwise made unavailable all SHA-1
profiles which relate to intermediates which chain up to publicly
trusted roots?

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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

[Andrew Ayer via dev-security-policy]

On Fri, 24 Feb 2017 07:08:54 -0800 (PST)
"blake.morgan--- via dev-security-policy"
 wrote:

> Trustis has some time ago, migrated all TLS certificate production to
> SHA-256 Issuing Authorities.  The small number of previously issued
> SHA-1 TLS certificates issued from “FPS TT”, that had lifetimes
> extending beyond 1 Jan 2017, were revoked towards the end of 2016.

Below is an unrevoked SHA-1 serverAuth certificate for
getset.trustis.com issued from this CA with a Not Before date of
2016-11-07.

Regards,
Andrew

-BEGIN CERTIFICATE-
MIIFYjCCBEqgAwIBAgIQXk1LkWmIzHB+YFd0TZ1TTDANBgkqhkiG9w0BAQUFADBS
MQswCQYDVQQGEwJHQjEYMBYGA1UEChMPVHJ1c3RpcyBMaW1pdGVkMSkwJwYDVQQL
EyBUcnVzdGlzIEZQUyBUVCBJc3N1aW5nIEF1dGhvcml0eTAeFw0xNjExMDcxNTE4
NTZaFw0yMDAxMTcxMTQ1NTZaMGsxCzAJBgNVBAYTAkdCMRgwFgYDVQQKEw9UcnVz
dGlzIExpbWl0ZWQxJTAjBgNVBAsTHEhNUkMgU0VUIENlcnRpZmljYXRlIFNlcnZp
Y2UxGzAZBgNVBAMTEmdldHNldC50cnVzdGlzLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMMvz9cWfI8vaGUdYPPr7uh41whxzhx0pFd6D0yTg2gd
MR8fqA93VViWV2XGqbFdbUnRQHksFZ0Vx6kA4BbyP/zRpaC3vOtcYpYqWnfudZLw
wRxVOwzVkz6ImhxiSWjbX1BdsDCohTmCBha4CKdtUewxeXQlIt2Cz//oxRvsZM+S
owY76YEDMF5V5lGgtYQXgyj/Oau7PAVurKtGB5IUbSBjXsfZsg4W//qsJzhlPLym
lmnWM2Yg/ykDLFKWeehRFa6jCz8w0JiRK5ynGu0aps//g65w+jeHiZyFzldWazqf
PpgvvKNtEYlT4pWc27Tk38ZzH8jNUksa9T9RBBnKUFcCAwEAAaOCAhkwggIVMB8G
A1UdIwQYMBaAFMCiJVnUHgITg9QvBIhUSiCNb43+MIIBOgYDVR0gBIIBMTCCAS0w
ggEpBgorBgEEAah1AQEDMIIBGTAtBggrBgEFBQcCARYhaHR0cDovL3d3dy50cnVz
dGlzLmNvbS9wa2kvZnBzaWEvMIHnBggrBgEFBQcCAjCB2hqB10lzc3VlZCBpbiBh
Y2NvcmRhbmNlIHdpdGggYW5kIGdvdmVybmVkIGJ5IHRoZSBUcnVzdGlzIEZQUyBJ
c3N1aW5nIEF1dGhvcml0eSBDZXJ0aWZpY2F0ZSBQb2xpY3kgd2hpY2ggY2FuIGJl
IGZvdW5kIGF0IGh0dHA6Ly93d3cudHJ1c3Rpcy5jb20vcGtpL2Zwc2lhLyAgIFRy
dXN0aXMgRlBTLCBhIGRpdmlzaW9uIG9mIFRydXN0aXMgTGltaXRlZCAod3d3LnRy
dXN0aXMuY29tKQ0KMHAGA1UdHwRpMGcwZaBjoGGGLmh0dHA6Ly93d3cudHJ1c3Rp
cy5jb20vcGtpL2Zwc2lhL2NybC90dC1lZS5jcmyGL2h0dHA6Ly9zY2NzLnRydXN0
aXMuY29tL3BraS9mcHNpYS9jcmwvdHQtZWUuY3JsMBMGA1UdJQQMMAoGCCsGAQUF
BwMBMA4GA1UdDwEB/wQEAwIFoDAdBgNVHQ4EFgQUudovYJjp2vzykUX0GuDVS6oL
hLMwDQYJKoZIhvcNAQEFBQADggEBAB/xHCvYydnefZrndUVVUMpUBCPkfmSAjWna
G/cu6xrLxy+SwNXqpUydcIKNj3MyoZCIfzzSGpB0GbE2fXKvVt0vW3+fqcPGBtz/
szYldrROH2DVbg4e3GbkV65SomwMpnQfvwBydLOa7eCyqD5uYQ4BVyT0bAnoiRHj
QrWpkbVknpgnvIDQR7NO6msg2hwiNH1j3VyfWaPTxLT2tybzgQzC2uH0ivTJim4n
Kbya3zUApBKgP5ylJSXh/t5sVKlB32Qby8fpxoDsPLexJZPiRJSJx6t/iCxpshB2
v8gl8IWKHF3xIdWfW4H72U/zIyEKnyR+1C/0KxnZP56tbtxWGp0=
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIFEDCCA/igAwIBAgIRAOvV+QArW1IlExGq8Ft+41EwDQYJKoZIhvcNAQEFBQAw
RTELMAkGA1UEBhMCR0IxGDAWBgNVBAoTD1RydXN0aXMgTGltaXRlZDEcMBoGA1UE
CxMTVHJ1c3RpcyBGUFMgUm9vdCBDQTAeFw0xMDEyMDExMjQyMzBaFw0yMDAxMTgx
MTQyMzBaMFIxCzAJBgNVBAYTAkdCMRgwFgYDVQQKEw9UcnVzdGlzIExpbWl0ZWQx
KTAnBgNVBAsTIFRydXN0aXMgRlBTIFRUIElzc3VpbmcgQXV0aG9yaXR5MIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAk7x4ogwd5RxiVm5ucUkaPjD592H3
fWNa+1jSz/GdP2VaCigGdAYGC9CdPrO5q+X2liSTjcW23OOoJxV//Dv5o73c+qmP
24LlUmhoddbk6yn6sBAZLqw0GbqITqQz+hSUD5V+JzV6LJfSmSBtBOT3ALQwgssC
RO5H/RkyGfKmdHqFfgorzwrUjSmuSPx2+ke9Q3kR2yL0Sk4741gRaPq5fo9XgZNY
80FLYnNthHM5wq9koUkmbogYW2qtO5aKv9N8KLWoW3dfLizloLqRiR+Kkuscgnty
LEvumNVF0o5LBk+h8KIqgTJWUyEmlAMQ0vFbCRFXVr+mu7CgJNK5gGIRGQIDAQAB
o4IB7DCCAegwHwYDVR0jBBgwFoAUuvpxJXmLV0ElIYYLceuyZA6LIWcwDwYDVR0T
AQH/BAUwAwEB/zCCAUcGA1UdIASCAT4wggE6MIIBNgYKKwYBBAGodQEBAzCCASYw
LQYIKwYBBQUHAgEWIWh0dHA6Ly93d3cudHJ1c3Rpcy5jb20vcGtpL2Zwc2lhLzCB
9AYIKwYBBQUHAgIwgecwChYDQ1BTMAMCAQEagdhJc3N1ZWQgaW4gYWNjb3JkYW5j
ZSB3aXRoIGFuZCBnb3Zlcm5lZCBieSB0aGUgVHJ1c3RpcyBGUFMgSXNzdWluZyBB
dXRob3JpdHkgQ2VydGlmaWNhdGUgUG9saWN5IHdoaWNoIGNhbiBiZSBmb3VuZCBh
dCANCmh0dHA6Ly93d3cudHJ1c3Rpcy5jb20vcGtpL2Zwc2lhLw0KDQpUcnVzdGlz
IEZQUywgYSBkaXZpc2lvbiBvZiBUcnVzdGlzIExpbWl0ZWQgKHd3dy50cnVzdGlz
LmNvbSkwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL3d3dy50cnVzdGlzLmNvbS9w
a2kvZnBzL2NybC9pYS5jcmwwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTAoiVZ
1B4CE4PULwSIVEogjW+N/jANBgkqhkiG9w0BAQUFAAOCAQEAVF6ttbAx8r0dwLlr
0wz/gHOC9ham3PHHDvlcC09QvoD3uOgqfdrtlLeTUHZHu4bYRELsEofUfsF5cHQS
M08SinUam3LWYrNygmwU4XNYk8M475Igun2wM30cx9TiBhL4VmdpG7T9Q2GF89YE
0YQf3xki3FltHOC7KtOHlBTktYgYwPdCdp0I0nEKMLUtd0OBPG2jPKU5gmBf5nxX
LlQpt5JkxY7Eg2PVXUkIEaKiCqjzLepLdFXCuAI1ONBxKNhD8bcq2NCT/e4+WRXk
7cqqnpseNaUdV7PRNjR/JttcYjXNCZ5dVYnpvlVLOonPI7mleR6ikAJX3mZiVSwY
bFKzCg==
-END CERTIFICATE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

[blake.morgan--- via dev-security-policy]

On Monday, February 20, 2017 at 11:50:59 AM UTC, Gervase Markham wrote:
> On 16/02/17 18:26, blake.mor...@trustis.com wrote:
> > Trustis has now revoked the SHA-1 Certificate for hmrcset.trustis.com
> > and replaced it with a SHA-256 Certificate.  This status is reflected
> > in the latest CRL.
> 
> Hi Blake,
> 
> We are pleased to hear that, but the detail of your report compares
> somewhat unfavourably with that of QuoVadis, about whom a similar
> problem was raised in the same timeframe. You can find their report here:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/xxtUlTOo6ak/XX6WqlEmEQAJ
> 
> We would appreciate it if Trustis could produce a similar document
> within the week.
> 
> Many thanks,
> 
> Gerv

Hi Gerv,

Please see Trustis' formal report into the incident posted below:

Trustis Incident Report

Background
 
Trustis provides specific services for a UK government department, HMRC.  This 
organisation acts as the only relying party and also has considerable control 
and influence over the nature of the service.  The hmrcset.trustis.com 
certificate provides TLS protection for an enrolment portal which forms part of 
this service.  It is used by a small number of applicants that have a 
pre-defined and established relationship with HMRC. The private keys for this 
certificate are managed and controlled by Trustis. 

This particular certificate was approaching expiry and a replacement was issued 
as part of a routine renewal process.

Certificates for the HMRC SET Service are issued from the SHA-1 “FPS TT Issuing 
Authority”, which is now only used for this service.  The replacement server 
certificate for hmrcset.trustis.com was issued from the FPS TT IA, via a manual 
process under the mistaken belief that this was necessary for this particular 
service to operate correctly. 

Trustis has some time ago, migrated all TLS certificate production to SHA-256 
Issuing Authorities.  The small number of previously issued SHA-1 TLS 
certificates issued from “FPS TT”, that had lifetimes extending beyond 1 Jan 
2017, were revoked towards the end of 2016.

Actions

Upon receiving notification of the mis-issuance, an assessment was conducted. 
As a result Trustis issued a replacement SHA-2 certificate and revoked the 
non-compliant certificate. .This was included in the CRL issued at 1806 hrs 
(UTC) on the 16th February 2017.

As part of the incident handling procedure, Trustis’ security management 
committee, commissioned a full investigation into the circumstances surrounding 
this incident and the details are provided below.

Investigation 

The generation of the private keys and the production of the certificate in 
question are managed via Trustis internal procedures.  These are separate to 
those for external Subscribers.  In this case the operation was made somewhat 
more complex due to the transition from SHA-1 to SHA-2 and the difficulty our 
customer had endured as a result.  

As a result of this, the operator mistakenly issued the certificate based on 
the customer’s SHA-1 requirements and it was subsequently issued from “FPS-TT”, 
under the belief that this was necessary for this particular service to 
operate.  The operator had failed to recognise that, despite the transition 
difficulties for our customer, a new SHA-2 profile specification should have 
been used.  

As a result of the investigation the security management committee has made a 
number of recommendations.  Principal amongst these is enhanced training and 
oversight for technical staff that deal with unique certificates or certificate 
management in complex circumstances that are not part of standard operations.   

Regards,

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