Atos Root Inclusion Request

[Kathleen Wilson]

Atos applied to include the “Atos TrustedRoot 2011” root certificate and
enable all three trust bits.

Atos Trustcenter acts in Europe, but also has international customers.
The PKI-Services are offered to the Public, with no restrictions to user
groups.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=711366

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Atos

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=725143

Noteworthy points:

* The primary document is the CPS which is provided in English.

Document Repository: https://pki.atos.net/TrustedRoot/

CPS (English):
https://pki.atos.net/EJPKI-WebFrontend/Public/TrustedRoot/Download?File=AtosTrustedCA_CPS_v1.5.pdf


Subscriber Agreement: https://bugzilla.mozilla.org/attachment.cgi?id=582228

This root signs three types of internally-operated intermediate
certificates for issuing SSL server, client, and code signing
certificates. The current subCAs are:
- Atos TrustedRoot Client‐CA 2011
- Atos TrustedRoot Client‐CA 2012
- Atos TrustedRoot Server‐CA 2011
- Atos TrustedRoot CodeSigning‐CA 2011

All three trust bits are requested.

* CPS chapter 4.2: The identity of an applicant is verified for the
different CAs with different evidences:
- [SSL-CA]: AO collects the necessary evidences for the verification of
the subject’s identity, requesting an AO SSL Server CA certificate. More
details see statement 77.
- [Client-CA]: AO collects the necessary evidences either directly for
the verification of the subject’s identity, requesting an AO Client CA
certificate. Alternatively there exists a registration authority
authorized by the CA and operating according to a contractual agreement
which is offered to a specific group of subscribers. The registration
authority collects the evidences for the verification of the subject’s
identity belonging to this group of subscribers. More details see
statements 69, 73, 74 and 75.
- [CodeSigning-CA]: AO collects the necessary evidences for the
verification of the subject’s identity, requesting an AO CodeSigning CA
certificate. More details see statement 76.

* CPS chapter 4.2, statement 77: A legal entity, represented by a device
or system, which requests a certificate is identified and authenticated
for the first time via the subject’s name of the certificate:
- The device or system possesses an Internet Domain name, and a
registration as Top Level Domain (which can be found for Germany with
www.denic.de or international with www.iana.com), where the registered
full name of the legal entity is registered and this matches the
subject’s full name.
- The legal’s entity full name matches the subject’s name in the
certificate.
- The existence of the legal entity is evident from an excerpt from the
commercial register (certificate of registration, in Germany:
Handelsregisterauszug).

* Atos_ca_Information_v1.1.pdf: After the request was created by a
customer, an email will be send to the email address given in the
certificate. The email contains a system generated one-time-password,
which the customer has to use to activate the certificate request.

* CPS chapter 4.2, statements 69, 73, 74, 75.
Statement 75: In addition to the personal identification and
authentication a representative has to provide:
- Evidence that he or she is authorized by the legal entity to request a
certificate (the name of the person is included in the certificate as
the subject) for it
- Evidence of the existence of the legal entity in form of
-- an excerpt from the commercial register (certificate of registration,
in Germany: Handelsregisterauszug), or
-- a registration of a Top Level Domain (which can be found for Germany
with www.denic.de or international with www.iana.com)

* Atos_ca_Information_v1.1.pdf: After register a new account at the
Website an email with a system generated one-time-password will be send
to the given mail address. The customer has to activate the service with
this password. After this procedure the customer could create
certificate request for this email address only

* CPS chapter 4.2 Statement 76: A legal entity requesting a certificate
is identified and authenticated for the first time via the subject’s
name of the certificate:
- The legal’s entity full name matches the subject’s name in the
certificate.
- The existence of the legal entity in form is evident with either
-- an excerpt from the commercial register (certificate of registration,
in Germany: Handelsregisterauszug), or
-- a registration as Top Level Domain (which can be found for Germany
with www.denic.de or international with www.iana.com), where the
registered full name of the legal entity is registered and it matches
the subject’s full name.


* EV Policy OID: Not requesting EV treatment.

* Root Cert: https://pki.atos.net/certs/Atos_TrustedRoot_2011.cer

* Test Website: https://pki.atos.net:7081/

* CRL
https://pki.atos.net/crl/Atos_TrustedRoot_CA_2011.crl
http://pki.atos.net/crl/Atos_TrustedRoot_Server_CA_2011.crl (NextUpdate:
24 hours)
CPS section 3.3: CRLs are published at least every 24 hours.

* OCSP: http://pki-ocsp.atos.net

* Audit: Audits are performed by DQS Holding GmbH,
https://de.dqs-ul.com, according to the ETSI TS 102 042 criteria. Annual
surveillance audits are also performed in order to maintain ETSI
certification.
The ETSI certificate is posted on the auditor’s website:
https://de.dqs-ul.com/kunden/kundendatenbank.html?aoemydqs[company_no]=334220&aoemydqs[action]=singleView&cHash=c086db2a2cd03a17407d1f2712ab2dd4


* Potentially Problematic Practices – None noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from Atos to include the “Atos
TrustedRoot 2011” root certificate and turn on all three trust bits. 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.

Kathleen

[Kathleen Wilson]

Does anyone of comments, questions, or concerns about this request?

If not, I will close this discussion and recommend approval in the bug.

Thanks,
Kathleen

[Erwann Abalea]

Le jeudi 14 mars 2013 23:54:30 UTC+1, Kathleen Wilson a écrit :
> Atos applied to include the “Atos TrustedRoot 2011” root certificate and
> enable all three trust bits.

[...]

> * Root Cert: https://pki.atos.net/certs/Atos_TrustedRoot_2011.cer
>
> * Test Website: https://pki.atos.net:7081/
>
> * CRL
> https://pki.atos.net/crl/Atos_TrustedRoot_CA_2011.crl
> http://pki.atos.net/crl/Atos_TrustedRoot_Server_CA_2011.crl (NextUpdate:
> 24 hours)
> CPS section 3.3: CRLs are published at least every 24 hours.
>
> * OCSP: http://pki-ocsp.atos.net

The intermediate CAs (Server, Client, CodeSigning) don't contain necessary information to check for their revocation status, there's no CRLDP and no AIA:OCSP extension.

This contradicts your answer to Mozilla January 10, 2013 Communication.
Question 3 was:
"While you are scanning your certificate databases to ensure that all certificates with basicConstraints:CA:TRUE have been issued in accordance with your CPS, please also check for compliance with the following practices.

* All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.
* All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.
* [...]"

And your answer was:
"3. We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted.
We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices."

[kramerm...@gmail.com]

The intermediate CAs for Client and CodeSigning already contain the necessary information to check their revocation status.
The given CRLDP is
[1]Sperrlisten-Verteilungspunkt
Name des Verteilungspunktes:
Vollst. Name:
URL=http://pki-crl.atos.net/crl/Atos_TrustedRoot_CA_2011.crl
URL=ldap://pki-ldap.atos.net/cn=Atos%20TrustedRoot%202011,ou=CA,ou=Atos%20TC,o=Atos,dc=atos,dc=net?certificateRevocationList
Sperrlistenaussteller:
Verzeichnisadresse:
CN=Atos TrustedRoot 2011
O=Atos
C=DE

Only the intermediate CA for SSL is missing this information.
We already prepared this change (include the CRLDP) for this intermediate CA while checking and answering Mozilla January 10, 2013 Communication.
Until now we do not create SSL-Server certificates from this CA, because we are not on the list of Mozilla Trusted Root CAs yet. So we did not implement this change directly. We will implement this change within the next few days and we will inform you when the new intermediate CA is installed and running. The old (current) SSL intermediate CA will be revoked.

[Erwann Abalea]

Le lundi 8 avril 2013 14:56:01 UTC+2, martin...@atos.net a écrit :
> The intermediate CAs for Client and CodeSigning already contain the necessary information to check their revocation status.

[...]

> Only the intermediate CA for SSL is missing this information.

This is not what I found while browsing your LDAP server.

Here's your intermediate "Client CA" cert:
-----BEGIN CERTIFICATE-----
MIIDgTCCAmmgAwIBAgIIW2qOjVqGcY8wDQYJKoZIhvcNAQELBQAwPDEeMBwGA1UE
AwwVQXRvcyBUcnVzdGVkUm9vdCAyMDExMQ0wCwYDVQQKDARBdG9zMQswCQYDVQQG
EwJERTAeFw0xMTA3MDcxNTA0MTFaFw0yMTA3MDQxNTA0MTFaMEYxKDAmBgNVBAMM
H0F0b3MgVHJ1c3RlZFJvb3QgQ2xpZW50LUNBIDIwMTExDTALBgNVBAoMBEF0b3Mx
CzAJBgNVBAYTAkRFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAgQoA
pzpVfAmKoQscO9Mn+B/UlmTPBi/4CEqsS5ovFkUT1YTWkqxmlGgmk62BxVKlpQWV
c7tdKXyqymQ+dIcySX+Bb4I6F18p2Do5QAAXcKBjlLeZbACdfDewiNj766enrBqa
xphF4Z6nz0HbNb+pJzCQUdnkgf+EwkmqR78Y6t6cQ+nzCvWGvg1uZCxHv5eagnqg
/e31CaZjp96hihcyw7Ur6cz+RJPN5wLxWcDNCX0pKGZtaAjvPTIX2tcOjJdh5One
2+fc3P0bZZG7xBuxhOc5A0ASa/fWPV03B0CvS2y2YTOM2bgYDpnNyEUJI5QJArK8
waa64ghmvBsRXSIUQwIDAQABo30wezAdBgNVHQ4EFgQU0JWX2DAytp9j5+BZYE0d
CMrw9OIwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBSnpQaxLKYJYO7Rl+lw
rrw7GWzbITAYBgNVHSAEETAPMA0GCysGAQQBsC0DBAEBMA4GA1UdDwEB/wQEAwIB
hjANBgkqhkiG9w0BAQsFAAOCAQEAF4q4+NV+tNZTTU2Um3cj93wsrg7YjluqZxSV
q8qTG5yqdPRZQBt5ga90yj/tcmMVu5GtAUMDhA8s3Q9CsTesbcGCPyCvrKL6/CSI
4H444qUEn0dn/spiwumASm4YkmkoGhZNh70uXOPxXJis8W+04CBnWOwc0ahZ5/3I
0vxwM5E4uk7DpKxek5pozCxicUQicRPz3+Wk8nw8yZmUKvMHbagvVqamf0kzr5G/
vrv5zYQwoYlpCJdTJgwn750pqEykeyhcqlRsnkFZnT83MDPJH0YC1vkPhOfNn9DR
CpMz7pDIQer61hRZShRY7+D4prEMMcAs7T7spjMoLDTR7DHKDA==
-----END CERTIFICATE-----

And here's your intermediate "CodeSigning CA" cert:
-----BEGIN CERTIFICATE-----
MIIDbDCCAlSgAwIBAgIIM0VSOewW3WIwDQYJKoZIhvcNAQELBQAwPDEeMBwGA1UE
AwwVQXRvcyBUcnVzdGVkUm9vdCAyMDExMQ0wCwYDVQQKDARBdG9zMQswCQYDVQQG
EwJERTAeFw0xMTA3MDcxNTA3MDVaFw0yMTA3MDQxNTA3MDVaMEsxLTArBgNVBAMM
JEF0b3MgVHJ1c3RlZFJvb3QgQ29kZVNpZ25pbmctQ0EgMjAxMTENMAsGA1UECgwE
QXRvczELMAkGA1UEBhMCREUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQC/s+F1Z2xI2oaXq9UFgcq7saTV0TXZw0BF2kElGHa8rLUqQDjUTz/91+4sE04x
HnEJiVvQvn7Ic/MI404LEzvRwOWtjBRHA7l0K2l7xryn5FTS/rg+ok0hBtMtWO9/
3bikmMwD4yYLSt1XEF9mLpv/8ndB4BeGx7axv5SALNMkHec1b08wAS04uG8LXTkW
7WxosnooLKcl6nDj4il1bWljDFW9P9/EQUTXxI+E1Ng7fgKatNrDdC+l5Vml6Dwi
0wmy5yxtJDppxSmQ4o3p4ynCSBZLcFPASfO6woeWG3yEU++ipoGxkYAg+0Ffk67L
Ug8LUtIj/m9XkqbwdH5bm2BnAgMBAAGjYzBhMB0GA1UdDgQWBBQVzpL1L8d97pgt
4RRa2OHvLfo74zAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFKelBrEspglg
7tGX6XCuvDsZbNshMA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOCAQEA
j+e6aV54aFWX0HIrozRU9YTN310EeHnq26+ae9rjce1FuqEqVUOEKU06jKcvnoI5
Nfh/4U6see3Pevq4s3pgJftDDpEoquQBgaa8d+eZawpjhzAsW5kkCwwGyGIqXGY9
Jjs4W5ERq9+C3JOpOTRNm03+C1neN0sUSdNh1Pp8l5exuWgrbnfwVJbAp0YXJCMK
qRu7nneHD6xmrB5t3tPWTgcniLTF2j4zHvAMONn9TSafJAtt2DA/7eDnzh/TEiVO
arVutLDE5Gpi5PQxwxI2LlUF5UQZ4N1rZnfTWDkb8+gr2L0WnIb7mB5YUZG8Lj24
IMENbbs+0BJiodIG/ix7Dg==
-----END CERTIFICATE-----

Both chain to the same root, and none of them is revoked (the CRL issued by your root is empty). Yet none of them contain any CRLDP.

> We already prepared this change (include the CRLDP) for this intermediate CA while checking and answering Mozilla January 10, 2013 Communication.
>
> Until now we do not create SSL-Server certificates from this CA, because we are not on the list of Mozilla Trusted Root CAs yet.

And your reply was based on this future hypothetical situation, whereas the question started with "Scan your certificate database ...", using the present tense.
Were there other elements in your answer to Mozilla that reflect a future hypothetical situation instead of the current one?

> So we did not implement this change directly. We will implement this change within the next few days and we will inform you when the new intermediate CA is installed and running. The old (current) SSL intermediate CA will be revoked.

As will probably be the CodeSigning and Client intermediate CAs once you'll have renewed them.

[kramerm...@gmail.com]

I will try to explain the complete history, to give you a detailed overview.

In 2012 we saw – within all the other tasks coming from CA-Browser-Forum - the requirement to add CRLDPs. We then added these CRLDPs to all intermediate CAs.
We were then asked by Mozilla to check our CA-System for CA-Certificates. We performed this verification and responded that everything was o.k.
There was no certificate with basicConstraints:CA:TRUE and missing cRLDistributionPoint while scanning the database of our CA-System.
Unfortunately we missed to update our LDAP and the Test-Website. That is what you saw.
We have now updated these systems. This reflects my answer to you on 8 April 2013 “We already prepared this change”.
To explicitly answer your questions:
- We performed the requested checks and answered truly.
- The CA-certificates, which you saw, did not “reflect a future hypothetical situation”. But we missed to technically update these systems.

A “future situation” is the OCSP service which we have to adapt to conform the chapter 13.2.6 of the CA/Browser Forum Baseline Requirements.
We already started working on this task, but it has the effective date 1 August 2013.

[Erwann Abalea]

Le vendredi 12 avril 2013 14:50:23 UTC+2, martin...@atos.net a écrit :
> I will try to explain the complete history, to give you a detailed overview.
>
> In 2012 we saw – within all the other tasks coming from CA-Browser-Forum - the requirement to add CRLDPs. We then added these CRLDPs to all intermediate CAs.

Except the SSL one, as you admitted in your april, 8th answer.

> We were then asked by Mozilla to check our CA-System for CA-Certificates. We performed this verification and responded that everything was o.k.
> There was no certificate with basicConstraints:CA:TRUE and missing cRLDistributionPoint while scanning the database of our CA-System.
> Unfortunately we missed to update our LDAP and the Test-Website. That is what you saw.
> We have now updated these systems. This reflects my answer to you on 8 April 2013 “We already prepared this change”.

Weren't those certificates (the ones without CRLDPs) in your database? After all, they weren't revoked, so they were still valid at this time. They are still valid.
In the previously mentioned email, you said the current (at this time) SSL certificate will be revoked when renewed. However, this hasn't been done. In fact, you can't, see below.

> To explicitly answer your questions:
> - We performed the requested checks and answered truly.
> - The CA-certificates, which you saw, did not “reflect a future hypothetical situation”. But we missed to technically update these systems.

You missed other things. The 3 intermediate certificates that were changed to add the CRLDP extension have been produced with the same exact content (except the CRLDP), *including the serial number*.

Let me complete the Mozilla communication you responded to.

Question 3 was:
"While you are scanning your certificate databases to ensure that all certificates with basicConstraints:CA:TRUE have been issued in accordance with your CPS, please also check for compliance with the following practices.

* All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.
* All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.

* All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration).
* [...]"

This requirement isn't a CABForum change, it's not a Mozilla change either. It's in fact an X.509 requirement, since the very first edition of X.509 in 1993.

This non-uniqueness hasn't been reported in your answer to Mozilla, it's not compliant with X.509, and this prevents you from revoking the intermediate certificates without CRLDP.


I think you're NOT ready to run a public CA.

[kramerm...@gmail.com]

We did not implement these changes until now because our understanding is to
1.) have finalized the discussion about findings,
2.) then agree with Mozilla about the next steps and
3.) as last step implement the changes.

@Kathleen: Do you agree?

[kramerm...@gmail.com]

To get a better impression of our work, skills and experience, please let me first summarize some facts about Atos and our Trustcenter:

Atos is the largest IT service provider in Europe and even one of the biggest in the world offering various kinds of services to our customers. The Atos Trustcenter is already acting in Germany since 1996 and since then growing year-by-year and also getting more and more international. For example, we are providing certificates for the electronic health card in Germany (“Elektronische Gesundheitskarte (eGK)”) – the certificates for more than 20% of the citizens.

Moreover, we are almost daily getting requests from our customers asking for (trusted) SSL certificates. In providing the additional service of trusted SSL certificates, we want to satisfy the needs of our customer and their clients as well as address the issue, contribute to and improve the overall security and trustworthiness of the World Wide Web. Today, we are already included as Trusted Root in Microsoft products and want to be included into the other browser and operating system (from vendors like Mozilla, Google or Apple) too. In addition, we have the plan to become a member of the CA/Browser form, but just stuck checking the legal conditions etc.

We agree that it was a fault of our side to have the CAs without CDP published, but we are quite familiar with the X509 specification, the Mozilla policies and the CABForum requirements. The missing CRLDP was added belatedly to the intermediate CA at setup of the infrastructure. The previous versions of these CA-certificates were not intended to be published. This finally led to the duplicate serial number issue for the “similar/same” intermediate CA certificates. Of course, our overall production process and the CA software are already designed and configured to prohibit the creation of two really different end entity certificates with the same serial number.

We already talked to Kathleen and our plan to become compliant with the requirements:
- Create three new intermediate CAs (Client, SSL and CodeSigning).
- For SSL and CodeSigning: revoke the old intermediate CAs.
- For Client: preparing the switch to the new intermediate CA and implement this asap.

The current status is:
- New intermediate CAs have been created.
- OCSP and Test-Website have been adapted.
- Test website: https://pki.atos.net:7081
- The old replaced SSL and CodeSigning intermediate CAs have been revoked.
- We have started to setup a migration plan with our customers for the client certificates.

[Kathleen Wilson]

On 5/8/13 5:45 AM, martin...@atos.net wrote:
> We agree that it was a fault of our side to have the CAs without CDP
> published, but we are quite familiar with the X509 specification, the
> Mozilla policies and the CABForum requirements. The missing CRLDP
> was added belatedly to the intermediate CA at setup of the infrastructure.
> The previous versions of these CA-certificates were not intended to be
> published. This finally led to the duplicate serial number issue for the

> �similar/same� intermediate CA certificates. Of course, our overall

> production process and the CA software are already designed and
> configured to prohibit the creation of two really different end entity
> certificates with the same serial number.

I still do not understand how the intermediate certs were created with
duplicate serial numbers.

I also do not understand why this wasn't caught when you did the DB scan
as requested in the CA Communication
https://wiki.mozilla.org/CA:Communications#January_10.2C_2013
"3) Scan your certificate database...

While you are scanning your certificate databases to ensure that all
certificates with basicConstraints:CA:TRUE have been issued in
accordance with your CPS, please also check for compliance with the

following practices. ...

All certificates that share a common issuer name contain unique serial
numbers (independent of certificate expiration)."

Please explain why the intermediate certs were created with duplicate
serial numbers and why they were not caught during the scan of the cert DB.

What procedures/software have been put in place to make sure that Atos
will not repeat this mistake of issuing intermediate certs with
duplicate serial numbers?


Also, it is not clear to me what this means:

> our overall production process and the CA software are
> already designed and configured to prohibit the creation
> of two really different end entity certificates with the
> same serial number.

Please explain what you mean by "two really different end entity certs".

Under what circumstances can end-entity certs be created with the same
serial number?

What exactly does the production process do to prohibit the creation of
end-entity certs with the same serial number?

Kathleen

[Erwann Abalea]

Le mercredi 8 mai 2013 14:45:47 UTC+2, martin...@atos.net a écrit :
[...]

> We agree that it was a fault of our side to have the CAs without CDP published, but we are quite familiar with the X509 specification, the Mozilla policies and the CABForum requirements. The missing CRLDP was added belatedly to the intermediate CA at setup of the infrastructure. The previous versions of these CA-certificates were not intended to be published. This finally led to the duplicate serial number issue for the “similar/same” intermediate CA certificates. Of course, our overall production process and the CA software are already designed and configured to prohibit the creation of two really different end entity certificates with the same serial number.

Certificates "never intended to be published" and then made available on a validation website and published in a directory... Consider that a certificate is a public object, always.
The uniqueness of serial numbers is not limited to "end-user certificates", it applies to every certificate, even those you produce on offline desktops, during a key ceremony.

> We already talked to Kathleen and our plan to become compliant with the requirements:
> - Create three new intermediate CAs (Client, SSL and CodeSigning).
> - For SSL and CodeSigning: revoke the old intermediate CAs.

Checked.

> - OCSP and Test-Website have been adapted.
> - Test website: https://pki.atos.net:7081

Your OCSP responder doesn't work with GET requests (I get a 'malformedRequest' answer). With a long-term goal of activating hard-fail, that may render all your certificates revoked (or all valid, depending on choices in FF facing errors).
Right now, Firefox doesn't use the GET method, but there was some recent activity on that point, and it could be activated soon (I hope). Nevertheless, GET support is mandatory for CABF BR (since 01/01/2013).
Firefox is said to remove support for CRLs in the future, so it's important that OCSP (both server and client) is reliable.

[kramerm...@gmail.com]

Sorry, for the inaccuracies. I will try to give you a more detailed description of the circumstances that result in the "duplicate serial number" issue:
In 2011 we did the setup of the PKI for our Trusted Root -- test environments and production. At this moment we created the intermediate CAs without CRLDP in all systems. In the beginning of 2012 we detected a problem with the intermediate CAs without CRLDP in some test cases of another project. At this moment the PKI of the productional TrustedRoot environment has not been used to create any end-entitiy certificates. Additionally we were just about to start the production phase of a project to create thousands of smartcards with client certificates. Hence, our solution was to just add the CRLDP manually to the existing intermediate CA certificates and remove the old version of that certificates from our database entirely. Unfortunately we did not check all intermediate CA certificate publishers, so the LDAP contained the old certificate. These intermediate CA certificates were seen by Erwann Abalea in April 2013. That is the reason our database scan did not find any certificates that are not compliant with the given practices.

After that replacement we started the production of certificates with our client CA in 2012. For CodeSigning and SSL we still only created two certificates: for the OSCP service and the SSL test website. We use the “EJBCA” as CA system in background, which prohibit to create certificates with the same serial number. We are aware that the creation of certificates with duplicate serial numbers is prohibited by the X509 standard. However, our process documentation is part of our internal continuously improvement process (PDCA) and we will address this specific issue during this process.

[Erwann Abalea]

Le jeudi 16 mai 2013 18:32:26 UTC+2, martin...@atos.net a écrit :
> Sorry, for the inaccuracies. I will try to give you a more detailed description of the circumstances that result in the "duplicate serial number" issue:
>
> In 2011 we did the setup of the PKI for our Trusted Root -- test environments and production. At this moment we created the intermediate CAs without CRLDP in all systems. In the beginning of 2012 we detected a problem with the intermediate CAs without CRLDP in some test cases of another project. At this moment the PKI of the productional TrustedRoot environment has not been used to create any end-entitiy certificates. Additionally we were just about to start the production phase of a project to create thousands of smartcards with client certificates. Hence, our solution was to just add the CRLDP manually to the existing intermediate CA certificates and remove the old version of that certificates from our database entirely. Unfortunately we did not check all intermediate CA certificate publishers, so the LDAP contained the old certificate. These intermediate CA certificates were seen by Erwann Abalea in April 2013. That is the reason our database scan did not find any certificates that are not compliant with the given practices.

So your plan was to recertify a CA certificate with the same serial number, delete the old version from all your repositories and replace it with the new version. Are you saying this failed because you missed one repository and got caught?

It failed because:
- you recertified your CA certificates with duplicate serial numbers
- you deleted objects that you're supposed to keep preciously at least for their entire lifetime, in order to be able to indicate their revocation status

Deleting certificates from your databases so you can't track and revoke them is one of the goals of someone compromising your infrastructure. One of your goals as a CA is the exact opposite.

[kramerm...@gmail.com]

Sorry Erwann, but the issue we are talking about has absolutely nothing to do with “compromising your infrastructure”: This never happened.

We know we made a mistake and tried to explain that incident in detail.

[Erwann Abalea]

Le vendredi 24 mai 2013 09:36:27 UTC+2, martin...@atos.net a écrit :
> Sorry Erwann, but the issue we are talking about has absolutely nothing to do with “compromising your infrastructure”: This never happened.
>
> We know we made a mistake and tried to explain that incident in detail.

Martin,

I'm not saying you were compromised.

I'm saying that as a CA, one of your responsibilities is to keep all the certificates you have produced, so that you can certify for their validity. If you delete certificates, you obviously can't produce a valid revocation status, which means you can't declare the missing certificates as revoked, especially bad ones.

[kramerm...@gmail.com]

Erwann,
we always were (and we still are) able to revoke all certificates.
The CA-certificates we talk about (Server & Codesign) are already revoked, the successor CA’s are in place.
The successor of the Client-CA is created and published. We started working to migrate the users to the new Client-CA. After having finished that we will revoke the previous Client-CA, too. We choosed this approach to reduce the inconvenience for the users, because the issue is not seen as a critical emergency with immediate action required.

In summary: The incident is identified, we discussed it here and with Kathleen, we explained the happening in detail, we revoked the certificates and replaced them by new ones and finally we are updating our documentation and work instructions where changes are necessary.

[Kathleen Wilson]

On 3/14/13 3:54 PM, Kathleen Wilson wrote:

> Atos applied to include the “Atos TrustedRoot 2011” root certificate and
> enable all three trust bits.
>
> Atos Trustcenter acts in Europe, but also has international customers.
> The PKI-Services are offered to the Public, with no restrictions to user
> groups.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=711366
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Atos
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=725143
>
> Noteworthy points:
>
> * The primary document is the CPS which is provided in English.
>
> Document Repository: https://pki.atos.net/TrustedRoot/
>
> CPS (English):
> https://pki.atos.net/EJPKI-WebFrontend/Public/TrustedRoot/Download?File=AtosTrustedCA_CPS_v1.5.pdf
>

Thanks to those of you who have reviewed and commented on this request.

The main issues that have been discussed are:
- No CRLDP and AIA:OCSP extension in the SSL intermediate cert.
- Intermediate certs were issued with duplicate serial numbers.
- Unclear responses regarding the CA Communication.

I propose to close this discussion and request that Atos provide a
Baseline Requirements Audit Statement according to Baseline Requirement #17.

My question to all: After I confirm the BR Audit Statement, should I
open a second round of discussion about this request? Or would the BR
Audit Statement (after I review/confirm it) be sufficient to move
forward with approval/inclusion?

Thanks,
Kathleen

[David E. Ross]

On 6/4/13 10:23 AM, Kathleen Wilson wrote:
>
>
> Thanks to those of you who have reviewed and commented on this request.
>
> The main issues that have been discussed are:
> - No CRLDP and AIA:OCSP extension in the SSL intermediate cert.
> - Intermediate certs were issued with duplicate serial numbers.
> - Unclear responses regarding the CA Communication.
>
> I propose to close this discussion and request that Atos provide a
> Baseline Requirements Audit Statement according to Baseline Requirement #17.
>
> My question to all: After I confirm the BR Audit Statement, should I
> open a second round of discussion about this request? Or would the BR
> Audit Statement (after I review/confirm it) be sufficient to move
> forward with approval/inclusion?
>
> Thanks,
> Kathleen

I think your question can be answered only after the audit statement is
reviewed. What it says will be important. Where it remains silent will
be equally important.

--
David E. Ross
<http://www.rossde.com/>

Are taxes too high in the U.S.? Check the bar graph
at <http://www.rossde.com/taxes/trickling.html> to see.

[Kathleen Wilson]

On 6/4/13 10:23 AM, Kathleen Wilson wrote:

I am closing this discussion with the following action item.

ACTION Atos: Complete a Baseline Requirements Audit according to BR #17.

I will track this action item in the bug, and after I confirm completion
of the action item I will start the second round of discussion.

https://bugzilla.mozilla.org/show_bug.cgi?id=711366

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen