Closed Bug 370627 Opened 17 years ago Closed 15 years ago

Add S-TRUST root certificates

Categories

(CA Program :: CA Certificate Root Program, task, P2)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ulrich.launer, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: Approved)

Attachments

(5 files, 2 obsolete files)

Initial Info-Gathering Doc
135.00 KB, application/octet-stream
Details
Completed Information Gathering Document
130.50 KB, application/msword
Details
Information gathering document converted to PDF
130.35 KB, application/pdf
Details
Base64 of Example cert issued from S-TRUST Authentication and Encryption Root CA 2005:PN
2.98 KB, application/x-zip-compressed
Details
Base64 of Example cert issued from S-TRUST Qualified Root CA 2008-001:PN
4.66 KB, application/x-zip-compressed
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: all Mozilla software using CA certificates (Firefox, Thunderbird)

Dear Sir or Madam,

herewith we apply for the admission to the Mozilla CA Certificate Policy Program.

Your contacts at Deutscher Sparkassenverlag are:
1)	Ulrich Launer, email: ulrich.launer@dsv-gruppe.de, phone number: +49 711 782 1831
2)	Jochen Knaab, email: jochen.knaab@dsv-gruppe.de, phone number: +49 711 782 1377

Company name and address: Deutscher Sparkassen Verlag GmbH, Am Wallgraben 115, 70565 Stuttgart, Germany.
 
Company web page address: www.s-trust.de S-TRUST is a trademark of Deutscher Sparkassen Verlag GmbH.

Number of roots Deutscher Sparkassenverlag (DSV) wants to submit: 
Initially 2 in 2007, following up to 8 roots in the next 5 years. Due to German legal requirements we have to issue one new so called “Qualified Root” every year (root renewal), in order to enable our customers to be consistent with these legal requirements. These “Qualified Roots” have a re-stricted validity time of 5 years and can be removed from the Mozilla-related software products certificate storage right after expiration to reduce the number of S-TRUST roots to a minimum. (German Signature Law: Germany was the first European country to transpose the European Community Signature Directive into national law. This law enables digital signatures created in conjunction with a qualified certificate to be the legal equivalent to hand written signatures. Due to the strict security demands of this law there are only a few PKI Providers which are approved by German authorities to issue qualified certificates. DSV is the first and only officially declared PKI Provider to issue qualified certificates on
Bank Cards). 

Business purpose of certificates issued from these S-TRUST roots:
The business purpose of the root certificates is to provide all customers of the German Savings Bank Financial Group  with client-certificates for his/her signature enabled debit card (smartcard). 

These signature cards are used to 
·	secure email communication using Mozilla Thunderbird
·	enable secure web-access with Mozilla Firefox e.g. for Online Banking/Brokerage (instead of pass-word and login)
·	sign legally binding transactions e. g. qualified signing of a contract
·	access more than 170 e-government applications like electronic tax-declaration

To whom will the certificates be issued?
Certificates will be issued to all Online Banking customers (private and business) of the German Savings Banks. Until the end of 2008 there will be about 45 Million signature enabled debit cards in the German market to be potentially equipped with S-TRUST certificates.
 
What extended Key Usages does the root require?
For both of the following roots the only key usages set are: “Key Certificate Signature” and “CRL Signature”.
1.	CN=S-TRUST Qualified Root CA 2007-001:PN
2.	CN= S-TRUST Authentication and Encryption Root CA 2005:PN
Key usages of the client-certificates issued under these roots: 
·	Client certificates issued under the first root have no extended key usages at all. 
·	Client certificates issued under the second root will have the following  extended key usages: client authentication, email protection, IP-Sec-User, smartcard-logon.
Our certificate profile is based on the ISIS-MTT specification which can be downloaded at http://www.isis-mtt.t7-isis.org/index.php?id=440&L=1.

What is done to validate the identity of someone requesting a certificate issued from this root?
The validation of an identity is based on the personal (physical) presence of the certificate applicant in front of an agent of our CA or RA who is following the requirements of the German signature law. The agent shall check the identity of the certificate applicant against a well-recognized form of government-issued photo-graphic identification, such as a passport.

Pointers to Certificate Practice Statement: https://www.s-trust.de/stn-cps 

Third party audit our CA practice has undergone: ETSI TS101 456

With kind regards, Deutscher Sparkassenverlag




Reproducible: Always

Steps to Reproduce:
1.
2.
3.


Expected Results:  
As the biggest smart card provider in germany, we provide more than 40 million cards which can be equipped with qualified certificates. 
It would be nice if the Mozilla team can implement our certificates to avoid a error message while using Mozilla combined our certificates.

Link for downloading our root certificates:
http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_stammzertifikate/index.htm
Why was this filed as security-confidential?
There is no need for it to be; removing flag.

Gerv
Group: security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Request of S-TRUST root certificates to be added to Mozilla-related software products default set of CA certificates → Add S-TRUST root certificates
Ulrich: Could you please give more details about the German Savings Bank Financial Group? Is it a single bank, or a consortium of banks? What is its connection with the German government? Is any German citizen able to get one of these cards?

Thanks,

Gerv
Priority: -- → P2
(In reply to comment #3)
> Ulrich: Could you please give more details about the German Savings Bank
> Financial Group? Is it a single bank, or a consortium of banks? What is its
> connection with the German government? Is any German citizen able to get one of
> these cards?
> 
> Thanks,
> 
> Gerv
> 

Gerv: The German Financial Group consists of 463 Savings banks with about 17.000 branches, 11 State banks, 11 State home loan banks, 12 Groups of primary insurers, 2 Factoring companies, 6 Leasing companies, 80 Venture capital companies and others. All German citizen are able to get one of these signature cards.
Ulrich:

Exactly which certificates are you requesting inclusion for? You mention 2 above, but there are five on the download page you link to.

Please can you fill out the form below for all certificates you'd like included?

Please give data in the following format, as a *plain text comment*. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates.

CA Details
----------

CA Name:
Website:
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, academic/research, nonprofit)
 - Primary geographical area(s) served
 - Number and type of subordinate CAs
Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):
  
Certificate Details
-------------------
(To be completed once for each certificate)
  
Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy, i.e. what you plan to do with the 
   root
Certificate HTTP URL (on CA website):
Version:
SHA1 Fingerprint:
MD5 Fingerprint:
Modulus Length (a.k.a. "key length"):
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):
CRL HTTP URL:
OCSP URL:
Class (domain-validated, identity-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code):

Thanks for your help in this matter. :-)

Gerv
I have received the following data from Mr Launer:

An overview about our CA-Hierarchy can be 

found in the document
http://www.s-trust.de/stn-cps/stn_cps.pdf on page 9.

CA Number 1 of 3:

Download-URL: 
http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_stammzertifikate/ordner_crt_dateien/authentication.crt


CA Details
----------
CA Name: Deutscher Sparkassen Verlag GmbH
Website: www.s-trust.de
Pupose of the CA: The purpose of this CA is, to enable up to 40 million 
german customers (end-users) to use their banking card as a certificate 
based signature, encryption as well as authentication device. There are no 

subordinate CAs for this CA available.
Audit Type (WebTrust, ETSI etc.): ETSI TS 101 456
Auditor: TÜV-IT
Auditor Website: http://www.tuvit.de/
Audit Document URL(s): 
http://www.tuvit.de/XS/c.020400&zerttyp=18/r.020400/sprache.EN/SX/

Certificate Details
-------------------
Certificate Name: S-TRUST Authentication and Encryption Root CA 2005:PN
Certification Practice Statement (Policy) can be found at 
www.s-trust.de/stn-cps.
Certificate HTTP URL (on CA website): www.s-trust.de
Version: X509V3
SHA1 Fingerprint: BEB5 A995 746B 9EDF 738B 56E6 DF43 7A77 BE10 6B81
MD5 Fingerprint: N/A
Modulus Length (a.k.a. "key length"): 2048 Bits RSA
Valid From (YYYY-MM-DD): 22. Juni 2005 01:00:00
Valid To (YYYY-MM-DD): 22. Juni 2030 00:59:59
CRL HTTP URL: N/A (Only available in End-user certificates)
OCSP URL: N/A (Only available in End-user certificates)
Identity-validated Class, personal (face to face) validation is conducted.
Certificate Policy URL: www.s-trust.de/stn-cps
CPS URL: www.s-trust.de/stn-cps
Requested Trust Indicators (email and/or SSL and/or code): E-Mail Security 

and SSL2 Web-Authentication
__________________________________________________________

CA Number 2 of 3:

Download-URL: 
http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_stammzertifikate/ordner_crt_dateien/STRUSTQualifiedRootCA2007-001.cer


CA Details
----------
CA Name: Deutscher Sparkassen Verlag GmbH
Website: www.s-trust.de
Pupose of the CA: The purpose of this CA is, to enable up to 40 million 
german customers (end-users) to use their banking card as a certificate 
based signature device. There are up to 10 subordinate CAs which 
eventually issue end-user certificates which are stored on the banking 
signature cards.
Audit Type (WebTrust, ETSI etc.): ETSI TS 101 456
Auditor: TÜV-IT
Auditor Website: http://www.tuvit.de/
Audit Document URL(s): 
http://www.tuvit.de/XS/c.020400&zerttyp=18/r.020400/sprache.EN/SX/

Certificate Details
-------------------
Certificate Name: S-TRUST Qualified Root CA 2007-001:PN
Certification Practice Statement (Policy) can be found at 
www.s-trust.de/stn-cps.
Certificate HTTP URL (on CA website): www.s-trust.de
Version: X509V3
SHA1 Fingerprint: 7A3C 1B60 2EBD A4A1 E0EB AD7A BA4F D143 69A9 39FC
MD5 Fingerprint: N/A
Modulus Length (a.k.a. "key length"): 2048-Bits RSA 
Valid From (YYYY-MM-DD): 1. Januar 2007 01:00:00
Valid To (YYYY-MM-DD): 31. Dezember 2011 00:59:59
CRL HTTP URL: N/A (Only available subordinate CA = issuing CA and in 
End-user certificates)
OCSP URL: N/A (Only available subordinate CA = issuing CA and in End-user 
certificates)
Identity-validated Class, personal (face to face) validation is conducted.
Certificate Policy URL: www.s-trust.de/stn-cps
CPS URL: www.s-trust.de/stn-cps
Requested Trust Indicators (email and/or SSL and/or code): E-Mail Security 

and SSL2 Web-Authentication

____________________________


CA Number 3 of 3:

Download-URL: 
http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_stammzertifikate/ordner_crt_dateien/S-TRUST_Qualified_Root_CA_2006-001_PN.crt


CA Details
----------
CA Name: Deutscher Sparkassen Verlag GmbH
Website: www.s-trust.de
Pupose of the CA: The purpose of this CA is, to enable up to 40 million 
german customers (end-users) to use their banking card as a certificate 
based signature device. There are up to 10 subordinate CAs which 
eventually issue end-user certificates which are stored on the banking 
signature cards.
Audit Type (WebTrust, ETSI etc.): ETSI TS 101 456
Auditor: TÜV-IT
Auditor Website: http://www.tuvit.de/
Audit Document URL(s): 
http://www.tuvit.de/XS/c.020400&zerttyp=18/r.020400/sprache.EN/SX/

Certificate Details
-------------------
Certificate Name: S-TRUST Qualified Root CA 2006-001:PN
Certification Practice Statement (Policy) can be found at 
www.s-trust.de/stn-cps.
Certificate HTTP URL (on CA website): www.s-trust.de
Version: X509V3
SHA1 Fingerprint:  7DDC 761C FDAF 4CE0 3AB5 3ADD C9FA 1335 19A3 DEC9
MD5 Fingerprint: N/A
Modulus Length (a.k.a. "key length"): 2048-Bits RSA 
Valid From (YYYY-MM-DD): 1. Januar 2006 01:00:00
Valid To (YYYY-MM-DD): 31. Dezember 2010 00:59:59
CRL HTTP URL: N/A (Only available in subordinate CA = issuing CA and in 
End-user certificates)
OCSP URL: N/A (Only available in subordinate CA = issuing CA and in 
End-user certificates)
Identity-validated Class, personal (face to face) validation is conducted.
Certificate Policy URL: www.s-trust.de/stn-cps
CPS URL: www.s-trust.de/stn-cps
Requested Trust Indicators (email and/or SSL and/or code): E-Mail Security 

and SSL2 Web-Authentication
> CRL HTTP URL: N/A (Only available in subordinate CA = issuing CA and in 
> End-user certificates)
> OCSP URL: N/A (Only available in subordinate CA = issuing CA and in 
> End-user certificates)

Yes, I understand that - but what values are you going to use?

>http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_stammzertifikate/ordner_crt_dateien/STRUSTQualifiedRootCA2007-001.cer

This file is served with the incorrect MIME type, and so cannot be easily installed in Firefox. Please could you reconfigure your server to send it as application/x-x509-ca-cert instead of text/plain?

Gerv


Values used in Sub-CAs:
CDP 1: URL=http://onsitecrl.s-trust.de/DeutscherSparkassenVerlagGmbHSTRUSTQualifiedRootCA2007001PN/LatestCRL.crl
CCP 2: URL=ldap://directory.s-trust.de/CN=S-TRUST%20Qualified%20Root%20CA%202007-001%3APN,O=Deutscher%20Sparkassen%20Verlag%20GmbH,L=Stuttgart,ST=Baden-Wuerttemberg%20(BW),C=DE?certificateRevocationList;binary

Values used in EE-Certificates:
http://ocsp-q.s-trust.de
and
http://ocsp.s-trust.de
and
URL: http://onsitecrl.s-trust.de/DeutscherSparkassenVerlagGmbHDebitCard/LatestCRL.crl
URL=ldap://directory.s-trust.de/CN=S-TRUST%20Authentication%20and%20Encryption%20Root%20CA%202005%3APN,O=Deutscher%20Sparkassen%20Verlag%20GmbH,L=Stuttgart,ST=Baden-Wuerttemberg%20(BW),C=DE?certificateRevocationList;binary

CRLIssuer: 
CN = S-TRUST Authentication and Encryption Root CA 2005:PN
O = Deutscher Sparkassen Verlag GmbH
L = Stuttgart
ST = Baden-Wuerttemberg (BW)
C = DE


The correct MIME type is now set for all S-TRUST CA-Certificates to be found on:
http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_stammzertifikate/index.htm
My Launer: The CRL you have given is for the 2007 root. I managed to guess the URL of the CRL of the 2006 root by changing the "7" to a "6", but I can't guess the URL of the CRL used with the 2005 root. Can you provide it?

I believe this is the last piece of information I need.

Thanks,

Gerv
Here we go - CRL 2005 (=ARL - Authority Revocation List):

http://onsitecrl.s-trust.de/DeutscherSparkassenVerlagGmbHSTRUSTQualifiedRootCA2005001PN/LatestCRL.crl

Thanks,

Ulrich
OK - thank you.

I have gathered together all the information you have provided, and placed it
in the "pending" CA root certificate request list, which is here:
http://www.mozilla.org/projects/security/certs/pending/

Please confirm that the information for your CA is correct, and add a comment
to this bug to that effect. Once you have done that, your application will turn
"green" and be ready for consideration.

If your CA or certificate does not have a summary paragraph, please feel free
to provide one. Note: these paragraphs are not supposed to be marketing
statements :-)

Gerv
Dear Gerv,

here are my corrections for the "pendig CA root certificate request list":

Please replace the two sentences "This CA exists to enable up to 40 million German customers (end-users).... + There are no subordinate CAs for this CA." with the following new one:
"Deutscher Sparkassen Verlag GmbH is the worlds largest smartcard and the central certification service provider for all German savings banks. This CA exists to enable up to 40 million German customers (end-users) to use their banking card as a certificate based signature, encryption and authentication device." 

Comment to S-TRUST Qualified Root CA 2007-001:PN, Revocation CRL, OCSP: The correct OCSP-URL is: http://ocsp-q.s-trust.de 

Comment to S-TRUST Qualified Root CA 2006-001:PN, Revocation CRL, OCSP: The correct OCSP-URL is: http://ocsp-q.s-trust.de 

Uli
Uli,

I have begun this evaluation, and I have some questions.

As you may know, our CA certificate policy has some minimum requirements for validation, in section 7. I need to ascertain that your CPS specifies that you do perform the validation steps required. Normally I read it to see, but it's in German :-) I can get translation help, but I would appreciate some pointers to the correct sections.

- Which section states that you verify an applicant has control of the relevant email address before issuing them an email signing cert?

- Which section states that you verify that an applicant has control of the relevant domain name before you issue them an SSL cert?

- Which section, if any, contains a certificate hierarchy diagram?

Lastly, can you please point me at one example each of websites which use SSL certificates issued by your roots?

Thanks,

Gerv

Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv
Assignee: hecker → gerv
Gerv,

here are my answers:

Relevant sectiond in the CPS are: 2.5.2.1 - 2.5.3.1

The applicant signs a paper-based application for a qualified certificate. The applicant/application form are personally identified/validated by our local registration authority administrators. This application form contains a field with the email address the applicant wants to use. The applicant confirms by his signature that he is the legal owner of the email address. Furthermore we send an e-mail to the applicants e-mail account whitch contains information needed to download the certificate (activate the certificate).

We have no SSL-description / product in the CPS yet. So please leave out the flag "ssl cert" until we have established these processes.

A certificate hierachy diagram can be found in section 2.1.1

Regards Uli
> Furthermore we
> send an e-mail to the applicants e-mail account whitch contains information
> needed to download the certificate (activate the certificate).

Would it be possible for an applicant to guess how to get the certificate (say, if they had been issued one before or were familiar with your procedures) or is there some randomly-generated and verified key in the URL in the email? If there is not, it would be possible for someone to obtain an email certificate for an email address they did not control.

Also, can you please point me at one example each of websites which use SSL
certificates issued by your roots?

Thanks,

Gerv

> Would it be possible for an applicant to guess how to get the certificate (say,
> if they had been issued one before or were familiar with your procedures) or is
> there some randomly-generated and verified key in the URL in the email? If
> there is not, it would be possible for someone to obtain an email certificate
> for an email address they did not control.

There is no randomly-generated data in the email but the E-Mail Adress is only 1 part of the data which is checked before the certificate for the correspondig email address is issued. During registration the following data is combined for later verification: First Name, Last Name, E-Mail Adress, PIN (more:...date of birth, place of birth etc.) a so called reference number. This reference number (part of a pin-letter which is personlly given to the applicant)  is only known to the applicant an the local registration authority administrator. Please find a Demo-Movie of our download prozess under the following link: http://www.s-trust.de/service_support/zertifikatsmanagement/download_qualifizierter_zertifikate/zert_down_v21.exe 
=> There is absolutely no way that anybody else except the applicant himself could obtain the certificate.

> Also, can you please point me at one example each of websites which use SSL
> certificates issued by your roots?

We have not issued any ssl certificates under the root yet. 

Thanks,
Uli

> => There is absolutely no way that anybody else except the applicant himself
> could obtain the certificate.

I'm sure that's true, but it's not my question. My question is: how do you know that the email address the applicant is claiming to own actually belongs to him? This is required by section 7, bullet A of our policy. As far as I can tell, the only way to check this is to send an email to the address with information no-one else could know in it, and see if the applicant knows the information. Do you do this? As far as I can tell from your answers, it seems that you don't.

I can't watch the movie at the link you sent me. There are two reasons for this. Firstly, it's an executable file, and I would not like to run executables downloaded from the Internet. Secondly, it's a ".exe" file, presumably for Windows, and I run Linux. If you make available a plain video in a format I can play on Linux (for example, Ogg Theora) then I'd be happy to look at it.

Gerv

Ulrich: there are questions for you in this bug. Are you able to answer them?

Gerv

Dear Gerv,

sorry, for making you wait so long: I was not in the office for the last couple of weeks. Please give me some time to answer all your questions above :-)

Regards Uli

Ulrich: have you been able to answer my questions? This bug would eventually be closed if there is no response...

Gerv
Gerv: We found a solution today. Additionally to the fact that the applicant confirms by his signature that he is the legal owner of the email address we are going to implement a technical verification process: An individuell "E-Mail-Address verification code" will be part of the E-Mail the applicant receives for downloading his certificate. Without this code a certificate issuence will not be possible.

Regards Uli
Uli: That sounds fine. Please let me know when your CP/CPS and your issuance policies have been updated to include this procedure.

Also, with what frequency do you issue CRLs for end-entity certificates?

When these two issues are sorted out, we should be OK.

Gerv
Gerv,

as soon as we know we will post it in here!

CRLs will be updated every 24 hours.

Thanks,
Uli
Uli: do you have an estimated time for the completion of the updated CPSes?

Gerv
Gerv: We are planning to have the additional technical verification process implemendted as of the quarter 1/2008. The CPS will be updated simultaneously.

Uli
OK. I am resolving this bug INCOMPLETE. Please reopen it when the updated CPs/CPSes are available.

Gerv
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
The links to download your certificates and audit result are currently broken.

I know this request is currently closed, but a more stable link to the certificates would be a good thing.
Dear Gerv,

we will go live with our updated CPS (Ver 1.2) and your issuance policies on Monday the 7th of January 2008.

The new CPS can be downloaded from that date on from the following link:
http://www.s-trust.de/stn-cps/

Our audit-result can already be downloaded via the auditors site: 
http://www.tuvit.de/41097.asp?zerttyp=18&sprache=DE 

Our CA Certificates (including the new 2008 qualified Root) can be downloaded from http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_wurzelzertifikate/index.htm
starting from 01.01.2008.
Please add the new CA "S-TRUST Qualified Root CA 2008-001:PN" to the pending certificate list of s-trust (http://www.mozilla.org/projects/security/certs/pending/#S-TRUST).

Thanks in advance Regards Uli
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Hi Ulrich,

The root program is now managed by Frank Hecker <hecker@mozillafoundation.org>. :-)

Gerv

Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program.

Gerv
Assignee: gerv → hecker
Status: REOPENED → NEW
The auditor-website has changed and was also updated with our latest certifications according to the ETSI TS 101456 / 102042 policies:

http://www.tuvit.de/english/41097.asp?zerttyp=18&sprache=EN

Regards Uli Launer
(In reply to comment #29)
> Our CA Certificates (including the new 2008 qualified Root) can be downloaded
> from
> http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_wurzelzertifikate/index.htm

This URL did not work; I believe that the correct URL is

http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_wurzelzertifikate1/index.htm

(Note the "1" after "download_wurzelzertifikate".)
Status: NEW → ASSIGNED
I have updated the S-TRUST entry in the pending list:

http://www.mozilla.org/projects/security/certs/pending/#S-TRUST

to reflect the current set of root CA certificates requested for inclusion, including corrected URLs for the certificates obtained from the URL in comment #33. The new version of the pending list should show up on the public site within an hour or so.

Please verify that the information in the entry is complete and correct, and then I will mark the entry as complete and proceed to the next step.
Entry is complete and correct.
According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the status of this request is: Information confirmed complete
Whiteboard: Information confirmed complete
Dear  Frank, 

according to the entry from Nelson Bolyard  on 2008-03-03 14:56:55 PDT 
the status of our apply is: Information confirmed complete  
Herewith we like to request politely the next steps, to finish the inclusion.
The next step, as discribed on the Pending Certificate List, “Public feedback requested; Mozilla Foundation to arrange for inclusion” seems to be open.
How can we support you to finish our apply, or how long it will last, until our certificates will be included and the status will change to inclusion?
regards, 

Uli
Severity: enhancement → normal
Severity: normal → enhancement
I'm assigning this bug to Kathleen Wilson, who will be collecting any other needed information relating to this request.
Assignee: hecker → kathleen95014
Status: ASSIGNED → NEW
As per Frank’s comment, I have been asked to review the information in this request thus far to ensure that all required information has been gathered and verified.  Attached is the initial version of the resulting info-gathering document in which I have highlighted the information that I have questions about. I will summarize below the information I would like to request.

1) In regards to: “There are up to 10 subordinate CAs which eventually issue end-user certificates which are stored on the banking signature cards.” 

a) Are these subordinate CAs operated internally by Deutscher Sparkassen Verlag GmbH, or are they operated by a third party, such as the German Savings Banks?

b) If subordinate CAs are operated by third parties, please explain how the CPS and audits ensure the third parties are in compliance. (Since the CPS is not in English, I am unable to search for this info myself.)


2) It looks like there are not any other root CAs that have issued cross-signing certificates for this root CA. Is that correct?

3) Would it be possible to get an example or demo end-entity certificate that chains from one of these roots?

4) Could you please provide the English translation for the section that was updated in the CPS in regards to Comment #26: “We are planning to have the additional technical verification process implemendted as of the quarter 1/2008. The CPS will be updated simultaneously.”

5) I’m supposed to review the CP/CPS for potentially problematic practices, as per http://wiki.mozilla.org/CA:Problematic_Practices. 
Since the CPS is not in English, would you please comment as to whether any of these are relevant.
If relevant, please provide further info:
•     Long-Lived Domain-Validated SSL certs 
•     Wildcard DV SSL certs
•     Issuing end entity certs directly from root rather than using an
offline root and issuing certs through a subordinate CA 
•     Allowing external entities to operate subordinate CAs – in this case need to demonstrate that the external entities are required to follow the CPS and are audited as such.


Note that I cannot open http://www.tuvit.de/english/41097.asp. I have sent email via the TUVIT website to ask them to fix this link.

Thanks,
Kathleen
Dear Kathleen, 
I would like to try to answer, to you your open questions on your  Bugzilla comment #39 from 2008-07-14.
I can insert no files in Bugzilla, hence, I permit myself to contact you by mail.

Question 1:
In regards to: “There are up to 10 subordinate CAs which eventually issue
end-user certificates which are stored on the banking signature cards.” 
a) Are these subordinate CAs operated internally by Deutscher Sparkassen Verlag
GmbH, or are they operated by a third party, such as the German Savings Banks?
Answer:
These subordinate CAs are all operated internally by Deutscher Sparkassen Verlag
GmbH

Question 2:
It looks like there are not any other root CAs that have issued cross-signing certificates for this root CA. Is that correct?
Answer:
That’s correct 

Question 3:
Would it be possible to get an example or demo end-entity certificate that
chains from one of these roots?
Answer:
I attached my qualified, and my Aut/Enc-certificate as example for you (Mail to you on 2008-09-05)



Question 4:
Could you please provide the English translation for the section that was
updated in the CPS in regards to Comment #26: “We are planning to have the
additional technical verification process implemendted as of the quarter
1/2008. The CPS will be updated simultaneously.”
Answer:
I translated  the part of that document here for you 

Methode to the possession proof of the e-mail address given in the certificate application 
Before  the ZDA DSV (Trustcenter Deutscher Sparkassenverlag) issues a certificate for a signature-prepared card with electronic chip, 
the application plate must prove that e-mail account (e-mail address) – which was given with the order – 
under the control from the card-owner stands. This proof occurs by means of a personal code which is sent to the application plate 
on affected e-mail account by the ZDA DSV. The download process – the exhibit of the personal certificates – 
can be carried out only under information of this e-mail-verification code.

Question 5:
I’m supposed to review the CP/CPS for potentially problematic practices, as
per http://wiki.mozilla.org/CA:Problematic_Practices. 
Since the CPS is not in English, would you please comment as to whether any of these are relevant.
Answer:
These subjects are not relevant for us

I hope my answers are helpful to you. 
If you have any further quastions, please feel free to contact me.

Best regards, 

Marcus
As per email exchange with Marcus, attaching example certs that can be used for testing purposes.
The information gathering and verification phase of this request is complete, as summarized in the attached document.

Assigning to Frank, so this can be included in his list of CAs that are ready for the public discussion phase.
Assignee: kathleen95014 → hecker
Status: NEW → ASSIGNED
The one-week public discussion period for this request has now started. See the
mozilla.dev.tech.crypto newsgroup for more information.
Kathleen, for some reason I'm not able to use the attached example certificates. I tried to parse them as pkcs7, pkcs12 and crl2pkcs7 and importing into Firefox. Nothing worked. Suggestions?
As referenced from your CPS under section 2.1.1:

Aus gesetzlichen Gründen ist es erforderlich, jedes Jahr eine neues Wurzelzertifikat und davon signierte Ausstellerzertifikate für die Ausgabe qualifizierte Zertifikate zu erstellen.

Can you please point me to the relevant "Gesetzensregelungen"? German is fine.
Comment on attachment 337729 [details]
Completed Information Gathering Document

An MS Word document?  

I submit that it is not really appropriate for a company/foundation 
committed to open standards to use a closed/proprietary document format
for important documents like this, at least not exclusively.

So, I ask that this document also be converted to html and attached to 
this bug as an html document.  Thanks.
Kathleen, can you publish the summaries as PDF files in the future?
I converted the CA information document to PDF format to provide a standard format. We'll do this in future as well for information documents for other CAs.
In response to Comment #46, I have replaced the example certs with Base64 files. I imported TestCert_AE via the People tab in the Firefox Cert Manager, and TestCert_QES via the Server tab. Please let me know if this still doesn’t work. 

Eddy, did you get a response to your request in #47 for a pointer to the relevant "Gesetzensregelungen"?
(In reply to comment #53)
> Eddy, did you get a response to your request in #47 for a pointer to the
> relevant "Gesetzensregelungen"?

ֹUnfortunaly not. I'd love to understand this problem better.
Dear Eddy, dear Kathleen, sorry I didn’t notice the question under #47
Before I will answer your question, I think it’s necessary to explain some fundamental aspects:
We offer two different certificates on our banking cards to the customer
-	authentication and encryption certificate
-	qualified signature certificates
Only in order to our qualified signature certificates we have to generate new root certificates every year. 
Due to German legal requirements we have to issue one new so called “Qualified Root” every year (root renewal), in order to enable our customers to be consistent with these legal requirements. These “Qualified Roots” have a restricted validity time of 5 years. Our banking cards also have a validity of 5 years, therefore we have to create a new root certificate every year. 
See germnan law “Signaturgesetz (SigG) and Signaturverordnung (SigV)
Hyperlink to both documents: 
http://www.bundesrecht.juris.de/bundesrecht/sigg_2001/gesamt.pdf
http://www.bundesrecht.juris.de/bundesrecht/sigv_2001/gesamt.pdf

Point of relevant law Signaturverordnung (SigV)

<b>§ 14 Inhalt und Gültigkeitsdauer von qualifizierten Zertifikaten</b>
...
(3) Die Gültigkeitsdauer eines qualifizierten Zertifikates darf höchstens fünf Jahre betragen und den Zeitraum der Eignung der eingesetzten algorithmen und zugehörigen Parameter nicht überschreiten. Die Gültigkeit eines qualifizierten Attribut-Zertifikates endet spätestens mit der Gültigkeit des qualifizierten Zertifikates, auf das es Bezug nimmt.
Dear Eddy, dear Kathleen, sorry I didn’t notice the question under #47
Before I will answer your question, I think it’s necessary to explain some fundamental aspects:
We offer two different certificates on our banking cards to the customer

-	authentication and encryption certificate
-	qualified signature certificates

Only in order to our qualified signature certificates we have to generate new root certificates every year. 
Due to German legal requirements we have to issue one new so called “Qualified Root” every year (root renewal), in order to enable our customers to be consistent with these legal requirements. These “Qualified Roots” have a restricted validity time of 5 years. Our banking cards also have a validity of 5 years, therefore we have to create a new root certificate every year. 
See germnan law “Signaturgesetz (SigG) and Signaturverordnung (SigV)
Hyperlink to both documents: 
http://www.bundesrecht.juris.de/bundesrecht/sigg_2001/gesamt.pdf
http://www.bundesrecht.juris.de/bundesrecht/sigv_2001/gesamt.pdf

Point of relevant law is Signaturverordnung (SigV)

§ 14 Inhalt und Gültigkeitsdauer von qualifizierten Zertifikaten
...
(3) Die Gültigkeitsdauer eines qualifizierten Zertifikates darf höchstens fünf Jahre betragen und den Zeitraum der Eignung der eingesetzten algorithmen und zugehörigen Parameter nicht überschreiten. Die Gültigkeit eines qualifizierten Attribut-Zertifikates endet spätestens mit der Gültigkeit des qualifizierten Zertifikates, auf das es Bezug nimmt.
Thank you. I'll study the documents and come back to you.
I perceive the need to generate a new root every year as a big problem.
I don't recall any other German CA ever declaring that it needs to do this.
Most other CAs say they must be audited every year, but not that they must 
generate new roots every year.  

Is S-Trust doing something different than the other German CAs that forces
S-Trust to do this, but does not force other CAs to do this?
Marcus, the section "Begriffsbestimmungen" in sigg_2001 doesn't make it clear what the difference is between a "qualifiziertes Zertifikat" and "qualifiziertes
Attribut-Zertifikat" as mentioned in sigv_2001, section 14. Can you please explain how you understand those terms?

Also, so far I haven't found anything which would prevent you from issuing an intermediate CA certificate with a validity period of five years? Did you pursue such an option or is there an understanding or outright regulation preventing from doing so?

Also, you mentioned in the comment above that the banking cards are also valid for five years, which means that they could be longer valid than the issuing CA certificate, is that correct? Did you pursue a lesser validity time for those end-user certificates, such as one year?
Nelson, your comment #58
Yes S-TRUST is doing something else then other German trust centers. 
We provide not only certificates on so called signature cards, like the other, we also provide certificates on banking cards. And we provide certificates with a validity of 5 years. The other Cas have validities of one, two, tree years but not 5 years. These banking cards have a validity of 5 years and are generated every year for new customers, customers who get lost old card, cards get damaged for example.
Therefore we have to create a new CA every year, because the validity of our certificates depends on validity of the banking cards. 
That’s the reason for creating it every year. But only for the qualified signature certificates!
Our authentication and encryption certificate have a CA from the year 2005 and didn’t change in 2009 too. 

Eddy: The difference between a “qualifiziertes Zertifikat” and a "qualifiziertes
Attribut-Zertifikat"
“qualifiziertes Zertifikat” meens qualified signature certificate
a "qualifiziertes Attribut-Zertifikat" is only an optional, second certificate for attributes, like admission and restriction. Those second certificates belongs to one qualified certificate and cant be used without the qualified certificate as base component!
Some German trust centers offer these separated attributes certificate, we STRUST don’t sell them separated, we offer attributes as a part of our main certificate. 
I hope I could explain it a bit clear and easy

Your second question I think will be answered with my comment to #58

In order to your last question, #58 will help too. 
If a customer sells a qualified signature, he can download his certificate on his banking card, or on a separate signature card without any other function. If he sells a certificate now! In 2009, it will be valid until 2013/12/31. if he wants to download this certificate on an older banking card for example (card valid until 2010) he is able to do this. But he can use his certificate not longer then the validity of his card, even if the certificate could be valid until 2013. 
The download of a certificate, which has a less validity then the card is not possible!
In order to my explanations in these part, it is even possible, that the customer (end-user) downloads his certificate on a card which ends in 2009/12. In this case the validity will be less then one year, even the qualified signature certificate could be valid until 2013/12

I Think the most important fact to all these questions is the difference between other German trust centers and S-TRUST
The other CAs sell there certificates together with signature cards, without any banking functions.
So the only have to create root certificates together with there cards. 
We sell them on signature cards and on banking cards. That’s the difference with all the results of other forces to S-TRUST
Nelson, your comment #58
Yes S-TRUST is doing something else then other German trust centers. 
We provide not only certificates on so called signature cards, like the other, we also provide certificates on banking cards. And we provide certificates with a validity of 5 years. The other Cas have validities of one, two, tree years but not 5 years. These banking cards have a validity of 5 years and are generated every year for new customers, customers who get lost old card, cards get damaged for example.
Therefore we have to create a new CA every year, because the validity of our certificates depends on validity of the banking cards. 
That’s the reason for creating it every year. But only for the qualified signature certificates!
Our authentication and encryption certificate have a CA from the year 2005 and didn’t change in 2009 too. 

Eddy: The difference between a “qualifiziertes Zertifikat” and a "qualifiziertes
Attribut-Zertifikat"
“qualifiziertes Zertifikat” meens qualified signature certificate
a "qualifiziertes Attribut-Zertifikat" is only an optional, second certificate for attributes, like admission and restriction. Those second certificates belongs to one qualified certificate and cant be used without the qualified certificate as base component!
Some German trust centers offer these separated attributes certificate, we STRUST don’t sell them separated, we offer attributes as a part of our main certificate. 
I hope I could explain it a bit clear and easy

Your second question I think will be answered with my comment to comment #58

In order to your last question, #58 will help too. 
If a customer sells a qualified signature, he can download his certificate on his banking card, or on a separate signature card without any other function. If he sells a certificate now! In 2009, it will be valid until 2013/12/31. if he wants to download this certificate on an older banking card for example (card valid until 2010) he is able to do this. But he can use his certificate not longer then the validity of his card, even if the certificate could be valid until 2013. 
The download of a certificate, which has a less validity then the card is not possible!
In order to my explanations in these part, it is even possible, that the customer (end-user) downloads his certificate on a card which ends in 2009/12. In this case the validity will be less then one year, even the qualified signature certificate could be valid until 2013/12

I Think the most important fact to all these questions is the difference between other German trust centers and S-TRUST
The other CAs sell there certificates together with signature cards, without any banking functions.
So the only have to create root certificates together with there cards. 
We sell them on signature cards and on banking cards. That’s the difference with all the results of other forces to S-TRUST
Nelson, your comment #58
Yes S-TRUST is doing something else then other German trust centers. 
We provide not only certificates on so called signature cards, like the other, we also provide certificates on banking cards. And we provide certificates with a validity of 5 years. The other Cas have validities of one, two, tree years but not 5 years. These banking cards have a validity of 5 years and are generated every year for new customers, customers who get lost old card, cards get damaged for example.
Therefore we have to create a new CA every year, because the validity of our certificates depends on validity of the banking cards. 
That’s the reason for creating it every year. But only for the qualified signature certificates!
Our authentication and encryption certificate have a CA from the year 2005 and didn’t change in 2009 too. 

Eddy to your comment #59: The difference between a “qualifiziertes Zertifikat” and a "qualifiziertes
Attribut-Zertifikat"
“qualifiziertes Zertifikat” meens qualified signature certificate
a "qualifiziertes Attribut-Zertifikat" is only an optional, second certificate for attributes, like admission and restriction. Those second certificates belongs to one qualified certificate and cant be used without the qualified certificate as base component!
Some German trust centers offer these separated attributes certificate, we STRUST don’t sell them separated, we offer attributes as a part of our main certificate. 
I hope I could explain it a bit clear and easy

Your second question I think will be answered with my comment to #58

In order to your last question, #58 will help too. 
If a customer sells a qualified signature, he can download his certificate on his banking card, or on a separate signature card without any other function. If he sells a certificate now! In 2009, it will be valid until 2013/12/31. if he wants to download this certificate on an older banking card for example (card valid until 2010) he is able to do this. But he can use his certificate not longer then the validity of his card, even if the certificate could be valid until 2013. 
The download of a certificate, which has a less validity then the card is not possible!
In order to my explanations in these part, it is even possible, that the customer (end-user) downloads his certificate on a card which ends in 2009/12. In this case the validity will be less then one year, even the qualified signature certificate could be valid until 2013/12

I Think the most important fact to all these questions is the difference between other German trust centers and S-TRUST
The other CAs sell there certificates together with signature cards, without any banking functions.
So the only have to create root certificates together with there cards. 
We sell them on signature cards and on banking cards. That’s the difference with all the results of other forces to S-TRUST
sorry i posted my comment 3 times because of typing corrections. 
Can you pls delete my comments #56 # 60 and #61
Thanks!
Thanks Marcus. I'm fluent in the German Language and I've read most important parts of the documents you pointed me to. Can you point me to the section which explicitly requires to limit the validity period of the ROOT certificate to five years? I haven't found it and in my opinion no such requirement exists according to the documents you pointed me to. It only applies to end user certificates as far as I can see.

I suggest to review your procedures and consult with the legislation once more. Needless to say that Mozilla most likely will *not include* and add/remove every year your roots nor do I see the benefit for doing so (which couldn't be achieved with Intermediate CA certificates). Please advice about your intentions.
Dear Eddy: Your right with your correction about the legislation. There is no rule which explicitly requires to limit the validity period of the ROOT certificate to five years. Only for end-user certificates, that’s right. 
But in order to fulfill all the rules and legislation into our processing center, our processing center is not able to create end-user certificates, which have a longer validity then the ROOT. 
In Germany we have to different types of validity rules, so called “Gültigkeitsmodelle”
1.)	Kettenmodell  (chainmodel)
2.)	Schalenmodell (layermodel)
I don’t want to explain the differences here, because its very technical and complicated to explain. But we have to support a “3 Stufige Zertifikats-Hierarchie” 3steps-certificate-hierarchy”, so that we are able, at least 5 years after validity of a certificate, to reconstruct the validity of digital signatures in the past. 
See also comment of the Bundesnetzagentur:
http://www.bundesnetzagentur.de/enid/8976b4911320b98de6b871b591bb1062,d0d2d85f7472636964092d0936333139/FAQ/Antwortss4_wp.html

I’m sorry for creating so much questions, but I really like to support you as well as I can. But why are these details so important to import our certificates to Mozilla? Why got we added in past without these details. We didn’t change our practice since we are in production as trust center?

I understand that it is more work for you / Mozilla to import our certificates every year, but we are not able to change these practice. 
Therefore I hope you will support us too in future and add our certificates every year. Our intension is to be able to advice our customers to work with Mozilla products. If we are not longer supported / included into Mozilla, we can not advice this in future, because the customers do not understand all these messages they get with “ non known certificate… Attentions, … will you really import these unknown….

yours faithfully, Marcus
In comment 65, Marcus Verheij wrote:
> our processing center is not able to create end-user certificates, 
> which have a longer validity then the ROOT. 

Right.  The requirement is that the root's validity period be AT LEAST 
as long as the vallidity period of subordinate certs, yet you propose to 
generate a new root every year for certs whose validity period will be
5 years.  Nothing you have written so far suggests that a single root 
with a 20 year validity period would not satisfy the requirements for 
at least the next 15 years.  

I imagine it is quite unlikely that Mozilla will be willing to add a new 
root cert for you every year.
(In reply to comment #65)
> Dear Eddy: Your right with your correction about the legislation. There is no
> rule which explicitly requires to limit the validity period of the ROOT
> certificate to five years. Only for end-user certificates, that’s right. 

Which is what I suspected. 

Perhaps I may suggest a different scenario, where you'd use intermediate CA certificates for the issuing of the end-user certs, whereas the intermediate CA would have a limited life-time. In this way you could must likely achieve a similar effect as today.

> But in order to fulfill all the rules and legislation into our processing
> center, our processing center is not able to create end-user certificates,
> which have a longer validity then the ROOT. 

Of course end-user certificates shouldn't have a longer validity than the root.

> I don’t want to explain the differences here, because its very technical and
> complicated to explain. But we have to support a “3 Stufige
> Zertifikats-Hierarchie” 3steps-certificate-hierarchy”, so that we are able, at
> least 5 years after validity of a certificate, to reconstruct the validity of
> digital signatures in the past. 
> See also comment of the Bundesnetzagentur:

And this document explicitly encourages to use chaining and discourages the layered model:

Für tatsächliche Unterschriften (d.h. qualifizierte Signaturen) sieht das Signaturgesetz deshalb das sog. Kettenmodell der Gültigkeit vor (siehe § 16 (1) und § 19 (5) SigG), bei dem eine erfolgreiche Verifikation der geleisteten Signatur auch über lange Zeiträume hinweg in die Vergangenheit möglich ist. 

and

Im Fall des „Schalenmodells" müssten im Fall einer solchen Sperrung alle (!) „darunterliegenden" Zertifikate gesperrt und gegen neue (Chipkarten) ausgetauscht werden, d.h. die Mitarbeiter könnten den GAU selbstständig herbeiführen.

Auch im Falle von Umfirmierungen, Zusammenschlüssen, Übernahmen...würde das Schalenmodell jeweils Massensperrungen von Zertifikaten erforderlich machen; ein hinsichtlich der Kundenbeziehung und der Ökonomie kein sehr erstrebenswerter Fall.

> I understand that it is more work for you / Mozilla

It's not only more work, it most likely would mean that roots would have to be retained and dragged around for many years to come.

> If we are not longer supported / included into Mozilla, we
> can not advice this in future, because the customers do not understand all

Two remarks here. Are the roots with validity of five years shipped by default by other software vendors, in particular Microsoft? Which roots are today in Mozilla and what is their life-time validity? Thanks!
Dear Eddy, 
in order to your comment 67 I would like to try to finish the problems. 

We are accredited since 2008/12
We fulfill all Common PKI rules
We are ETSI conform
 I think this shows that we are one of the most secure trust center in germany

In some cases we work / proceed in different ways to other trust centers and I tried to explain our backgrounds for these processes. I’m sorry to answer you, that we are not able to change this procedures ( And because of some political strategies we wont change too)

I took the activities about the integration of our certificates in Mozilla from Ulli Launer, as he left our company. I was sure, that we got integrated in past with our qualified signature certificates, as well with our authentication and encryption certificates. 
I’m sorry but I can’t find any documentations or proofs for it. 

In this  documentations here  in this Bug is shown, that we changed some processes on account of your requirements. See comment # 22 comment # 29 comment # 33 for example

May I ask how we can finish our status from pending to implication. 
Maybe only for the authentication and encryption certificates which are unchanged since 2005, if the implementation of our qualified signature certificate is not possible in order to our policies and the policies of Mozilla?

I hope there is a way to finish it as soon as possible. 

Thanks in advance Regards Marcus

P.S. In the Microsoft browser we are included only with our authentication and encryption certificate.
Hi Marcus,

I have no doubt that S-Trust operates very securely. The problem I'm seeing is the very short life-time of the CA roots might make it impossible to economically support your CA. Also I couldn't find any precedents in this respect. This matter is however to be decided by the relevant developers and responsible persons.

(In reply to comment #68)
> P.S. In the Microsoft browser we are included only with our authentication and
> encryption certificate.

Which certificates are those? To which roots does it apply? Does this include the "rolling" roots with validity of five years only?
Hi Eddy, 
see comment # 29 from Ulli 
Here is our link to the recent cps 
http://www.s-trust.de/stn-cps/stn_cps.pdf
In chapter 2 under 2.1.1 you can see the hierarchy of the authentication and
encryption certificate. 

In Microsoft is included our ResponderS-TRUST Authentication and Encryption Root CA as shown in 2.1.1
This root (S-TRUST Authentication and Encryption Root CA) is also valid until 2030. I'm certain that Mozilla can support this root as well.
I have just called with Jochen Knaab, who referred me to Michael Verheij, which whom I have talked for a while.

1. Root validity
The roots which are issued yearly (which caused objection) are for the so-called "qualified signature" ("Qualifizierte Signatur"). A "Qualified Signature" is defined by German law and able to enter legally binding contracts (purely electronically) and do e-government. The law defines other requirements like formal approval of the user software and hardware, which Mozilla does not fulfill anyways, nor do users usually want to enter into formal agreements when sending and signing normal emails (and have a hard time understanding the difference between cert and signature types), so an inclusion of the "qualified signature" roots in Mozilla doesn't make sense anyways, according to Mr. Verheij. Therefore, the yearly roots are no problem, they are no longer asked to be included into Mozilla.

The root "S-TRUST Authentication and Encryption Root CA" is the so-called "advanced signature" ("Fortgeschrittene Signatur") and intended for use in email etc.. This is requested for inclusion in Mozilla, and the root lasts for many years.

2. Email address verification
The applicant, in addition to filling out a form and performing an in-person verification specifically for the certificate, have to go to a S-TRUST portal with a special Java applet shipped on CD with the smartcard, and continue the registration process there. One part of that process is that S-TRUST sends an email with a random number/key, which the user has to enter on the S-TRUST website again. So, email verification is performed. This was a direct result of our request, see comment 22 and before/after.

3. Number of users
There are, so far, only 5000 users having performed the verification process and having obtained a certificate.

The 40 Million bank cards ship with a private key and are prepared to be used as smartcards, but they keys are inactive until the user goes through this extra verification and registration process (the bank's customer verification process is not used for this, in contrast to what I thought earlier). Furthermore, the bank cards are not a precondition for the certificate: an application can also obtain other smartcard types (GeldKarte and maybe others) without having a bank account at these associated banks "Sparkasse".
Frank wrote on m.p.d.crypto:
I agree on the inclusion of "S-TRUST Authentication and Encryption Root CA 2005:PN", and so I'm going to go ahead and formally approve that.

On the inclusion of the other roots, there is nothing in our policy that  addresses the issue of short-lived roots. However the consensus seems to be that this practice is not actually legally-required, and it does pose a burden on us. I'm therefore OK with not including the other roots for now, and encouraging S-TRUST to move to a scheme where they use a longer-lived root for these certs.

Kathleen, could you post a summary to bug 370627, and then ping me for final approval?

Frank
(In reply to comment #72)
> The 40 Million bank cards ship with a private key and are prepared to be used
> as smartcards, but they keys are inactive until the user goes through this
> extra verification and registration process (the bank's customer verification
> process is not used for this, in contrast to what I thought earlier).

Does this mean that the smart card hasn't a S/MIME capable certificate install on the card and this is added later? Or how else are the keys inactive?
> Does this mean that the smart card hasn't a S/MIME capable certificate install
> on the card and this is added later?

Correct.
The public comment period for this request is now over. 

This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at

  http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add a new root CA certificate for S-TRUST Authentication and Encryption Root CA 2005:PN. The other roots that were included in this request are not under consideration for inclusion at this time. 

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by S-TRUST, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. S-TRUST appears to provide a service relevant to Mozilla users: S-TRUST is a trademark of Deutscher Sparkassen Verlag GmbH which is the central certification service provider for all German savings banks. The business purpose of this root is to provide customers of the German Savings Bank Financial Group (463 Savings banks) with client-certificates for his/her signature enabled debit card (smartcard).

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main document of interest is the Certification Practice Statement for the S-TRUST Network (STN-CPS).

http://www.s-trust.de/stn-cps/stn_cps.pdf

This document is provided in German. The necessary sections were translated into English and the translations were verified.

Section 7 [Validation]. S-TRUST appears to meet the minimum requirements for subscriber verification, as follows:

* Email: S-TRUST takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate. According to section 3.4.2 of the STN-CPS the proof of email ownership occurs by means of a personal code which is sent to the applicant via the email address specified in the certificate. The download process can only be completed using this email verification code.

* SSL: Not applicable. S-TRUST does not issue certificates for SSL use through this hierarchy.

* Code: Not applicable. S-TRUST does not issue certificates for code signing use through this hierarchy.

Section 8-10 [Audit]. S-TRUST has successfully completed independent audits using the ETSI TS 101 456 and 102 042 criteria. The audits were done by the certification body of TÜV Informationstechnik GmbH. The latest audit statement is dated 5/2/2008.

Section 13 [Certificate Hierarchy]. S-TRUST Authentication and Encryption Root CA directly issues end-entity certificates for authentication and encryption. The root also issues the OCSP-Responder and the CRL Authentication and Encryption certificates. There are no subordinate CAs chaining up to this root.

Other: S-TRUST issues CRLs on a 24-hour schedule. OCSP is also provided.

Potentially problematic practices: There is only one relevant potentially problematic practice, which is that the S-TRUST Authentication and Encryption Root CA issues end entity certificates directly from the root.

Based on this assessment I recommend that Mozilla approve this request to add the S-TRUST Authentication and Encryption Root CA 2005:PN Certificate Authority root certificate to NSS.
It would be good to receive a statement from S-Trust that they are not actively seeking to have the rolling "S-TRUST Qualified Root CA" roots included anymore with Mozilla.
According to our call with Ben Buksch and comment #68 and comment #77:
S-TRUST is actually not seeking to have the rolling "S-TRUST Qualified Root CA" roots included anymore at Mozilla.
In order to #73, we hope to get the status “VERIFIED” with our S-TRUST Authentication and Encryption Root CA as soon as possible. 
Thanks, Marcus
(In reply to comment #78)
> According to our call with Ben Buksch and comment #68 and comment #77:
> S-TRUST is actually not seeking to have the rolling "S-TRUST Qualified Root CA"
> roots included anymore at Mozilla.

Thank you, Marcus.

> In order to #73, we hope to get the status “VERIFIED” with our S-TRUST
> Authentication and Encryption Root CA as soon as possible. 

Yes, I expect this to happen very soon. Good Luck!
To Kathleen: Thank you for your work on this request.

To representatives of S-TRUST: Thank you for your cooperation and your
patience.

To all others who have commented on this bug: Thank you for volunteering your
time to assist in reviewing this CA request.

I have reviewed the summary and recommendation in comment #76, and on behalf of
the Mozilla project I approve this request from S-TRUST to add the S-TRUST Authentication and Encryption Root CA 2005:PN Certificate Authority root certificate to NSS, with the trust bit for email enabled.
Whiteboard: Information confirmed complete → Approved
Kathleen, I'm re-assigning this bug to you for the final steps. Could you please do the following:

1. File the necessary bug against NSS.
2. Mark this bug as dependent on the NSS bug.
3. When the NSS bug is complete, change the status of this bug to RESOLVED FIXED.

Thanks in advance!
Assignee: hecker → kathleen95014
Depends on: 478573
I have filed bug 478573 against NSS for the actual changes.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: