531237 - Scientific Trust operated by FernUniversitaet in Hagen - G1

Status: RESOLVED WONTFIX

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

Description

[Ralph Knoche]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.5) 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

Comment 1

[Ralph Knoche]

Attachment: CA hierarchy diagram

Comment 2

[Kathleen Wilson]

Starting the Information Gathering and Verification phase as per:
https://wiki.mozilla.org/CA:How_to_apply

Comment 3

[Kathleen Wilson]

Attachment: 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.

Comment 4

[Ralph Knoche]

Attachment: Answer Initial Information Gathering Document

Comment 5

[Kathleen Wilson]

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?

Comment 6

[Ralph Knoche]

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

Comment 7

[Ralph Knoche]

Attachment: Answer questions 14-12-2009

Comment 8

[Kathleen Wilson]

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

Comment 9

[David E. Ross]

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?

Comment 10

[Ralph Knoche]

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

Comment 11

[David E. Ross]

The changes to the CP cited in comment #10 sufficiently address my concerns stated in comment #9.

Comment 12

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 13

[Kathleen Wilson]

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

Comment 14

[Kathleen Wilson]

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?

Comment 15

[Ralph Knoche]

Hi,

1) This is right! 

2) At the moment we are performing a recertification. I am confident that we will have it soon.

Comment 16

[Kathleen Wilson]

Thanks, I expect to start the discussion in the mozilla.dev.security.policy forum next week.

Comment 17

[Kathleen Wilson]

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 [e-mail] 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.

Comment 18

[Kathleen Wilson]

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

Comment 19

[Kathleen Wilson]

Closing because no response from CA since 2011.