Bugzilla

Reporter

Comment 1

•

18 years ago

(In reply to comment #0)

No more activity on this list? Is Franck Hecker alive and active?

Frank Hecker

Comment 2

•

18 years ago

(In reply to comment #1)
> No more activity on this list? Is Franck Hecker alive and active?

Yes, I'm alive, but I haven't had a lot of time to consider CA applications. I've just recently completed approving one application, and am now going to consider other applications, including yours.

Status: NEW → ASSIGNED

Reporter

Comment 3

•

18 years ago

(In reply to comment #2)
> > No more activity on this list? Is Franck Hecker alive and active?
> 
> Yes, I'm alive, but I haven't had a lot of time to consider CA applications.
> I've just recently completed approving one application, and am now going to
> consider other applications, including yours.

Sorry for being annoying, but my hierarchy asks for some progress report, and I have nothing else to tell them other than "Mr Hecker will work on it asap".

Comment 4

•

18 years ago

This is an enhancement request.

Severity: normal → enhancement

Updated

•

18 years ago

Summary: Request for CA certificate integration → Add Certplus root CA cert

Updated

•

18 years ago

QA Contact: ca-certificates

Assignee

Updated

•

17 years ago

Priority: -- → P2

Reporter

Comment 5

•

17 years ago

Based on bug #333272, here are some technical informations:

> Certificate Name (exactly as listed in NSS)
Certplus Class 2 Primary CA

[...]

> Certificate Data URL
http://www.certplus.com/PC/certplus_class2.pem

>   Version
3

>   SHA1 Fingerprint
74:20:74:41:72:9C:DD:92:EC:79:31:D8:23:10:8D:C2:81:92:E2:BB

>   MD5 Fingerprint
88:2C:8C:52:B8:A2:3C:F3:F7:BB:03:EA:AE:AC:42:0B

>   Modulus Length (a.k.a. "key length")
2048 bits

>   Valid From
Jul  7 17:05:00 1999 GMT

>   Valid To
Jul  6 23:59:59 2019 GMT

>   CRL URL
http://www.certplus.com/CRL/class2.crl

>   OCSP URL
No OCSP service

>   Class (domain-validated, identity-validated, EV)
domain-validated, identity-validated (in the future), EV (in the future)

>   Certificate Policy URL
For the Root:
<http://www.keynectis.com/PC/DSQ_CP_SSL_RCA_CP_1 0.pdf>
For any sub-CA:
<http://www.keynectis.com/PC/DSQ_CP_SSL_CA_CP_1 0.pdf>

Yes, there's a space in the URLs. We'll change that, if it's necessary.

> CPS URL
Not finished at the moment.

> Default Trust Indicators (email, SSL, code)
email, SSL

Reporter

Comment 6

•

17 years ago

I don't know if Bugzilla will mess this URL encoding, here's a test:

>   Certificate Policy URL
For the Root:
http://www.keynectis.com/PC/DSQ_CP_SSL_RCA_CP_1%200.pdf
For any sub-CA:
http://www.keynectis.com/PC/DSQ_CP_SSL_CA_CP_1%200.pdf

Assignee

Comment 7

•

17 years ago

Erwann: Do you have an HTTP URL on your site pointing at an installable version of the CA certificate? http://www.certplus.com/PC/certplus_class2.pem doesn't produce the "certificate install" dialog in Firefox.

Do you have any date by which you expect to finish writing your CPS?

You say: "Keynectis has been TS101456 validated to deliver qualified certificates in 2005." Are supporting documents available on your website for that audit?

Gerv

Comment 8

•

17 years ago

(In reply to comment #7)
> Erwann: Do you have an HTTP URL on your site pointing at an installable 
> version of the CA certificate? 
> http://www.certplus.com/PC/certplus_class2.pem doesn't produce the 
> "certificate install" dialog in Firefox.

That's because that page is served with the MIME Content-type: text/plain
instead of the MIME Content-type: application/x-x509-ca-cert

Reporter

Comment 9

•

17 years ago

The MIME type has been modified.

In the CD I gave you at the FOSDEM, you'll find two documents, titled "Certificat conformité ETSI 101-456.pdf" and "Certificat conformité ETSI 101-456_verso.pdf". These are scanned versions of our TS101456 certificate, in french.

Assignee

Comment 10

•

17 years ago

Erwann: It's great that they are on the CD, but I can't give a copy of it to anyone who is interested in the Firefox root store and the credentials of the CAs therein. :-) Supporting documentation needs to be (ideally) available from your website to everyone, or alternatively attached to this bug.

Thanks for fixing the MIME type :-)

Gerv

Reporter

Comment 11

•

17 years ago

The documents are too large for Bugzilla (the limit is said to be 300k), so here are 2 links to them:
http://www.keynectis.com/PC/Certificat_conformite_ETSI_101-456.pdf
http://www.keynectis.com/PC/Certificat_conformite_ETSI_101-456_verso.pdf

Assignee

Comment 12

•

17 years ago

By the way, you will be pleased to know that there appears to be no obstacle to including newly-added roots in Firefox point releases (e.g. 2.0.0.4).

Gerv

Status: ASSIGNED → NEW

Assignee

Comment 13

•

17 years ago

OK, so the remaining issue before I have all the information I need to look at the request is lack of a CPS.

Gerv

Reporter

Comment 14

•

17 years ago

The CPS will be available by monday, 12th.

I haven't found any mention of version 2.0.0.3 on Mozilla website. Isn't 2.0.0.2 the latest available version?

Erwann.

Assignee

Comment 15

•

17 years ago

Yes. I gave 2.0.0.4 as an example because 2.0.0.3 will be out before we've finished this process.

Gerv

Reporter

Comment 16

•

17 years ago

The version 1.0 of the CPS is available here:
http://www.keynectis.com/PC/CPS_KEYNECTIS_120307v1.0.pdf

A link from the http://www.keynectis.com/PC/ page will be available shortly.

Assignee

Comment 17

•

17 years ago

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

Reporter

Comment 18

•

17 years ago

Hello Gerv,

We confirm that the information listed in the pending Root CA list mentioned above is correct for the Certplus/Keynectis Root CA Class2.

Concerning the summary paragraph, we won't provide one for now, maybe in the future.

Erwann.

Assignee

Comment 19

•

17 years ago

Erwann,

I have started this evaluation. Some questions:

My French is rusty, and so it's hard for me to skim-read documents. Please can you tell me exactly where in your documents it says:

  - That, when issuing certificates for email signing, you confirm that the 
    person requesting the certificate controls the email address concerned

  - That, when issuing certificates for websites, you confirm that the person 
    requesting the certificate controls the domain name in question

?

Do you have a diagram of your certificate hierarchy?

Lastly, would you consider 20 years to be perhaps a bit of a long time for a particular copy of a CRL to remain valid?

gerv@otter:certs$ wget http://www.certplus.com/CRL/class2.crl

gerv@otter:certs$ ~/bin/nss-3.11.4/bin/pp -t crl -i class2.crl 
CRL:
    Data:
        Version: 1 (0x0)
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "CN=Class 2 Primary CA,O=Certplus,C=FR"
        This Update: Thu Jul 08 00:00:00 1999
        Next Update: Sat Jul 06 23:59:59 2019

Thanks,

Gerv

Summary: Add Certplus root CA cert → Add Keynectis/Certplus root CA cert

Reporter

Comment 20

•

17 years ago

Gerv,

The exact procedures are not part of the published CPS (this specific case is permitted by RFC3647), but here's a translation of the requested part:

----- Question 1 -----
Certificates issued to individuals

Individual certificates are normally used by individuals to sign and encrypt e-mails to authenticate to applications (client authentication). An individual certificate may be used provided that a relying party is able to reasonably rely on that certificate and the usage is not otherwise prohibited by law, the CP, the CPS under which that certificate has been issued and any agreement with subscribers.

Authentication of individual identity
Authentication of individual identity differs according to the class of certificate. The minimum authentication standard for each class of certificates is explained below :
- Class 1: No identity authentication. There is a limited confirmation of the subscriber's e-mail address by requiring the subscriber to be able to answer an e-mail to that address.
- Class 2: Authenticate identity by matching the identity by the subscriber to information residing in the Keynectis reliable source of information (database) or information contained in the business database (employee or customers directories) of an RA approving certificates to its own individuals.
- Class 3: The authentication of Class 3 individual certificates is based on the personal (physical) presence of the certificate subscriber before an agent of the CA or RA or before other official with comparable authority within the certificate subscriber's jurisdiction. The agent shall check the identity of the certificate subscriber against a well-recognized form of government-issued photographic identification (such as a passport or ID card) and one other identification credential. The authentication of Class 3 administrator certificates is based on authentication of the organization and a confirmation from the organization of the employment and authorization of the person to act as administrator. KEYNECTIS may also have occasion to approve Certificate applications for its own administrators (trusted persons in the organization). In this case, authentication of their certificate applications shall be based on confirmation of their identity in connection with their employment

Non-verified subscriber information includes: Organization unit (OU), subscriber's name in Class1 certificates, any other information designated as non-verified in the certificate.

Validation of Authority
Whenever an individual's name is associated with an Organization name in a certificate in such a way to indicate the individual's affiliation or authorization to act on behalf of the organization, Keynectis or a RA :
- determines that the organization exists by using at least one third party identity proofing database, or alternatively, organizational documentation issued by or filled with the applicable government that confirms the existence of the organization and
- uses information contained in the business records or employee directory of an RA approving certificates to its own individuals or confirms by telephone, confirmatory postal mail or comparable procedure to the organization, the employment with the organization of the individual submitting the certificate application and when, appropriate, his authority to act on behalf of the organization.
-----

----- Question 2 -----
The validation process of certificate request consists of two separate steps: Authentication and Validation.

In order to avoid errors and fraudulent issuance of certificates, the process is based on the principle of "segregation of duties’’. The person who performs the authentication cannot be the same as the person who performs the validation, and vice-versa. Therefore, the process is performed by a pair (person n°1 / person n°2) whose tasks shall be distributed.

Authentication procedure

The authentication procedure aims at obtaining the precise identity of the organization which is requesting a certificate. Authentication is one of the two steps of the validation procedure, the other step being verification.

The "Authentication" step enables us to ascertain that: The organization mentioned in the CSR actually exists and is legally entitled to the exclusive use of its name, the domain name featured in the request belongs to that organization - which is therefore entitled to use it, the technical contact is indeed entitled to submit the request since he belongs to the organization or to a company appointed by the organization which owns the domain name and which has authorized him to send the request. For example: a company with a capitalistic relationship, a host.

The validation of a certificate request is accepted when the 3 following verifications have all provided results that are satisfactory by the rules: The name of the organization in the DN is similar (but might not be exactly the same) to that of the domain owner (capitalistic relationship between the 2 organizations, request submitted by a host for the organization), the domain name owner has not frozen the certificate request (within 24h) following the sending of an e-mail informing him a request has been submitted by his technical contact and the organization featured in the certificate request is indeed connected to the domain name owner.

E-mail sent to the domain name's administrative contact

During the request's registration, an e-mail has been sent to the administrative contact of the domain name associated to the organization, this to inform him of the certificate request. The administrative contact then has 24h to "oppose" the issuance of the requested certificate. A copy of this e-mail is sent to the customer service. In case the domain name's administrative contact rejects the request after the certificate is issued, the customer service is to proceed with the revocation of the said certificate.

Verification of domain name (Common Name)

The domain name is the name that has been registered by the organization with agencies such as INTERNIC. The domain name is always to be registered in the name of the organization that requests it. During the registration process, the domain name is "associated" to an owner who is legally entitled to use this domain name. The domain name's owner must be the same as the Organization for which the certificate is issued, or be one of its subsidiaries.

If the domain name registered on the reference websites matches the name of the organization featured in the request, customer service validates this step and proceed with telephone verifications. If the domain name is not registered in the name of the organization featured in the certificate request, or if the domain is registered in the name of an individual, customer service is to send complementary documents to allow the validation to be completed. There are 4 procedures to circumvent this situation and achieve positive validation:

- Legal relationship: The customer must prove the existing legal relationship between his organization and the organization that is featured in the domain name registration, this by providing an official document.

- Changing the domain name registration: If the domain name owner does not match the organization, the customer must change the information featured in the domain name registration and enter the name of his organization as being the domain name owner.

- Authorization to use the domain name: The customer will be appointed to submit a request for the domain name owner (ex: relationship between the applicant organization and an Internet provider). The customer must prove this relationship by sending us a letter "authorizing the use of his domain name". This letter is to be signed by that administrative contact that is mentioned in the domain name registration, and to authorize the applicant organization to use the domain name featured in the request.

- Re-initiate the process: The customer submits a new request in the name of the organization featuring in the domain name registration.

Telephone verification

The telephone verification procedure enables the following points to be ascertained: The contact provided is indeed employed by the applicant company, he is aware of the request, he confirms the e-mail addresses and he is authorized to submit a certificate request, to receive it and to install it.

During the call, the customer service is to ask a number of questions to validate the cogency of the online request: If it obtains all the answers to its questions, customer service can validate this verification step and issue the certificate If some items of information are missing or incorrect, customer service is to inform the customer of all the items he must provide with in order to rectify his request.
-----

----- Question 3 -----
See scheme p24 of the CPS. For better understanding :

- AC Racine means Root CA
- AC means CA (subordinate)
- AC UF means end user CA
-----

----- Question 4 -----
No, I don't consider 20 years to be "too long", because the CRL has to be downloaded way before the nextUpdate field (and that's correctly done by Mozilla products). The RFC3280 specifies:

===
5.1.2.5 Next Update

This field indicates the date by which the next CRL will be issued.
The next CRL could be issued before the indicated date, but it will
not be issued any later than the indicated date. CRL issuers SHOULD
issue CRLs with a nextUpdate time equal to or later than all previous
CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime.
===

Which means that this nextUpdate date is an "at most" date. The meaning is slightly different than the notAfter date of a certificate. This is conformant with what the X.509 normative document specifies. Moreover, as specified in our hierarchy diagram, the Root CA will only sign subordinate CAs, and revocation of such CAs is not a frequent operation.

Thanks,

Erwann.

-----

Assignee

Comment 21

•

17 years ago

Erwann,

Exactly which sections of the CPS have you translated? I can't find the matching bits.

> See scheme p24 of the CPS. For better understanding :

I don't quite understand that diagram. As you have only one root, I would expect there to be a single node at the top of the tree, called "Certplus Class 2 Primary CA".

> No, I don't consider 20 years to be "too long", because the CRL has to be
> downloaded way before the nextUpdate field (and that's correctly done by
> Mozilla products).

One of our developers told me the other day that Mozilla (or Firefox) waits until the nextUpdate date before downloading a new CRL. Do you know that to be incorrect?

Thanks,

Gerv

Reporter

Comment 22

•

17 years ago

Gerv,

This extract wasn't taken from our CPS. In the CPS, paragraph 5, page 38, is mentioned the fact that the CA will do all the required verifications before inclusion of any information in the certificate. What I posted is taken from our procedures. As indicated on the same page, these procedures can be obtained by written order; these are "kind of" business confidential. I need to check the security department about exposure of such material. Could they eventually be sent to you privately?

The diagram lists 3 of our CAs, and the whole CP/CPS applies to all 3, even if we're only requesting for the inclusion of the "Class 2 Primary CA" in Firefox. All 3 (in fact, 5) are already included in Microsoft products.

About the download of a CRL, maybe I mistaken. When you click on the CRL URL, Firefox asks you wether you want to update it automatically, and if yes, proposes you to download it at least 'n' days before the nextUpdate, or every 'n' days. I downloaded the NSS library source code, and it's pretty hard to spot the corresponding code.
If Mozilla really does wait until the nextUpdate date, then yes, this is not a satisfactory situation. We then have 3 solutions:
- generate CRLs every 2 or 3 months (the root CA key is on a set of tokens stored offline, in a vault, there must be at least 6 different people present to operate it, so generating a CRL every day or every week is not feasible),
- generate CRLs when necessary (in the case of a revocation), without specifying the nextUpdate date. I don't know Mozilla's behaviour in this situation. This field is optional from the X.509 normative document, it is said to be required by the RFC3280, but this is not defined in terms of MUST, or SHOULD, as defined by RFC2119, so strictly speaking, such a solution is compliant to RFC3280,
- don't generate a CRL, and provide an OCSP service (or any other revocation/status mechanism). That might not be accepted by the Mozilla Root inclusion process.

Solution 1 is probably the best option, followed by solution 2. Solution 3 is a theoretical solution only, as we can't expect all software to be able to use an OCSP service.

I have to check the NSS source code about this issue, and if Mozilla really works like this, then find a satisfactory solution.

Regards,

Erwann.

Kaspar

Comment 23

•

17 years ago

(In reply to comment #22)
> If Mozilla really does wait until the nextUpdate date, then yes, this is not a
> satisfactory situation. We then have 3 solutions:
>  - generate CRLs every 2 or 3 months (the root CA key is on a set of tokens
> stored offline, in a vault, there must be at least 6 different people present
> to operate it, so generating a CRL every day or every week is not feasible),

I would highly recommend to implement this solution - it's not only an issue with Mozilla, but with all other implementations which follow the path validation algorithm of RFC 3280 (section 6). In particular, "6.3.3  CRL Processing" only requires the local CRL cache to be updated "[i]f the current time is after the value of the CRL next update field". Microsoft's CryptoAPI e.g. does it exactly like that - it won't fetch a new CRL from the network if the one in the cache is still valid (cf. http://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx).

Assignee

Comment 24

•

17 years ago

Erwann: I don't need to see your internal procedures. I am looking for the statements in question in your CPS.

As you may know, section 7 of our CA certificate policy gives some (fairly minimal) requirements for the validation a CA needs to do for the three different types of cert we care about:
http://www.mozilla.org/projects/security/certs/policy/

For the email requirement, I believe there is a statement in section 2.3.1 which suffices. And obviously the code-signing requirement does not apply to you. But I am still looking for the part of your CPS which states that you make sure that the requester of an SSL certificate actually owns the domain in question before issuing them a cert. :-)

We would expect to see your practices in this regard stated in your Certificate Practice Statement. Normally, I would read through the CPS looking for the relevant sections, but as the CPS is in French, this is rather a slow process for me. So I asked you where in the CPS to look. There are only two possible answers - a section number, or "they aren't there" :-)

I see your problem regarding CRLs and the impracticality of generating them every day or every week. And I note that the Mozilla CA policy has no requirement regarding CRL expiry dates, and that Firefox currently doesn't check them by default anyway. But, as a matter of good practice, I would suggest that you do what Kaspar has suggested.

How regularly do you issue CRLs for end entity certificates?

Gerv

Reporter

Comment 25

•

17 years ago

Gerv,

Paragraph 5.1 of our CPS should be what you're looking for. This paragraph lists what the CA needs to validate before generating a certificate. Paragraphs 2.3.2 and 2.4 also cover the subject. You won't find detailed procedures of the process, just a mention of what is verified (either "in general", for example "the identity of the requester", or each item specified, for example "the organization of the requester").

For the CRL, I can't take that decision by myself, I'll contact our key manager.

For end-user certificates, the process is completely "on-line", and such CRLs are generated every day, with a nextUpdate set to 7 days later.

Erwann.

Assignee

Comment 26

•

17 years ago

Erwann: my concern is that your CPS is vague about what you actually do to verify these things. I realise there's a balance to be struck between too little detail and excessive detail, but at the moment it seems to me that you have the former. 

In what way do you do "Confirmation nom de domaine InterNIC", as section 5.1 puts it? Do you send a representative round to InterNIC to ask in person? :-) I would suggest that the CPS needs to say.

To put it precisely: the public documents of any CA we admit need to contain statements sufficient to verify that their processes meet our requirements, as outlined in section 7 of our policy. The requirements are very simple and basic, so I don't think that's a big thing to ask.

A couple of CAs over the past two weeks have been kind enough to revise their CPSes to clarify these points. Would you be able to do the same?

Gerv

Reporter

Comment 27

•

17 years ago

Gerv,

We're currently working toward the clarification of the CPS for this issue. It will be available later this week.

Thanks for your comprehension.

Erwann.

Reporter

Comment 28

•

17 years ago

Gerv,

An udpated CPS can be found here:
http://www.keynectis.com/PC/CPS_KEYNECTIS_120407v1.1.pdf

Updated parts are paragraphs 5.2 to 6.3.

Erwann.

Assignee

Comment 29

•

17 years ago

I have evaluated this request, as per sections 1, 5 and 15 of the official CA policy at: http://www.mozilla.org/projects/security/certs/policy/ . On behalf of the Mozilla project, I apologise for the delay.

Here follows my assessment. If anyone sees any factual errors, please point them out.

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by Keynectis, 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]. Keynectis appears to provide a service relevant to Mozilla users: they are a French commercial CA who issue certificates to the general public. Policies are documented in the documents published on their website and listed in the entry on the pending applications list.

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

* Email: For certificates with the E-mail Protection EKU (1.3.6.1.5.5.7.3.4), Keynectis verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate. (See section 2.3.1 of CPS v1.1.)

* SSL: For certificates with the TLS Web Server Authentication EKU (1.3.6.1.5.5.7.3.1), Keynectis verifies domain control by communicating with the Administrative Contact listed in WHOIS. (See section 6.1.3.2 of CPS v1.1.)

* Code: Keynectis does not issue Code Signing certificates.

Section 8-10 [Audit]. Keynectis has successfully completed an audit using the ETSI TS 101.456 criteria. The auditors were LSTI - La Sécurité des Technologies de l'Information. The audit is valid until 17th October 2008.

Section 13 [Certificate Hierarchy]. Keynectis has multiple intermediate CAs under three roots, of which only one is to be included. (See page 24 of CPS v1.0.)

Other: Keynectis issues CRLs (on a 1 day schedule). It does not offer OCSP services.

I am therefore minded to approve the application. Before I do, I'm opening up a period of public discussion of this request. I'll post in the news://news.mozilla.org/mozilla.dev.tech.crypto newsgroup to allow people to make comments. The normal comment period, unless discussion continues beyond that time, is two weeks.

Gerv

Status: NEW → ASSIGNED

Assignee

Comment 30

•

17 years ago

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

Gerv

Assignee: hecker → gerv

Status: ASSIGNED → NEW