369357 - ADD DigiNotar EV Root CA certificates

Status: RESOLVED FIXED

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

Description

[Kick Willemse]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Build Identifier: 

DigiNotar is a trusted third party in the Netherlands issuing digital certificates. For now our main customers are based in the Netherlands. Our customers are goverment, banking, industry. DigiNotar is qualified against ETSI 101456 for issuing qualified electronic signatures conform EU regulations (Price Waterhouse Coopers http://www.diginotar.nl/files/etsi.pdf). As a member of the CABforum we also implement the new EV SSL standard. To do so we are also passed the WebTrust 'readiness' audit (KPMG).  

DigiNotar wants to submit the following roots

1. DigiNotar TopRoot
Description:  This is the toproot of the DigiNotar CA hierarchy.  
Download:  https://service.diginotar.nl/files/DigiNotar%20Root%20CA.crt
Thumbprint:  fe 02 91 be 1f 93 5f 42 00 36 1b dc 1b aa 2f 52 64 0f cf 55
Purposes/Usage: ALL
OID:  2.16.528.1.1001.1.1.1.1.5.2.6.4
CPS: http://www.diginotar.nl/cps


2. DigiNotar Qualified Sub CA
Description:  This is the subca for issuing qualified certificates 
Download:  http://www.diginotar.nl/Files/DigiNotar%20Qualified%20CA.crt
Thumbprint:  FFAD 0E26 F05B BCD8 063C CE1D FA60 245E 143D 5380
Purposes/Usage: ALL
CRL:  http://service.diginotar.nl/crl/root/latestCRL.crl
OCSP:  http://validation.diginotar.nl
OID:  2.16.528.1.1001.1.3.3.1.5.2.6.4

3. DigiNotar EV SSL Sub CA
Description:  This is the EV SSL SubRoot for issuing evssl certs
Download:  https://service.diginotar.nl/files/DigiNotar%20Extended%20Validation%20CA.crt
Thumbprint:  fe 02 91 be 1f 93 5f 42 00 36 1b dc 1b aa 2f 52 64 0f cf 55
Purposes/Usage: EV SSL
CRL:  http://service.diginotar.nl/crl/root/latestCRL.crl
OCSP:  http://validation.diginotar.nl
OID:  2.16.528.1.1001.1.1.1.1.5.2.6.4

4. DigiNotar Public Sub CA
Description:  This is the toproot of the DigiNotar CA hierarchy.  
Download:  http://www.diginotar.nl/rootcertificaten/DigiNotar%20Public%20CA%202025.crt
Thumbprint:  3f 01 8e 6f e3 36 09 6a 79 1b 81 e7 69 be 70 1a af 21 e3 07
Purposes/Usage: ALL
CRL:  http://service.diginotar.nl/crl/root/latestCRL.crl
OCSP:  http://validation.diginotar.nl
OID:  2.16.528.1.1001.1.1.1.1.5.2.6.4


5. DigiNotar Services Sub CA
Description:  This is the toproot of the DigiNotar CA hierarchy.  
Download:  https://service.diginotar.nl/files/DigiNotar%20Root%20CA.crt
Thumbprint:  94 32 bd 9a ec 1d 75 d1 70 5c 54 3a a3 4c 4a f6 a5 26 c1 3d
Purposes/Usage: ALL
CRL:  http://service.diginotar.nl/crl/root/latestCRL.crl
OCSP:  http://validation.diginotar.nl
OID:  2.16.528.1.1001.1.1.1.1.5.2.6.4



Microsoft will include our CA certs in the next update.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Kick Willemse]

I just noticed that the URL of the sub CA services cert is not correct. To make sure I will attached the certs

Comment 2

[Kick Willemse]

Attachment: Public Sub CA

Comment 3

[Kick Willemse]

Attachment: Qualified sub CA

Comment 4

[Kick Willemse]

Attachment: Root CA

Comment 5

[Kick Willemse]

Attachment: EV SSL Sub CA

Comment 6

[Kick Willemse]

Attachment: Services sub CA

Comment 7

[Gervase Markham [:gerv]]

Kick: We don't include sub CAs in the Mozilla store, only root CAs. You only have one root CA, is that correct? If so, please complete the below for your CA and that certificate only.

There are a large number of outstanding CA requests, and it will take me some time to work through them. I can tell you that I will need the following data for each request. If some of this data is missing, the request cannot proceed. Even if all of it is already present somewhere in the bug or the materials provided, it will speed up your application if you provide it again. This means I can make everyone happier, quicker :-)

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
Gerv

Comment 8

[Kick Willemse]

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

CA Name: DigiNotar
Website: www.diginotar.nl
One Paragraph Summary of CA, including the following:
DigiNotar is a Dutch trusted third party, mainly operating in the Netherlands. We issue certificates based on the trust role of the notary. We service business, governement and consumer market.  We have 5 subordinate CA's. 
- Public certificates (Medium trust personal and organisational certificates)
- Qualified certificates (Conform EU regulations)
- Services certificates (SSL, Software Signing, S/Mime)
- EV SSL for issuing EV SSL
- Private subCA (Customers have a private subCA)

Audit Type (WebTrust, ETSI etc.): ETSI 101456
Auditor: Price Waterhouse Coopers
Auditor Website: www.pwc.nl
Audit Document URL(s): http://www.diginotar.nl/files/etsi.pdf

Certificate Details
-------------------
(To be completed once for each certificate)

Certificate Name: DigiNotar Root CA
Summary Paragraph, including the following:
 - This is our top root issuing 5x subordinate CA's. These CA's issue SSL, personal and organisational level certificates. Both smartcard, softtoken.
Certificate HTTP URL (on CA website): https://service.diginotar.nl/files/DigiNotar%20Root%20CA.crt
Version: V3
SHA1 Fingerprint:fe 02 91 be 1f 93 5f 42 00 36 1b dc 1b aa 2f 52 64 0f cf 55

MD5 Fingerprint: X
Modulus Length (a.k.a. "key length"): 4096
Valid From (YYYY-MM-DD):2005-03-31
Valid To (YYYY-MM-DD):2025-03-31
CRL HTTP URL: http://service.diginotar.nl/crl/root/latestCRL.crl
OCSP URL: http://validation.diginotar.nl
Class (domain-validated, identity-validated or EV): EV SSL, Identity-validated, domain-validated
Certificate Policy URL:http://www.diginotar.nl/cps
CPS URL: http://www.diginotar.nl/cps
Requested Trust Indicators (email and/or SSL and/or code): Genric/ ALL

Comment 9

[Kick Willemse]

Gerv,

I updated the root registration "bug" I have a question regarding EV SSL.

Although you only register our topRoot, do you need our OID for EVSSL of the SubCA?

Kick

Comment 10

[Gervase Markham [:gerv]]

Kick: No, thank you. We will be doing EV approvals as a separate process, and will gather the needed information then.

Gerv

Comment 11

[Gervase Markham [:gerv]]

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

Comment 12

[Gervase Markham [:gerv]]

Kick: It's been nearly a month. Are you able to confirm that your information is correct?

Thanks,

Gerv

Comment 13

[Kick Willemse]

Gerv,

Thank you for your reply. I was not aware of you waiting for us, sorry for that. I confirm this information is correct.

I prefer to have the following link for our ETSI certificate, so this can be a 

Use the following for the paragraph:

DigiNotar is a Dutch trusted third party, mainly operating in the Netherlands. They issue certificates based on notary verification of applicants. They service the business, government and consumer markets.

If this is not OK, please send me a sample and location of this paragraph.

Kick





(In reply to comment #12)
> Kick: It's been nearly a month. Are you able to confirm that your information
> is correct?
> 
> Thanks,
> 
> Gerv
> 

Comment 14

[Kick Willemse]

Sorry, I forgot the link for the ETSI:

http://www.diginotar.nl/certification

Kick

Comment 15

[Gervase Markham [:gerv]]

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

Gerv

Comment 16

[Gervase Markham [:gerv]]

Kick: I can't see how the page at that URL relates to your ETSI audit. The link I have at the moment goes directly to the audit certificate - what's wrong with it?

As you have confirmed the data, I have put your CA in the queue for assessment.

Gerv

Comment 17

[Kick Willemse]

Hi Gerv,

Thank you for for the reply. I thought for future use (When we get an update of our ETSI audit or additional audits) it would be beter to refer to a redirect URL. If this is only a link for the current assessment just leave it as is.

Any idea about the time/planning for assessment <> include in browser?

Kick

Comment 18

[Kick Willemse]

I noticed that on http://www.mozilla.org/projects/security/certs/pending/ the request is not green yet. I am probably to fast :-)

Comment 19

[Gervase Markham [:gerv]]

Kick: I never promise anything :-)

You should be green very soon.

Gerv

Comment 20

[Kick Willemse]

Hi Gerv,

Just to manage our internal roadmap and communications to our customers, are you able to provide any time estimate for the evaluation phase by mozilla and the timeline/procedure to update the browsers?

Look forward meeting you in one of the cabforum meetings.

Kick

Comment 21

[Gervase Markham [:gerv]]

No promises :-) The first CAs to be approved are going to get included soon, and then they'll be in an NSS release, and after that in a Firefox release. It all depends on how the relative release timings work. NSS releases are every couple of months, Firefox releases similarly. So it's very hard to predict.

You could probably say "next few months".

Gerv

Comment 22

[Gervase Markham [:gerv]]

Kick has had to have his top root re-signed; this bug is on hold waiting for him to submit new information (which I have just asked him to do; the delay is my fault, not his).

Gerv

Comment 23

[Kick Willemse]

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

CA Name: DigiNotar
Website: www.diginotar.nl
One Paragraph Summary of CA, including the following:
DigiNotar is a Dutch trusted third party, mainly operating in the Netherlands.
We issue certificates based on the trust role of the notary. We service
business, governement and consumer market.  We have 5 subordinate CA's. 
- Public certificates (Medium trust personal and organisational certificates)
- Qualified certificates (Conform EU regulations)
- Services certificates (SSL, Software Signing, S/Mime)
- EV SSL for issuing EV SSL
- Private subCA (Customers have a private subCA)

Audit Type (WebTrust, ETSI etc.): ETSI 101456, Webtrust EV
Auditor: Price Waterhouse Coopers ETSI, KPMG Webtrust EV
Auditor Website: www.pwc.nl, www.kpmg.nl
Audit Document URL(s): http://www.diginotar.nl/files/etsi.pdf

Certificate Details
-------------------
(To be completed once for each certificate)

Certificate Name: DigiNotar Root CA
Summary Paragraph, including the following:
 - This is our top root issuing 5x subordinate CA's. These CA's issue SSL,
personal and organisational level certificates. Both smartcard, softtoken.
Certificate HTTP URL (on CA website):
http://www.diginotar.nl/files/Rootcertificaten/DigiNotar%20root%20CA2007.crt
Version: V3
SHA1 Fingerprint:c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c

MD5 Fingerprint: X
Modulus Length (a.k.a. "key length"): 4096
Valid From (YYYY-MM-DD):2007-05-16
Valid To (YYYY-MM-DD):2025-03-31
CRL HTTP URL: http://service.diginotar.nl/crl/root/latestCRL.crl
OCSP URL: http://validation.diginotar.nl
Class (domain-validated, identity-validated or EV): EV SSL, Identity-validated,
domain-validated
Certificate Policy URL:http://www.diginotar.nl/cps
CPS URL: http://www.diginotar.nl/cps
Requested Trust Indicators (email and/or SSL and/or code): Genric/ ALL

Comment 24

[Gervase Markham [:gerv]]

Kick: I have put the new data up on http://www.mozilla.org/projects/security/certs/pending/ ; please can you again check that it's all correct?

- Do you have a certificate hierarchy diagram?

- At what frequency do you issue CRLs for end entity certificates?

Your CP/CPS and/or other documents are not in English. Assuming they are not available in English (please let me know if they are), then I have to have particular parts translated. As having documents translated and reading approximate translations is a tedious task, I hope you will be able to help me in narrowing down which parts to read.

When I read a CP/CPS, I am looking to see if the practices of the CA satisfy the criteria in our CA Certificate Policy:
http://www.mozilla.org/projects/security/certs/policy/

Specifically, I look for:

- Which exact section contains an undertaking to confirm that the applicant has control of the email address before issuing them an email certificate?

- Which exact section contains an undertaking to confirm that the application has control of a domain name before issuing them an SSL certificate?

- (If applicable) Which exact section contains an undertaking that the applicant's identity is strongly validated before issuing them a code signing certificate?

Can you point me at the correct sections for each of these cases?

Thanks,

Gerv

Comment 25

[Kick Willemse]

Gerv,

I confirm that the data for DigiNotar at http://www.mozilla.org/projects/security/certs/pending/ is correct.

Our certificate hierarchy in words:

TOP Root CA
SUB Root Services (Issuing services certificates for signing, ssl, object)
SUB Root EV (For issuing EV certificates
SUB ROOT QUALIFIED (Issuing personal QUALIFIED certificates conform ETSI
SUB ROOT Public (Issuing non-qualified personal certificates)
SUB ROOT Private (Issuing private sub sub roots for companies, internal certs)

CRL Publishing

Customers are able to validate certificates on website realtime
We provide OCSP services realtime
CRL published with validity of 24 hours.

I will come back on the legal CPS part. I suggest, looking at the different CA's you need to approve, you ask for a statement of a local auditor that we are working conform your cert policy. This saves a lot of work for your organisation and translations.

Comment 26

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #24)

> 
> - Which exact section contains an undertaking to confirm that the applicant has
> control of the email address before issuing them an email certificate?
> 
> - Which exact section contains an undertaking to confirm that the application
> has control of a domain name before issuing them an SSL certificate?
> 
> - (If applicable) Which exact section contains an undertaking that the
> applicant's identity is strongly validated before issuing them a code signing
> certificate?
> 
> Can you point me at the correct sections for each of these cases?
> 
> Thanks,
> 
> Gerv

http://www.diginotar.nl/Portals/7/Voorwaarden/CPS%20algemeen%20versie%203.4.2.pdf  

section 4 is about requesting a certificate (in short):
- only by mail (post)
- you need a valid id (check by a notary)
- the registration of a company will be checked in the commercial register
- the domain/ip address will be checked 
- 

it looks like they meet requirements of Mozilla CA Certificate Policy 

greetings 

Tim Maks
p.s. they have a few important organizations as a client like the ministry of justice, kadaster ( the Offices of the land registry), the commercial register, etc  

Comment 27

[Gervase Markham [:gerv]]

OK, I've found the parts about domain control for SSL, and you check identity for all certificates, so that's OK for code signing. But I can't find anything about email address ownership verification. Searching for "email" turns up only one reference, which doesn't seem to unambiguously fit the bill.

Kick: when issuing certificates for email signing, do you confirm that the applicant owns the email address in question? If so, how, and where does your CPS talk about this?

Thanks,

Gerv

Comment 28

[Gervase Markham [:gerv]]

Oh, I should have mentioned - the other option is to withdraw the application for email signing status, and just proceed on the basis of SSL and code. We can do that if you like. I have no other issues than this one, so that would mean we'd be finished.

Gerv

Comment 29

[Kick Willemse]

Gerv,

To withdraw the application for e-mail is no option for us. We think this is a very important functionality for us. 

Looking at the certificates we issue (Personal certificates, Organisational and Server certificates) we validate the identity of the person, organisation or server (Domain). Validating that the e-mail belongs to the certificateholder is something we think is not possible/ important. We garantee that when you receive a signed e-mail, that you can relate this to an existing person or organisation. The applicants can request certificates on any e-mail they like ([e-mail] etc.)  and we think it is not possible to garantee anything on the e-mail accept for checking that the applicant has access to this mailbox. Even ETSI or EVSSL are not stating anything on this.

What type of e-mail validation do you expect from a CA?

Are you in Amsterdam coming thursday and friday for the CABforum meeting?

Comment 30

[Gervase Markham [:gerv]]

(In reply to comment #29)
> The applicants can request certificates on any e-mail they like
> ([e-mail] etc.)  and we think it is not possible to garantee anything
> on the e-mail accept for checking that the applicant has access to this
> mailbox. 

Precisely :-)

> What type of e-mail validation do you expect from a CA?

I expect you to check that the applicant has access to the mailbox. If my name is Tom Smith, email address [e-mail], I don't want someone else also called Tom Smith getting an email certificate for my email address! It seems to me to be vital that if you are issuing an email certificate to someone, you do it in such a way that you confirm that they actually own the email address in question.

Section 7 of our policy 
http://www.mozilla.org/projects/security/certs/policy/
is clear:
"for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf;"

If you don't do that, we can't enable your root for email.

> Are you in Amsterdam coming thursday and friday for the CABforum meeting?

As you may have noticed, sadly I wasn't. I had another commitment at that time. I hope the meeting went well. I look forward to reading the minutes.

Gerv

Comment 31

[Kick Willemse]

Gerv,

We are internally checking how we can fullfil the requirements on E-mail. Please let me know if there is any specific deadline to be at least registered in any next update. 


Kick

Comment 32

[Kick Willemse]

Gerv,

Although we know that it is possible to send a confirmation link e-mail to the certificate requester somewhere in the registration proces (Which we want to implement in the coming months) is there a way to solve this in a more pragmetic way like asking the requester to agree on a term that he is really the owner?  

How do you see this working out if we technicaly implement this e-mail validation the coming months in relation to the 10.000 certs we already issued from this Root.

I wonder if you should enable roots looking at the technical use or that you should just look at the independent sources that we are checked making sure the identity of the certificateholder (Identity check, domain etc..)

Comment 33

[Gervase Markham [:gerv]]

(In reply to comment #32)
> Gerv,
> 
> Although we know that it is possible to send a confirmation link e-mail to the
> certificate requester somewhere in the registration proces (Which we want to
> implement in the coming months) is there a way to solve this in a more
> pragmetic way like asking the requester to agree on a term that he is really
> the owner?  

Well, a fraudster would be happy to agree to anything you asked him.

> I wonder if you should enable roots looking at the technical use or that you
> should just look at the independent sources that we are checked making sure the
> identity of the certificateholder (Identity check, domain etc..)

This is not just a technical question. It seems to me that, under the current system, if I apply for a certificate for the email address "[e-mail]" or "[e-mail]", giving all my own personal details, I would get one - because you would carefully check my personal details and confirm that yes, I am indeed me. That's a serious hole. Don't you agree? Without verification of email address control, all sorts of abuses are possible.

Gerv

Comment 34

[Kick Willemse]

Gerv,

I agree on your first comment, but at least we know who it is.

Second discussion:

Because we are certain about the identity of the certificate holder we can always trackback to a physical person/organisation who used this certificate. So in case of any person requesting a certificate with a different e-mail adres and using this to mislead the recipient, because his e-mail is "[e-mail]" we will always know who did this. Therefore it makes no sense to use this certificate to "fraud" 

Looking at your policy. What should we do if somebody requests [e-mail] They will be able to acces the mailbox but the potential of "fraud" is still the same.

Only checking that the person or organisation owns the domain used for sending e-mail ([e-mail]) will not work in case of commercial webmail providers. Looking at our customer requests over 50% use a commercial ISP/ mail provider for their certificate.

The problem is more in the perception of recipients/ applications that only an e-mail adres would certify the users identity. So they should look at certificate details more closely to make sure who this is and what garantees are given. Only accepting Root certificates that garantee a certain level of identification would help to solve this issue.

So I agree we can include an additional threshold by checking that the recipient controls that e-mail adres, but this will never solve the issue of potential fraud. So I see no reason not accepting root certs that garantee a certain level of identity verification like EVSSL so at least you can track back the organisation/person and help recipients understanding that they should look at more criteria and not only e-mail adres.

Besides I would like to know how we can comply to your requirements and include our Root certificate when we start checking e-mail control today in relation to the certificates already issued.

Looking at the impact of not including our root for e-mail, am i right that this is only related to thunderbird not accepting our e-mails as being trusted directly? Or are there other applications?

Hope to hear from you soon.

Kick

Comment 35

[Kick Willemse]

Hi Gerv,

Any feedback on my previous questions. Besides, when I look in my current Rootstore I see the following Root: Staat der Nederlanden CA. Could you tell me if this root is enabled for e-mail signing or where I can see this? I would like to compair their procedures.

Kick 

Comment 36

[Nelson Bolyard (seldom reads bugmail)]

Kick, Here's how to see trust information for that (or any cert).

When you see "Staat der Nederlanden Root CA" in the Authorities tab in the
browser's certificate manager, Click on it.  Then at the bottom of the 
certificate manager window, buttons named "View" "Edit" and "Delete" will
become enabled (they will change from gray to black).  Click the Edit button.

A small dialog box will appear with three check boxes.  Those checkboxes 
will tell you the purposes (if any) for which the cert is trusted.  You 
may also change it there.  Click Cancel if you wish to make no changes.

In my browser, that CA is trusted for all three usages, SSL, eMail, and 
code signing.

Comment 37

[Kick Willemse]

Nelson, Gerv,

I checked the Root status and see that Staat der Nederlanden Root CA is enabled for eMail. This Root is the top of a scheme that allows Dutch CA's to issue Staat der Nederlanden end user certs. We are an audited party that can issue these certs. I checked on the procedure we follow regarding e-mail adres and this is exactly the same as our other certificates/roots. 

Therefore I see no issue to enable our Roots for eMail.

Kick

Comment 38

[Gervase Markham [:gerv]]

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

Gerv

Comment 39

[Nelson Bolyard (seldom reads bugmail)]

According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the status of this request is: Information confirmed complete	

Comment 40

[Frank Hecker]

I'm now actively evaluating this application, and have just checked in a new version of the pending list with revisions to DigiNotar's entry:

http://www.mozilla.org/projects/security/certs/pending/#DigiNotar

It should show up on the public site within an hour. I expanded the summary to list all of the subordinate CAs, and also referenced the English version of the CPS.

It appears that one item we're missing is the EV OID; could you please post this value in a bug comment? Note that I can go ahead and evaluate the application without the OID, but we will need the OID later.

Also, could you provide a URL for your WebTrust EV audit report? We need this in order to confirm your compliance with the CAB Forum EV guidelines.

In the meantime, before I get the EV information, I'll do the evaluation for overall inclusion of the root from a non-EV perspective.

Comment 41

[Kick Willemse]

Hi Frank,

To see an example of our EV certificates check: https://www.diginotar.nl
The OID is: 2.16.528.1.1001.1.1.1.12.6.1.1.1 as you can confirm within the certificate. 

Our ETSI certificate can be found on: https://www.diginotar.nl/Portals/7/ETSI/Certificate.pdf

In addition KPMG audited us to bridge the gap between the ETSI audit and webtrust. We have a statement of this as well. This is not publicly available on our website. I will send you a digital copy by mail.

Comment 42

[Kick Willemse]

Frank,

Please find enclosed a public link to the webtrust appendix. Let me know if there is any outstanding issues.

http://www.diginotar.nl/files/20061214%20DigiNotar%20WebTrust%20for%20CAs%20EV%20KPMG%20Report.pdf


Kick

Comment 43

[Frank Hecker]

Thanks for posting the WebTrust EV document; I've updated the pending page to link to it, and have added the EV OID. 

Comment 44

[Frank Hecker]

I have now completed my review of DigiNotar's application for adding the
DigiNotar Root CA certificate and enabling it for EV use, per the official Mozilla CA certificate policy at:

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

I apologize for the delays on my part in doing the review.

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 DigiNotar (however see the note below regarding EV certificates), or of instances where DigiNotar has 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]. DigiNotar appears to provide a service relevant to Mozilla users. It is a Dutch CA operating primarily in the Netherlands, and issuing certificates to individuals and organizations; it operates in partnership with Dutch civil-law notaries. Its policies are documented in its CPS:

http://www.diginotar.com/Portals/0/General%20terms/DigiNotar_CPS_3.5_-_EN.pdf

* Email: DigiNotar verifies identity for applicants issued certificates suitable for use with email. (See section 4.3.1 of the CPS, along with section 4.3.2 for some additional procedures applicable to particular types of certificates.)

* SSL: DigiNotar verifies identity for applicants issued certificates suitable for use with SSL-enabled servers, with verification for EV SSL certificates done according to the CAB Forum Guidelines. (See sections 4.3.1 and 4.3.2.6 of the CPS, including section 4.3.2.6.4 for EV.)

* Code: DigiNotar verifies identity for applicants issued certificates suitable for code signing. (See sections 4.3.1 and 4.3.2.6 of the CPS.)

Section 8-10 [Audit]. DigiNotar has successfully completed an independent audit using the ETSI 101 456 criteria. The audit was done by Price Waterhouse Coopers. Attestation of the successful completion of the audit is in the form of a certificate available at

  http://www.diginotar.nl/files/etsi.pdf

Note that since the certificate in question was provided by the CA, final approval is contingent upon contacting PWC and verifying that such a certificate was issued.

DigiNotar has also completed a WebTrust EV audit, done by KPMG, a report of which is available at

http://www.diginotar.nl/files/20061214%20DigiNotar%20WebTrust%20for%20CAs%20EV%20KPMG%20Report.pdf

Note that, as noted in the report, at the time of the audit the CA software used by DigiNotar did not have the necessary features to issue EV certificates; the software has since been upgraded and DigiNotar has since successfully issued EV certificates. See for example the certificate at

https://www.diginotar.com/

Note that the EV audit was done against the draft 11 EV guidelines. Also note that since the EV report was provided by the CA itself, final approval of this request is contingent upon verifying with KPMG that the report in question was indeed issued by them.

Audits are done annually (section 11.3 of the CPS).

Section 13 [Certificate Hierarchy]. DigiNotar operates five subordinate CAs corresponding to the different types of certificates issued, including in particular DigiNotar Extended Validation CA for EV certificates.

Other: DigiNotar issues CRLs (with any given CRL not being more than a day out of date) and also maintains an OCSP responder. (See section 6.10 of the CPS.)

Based on the above information, I am minded to approve the inclusion of the
DigiNotar Root CA certificate in NSS (and thence in Firefox and other Mozilla-based products), with the trust bits for email, SSL, and code signing set, and the root's enabling for EV with policy OID 2.16.528.1.1001.1.1.1.12.6.1.1.1. Before I issue my final approval, I'm opening up a period of public discussion of this request in the mozilla.dev.tech.crypto newsgroup [1].

[1] The mozilla.dev.tech.crypto newsgroup is accessible via NNTP-capable
newsreaders at:

  news://news.mozilla.org/mozilla.dev.tech.crypto

via email by subscribing to the associated mailing list:

  https://lists.mozilla.org/listinfo/dev-tech-crypto

and via the web at:

  http://groups.google.com/group/mozilla.dev.tech.crypto/topics

Comment 45

[Frank Hecker]

Based on discussion during the public comment period, I've decided to consider this application as applying to SSL and code signing uses only, and to postpone any approval for email use until such time as we determine that DigiNotar is in compliance with our current policy requirements regarding verifying that email addresses referenced in certificates actually belong to the entity holding the certificate.

Regarding comment #37 about Staat der Nederlanden certificates: The Staat der Nederlanden root CA was approved for inclusion during a time when our current policy was not in effect and we didn't have any policy requirements relating to certificates used in the context of signed/encrypted email. We'll take a second look at the Staat der Nederlanden case based on our current policy, and determine what to do about the email trust bit for that root CA.

Comment 46

[Frank Hecker]

Per my comments in the mozilla.dev.tech.crypto newsgroup, I am now formally approving inclusion of the DigiNotar Root CA certificate, for SSL and code signing purposes only. I am postponing approval for enabling of the email trust bit and enabling the root for EV use until such time as the outstanding issues related to email address validation and EV audit schedule are resolved to my satisfaction.

Comment 47

[Frank Hecker]

Filed bug 431621 against NSS to add the root, and marked it as blocking this bug. Also changed the status whiteboard.

Comment 48

[Nelson Bolyard (seldom reads bugmail)]

I have found some technical issues with some certs issued by Diginotar.
I found them while testing the cert chain for the server www.diginotar.nl

The first problem is minor.  The second problem is a complete stopper.

1) Minor: The Attribute Value Assertions for the Relative Distinguished names 
in the EV certificate subject name appear to be in reverse order from the 
standard.  As encoded in the certificate, they appear to be ordered with the most specific attribute value assertion first, and the most general one last.  

Note that the order in which the AVAs of a cert DN are commonly displayed is
the reverse of the order in which they are encoded.  Or, to say that another
way, when displaying the AVAs from a cert name, they are ordered right-to-left
with the first one in the cert being on the right and the last one on the left. 

The standard says that the AVAs in the cert itself must be ordered from 
most general (typically country) to most specific.  So, a typical order of
AVAs in a cert is something like
     Country
     STate
     Locality
     Organization
     Organizational Unit
     Common Name
but when displayed, these are displayed in this order:
   CN=xxx,OC=xxx,O=xxx,L=xxx,ST=XXX,C=XX

However, the order of the AVAs in the subject for the www.diginotar.nl 
cert appears to be the opposite, with Country encoded last.  It is encoded 
in the certificate in this order:

  OID.1.3.6.1.4.1.311.60.2.1.3=NL
  OID.1.3.6.1.4.1.311.60.2.1.1=Beverwijk,
  CN=www.diginotar.nl,
  serialNumber=34104947,
  OU=n.v.t.,
  OU=Extended Validation SSL Certificate - Zie CPS,
  L=Beverwijk Vondellaan 8 (0000),
  O=DigiNotar B.V. (0034104947),
  C=NL

This is a relatively minor issue for Mozilla PROVIDED THAT there is only 
one attribute of each type.  However, if the cert should contain multiple
Common Name attributes, this could be a problem.  Mozilla follows the RFC,
honoring only the most specific (last encoded) Common Name in a cert subject
name.  

2) Bigger problem, stopper for EV.
There is a technical problem with the OCSP responses for Diginotar's EV certs.
When checking an OCSP repsonse for an inquiry about a cert under test,
the cert that is used to sign the OCSP responses is required to be either 

- the cert for the issuer of the cert under test, that is, a cert whose 
subject name matches the issuer name in the cert under test, or 

- an OCSP responder cert (cert with a special Extended Key Usage) 
issued by the issuer for the cert under test; that is, a cert whose 
issuer name matches the issuer name in the cert under test.  

The issuer for the www.diginotar.nl server cert is:
   E=[e-mail],CN=DigiNotar Extended Validation CA,O=DigiNotar,C=NL

(Note that the AVAs in that name are in the expected order).
However the OCSP response signer cert has the following subject and issuer
names (shown here in display order, not in encoding order)

Issuer: 
   E=[e-mail],CN=DigiNotar Services CA,O=DigiNotar,C=NL

Subject: 
  CN=http://validation.diginotar.nl,
  OU=Maatwerk certficaat -zie CPS OCSP Signing,
  OU=Servercertificaat - zie CPS,
  L=Beverwijk vondellaan 8 (0000),
  O=DigiNotar B.V. (0034104947),
  C=NL

(Note that those names are encoded in the expected order).
Neither of those names matches the issuer name of the cert under test.
Consequently, this cert is not eligible to be a valid OCSP signer cert 
for the OCSP repsonse for that server cert.  

If the issuer name for the cert for www.diginotar.nl is typical of the 
issuer names in EV certs issued by Diginotar, and if the OCSP response's
signer cert is typical of the OCSP responses for Diginotar EV certs, then
all those EV responses will be found to be invalid.  

IMO, this is a serious issue.  Mozilla's CA policy is relevant here, IMO.

Comment 49

[Nelson Bolyard (seldom reads bugmail)]

Attachment: OCSP response - pretty printed, with signer cert

Here is the OCSP repsonse for the cert www.diginotar.nl, pretty printed.
The signer cert is embedded within it.

Comment 50

[Eddy Nigg (StartCom)]

(In reply to comment #48)
> 2) Bigger problem, stopper for EV.
> There is a technical problem with the OCSP responses for Diginotar's EV certs.
> When checking an OCSP repsonse for an inquiry about a cert under test,
> the cert that is used to sign the OCSP responses is required to be either 

Just to make it clear, it doesn't affect only EV but FF3 generally, since the default selection is to check with the OCSP responder. However I guess that they have enough time to fix this until then, second it's their subscribers suffering, FF3 will simply refuse to connect (as it happened to me, bug 431621). But we should have checked this before checking in the root, but not sure if this IS a stopper at all.

Comment 51

[Frank Hecker]

My position on this: (In reply to comment #48)
> I have found some technical issues with some certs issued by Diginotar.
> I found them while testing the cert chain for the server www.diginotar.nl
> 
> The first problem is minor.  The second problem is a complete stopper.

My comments below.

> 1) Minor: The Attribute Value Assertions for the Relative Distinguished names 
> in the EV certificate subject name appear to be in reverse order from the 
> standard.  As encoded in the certificate, they appear to be ordered with the
> most specific attribute value assertion first, and the most general one
> last.  
<snip>
> This is a relatively minor issue for Mozilla PROVIDED THAT there is only 
> one attribute of each type.  However, if the cert should contain multiple
> Common Name attributes, this could be a problem.  Mozilla follows the RFC,
> honoring only the most specific (last encoded) Common Name in a cert subject
> name.

Someone from DigiNotar needs to investigate and respond to Nelson's comments above, and in particular confirm that the configuration of DigiNotar's CA software is such that it would never generate multiple CN attributes.

> 2) Bigger problem, stopper for EV.
> There is a technical problem with the OCSP responses for Diginotar's EV certs.

Again, DigiNotar needs to investigate and respond. If this was just an EV problem then I would not be concerned, since DigiNotar is not approved for EV. However it sounds from Eddy's response (comment #50) that this is more a problem with Firefox 3 and OCSP checking in general.

> IMO, this is a serious issue.  Mozilla's CA policy is relevant here, IMO.

Agreed. In particular, if including DigiNotar's root in Firefox 3 causes problems due to the OCSP issue, and if no resolution is possible in the short term, then in my opinion we should remove DigiNotar's root as soon as practicable.

Comment 52

[Eddy Nigg (StartCom)]

Frank, please note that removing this root will have no effect whatsoever on DigiNotar, since their root is cross-signed by Entrust.

Comment 53

[Nelson Bolyard (seldom reads bugmail)]

The presence or absence of the new root makes no difference to the OCSP
issue, AFAICT.  

Ideally I would like us to be able to test a sampling of live https servers
with live EV certs from the new CAs before adding CA certs and/or EV enabling
them.  We would benefit from more compatibility testing.  

Comment 54

[Eddy Nigg (StartCom)]

In relation to that, I'd like to know how a CA can test EV certs it issues. However that's a different subject (still worth thinking about), but has no effect concerning OCSP. For OCSP EV doesn't have to be enabled.

Comment 55

[Erwann Abalea]

(In reply to comment #48)
> 1) Minor: The Attribute Value Assertions for the Relative Distinguished names 
> in the EV certificate subject name appear to be in reverse order from the 
> standard.  As encoded in the certificate, they appear to be ordered with the
> most specific attribute value assertion first, and the most general one last.  

I can't find any standard defining a specific order for the RDNs. I checked the X.509, X.501, RFC3280 and RFC2246.

[...]
> This is a relatively minor issue for Mozilla PROVIDED THAT there is only 
> one attribute of each type.

VeriSign affiliates generate SSL certificates containing several OU elements, for example, and that's not a problem.

> However, if the cert should contain multiple
> Common Name attributes, this could be a problem.  Mozilla follows the RFC,
> honoring only the most specific (last encoded) Common Name in a cert subject
> name.

The (informational) RFC 2818 doesn't say you need to get the last encoded commmonName entry. And yes, Mozilla follows this RFC in the sense that it checks if the subjectAltName extension is present, allowing several dNSName entries to be present.

Comment 56

[Kai Engert (:KaiE:)]

(In reply to comment #54)
> In relation to that, I'd like to know how a CA can test EV certs it issues.

You mean, test in the browser?

CAs are free to run local builds and include the blessing of their cert for EV in their own test build.

I had actually implemented a mechanism that allows to load EV blessings from an external text file stored in the profile, however, this feature is disabled in release builds. It requires a "debug mode" build.

Comment 57

[Eddy Nigg (StartCom)]

Thanks Kai! Some instructions where and which patches to apply would be helpful (somewhere on developer or wiki). However I'm not sure if every CA is capable of building their own.

Comment 58

[Kick Willemse]

To all,

Due to the fact of holiday season I am wrapping up all the discussions going on and give my feedback on this today, sorry for the delay. Feel free to add issues I missed, otherwise I hope I can get some comment on this.

1. No validation of email address. This discussion expanded to the EV Cabforum to be discussed probably during the face to face meeting in Oslo. 
2. Enabling Diginotar Root for e-mail. As discussed the DigiNotar Root is not enabled for e-mail at this moment of time. As long as Mozilla makes sure a straight policy on this is implemented in the near future, taking into account issue 1!
3. Staat der Nederlanden Root enabled for mail. I will leave this to Mozilla. If there is any need for feedback on the Dutch Market just let me know.
4. Our Root chain and Entrust. Our root is issued on a later date. I think our not before date of our top root is the newest. I know IE implemented this the same and there it causes no problem. Our top root is issued and valid not before: 16-05-2007. The Entrust top root is valid not before somewhere 1999. Our crossigned subroot is valid not before 26-7-2007 17:57:39. So it probably takes the crossigned subroot in stead of the toproot. So is this normal behaviour from FF? I would suggest you take the most pure top root... Any comments why IE works OK and also taking into account my date feedback?
5. OCSP Minor. As in comment 55. There is several good reasons to include extra ou fields and use a different order. We use the extra ou field for identifing the type of certificate because we think policy oid fields are to hidden for the end-user. The order of the subjectDname is because of publishing to an LDAP. This order helps us in organising our public certificate directory much better.. I can assure you we do not include more than one CN in our certificates, but I am uncertain if FF can always expect this looking at the standards.
6. OCSP Major. We are using an OCSP responder that is able to handle OCSP requests from multiple CA´s. Our default OCSP responder is issued from a sub CA (services) We have a single policy that allows us to issue an OCSP responder certificate conform our CPS. We do not accept issuing a responder certificate from our EV Sub CA and I see no reason for this, because they are both issued by the same topCA. So  why is FF not accepting signed responses from an OCSP server that handles a request issued from the same top root. In this case both certificates have the same issuer being the top root ca.... In your investigation you are only looking at the sub ca? (E=[e-mail],CN=DigiNotar Extended Validation CA,O=DigiNotar,C=NL <> E=[e-mail],CN=DigiNotar Services CA,O=DigiNotar,C=NL_

Kick

Comment 59

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 55,
X.501 section 9 makes this clear in several ways.  The most succinct is 
this statement:

   Each initial sub-sequence of the name of an object is also the name 
   of an object. The sequence of objects so identified, starting with 
   the root and ending with the object being named, is such that each 
   is the immediate superior of that which follows it in the sequence.

The first attribute in the sequence is said to be the "most general"
and the last is said to be the "most specific".  When an attribute
type appears more than once, the first occurrence is said to be the 
"most general" of the attributes of that type, and the last occurrence 
is said to be the "most specific" of the attributes of that type.

As long as a DN has only one attribute of each type, the order is 
unimportant for purposes of identifying the value of any attribute.
However, the need to choose the "most specific" common name (as specified
in RFC 2818) makes the order relevant.  It's true that RFC 2818 is 
informational, but it's also true that the browsers all honor it as a 
standard.

Comment 60

[Nelson Bolyard (seldom reads bugmail)]

I meant to add this URL for X.501:
http://www.itu.int/rec/T-REC-X.501-200102-I/e

Comment 61

[Frank Hecker]

(In reply to comment #52)
> Frank, please note that removing this root will have no effect whatsoever on
> DigiNotar, since their root is cross-signed by Entrust.

Sorry, I got the impression that the OCSP issue was in some way tied in to
DigiNotar's having its own root included vs. chaining to Entrust. So, as I
understand it, this is a DigiNotar problem with Firefox 3 no matter what. Given
that, I'll withdraw my prior comments (in comment #51), unless someone comes up
with a compelling reason why removing the DigiNotar root would make a real
difference with respect to the technical issues we're discussing.

On the issue of testing CA's EV certificates before adding them: Lack of an
easy mechanism to configure of EV status for a CA (e.g., to turn on EV status
for a CA and supply one or more EV policy OIDs) is a major shortcoming of our
current EV implementation. Hopefully we can get some development resources
looking at this for Mozilla 2.0 and Firefox 4 (or whatever it turns out to be
numbered).

Comment 62

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 58, item 4 (Kick's comment about dates on root certs):

For purposes of validating an SSL server cert (without regard to EV),
and for purposes of picking a chain to display to users in the dialog,
NSS in Firefox attempts to build a path from leaf to (some) trusted root.  

As it builds the path, for each cert it tries to find an issuer cert.
If it finds multiple issuers, all of which appear to be acceptable based on 
the constraints imposed by the subordinate cert (i.e., all are in their validity periods, and all have the same subject key ID, if the subordinate 
specifies an authority key ID), it chooses the "newest" cert from among those.  

It does not compare the dates of certs at different path distances from the 
EE cert.  It only compares dates among the direct issuers of a cert.  
If you have a CA for which multiple issuer certs exist, perhaps one being a
self-signed root and another being subordinate to another CA, and all are
acceptable (validity periods, key IDs, etc.) then it will always pick the
"newest" from among those certs.  It will not look at the dates of issuers
of issuers, for the purpose of choosing an immediate issuer.  In other words,
it only compares the dates on root CA certs if those certs are both potential
direct issuers of the same cert.

The determination of "newest" is based on the notBefore date, which is 
presumed to be the date of issuance.  If multiple certs have the exact same 
notBefore date, so that there is a tie for "newest", it chooses the one with 
the latest (most future) notAfter date. 

The algorithm used for validating certs for EV is different.  It is a second
step, performed after a cert has been validated for basic SSL service by the
algorithm described above.

Comment 63

[Kai Engert (:KaiE:)]

(In reply to comment #57)
> Some instructions where and which patches to apply would be helpful

http://wiki.mozilla.org/PSM:EV_Testing

Comment 64

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 58, item 6 (OCSP responses signature invalid),
The OCSP RFC, RFC 2560, says in section 4.2.2.2  Authorized Responders:

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. It is necessary however to
   ensure that the entity signing this information is authorized to do
   so.  Therefore, a certificate's issuer MUST either sign the OCSP
   responses itself or it MUST explicitly designate this authority to
   another entity.  OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-ad-ocspSigning value as
   described above. They MAY provide a means of locally configuring one
   or more OCSP signing authorities, and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

NSS rejects the OCSP response for the www.diginotar.nl server cert 
because the certificate required to validate the signature on the 
response fails to meet any of those criteria.

Comment 65

[Kick Willemse]

Nelson, Thank you for your comment. I have been looking at the rfc as well a few times but please find my enclosed comment (Which I was just typing)

I just have doubts looking at rfc 2560 our OCSP response certificate should match the EE certificate that is validated at the subCA certs level. In the end they are both issued by the same issuer (Top Root) 

Not that we don't
want to issue a matching subcert in technical sense, but from a legal
perspective (CPS) our auditors don't like the fact that for example we have to
issue an ocsp signer certificate from our EV Sub CA.

@ Frank, Besides all the other discussions on standards, policies etc. I see no
reason for not including our root within FF if OCSP is not working yet. 

There is a CDP as well and I think we should just classify this as a
temporarily issue. This could also happen if CA's ocsp services are down for
maintanance. As you might understand a working ocsp check is very important for
a CA. FF is just not presenting the website if OCSP fails. 

Comment 66

[Eddy Nigg (StartCom)]

(In reply to comment #65)

> Not that we don't
> want to issue a matching subcert in technical sense, but from a legal
> perspective (CPS) our auditors don't like the fact that for example we have to
> issue an ocsp signer certificate from our EV Sub CA.
> 

Can you explain a little bit more about this? What's the reasoning of your auditor?

Comment 67

[Kick Willemse]

I am waiting for an answer from Mozilla on the fact that if the certs (OCSP Signer and EE cert) are from the same top root why it fails. I think the rfc 2560 is not demanding the subca level to be the same.

Nevertheless I agree with our auditor that if we have a special subCA that is only restricted to issue EV type certificates. It is rather strange to issue an OCSP signer certificate from this root as well. This certificate must be conform the CPS of this subCA. For example the ocspNoCheck bit is turned on for the OCSP signer cert. Why issue certs from an EVSubCa that include extended key-usages or other extentions that are not allowed by the EV policy.. Our OCSP signer certificate needs to comply with another CPS and therefore we issue this from our Services subCA.

I hope this clarifies this a little more.

Comment 68

[Eddy Nigg (StartCom)]

Nelson, could you please compare the OCSP responses from other CAs such as Verisign and Network Solutions to that of DigiNotar? The comparison could highlight other issues or confirm common practice.

Comment 69

[Nelson Bolyard (seldom reads bugmail)]

RFC 2560 absolutely requires the OCSP response to come from the same 
issuer CA that issued the cert under test, or from a responder to whom 
that CA has delegated OCSP responsibility by issuing it a cert.
The passage from RFC 2560 that I quoted (in comment 64) says that very 
clearly, and more than once.  

NSS enforces that requirement, just exactly as RFC 2560 requires it to do. 
NSS works with all the major CAs that have OCSP responders.

Note that the CA can use its own CA cert as the OCSP responder cert.
It is not required to delegate that responsibility to another server.

Multiple CAs can delegate their responsibility to the same responder.
Each of them issues a cert to that responder.  The responder has 
multiple certs, and must use the right one when it signs the response.
All those certs could potentially have the same public key, although
I would not recommend that.

As for opinionated auditors, I suggest they be told that the choices are:
- conform to the standard, or 
- fail in the market place.  
The latter choice leaves them without a paying customer.  

Comment 70

[Kick Willemse]

Thank you for pointing this out again. I just miss the answer on my issue here. I try to understand the following:

"from the same issuer CA that issued the cert under test" or for delegation "This certificate MUST be issued directly to the responder by the cognizant CA"

If I define a top root ca as the issuer CA or cognizant CA, why would a signer cert from one sub ca and an ee cert from another subca fail. 

Hope you can point me to the right direction/ definition for "issuer CA" or "cognizant CA" not being the top root ca for this to understand that this is conform standards and convince the auditors on this.

Comment 71

[Nelson Bolyard (seldom reads bugmail)]

The designation of the issuer of a cert under test is not abstract.
The cert under test names its issuer.  The determination of whether a cert 
is or is not the issuer cert is something that can be directly tested based 
on the contents of the cert under test and the issuer cert, by comparing subject and issuer names.  

The phrase 
"Is the certificate of the CA that issued the certificate in question;"
implies, among other things, that the OCSP signer cert's subject name is 
the issuer name for the cert under test.  It means "is the CA cert with 
which the signature on the cert under test is verified."

The phrase "is issued by the CA that issued the certificate in question."
implies, among other things, the the OCSP signer cert's issuer name is the
same as the issuer name of the cert under test.  It means that the CA cert
used to verify the signature on the OCSP responder's cert is the same 
CA cert used to verify the signature on the cert under test.  

Think about this.  If it were not this way, if any CA whose cert chains
to the same root as the cert under test is allowed to be the OCSP responder 
for the cert under test, or to issue an OCSP responder cert for the 
responder for the cert under test, then any of the CAs whose certs have been 
cross-signed by Entrust could act as OCSP responders for your CAs.  Do you 
want your competitors to be able to act as OCSP responders for your CA?  
Do you trust them to do that?  Should your relying parties do so?

Comment 72

[Kick Willemse]

Thank you for the quick response. 

If these phrases "imply" that issuer subjectname is the same as the subject name of the issuer name of the EE cert I prefered that this was more clear within the rfc. I assume this is how industry is interpreting this and now at least we know. 

I think EKU's  and policy OID's are defined to prevent cross CA's to issue OCSP responder certs, besides the AIA is pointing to the responder. 

I agree with you on the potential risk, but maybe an ocsp validation service for other CA's could bring some extra paying customers. I think we can have good and long discussions on this. Look forward doing this with a beer in our hands, making applications more trustworthy.

Comment 73

[Kick Willemse]

I would like to dust off our EV application. Just a wrap up of the issues that were blocking previously:

1. Recent EVSSL Webtrust addendum
2. Functioning of OCSP not conform standard

As of the end of 2008 we have the renewed audit reports available. (Attached) and we solved the issues regarding OCSP and EV.

I hope this solves the snooker situation and makes it possible to finalise the application.

Kick

Comment 74

[Kick Willemse]

Attachment: PWC Audit Assertion

Comment 75

[Kick Willemse]

Attachment: Certificate Registry

Comment 76

[Kick Willemse]

Attachment: TTP.NL CA certified list

Comment 77

[Kick Willemse]

Could anyone assigned to this bug inform me on the progress?

Kick

Comment 78

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Proceeding with processing this request for EV-enablement of this root.

I have attached the Initial Information Gathering document which summarizes the information that has been gathered and verified as per
https://wiki.mozilla.org/CA:How_to_apply

Please review the attached document for accuracy and completeness.  Within the document the items highlighted in yellow indicate where further clarification is needed. I will also summarize below:

1) When I try to download the CRL http://service.diginotar.nl/crl/root/latestCRL.crl into Firefox I get the error ffffe009, which is equivalent to -8183, “Security library: improperly formatted DER-encoded message”, as per http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html. The way to remove this error is to change the encoding from PEM to DER.

2) What is the maximum time until the OCSP responders are updated to reflect end-entity revocation?
http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf Section 26(b):
“If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.”

3) Are any of the subordinate CAs operated by third-parties, such as the Private sub-CAs?
Please refer to https://wiki.mozilla.org/CA:SubordinateCA_checklist
Are any of the sub-CAs that are operated by third-parties are or will be EV enabled? If the answer is yes, then please refer to http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf section 7.b.1 and section 37b.

4) Are there any root CAs that have issued cross-signing certificates for this root CA

5) For testing purposes, we’ll need a website whose EV SSL cert chains up to this root. The following two URLs are redirecting back to http: https://www.diginotar.nl, https://www.diginotar.com/

6) Please review the latest potentially problematic practices at http://wiki.mozilla.org/CA:Problematic_Practices. For the relevant items, provide further information.

7) I need to confirm the authenticity of the WebTrust EV audit report, because it is provided by the CA and not posted on the auditors website or on the cert.webtrust.org website. Please provide email and contact information for the WebTrust CA auditor, A.J.M. de Bruijn RE RA at PricewaterhouseCoopers

Comment 79

[Kick Willemse]

1) At this moment the crl distributionpoint is pointing to a PEM based CRL. There is a CRL in DER available at: http://service.diginotar.nl/crl/root/latestCRLDER.crl. Is there a requirement for mozilla to have it in DER only and not supporting PEM for the CDP?
2) The OCSP service of DigiNotar contains the most accurate revocation information as possible. The CRL is published every half hour to the OCSP server. This is audited and approved by our auditors to be in line with the CABforum requirements. On which the provided EV statement is issued.
3) The subordinated CA's are operated as a managed PKI hosted in the Diginotar environment. There are no subordinates enabled for EV.
4) Like other CA's the Diginotar root CA is cross-signed by the Entrust CA to make sure the SSL certificates are trusted if the end-user is not using an EV enabled webbrowser. https://www.diginotar.nl/Portals/7/Rootcertificaten/DigiNotar%20Root%20CA%20Entrust.crt
5) You can test EVSSL on https://www.evssl.nl and https://www.polisdirect.nl
6)  
- Diginotar only issues wildcard SSL certificates if the organisation is validated. 
- In some cases Diginotar is issuing PKCS#12 files. PKCS#12 files are send in a secure way using certified snail-mail. Some end-user request this type of certificate because of back-up/ key archiving services.
- In some cases, for working functionality, it is an obligation to include a hostname in the subject altname, like outlook 2007 mail certificates. See: http://technet.microsoft.com/en-us/library/bb851505.aspx
7) As provided by private e-mail.

Comment 80

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #79)
> 1) At this moment the crl distributionpoint is pointing to a PEM based CRL.
> There is a CRL in DER available at:
> http://service.diginotar.nl/crl/root/latestCRLDER.crl. Is there a requirement
> for mozilla to have it in DER only and not supporting PEM for the CDP?

Yes, it's an IETF standard requirement.  RFC 5280 says, in section
4.2.1.13  CRL Distribution Points:

   If the DistributionPointName contains a general name of type URI, the
   following semantics MUST be assumed: the URI is a pointer to the
   current CRL for the associated reasons and will be issued by the
   associated cRLIssuer.  When the HTTP or FTP URI scheme is used, the
   URI MUST point to a single DER encoded CRL as specified in
   [RFC2585].  HTTP server implementations accessed via the URI SHOULD
   specify the media type application/pkix-crl in the content-type
   header field of the response.

Comment 81

[Kathleen Wilson]

Downloading the following CRL into Firefox also gives the ffffe009 error
http://service.diginotar.nl/crl/extendedvalidation/latestCRL.crl

I suspect that many of the CRLs for certs chaining up to this root have this problem and are not currently downloading correctly into Firefox. 

Note that the authenticity of the audit report has been confirmed via email exchanged with the auditor. The only remaining issue to be resolved before public discussion can proceed is that of DER encoding the CRLs.

Comment 82

[Kick Willemse]

DigiNotar started a change request with a minor impact classification. I think Diginotar is able to change the PEM CRL to a DER CRL conform standards within a week. I will inform you as soon as the CRL format is changed.

Comment 83

[Kick Willemse]

DigiNotar succesfully finished the CRL DER change in their infrastructure. I can confirm that all our CRL's at CDP locations are now in DER format.

Comment 84

[Kathleen Wilson]

I can now import this CRL into Firefox successfully
http://service.diginotar.nl/crl/extendedvalidation/latestCRL.crl

However,
http://service.diginotar.nl/crl/root/latestCRL.crl
still gives the ffffe009 error code when I try to import it into Firefox. Does it import correctly when you try it?

Comment 85

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #84)
> However, http://service.diginotar.nl/crl/root/latestCRL.crl still gives 
> the ffffe009 error code when I try to import it into Firefox. Does
> it import correctly when you try it?

No.  It's a PEM document (and coincidentally, it's missing the end-of-line characters on the last line).  We don't support PEM CRLs in Firefox.

Comment 86

[Frank Hecker]

Re-assigning this bug to Kathleen Wilson, since she's the person actively working on it.

Comment 87

[Kick Willemse]

I was to quick with the response. The Diginotar Team was still working on the CRL changes for the root levels. Every CDP should be in DER now.

Comment 88

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 89

[Kathleen Wilson]

This completed the Information Gathering and Verification phase of this request to EV-enable a root that is already included in NSS, as per

https://wiki.mozilla.org/CA:How_to_apply

This request is in the queue for public discussion at

https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
The Status column indicates which request is currently in discussion.

Comment 90

[Kathleen Wilson]

I am now opening the first public discussion period for this request from DigiNotar to EV-enable the DigiNotar Root CA root certificate which is already included in NSS.

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 “DigiNotar EV-Enablement Request”

Please actively review, respond, and contribute to the discussion.

Comment 91

[Kathleen Wilson]

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 DigiNotar’s request to enable the DigiNotar Root CA root certificate for EV. This root is already in the Mozilla root store.  The Websites and Code Signing trust bits are already enabled for this root. The Email trust bit is not requested.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by DigiNotar, 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]. DigiNotar appears to provide a service relevant to Mozilla users: It is a Dutch CA operating primarily in the Netherlands.

EV Policy OID: 2.16.528.1.1001.1.1.1.12.6.1.1.1

The certificate policies for DigiNotar are published on their website and listed in the entry on the pending applications list. The main document is the Certificate Practice Statement, which is provided in English.

http://www.diginotar.com/Portals/0/General%20terms/DigiNotar_CPS_3.5_-_EN.pdf

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

* Email: The Email trust bit is not requested.

* SSL: CPS section 4.3.2.6:“For an application for an SSL Server Certificate PLUS, an independent registration service checks whether the Client is registered as the owner of the domain name or the IP 
address provided. If it emerges that the domain name or the IP address provided belongs to another organisation than the Client, then the Client must provide a statement that demonstrates that permission has 
been obtained from this organisation to use the domain name and/or the IP address.” 
** CPS section 4.3.2.6.4:“For an application for an EV SSL Server Certificate, an independent registration service checks whether the Client is registered as the owner of the domain name of the IP address 
provided. For an application for an EV SSL Server Certificate, an extra control measure will be performed by telephone to the number provided by the Client. One goal of this check is to ensure that the telephone number provided is the same as the telephone number of the location where the company is operated. In any case, the above-mentioned controls and the other controls to be conducted are performed while talking into account the most recent guidelines in the ‘Guidelines for Extended Validation Certificates’ (drawn up by the CA/Browser Forum and published at: http://www.cabforum.org) which are set out as mandatory (and generally designated in the Guidelines by MUST) and taking into account the instructions in which certain issues are expressly forbidden (generally designated in the Guidelines by MUST NOT). To this extent, the Guidelines for Extended Validation Certificates apply directly to the issue of EV SSL Server Certificates.”

* Code: CPS section 4.3: “the registration of a company will be checked in the commercial register”

Section 8-10 [Audit]. Section 8-10 [Audit].  DigiNotar provided an audit report from PricewaterhouseCoopers that says that DigiNotar has completed an audit using the WebTrust EV criteria as of November, 2008. DigiNotar also provided a letter from PricewaterhouseCoopers that states compliance with ETSI TS 101.456. The auditor has confirmed the authenticity of these documents. 
** The WebTrust EV audit report noted one issue: “In the course of our examination, we noted that DigiNotar did not include the Business Category attribute in the certificates published in this period of 
time. This is due to early implementation of the certificate profile against the early version of the CAB Forum guidelines. According to DigiNotar management all new certificates will be issued against the 
new current certificate profile as defined in the CAB Forum guidelines. Furthermore, DigiNotar defined an action plan to address our audit findings.”

Section 13 [Certificate Hierarchy].  This root has five internally-operated, application-specific subordinate CAs: 
DigiNotar Public CA 2025 (non-qualified personal certificates), 
DigiNotar Qualified CA (qualified personal certificates), 
DigiNotar Services CA (SSL and object signing certificates), 
DigiNotar Extended Validation CA (EV certificates), and 
DigiNotar Private CA (CA certificates for organizational CAs). 

** This root does not have any subordinate-CAs that are operated by third parties.

** DigiNotar is cross signed by Entrust to make sure the EVSSL certs are basic trusted by older browsers, but there is no intention that these should go green under the Entrust Root. DigiNotar is just making use of the Root Flip/ SSL Beacon like many other EV SSL providers did in the first days of EVSSL. When chained to the Entrust Root the EV UI is not showing up in other browser. DigiNotar only wants the EV UI if it is chained to the DigiNotar EV sub root.

Other: 
* DigiNotar provides both OCSP and CRL. 
** CPS section 6.10.3: “The DigiNotar CRL used for the CRL validation  is never more than 25 (twenty-five) hours older than the current CRL.” 
** “The CRL is published every half hour to the OCSP server. This is audited and approved by our auditors to be in line with the CABforum requirements. On which the provided EV statement is issued.”

Potentially problematic practices: 

* The any policy OID is allowed in the EV subroot. 
** There are private sub CAs (special sub CAs for customers) linked to the DigiNotar Root CA. They are not linked to the DigiNotar EV sub CA. All of the private sub CAs are managed PKI customers using the DigiNotar Certificate Management System. DigiNotar has Policy OIDs in the private CAs. All Sub CA's have a policy OID: 2.16.528.1.1001.1.1.1.1.5.2.6.4
** The private CA is used for organizations to issue certificates for personal use, so key usage is restricted and these customers need to fulfill legal requirements to make sure they comply with the DigiNotar Root program audit rules. There are no CA certs signed by the private CA. All the private keys of the private CA's are hosted in DigiNotar premises. DigiNotar does the key generation and configures the allowed policies to issue the specific customer certificates. 

Based on this assessment I recommend that Mozilla approve the request to enable the DigiNotar Root CA root certificate for EV.

Comment 92

[Frank Hecker]

To Kathleen: Thank you for your work on this request.

To the representatives of DigiNotar: Thank you for your cooperation and your patience.

To all others who have commented on this bug and participated in the associated public discussion: Thank you for volunteering your time to assist in reviewing this CA request.

I have reviewed the summary and recommendation in comment #91, and on behalf of
the Mozilla project I approve the request from DigiNotar to enable the following root certificate for EV:

* DigiNotar Root CA

Kathleen, please do the following:

1. File the necessary bug against PSM for the EV enablement.
2. Mark this bug as dependent on the PSM bug.
2. When that bug is complete, change the status of this bug to RESOLVED FIXED.

Thanks in advance!

Comment 93

[Kathleen Wilson]

I have filed bug 493265 against PSM for the actual changes.

Comment 94

[Nelson Bolyard (seldom reads bugmail)]

I believe this bug was fixed by the checkin for 
Bug 493709 -  Combined EV enablement 
so I am resolving this bug as fixed.  
Please reopen it if it is not fixed.
I hope Kathleen doesn't mind me resolving these bugs.

Comment 95

[Kathleen Wilson]

Attachment: ETSI Certificate 2010

Saving for reference.

Comment 96

[Kathleen Wilson]

Attachment: DigiNotar CPS V3.5

Saving for reference.