64.41 KB, image/jpeg
31.70 KB, application/pdf
44.89 KB, application/pdf
15.74 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
86.88 KB, application/pdf
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:18.104.22.168) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Build Identifier: CA Details CA Company/Organization Name: Scientific Trust operated by FernUniversitaet in Hagen Website: http://www.scientific-trust.de (German), http://www.scientific-trust.de/index_en.php (English) One Paragraph Summary of CA Company/Organization, including the following: Scientific Trust is a division of the University of Hagen and has its own Root Certificate. Scientific Trust has passed a Webtrust audit and offers Intermediate Certificates to other universities and companies. The University of Hagen (FernUniversität in Hagen) is the only state-maintained distance teaching university in German-speaking countries. Our 67000 Students benefit from our modern distance education system. At this time Scientific Trust has one internally-operated subordinate CA, but eight commitments of other companies that they want to become a subordinate CA. The primary market is the German speaking area (Austria, Germany, Switzerland). Audit Type (WebTrust, ETSI etc.): WebTrust Auditor: KPMG Auditor Website: www.kpmg.de Audit Document URL(s): https://cert.webtrust.org/ViewSeal?id=974 Certificate Details Certificate Name: Scientific Trust operated by FernUniversitaet in Hagen – G1 This Root has one internally-operated subordinate CA issuing client and server certificates. In future there will be more subordinate CAs, issuing client and server certificates. Certificate HTTP download URL (on CA website): http://www.scientific-trust.de/scientific-trust.crt Version: v3 SHA1 Fingerprint: 8A:A3:F5:A6:44:D1:B4:23:97:CF:82:67:5D:1F:D8:35:D0:BA:31:46 Public key length (for RSA, modulus length) in bits: 4096 Valid From (YYYY-MM-DD): 2009-08-24 Valid To (YYYY-MM-DD): 2037-12-25 CRL HTTP URL: http://cdp1.scientific-trust.de/g1/crl/root.crl CRL issuing frequency for end-entity certificates: CRLs must be published as soon as they are issued and always when needed (e.g. in case of revoking a certificate). OCSP URL: none Class (domain-validated, identity/organisationally-validated or EV): identity/organisationally Certificate Policy URL: http://www.scientific-trust.de/download/cp_V1.2.pdf CPS Scientific Trust URL: http://www.scientific-trust.de/download/cps_st_V1.0.pdf CPS FernUniversitaet in Hagen URL: http://www.scientific-trust.de/download/cps_feu_V1.0.pdf List one or more Trust Bits to enable, choices are Websites (SSL/TLS), Email (S/MIME), and/or Code (code/document signing): Websites, Email, Code URL of website whose SSL certificate chains to this root (if applying for SSL): https://www.scientific-trust.de Reproducible: Always
Starting the Information Gathering and Verification phase as per: https://wiki.mozilla.org/CA:How_to_apply
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: Information incomplete
Created attachment 415922 [details] Initial Information Gathering Document The attached document summarizes the information that has been gathered and verified. The items highlighted in yellow indicate where further information or clarification is needed. Please review the full document for accuracy and completeness.
Summary: Scientific Trust operated by FernUniversitaet in Hagen -G1 → Scientific Trust operated by FernUniversitaet in Hagen - G1
Thank you for the information. I have a couple follow-up questions… > Future externally-operated Sub-CAs Based on CP section 1.3.1, it looks like any business may operate a sub-CA, and those sub-CAs may issue their own sub-CAs, up to a path length of 5. There does not seem to be any restriction on the types of businesses that may operate sub-CAs, or who they can issue sub-CAs to. If Mozilla accepts and includes the “Scientific Trust operated by FernUniversitaet in Hagen – G1” root, then we have to assume that we also accept any of your future sub-CAs and their sub-CAs. Therefore, the selection criteria for your sub-CAs and their sub-CAs will be a critical decision factor. Please point me to the parts of the CP that clearly explain who can apply to operate a sub-CA (at any level), the selection/approval process for sub-CAs and their sub-CAs, the verification procedures applied to sub-CAs and their sub-CAs, what restrictions (legal and technical) are placed on all sub-CAs (eg constraints to issuing certs within certain domains). > A Server cert can have a maximum lifetime of 2 years (for all sub-CAs). Where is this documented?
Hello, > A Server cert can have a maximum lifetime of 2 years (for all sub-CAs). > Where is this documented? See FernUniversitaet in Hagen CPS document Section 5.3. We want to add this information to the CP as well. Would this be enough? > Future externally-operated Sub-CAs We will update our CP Section 1.3.1 to specify the information: Scientific Trust issues Certificates to the CAs Staff or Business or Universities operating as Intermediate CAs. These Intermediate CAs may use as many Intermediate CAs below them as they required or either issue Certificates to End Entities. But an Intermediate CA can only issue an Intermediate CA certificate for internal use only (e.g. an intermediate CA for their active directory). It is not permitted that an Intermediate CA of Scientific Trust issues an Intermediate CA certificate outside the Intermediate domain. However, the path length must not exceed the number of five. Scientific Trust may also operate an Intermediate CA, which issues Certificates for the general public. Intermediate CAs must sign an agreement with the issuing CA, stating the obligation to adhere to the agreed procedures. > Selection / approval / verification process of Intermediate CAs If Scientific Trust wants to issue an Intermediate CA certificate see Section 3.1.1 of Scientific Trust CPS document. If an Intermediate CA wants to issue an Intermediate CA certificate, we want to add the following to the Scientific Trust CPS document: For intermediate certificates authentication level is personal. Actor's actions are as defined below: Actor Number Action Applicant 1. Wants to have an intermediate certificate Intermediate CA 2. Requests more informationen over the applicant and wants a CPS document. Applicant 3. Submits his CPS document to the CA Intermediate CA 4. Checks the CPS document. Scientific Trust 5. CA performs an audit at the applicant. Intermediate CA 6. Issues the requested certificate. Intermediate CA 7. Hands out certificate to applicant. Applicant 8. Ensures certificate usage in conformity with CP and this CPS. Ist this okay? Thanks and kind regards! Ralph
>> A Server cert can have a maximum lifetime of 2 years (for all sub-CAs). >> Where is this documented? > See FernUniversitaet in Hagen CPS document Section 5.3. We want to add > this information to the CP as well. Would this be enough? Yes. >> Future externally-operated Sub-CAs > We will update our CP Section 1.3.1 to specify the information: > ... Yes. It is very helpful to know that the intermediate CAs can only issue intermediate CAs for internal use, and not to other organizations. It would also be useful to know if there are any restrictions about who the intermediate CAs can issue end-entity certs to. e.g can anyone from the general public apply for an end-entity cert chaining up to their intermediate CA? Or will they be limited (like FernUniversitaet in Hagen) to issuing end-entity certs to students, employees, and guests doing work specifically related to their company/university? In CP section 1.3.2: Intermediate CAs and their RAs are audited by Scientific Trust staff. If they can only issue certs for internal use, then this should be OK. If they can issue certs to the general public, then this won't be sufficient. They will need to be audited anually according to sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/ >> Selection / approval / verification process of Intermediate CAs > If Scientific Trust wants to issue an Intermediate CA certificate see > Section 3.1.1 of Scientific Trust CPS document. > If an Intermediate CA wants to issue an Intermediate CA certificate, we > want to add the following to the Scientific Trust CPS document: If this section is for the practice of issuing intermediate CAs internally, then please re-state that in the added section/text. Please add a comment in this bug when the CP/CPS have been updated.
Re comment #5 and comment #6: The CP should also indicate how external CAs are monitored to ensure they comply with the restrictions in the revised Section 1.3.1. Will Scientific Trust periodically examine the operations of the external CAs? Or will Scientific Trust require the external CAs to undergo independent audits? And how often?
Hello and a happy new year! ;-) We have updated our CP und CPS document. I also updated the links to our documents: http://www.scientific-trust.de/download/cp.pdf (Updated section: 1.3.1, 2.7.2, 6.3.2) http://www.scientific-trust.de/download/cps_st.pdf (New section 3.2.3) > It would also be useful to know if there are any restrictions about who the > intermediate CAs can issue end-entity certs to. e.g can anyone from the > general public apply for an end-entity cert chaining up to their intermediate > CA? Or will they be limited (like FernUniversitaet in Hagen) to issuing > end-entity certs to students, employees, and guests doing work specifically > related to their company/university? Is section 1.3.3 enough or should we provide more information in the CP? Greetings Ralph
This request has been added to the queue for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Whiteboard: Information incomplete → Information confirmed complete
This request is near the top of the queue for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion As such, I am re-reviewing the information to ensure it is current. 1) My notes say: "This root has one internally-operated subordinate CA issuing client and server certificates. This root will also have externally-operated subordinate CAs, issuing client and server certificates." Is this still accurate? 2) The audit report that I have noted is from June, 2009: https://cert.webtrust.org/ViewSeal?id=974 Do you have an audit statement for this year?
Hi, 1) This is right! 2) At the moment we are performing a recertification. I am confident that we will have it soon.
Thanks, I expect to start the discussion in the mozilla.dev.security.policy forum next week.
I am now opening the first public discussion period for this request from Scientific Trust to add the “Scientific Trust operated by FernUniversitaet in Hagen – G1” root certificate and enable all three trust bits. For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding email@example.com mailing list. http://www.mozilla.org/community/developer-forums.html https://lists.mozilla.org/listinfo/dev-security-policy news://news.mozilla.org/mozilla.dev.security.policy The discussion thread is called “Scientific Trust Root Inclusion Request” Please actively review, respond, and contribute to the discussion. A representative of Scientific Trust must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion
The first round of discussion for this request has been closed. The result of the discussion is the following action item, which will be tracked in this bug. After I have confirmed completion of the action item, I will open a second round of discussion for this request. -- ACTION Scientific Trust: Update the CP to clearly state the minimum requirements of the root and all subordinate CAs. The requirements must satisfy the Mozilla CA Certificate Policy Version 2.0. Specific examples were provided in this discussion, including: a) Subscriber Verification Requirements. Describe the minimum steps that must be taken by the CA and all sub-CAs to verify subscriber information. https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscriber and Items #3, #4, and #5 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices b) Binding Requirements. The sub-CA obligations as documented in the CP must be binding requirements, and contain sufficient description of the minimum actions to be taken and the minimum standards to be used. c) Minimum key length for end-entity certs: RSA 2048 bits or higher; and RSA 1024 bits (only until December 31, 2013). d) Audit Requirements. More specifically and clearly state the requirements that Scientific Trust places on their sub-CAs in regards documentation and auditing of policies and practices. It must be taken into account that the CP allows for externally-operated sub-CAs in the future. e) Deficiencies. Include information about actions that will be taken when deficiencies are found. --
Whiteboard: In public discussion → Public Discussion Action Items
Closing because no response from CA since 2011.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.