Scientific Trust operated by FernUniversitaet in Hagen - G1

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
9 years ago
a year ago

People

(Reporter: ralph.knoche, Assigned: kwilson)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Public Discussion Action Items)

Attachments

(5 attachments)

(Reporter)

Description

9 years ago
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
(Reporter)

Comment 1

9 years ago
Created attachment 414700 [details]
CA hierarchy diagram
(Assignee)

Comment 2

9 years ago
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
(Assignee)

Comment 3

9 years ago
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.
(Reporter)

Comment 4

9 years ago
Created attachment 417094 [details]
Answer Initial Information Gathering Document
(Reporter)

Updated

9 years ago
Summary: Scientific Trust operated by FernUniversitaet in Hagen -G1 → Scientific Trust operated by FernUniversitaet in Hagen - G1
(Assignee)

Comment 5

9 years ago
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?
(Reporter)

Comment 6

9 years ago
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
(Reporter)

Comment 7

9 years ago
Created attachment 417911 [details]
Answer questions 14-12-2009
(Assignee)

Comment 8

9 years ago
>> 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

9 years ago
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?
(Reporter)

Comment 10

9 years ago
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

9 years ago
The changes to the CP cited in comment #10 sufficiently address my concerns stated in comment #9.
(Assignee)

Comment 12

9 years ago
Created attachment 421116 [details]
Completed Information Gathering Document
(Assignee)

Comment 13

9 years ago
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
(Assignee)

Comment 14

8 years ago
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?
(Reporter)

Comment 15

8 years ago
Hi,

1) This is right! 

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

Comment 16

8 years ago
Thanks, I expect to start the discussion in the mozilla.dev.security.policy forum next week.
(Assignee)

Comment 17

8 years ago
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 dev-security-policy@lists.mozilla.org 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
(Assignee)

Comment 18

8 years ago
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
(Assignee)

Comment 19

5 years ago
Closing because no response from CA since 2011.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX

Updated

a year ago
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.