Staat der Nederlanden Root Inclusion Request
Kathleen Wilson
der Nederlanden is the next request in the queue for public
discussion.
Staat der Nederlanden (the Netherlands national government CA) has
applied to add the “Staat der Nederlanden Root CA - G2” root
certificate and enable all three trust bits. The request is documented
in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=436056
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Staat%20der%20Nederlanden
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=407386
Noteworthy points:
* This is the next generation of the Staat der Nederlandend Root CA
that is currently in the Mozilla store.
* The CP and CPS documents are in Dutch. English translations of
certain sections have been provided and verified using Google
Translate, and have been included in the Summary of Information
Gathered and Verified document. The main documents are the CPS and CP
parts a, b, and c.
** CPS of the Policy Authority PKI Overheid
http://www.pkioverheid.nl/fileadmin/PKI/CPS_PA_PKIoverheid_v3.0.pdf
** CP Part 3a for employees of governmental organizations or
commercial companies
http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3a_v2.0.pdf
** CP Part 3b for SSL services of governmental organizations or
commercial companies
http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3b_v2.0.pdf
** CP Part 3c for personal use of civilians
http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3c_v2.0.pdf
* The PKIoverheid issues two internally operated subordinate CAs,
which issue subordinate CAs to CSPs. The CSPs are commercial and
governmental organizations.
*A summary of the information that has been gathered and verified for
each CSP is attached to the bug:
https://bugzilla.mozilla.org/attachment.cgi?id=407385
** Each CSP has to prove that it complies with ETSI TS 101 456 and the
Dutch law on electronic signatures.
** CSPs must conclude a contract with a representative of a government
organization or commercial company before issuing end-entity
certificates.
** The only reason that a CSP within the PKIoverheid creates a Sub-CA
is to differentiate between the different usages of certificates. This
means that, if applicable, a Sub-CA is created for certificates meant
for personal use (authentication, encryption and non-repudiation) and
a Sub-CA for certificates meant for services (e.g. SSL). Before a CSP
can create a Sub-CA they must have permission from the Policy
Authority (PA) of PKIoverheid, as is stated in CP Part 3a and 3c in
paragraph 9.12.2.2 and in Part 3b in paragraph 9.12.2.2. The PA grants
its permission by assigning a separate OID for the Sub-CA.
* The request is to enable all three trust bits for this root:
Websites, Email, and Code Signing.
* Verification of Domain Ownership/Control is specified in CP Part 3b:
The subscriber must demonstrate that the organization may carry this
name. The service MUST have a DNS name that the common name mentioned
as a fully-qualified domain name (see the definition in section 4).
The CSP MUST register with authorized (Stichting Internet Domain
Registration Netherlands (SIDN) or Internet Assigned Numbers Authority
(IANA)) check whether the subscriber is the owner of the domain.
* Verification of Email Address Ownership/Control: PKIoverheid does
not allow the email address to be included in the Subject.emailAddress
field. The email address is deprecated but permitted in the
SubjectAltName.rfc822Name field. CP Part 3a: If the e-mail address is
included in the certificate the CSP must: let the subscriber agree on
this by signing an agreement and; verify that the e-mail address
belongs to the domain of the subscriber.
* Verification of Code Signing Subscriber Identity: All CSPs perform
an extensive identity validation check and organizational validation
check regarding the (representative of the) subscriber (governmental
organization or commercial company) and the end-user. Details are
found in CP part 3b, and translations have been provided in the
Summary of Information Gathered and Verified.
* Test Certificate: https://www.pkioverheid.nl/fileadmin/PKI/PKI_certifcaten/staatdernederlandenorganisatieca-g2.crt
* Both CRL and OCSP will be provided under this root.
** The CP indicates that the CRL and OCSP update frequency for end-
entity certificates has to take place at least every 4 hours.
** The CSPs provide OCSP.
* Audit: Staat der Nederlanden was audited within the past year by
KPMG, using the WebTrust CA criteria. https://cert.webtrust.org/ViewSeal?id=683.
This G2 root is included in the audit report. The CSPs are also
audited annually. Links to their (ETSI TS 101 456) audits are provided
in the summary of CSP information (https://bugzilla.mozilla.org/
attachment.cgi?id=407385).
This begins the one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved. If there are
outstanding issues or action items, then an additional discussion may
be needed as follow-up.
Kathleen
Ian G
As far as I can see this CA purposed directly for issuance to government
orgs and employees. As they are the authority over those subjects as
well as the issuer of personal docs, this is the same thing as the
Japanese government CA.
Their audit framework looks complicated, but it seems to meet and exceed
"reasonablness" tests.
+1
iang
Eddy Nigg
> * Verification of Domain Ownership/Control is specified in CP Part 3b:
> The subscriber must demonstrate that the organization may carry this
> name. The service MUST have a DNS name that the common name mentioned
> as a fully-qualified domain name (see the definition in section 4).
> The CSP MUST register with authorized (Stichting Internet Domain
> Registration Netherlands (SIDN) or Internet Assigned Numbers Authority
> (IANA)) check whether the subscriber is the owner of the domain.
>
Is there a particular method about how domain ownership is confirmed?
How is this done when the subject is a company (e.g. how is the company
verified - the above description suggest by contract only) and how, if
the subject is an individual. A working DNS is hardly a requirement for
determining ownership.
> * Verification of Email Address Ownership/Control: PKIoverheid does
> not allow the email address to be included in the Subject.emailAddress
> field. The email address is deprecated but permitted in the
> SubjectAltName.rfc822Name field. CP Part 3a: If the e-mail address is
> included in the certificate the CSP must: let the subscriber agree on
> this by signing an agreement and; verify that the e-mail address
> belongs to the domain of the subscriber.
>
The Staat der Nederlanden CA has been know for quite some time to issue
S/MIME certificates without validating the email addresses in the
certificates. I would like to receive assurance that this issue has been
addressed sufficiently - the above comment doesn't suggest that it is.
In particular how do email addresses refer to S/MIME certificates (any
instance in the DN and SAN) when there is no email address included? How
can a subscriber receive an S/MIME certificate for gmail or other public
providers, as they are obviously not under control of the domain and
don't own the gmail.com domain? Can only domain owners receive S/MIME
certificates with an email address included and how is this verified
(similar to above)?
Additionally I believe at the moment email signing bit can not be
enabled since for example DigiNotar's email signing bit hasn't been
approved either, however this CA cross-signed the DigiNotar root. This
alone makes it very problematic, because depending on the chaining the
CA certificates, DigiNotar could issue and sign S/MIME certificates
without having been approved for it.
Another question which arises in this respect, were all the five
cross-signed or sub ordinate CAs and their respective CP/CPS examined
accordingly? Kathleen, why isn't this clearly mentioned in your message
for the discussion?
What are the requirements of the Staat der Nederlanden CA to add another
CA in a similar fashion in the future? Are all those CAs also audited
and included in the WebTrust report? I think this request must be
evaluated according to the sub ordinate CAs in this PKI and not by a
blanket approval through the parent CA. We have clearly seen issues
previously (not negative as such, just that certain trust bits were not
enabled) with some sub-ordinate CA of the Staat der Nederlanden CA.
There can't be approval of different CAs without proper assurances that
those CAs are set to the same standard and requirements than any other CA.
> * Both CRL and OCSP will be provided under this root.
> ** The CP indicates that the CRL and OCSP update frequency for end-
> entity certificates has to take place at least every 4 hours.
> ** The CSPs provide OCSP.
>
Do we have some test sites? Including all sub-ordinate and cross-signed CAs?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Policy Authority PKIoverheid
Thanks iang for your first reaction. Looking forward to other
comments...
Mark
Policy Authority PKIoverheid
Unfortunately this message includes some incorrect assumptions:
- “this CA cross-signed the DigiNotar root”. That is incorrect the
Staat der Nederlanden Root CA – G2 (and the Staat der Nederlanden Root
CA) is not cross-signed and will not be cross-signed with the
DigiNotar root (or any other root or CA). DigiNotar is one of the CSPs
within the governmental PKIoverheid hierarchy. Besides that they have
their own commercially based root. Both roots are unrelated to each
other;
- “……How is this done when the subject is a company (e.g. how is the
company verified - the above description suggest by contract only) and
how, IF THE SUBJECT IS AN INDIVIDUAL.” Up to this moment CSPs within
the PKIoverheid don’t issue certificates directly to individuals. For
further details see comment # 15 in bug 436056;
- “The Staat der Nederlanden CA has been know for quite some time to
issue S/MIME certificates without validating the email addresses in
the certificates.” I do not agree with this conclusion. This
information is based on other sources (bug 369357) and not verified
with PKIoverheid. Up to this moment CSPs within the PKIoverheid
hierarchy only issue certificates to subscribers (to be used by their
employees) within companies and governmental organizations and not
directly to individuals. If an email address is included in the
certificate then the subscriber has to be in control of the domain
(name). However I agree that our CP wasn’t very clear about this. This
has been resolved. See comment # 21 in bug 436056.
On your question:
Is there a particular method about how domain ownership is confirmed?
How is this done when the subject is a company (e.g. HOW IS THE
COMPANY VERIFIED - the above description suggest by contract only) and
how, if the subject is an individual.
Answer:
With regard to the situation if the subject is an individual I would
like to refer to my earlier remark about incorrect assumptions. On
your question how is the company verified I would like to refer to
comment # 8 in bug 436056. CSPs within the PKIoverheid hierarchy will
verify, on the basis of The Dutch Trade Register (http://www.kvk.nl/
english/traderegister/default.asp) whether the (representative of)
subscriber may represent the organization, whether the name of the
organization is true and whether the address of the organization is
correct. At the request of SSL certificates CSPs MUST (and will)
verify the records of the SIDN (aka www.domain-registry.nl) or the
Internet Assigned Numbers Authority(IANA)) whether the subscriber is
the owner of the domain name.
On your question:
In particular how do email addresses refer to S/MIME certificates (any
instance in the DN and SAN) when there is no email address included?
Answer:
I hope that I interpret the question correctly: it is not a necessity
to include an e-mail address in the certificate with regard to email
signing. See: http://support.microsoft.com/default.aspx?scid=kb;en-us;276597.
A disadvantage of this method is that you have to explain (much) more
to the end-user how to configure MS Outlook with regard to email
signing.
On your question:
How can a subscriber receive an S/MIME certificate for gmail or other
public providers, as they are obviously not under control of the
domain and don't own the gmail.com domain? Can only domain owners
receive S/MIME certificates with an email address included and how is
this verified
(similar to above)?
Answer:
Within the PKIoverheid hierarchy a subscriber can not receive an S/
MIME certificate for gmail or other public providers. The subscriber
can only receive an S/MIME certificate where he or she has the control
of the domain (name). For example: suppose the company Philips is a
subscriber. Then only S/MIME certificates will be issued to this
subscriber with email addresses including the domain @philips.com or
@philips.nl. On the question how this is verified see my answer
above.
On your question:
Another question which arises in this respect, were all the five cross-
signed or sub ordinate CAs and their respective CP/CPS examined
accordingly?
Answer:
I have to refer to my detailed and extensive explanations in bug
436056.
On your question:
What are the requirements of the Staat der Nederlanden CA to add
another CA in a similar fashion in the future? Are all those CAs also
audited and included in the WebTrust report?
Answer:
All future CSPs have to undergo an ETSI TS 101 456 audit and at the
same time in addition, a separate audit with regard to the PKIoverheid
requirements as stated in our CP, before they can enter the
PKIoverheid hierarchy and issue certificates. So they also have to
comply with the email and domain name validation requirements.
On your question:
Do we have some test sites? Including all sub-ordinate and cross-
signed CAs?
Answer:
As stated cross-signed CA’s are not applicable. See comment # 19 in
bug 436056 regarding a SSL certificate for testing purposes.
Regards
Mark
Eddy Nigg
On 10/31/2009 14:59 PM, Eddy Nigg: Unfortunately this message includes some incorrect assumptions: - “this CA cross-signed the DigiNotar root”. That is incorrect the Staat der Nederlanden Root CA – G2 (and the Staat der Nederlanden Root CA) is not cross-signed and will not be cross-signed with the DigiNotar root (or any other root or CA). DigiNotar is one of the CSPs within the governmental PKIoverheid hierarchy. Besides that they have their own commercially based root. Both roots are unrelated to each other;
- Its root was cross-signed by another included CA - but apparently this was NOT your CA.
- DigiNotar pointed to your CA as an example of not validating the email address but nevertheless having the email bit turned on.
- At last the bug comments suggested that DigiNotar and others are
part of your PKI, which apparently is not correct.
With regard to the situation if the subject is an individual I would like to refer to my earlier remark about incorrect assumptions. On your question how is the company verified I would like to refer to comment # 8 in bug 436056. CSPs within the PKIoverheid hierarchy will verify, on the basis of The Dutch Trade Register (http://www.kvk.nl/ english/traderegister/default.asp) whether the (representative of) subscriber may represent the organization, whether the name of the organization is true and whether the address of the organization is correct. At the request of SSL certificates CSPs MUST (and will) verify the records of the SIDN (aka www.domain-registry.nl) or the Internet Assigned Numbers Authority(IANA)) whether the subscriber is the owner of the domain name.
I hope that I interpret the question correctly: it is not a necessity to include an e-mail address in the certificate with regard to email signing. See: http://support.microsoft.com/default.aspx?scid=kb;en-us;276597. A disadvantage of this method is that you have to explain (much) more to the end-user how to configure MS Outlook with regard to email signing.
On your question: How can a subscriber receive an S/MIME certificate for gmail or other public providers, as they are obviously not under control of the domain and don't own the gmail.com domain? Can only domain owners receive S/MIME certificates with an email address included and how is this verified (similar to above)? Answer: Within the PKIoverheid hierarchy a subscriber can not receive an S/ MIME certificate for gmail or other public providers. The subscriber can only receive an S/MIME certificate where he or she has the control of the domain (name). For example: suppose the company Philips is a subscriber. Then only S/MIME certificates will be issued to this subscriber with email addresses including the domain @philips.com or @philips.nl. On the question how this is verified see my answer above.
Answer: All future CSPs have to undergo an ETSI TS 101 456 audit and at the same time in addition, a separate audit with regard to the PKIoverheid requirements as stated in our CP, before they can enter the PKIoverheid hierarchy and issue certificates. So they also have to comply with the email and domain name validation requirements.
On your question: Do we have some test sites? Including all sub-ordinate and cross- signed CAs? Answer: As stated cross-signed CA’s are not applicable. See comment # 19 in bug 436056 regarding a SSL certificate for testing purposes.
Policy Authority PKIoverheid
Your question:
I understand that the exact company details must be stated in the
WHOIS records and you match those details with the ones you verified.
Answer:
That is correct.
Your question:
Does your CA issue certificates to organizations not operating within
your country or which have TLD extensions other than .nl ?
Answer:
CSPs within the PKIoverheid only issue certificates to organizations
operating within the Netherlands. See CP part 3b
http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3b_v2.0.pdf for
the description of Subject.countryName. The fixed value is C=NL
according to ISO 3166. So I don’t have and I don’t know of any
PKIoverheid SSL certs with a different TLD then .nl
Your question/remark:
I'm unsure about how that should work, an S/MIME certificate without
an email address would not show up valid with Mozilla software, e.g.
Thunderbird.
Answer:
Please look to this instruction and test it your self. See chapter 3
page 10. The instruction is in Dutch but the print screens are in
English:
http://www.uziregister.nl/Images/Toelichting%20gebruik%20UZI-pas%20voor%20ondertekening%20e-mail_tcm19-12715.pdf
Your question:
Since you provide an OCSP responder, would it be possible to create a
server certificate in order to test the correct behavior of both, the
end-user certificate installed at a web site including chaining and
the OCSP responder? Please note that already approved CAs at this
very moment are not included and waiting until they can demonstrate
correct functioning of their certificates.
Answer:
Both our Staat der Nederlanden root CA and the Staat der Nederlanden
Root CA – G2 don’t support OCSP only CRL. Only CSPs within the
PKIoverheid hierarchy support OCSP with regard to end entity
certificates. I will contact one of our CSPs if they can provide a SSL
cert for testing purposes. I will inform you as soon as possible.
Regards
Mark
Eddy Nigg
> CSPs within the PKIoverheid only issue certificates to organizations
> operating within the Netherlands. See CP part 3b
> http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3b_v2.0.pdf for
> the description of Subject.countryName. The fixed value is C=NL
> according to ISO 3166. So I don’t have and I don’t know of any
> PKIoverheid SSL certs with a different TLD then .nl
>
Thanks for that explanation, that helps a lot!
> Answer:
> Please look to this instruction and test it your self. See chapter 3
> page 10. The instruction is in Dutch but the print screens are in
> English:
> http://www.uziregister.nl/Images/Toelichting%20gebruik%20UZI-pas%20voor%20ondertekening%20e-mail_tcm19-12715.pdf
>
OK, I had a good look on that document. One of the images regarding
Thunderbird is a bit ambitious I think, it seems as it's reported as
valid, but the underlying certificate has an email address in it. The
others don't have an email address.
However the other images clearly confirm my understanding that those
certificates will never work as S/MIME, neither by the key usage nor
practical because of the missing email field. It's impossible to send an
encrypted message to a holder of the certificates your CA issues.
In this respect my recommendation is not to enable the email trust bit -
as it hasn't been enabled for DigiNotar either. I do however highly
recommend a change in your policies and implementations in order to
confirm to the Mozilla CA Policies requirements of email validation and
make your client certificates actually work for S/MIME.
Additionally I suggest to consider removing the email trust bit of the
already included Staat der Nederlanden root, or create a tracking item
in case Staat der Nederlanden CA is interested in changing its policies
and implementations in order to conform to the basic requirements for
S/MIME.
> Both our Staat der Nederlanden root CA and the Staat der Nederlanden
> Root CA – G2 don’t support OCSP only CRL. Only CSPs within the
> PKIoverheid hierarchy support OCSP with regard to end entity
> certificates. I will contact one of our CSPs if they can provide a SSL
> cert for testing purposes. I will inform you as soon as possible.
>
I think this item is possible to be tracked at the bug. Thanks Mark for
your cooperation and speedy answers!
Ian G
>> Answer:
>> Please look to this instruction and test it your self. See chapter 3
>> page 10. The instruction is in Dutch but the print screens are in
>> English:
>> http://www.uziregister.nl/Images/Toelichting%20gebruik%20UZI-pas%20voor%20ondertekening%20e-mail_tcm19-12715.pdf
>>
>
> OK, I had a good look on that document. One of the images regarding
> Thunderbird is a bit ambitious I think, it seems as it's reported as
> valid, but the underlying certificate has an email address in it. The
> others don't have an email address.
>
> However the other images clearly confirm my understanding that those
> certificates will never work as S/MIME, neither by the key usage nor
> practical because of the missing email field. It's impossible to send an
> encrypted message to a holder of the certificates your CA issues.
So Tbird sees it as a no-op. Is there a harm here?
> In this respect my recommendation is not to enable the email trust bit -
> as it hasn't been enabled for DigiNotar either. I do however highly
> recommend a change in your policies and implementations in order to
> confirm to the Mozilla CA Policies requirements of email validation and
> make your client certificates actually work for S/MIME.
I'm also unsure what the point of client certificates in email is
without the email address. I think it is probably worth following the
mainstream notion of including the email address. But I'm not sure what
the policy interest here is.
Certificates should be capable of asserting a claim over the
information; email address or name or other more Brandsian claims,
whichever, I hope there is more of a basis for discrimination than
simply "wot the rest do"?
Is there a definition of what the email "trust" bit signifies?
> Additionally I suggest to consider removing the email trust bit of the
> already included Staat der Nederlanden root, or create a tracking item
> in case Staat der Nederlanden CA is interested in changing its policies
> and implementations in order to conform to the basic requirements for
> S/MIME.
Well, that might be convenient in this case, but it might also open a
can of worms with all the other existing unreviewed roots?
iang
Eddy Nigg
So Tbird sees it as a no-op. Is there a harm here?
I'm also unsure what the point of client certificates in email is without the email address. I think it is probably worth following the mainstream notion of including the email address. But I'm not sure what the policy interest here is.
- 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;
To be used for digitally signing and/or encrypting email messages.....controls the email account associated with the email address referenced in the certificate....
There is no signing and/or encrypting of email messages possible without an email address - and the email address has to be verified...without an email address it's not a certificate to be used for signing and encrypting email messages...maybe something else about which we don't care....anyway...
Is there a definition of what the email "trust" bit signifies?
Signing
Key Encipherment
Data Encipherment
E-mail protection
Well, that might be convenient in this case, but it might also open a can of worms with all the other existing unreviewed roots?
There is no point in denying a trust bit, if another root from the same CA and which conforms to the same policy has the trust bit set on...it's very easy to circumvent any decision taken here. As such, we've been patiently waiting for some CA to take their turn...
Policy Authority PKIoverheid
Many thanks for your comments.
The reason why PKIoverheid deprecated the use of an email address is
because of security concerns. Firstly, including an email address in a
certificate severely weakens the PKI model with regard to privacy.
Secondly, including email addresses in certificates can lead to spam
attacks. These are the ONLY reasons why there is a CSP within the
PKIoverheid that does not include email addresses in S/MIME
certificates to be used by end-users. It’s out of the question that
this is done to bypass Tbird in some illegal manner as was implicitly
suggested in some previous postings.
Furthermore the applicable RFC standard 3850 Secure/Multipurpose
Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling:
http://www.rfc-archive.org/getrfc.php?rfc=3850&tag=Secure%2FMultipurpose-Internet-Mail-Extensions-%28S%2FMIME%29-Version-3.1-Certificate-Handling
allows the email address NOT to be included in the S/MIME certificate.
In chapter 3 it is stated that “End-entity certificates MAY contain an
Internet mail address as described in [RFC 2822].” And that “Receiving
agents MUST recognize and accept certificates that contain no email
address.” The Mozilla policy appears not to be consistent with this
standard.
Nevertheless PKIoverheid recognize the fact that it is common practice
to include email addresses in S/MIME certificates because this is the
default situation for most applications like Tbird and Outlook. That
is why the email address is deprecated BUT permitted in the
SubjectAltName.rfc822Name field.
Conclusion:
If the email address is included in the certificate than our CP
requires that the CSP MUST: let the subscriber agree on this by
signing an agreement and; verify that the e-mail address belongs to
the domain of the subscriber. To my opinion this complies with the
Mozilla policy.
If the email address is not included in the S/MIME certificate than
this does not comply with the Mozilla policy. However not including an
email address is consistent with the applicable RFC standard and is
done because of legitimate reasons (security concerns with regard to
privacy, spam). Furthermore Microsoft wrote an official support
document on this which emphasizes that this is a legitimate and
workable procedure.
Because of these reasons I want to ask you to reconsider your
recommendation not to enable the email trust bit for the Staat der
Nederlanden Root CA and Staat der Nederlanden Root CA – G2.
Awaiting you reply.
Regards,
Mark
Ian G
> On 11/02/2009 18:31 PM, Eddy Nigg:
>
> Many thanks for your comments.
>
> The reason why PKIoverheid deprecated the use of an email address is
> because of security concerns. Firstly, including an email address in a
> certificate severely weakens the PKI model with regard to privacy.
> Secondly, including email addresses in certificates can lead to spam
> attacks. These are the ONLY reasons why there is a CSP within the
> PKIoverheid that does not include email addresses in S/MIME
> this is done to bypass Tbird in some illegal manner as was implicitly
> suggested in some previous postings.
>
> Furthermore the applicable RFC standard 3850 Secure/Multipurpose
> Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling:
> http://www.rfc-archive.org/getrfc.php?rfc=3850&tag=Secure%2FMultipurpose-Internet-Mail-Extensions-%28S%2FMIME%29-Version-3.1-Certificate-Handling
> allows the email address NOT to be included in the S/MIME certificate.
> Internet mail address as described in [RFC 2822].� And that �Receiving
> agents MUST recognize and accept certificates that contain no email
> standard.
Assuming that the email address in S/MIME client certs is optional, and
that Tbird does not handle this well, a very good next step would be to
file a bug on bugzilla quoting the above.
I understand the European context and I understand approximately where
this is coming from. My view (whether I like it or not) is that this is
not going to go away; European CAs are going to continue issuing
certificates according to their way, not the north american way.
So at the minimum this is something that should be debated in a
professional manner. Best place for that is the bugzilla bug post
because it maintains the entire context better than this mailing list.
> Nevertheless PKIoverheid recognize the fact that it is common practice
> to include email addresses in S/MIME certificates because this is the
> default situation for most applications like Tbird and Outlook. That
> is why the email address is deprecated BUT permitted in the
> SubjectAltName.rfc822Name field.
>
> Conclusion:
> If the email address is included in the certificate than our CP
> requires that the CSP MUST: let the subscriber agree on this by
> signing an agreement and; verify that the e-mail address belongs to
> the domain of the subscriber. To my opinion this complies with the
> Mozilla policy.
> If the email address is not included in the S/MIME certificate than
> this does not comply with the Mozilla policy. However not including an
> email address is consistent with the applicable RFC standard and is
> done because of legitimate reasons (security concerns with regard to
> privacy, spam). Furthermore Microsoft wrote an official support
> document on this which emphasizes that this is a legitimate and
> workable procedure.
I suggest that this particular policy question of demanding an email
address to be in a client certificate (for or not for this purpose)
should be deferred until above.
> Because of these reasons I want to ask you to reconsider your
> recommendation not to enable the email trust bit for the Staat der
> Nederlanden Root CA and Staat der Nederlanden Root CA � G2.
I think that is a fair request to reconsider.
As the lack of an email address does not markedly effect the overall
reliance equation of the end-user (she can't rely on what's not there,
and the Tbird result is a bug/operational issue that should be fixed
regardless) ... the only thing that holds it back is a questionable
policy prescription.
iang
PS: Mark, can you send my an email signed by a certificate without an
email address? It would be good to see what Tbird did in that case.
Eddy Nigg
On 11/02/2009 18:31 PM, Eddy Nigg: Many thanks for your comments.
The reason why PKIoverheid deprecated the use of an email address is because of security concerns. Firstly, including an email address in a certificate severely weakens the PKI model with regard to privacy.
Secondly, including email addresses in certificates can lead to spam attacks.
We are talking here about enabling the email trust bit, speak S/MIME.
These are the ONLY reasons why there is a CSP within the PKIoverheid that does not include email addresses in S/MIME certificates to be used by end-users.
Furthermore the applicable RFC standard 3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling: http://www.rfc-archive.org/getrfc.php?rfc=3850&tag=Secure%2FMultipurpose-Internet-Mail-Extensions-%28S%2FMIME%29-Version-3.1-Certificate-Handling allows the email address NOT to be included in the S/MIME certificate. In chapter 3 it is stated that “End-entity certificates MAY contain an Internet mail address as described in [RFC 2822].” And that “Receiving agents MUST recognize and accept certificates that contain no email address.” The Mozilla policy appears not to be consistent with this standard.
If the email address is included in the certificate than our CP requires that the CSP MUST: let the subscriber agree on this by signing an agreement and; verify that the e-mail address belongs to the domain of the subscriber. To my opinion this complies with the Mozilla policy.
If the email address is not included in the S/MIME certificate than this does not comply with the Mozilla policy. However not including an email address is consistent with the applicable RFC standard and is done because of legitimate reasons.
I doubt about the reasons, but I think we should weigh the benefit first. If the vast majority of certificates will not have an email address included, you probably should advise about the limitations. Certainly your document is somewhat misleading.
Because of these reasons I want to ask you to reconsider your recommendation not to enable the email trust bit for the Staat der Nederlanden Root CA and Staat der Nederlanden Root CA – G2
Ian G
> On 11/05/2009 01:36 PM, Policy Authority PKIoverheid:
>> On 11/02/2009 18:31 PM, Eddy Nigg:
>> These are the ONLY reasons why there is a CSP within the
>> PKIoverheid that does not include email addresses in S/MIME
>> certificates to be used by end-users.
>
> The certificates you issue aren't really S/MIME certificates either,
> since they are lacking the required key usages.
Which ones are required?
>> Furthermore the applicable RFC standard 3850 Secure/Multipurpose
>> Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling:
>> http://www.rfc-archive.org/getrfc.php?rfc=3850&tag=Secure%2FMultipurpose-Internet-Mail-Extensions-%28S%2FMIME%29-Version-3.1-Certificate-Handling
>> allows the email address NOT to be included in the S/MIME certificate.
>> In chapter 3 it is stated that “End-entity certificates MAY contain an
>> Internet mail address as described in [RFC 2822].” And that “Receiving
>> agents MUST recognize and accept certificates that contain no email
>> address.” The Mozilla policy appears not to be consistent with this
>> standard.
>>
>
> The RFCs allow many things in theory, however there is no point in
> issuing an S/MIME certificates without an email address.
No, that's not true. The point here is quite clear: the relying party
can rely on the Name that is presented, and presumably verified by the CA.
The name is in many senses dominating, as it is far more useful than
some random hotmail account. E.g., an email address is not accepted in
court as anything in particular, whereas a name is.
> Against which
> validation should the application check?
It probably shouldn't be checking unless the optional header-protection
thing is enabled in RFC3851:
3.1. Preparing the MIME Entity for Signing, Enveloping or Compressing
S/MIME is used to secure MIME entities. A MIME entity can be a sub-
part, sub-parts of a message, or the whole message with all its sub-
parts. A MIME entity that is the whole message includes only the
MIME headers and MIME body, and does not include the RFC-822 headers.
Note that S/MIME can also be used to secure MIME entities used in
applications other than Internet mail. If protection of the RFC-822
headers is required, the use of the message/rfc822 MIME type is
explained later in this section.
Later:
In order to protect outer, non-content related message headers (for
instance, the "Subject", "To", "From" and "CC" fields), the sending
client MAY wrap a full MIME message in a message/rfc822 wrapper in
order to apply S/MIME security services to these headers. It is up
to the receiving client to decide how to present these "inner"
headers along with the unprotected "outer" headers.
http://www.isi.edu/in-notes/rfc3851.txt
The application checks the certificate is signed correctly, and presents
that information to the relying party. In this case, the information
needs no more checking, it is up to the relying party.
In general PKI, there is no need for the application to check the
consistency, it just happens to be that an email client can check that
an email address in the headers happens to match the one in the cert.
But it is likely not a problem if the email addresses don't match,
because the cert info is dominating. A warning might be warranted, but
the click-thru-to-doom approach from firefox certainly isn't.
> And if the user must "accept"
> the certificate anyway, there are no trust bits needed either. More than
> that, most applications will not be able to sign, encrypt and
> counter-encrypt with such a certificate.
The fact that applications might not be able to do anything with it is a
separate issue from whether this does anyone any harm.
Mozilla could decide that clause 4 should be invoked, or clause 6. Sure.
But it would be good to establish what the harm is here to the end users
of Mozilla before we wield the policy like a blunt instrument.
>> If the email address is included in the certificate than our CP
>> requires that the CSP MUST: let the subscriber agree on this by
>> signing an agreement and; verify that the e-mail address belongs to
>> the domain of the subscriber. To my opinion this complies with the
>> Mozilla policy.
>>
> I would also inquire regarding the key usage extensions of your client
> certs. What does your CA policy say about it?
>
>> If the email address is not included in the S/MIME certificate than
>> this does not comply with the Mozilla policy. However not including an
>> email address is consistent with the applicable RFC standard and is
>> done because of legitimate reasons.
>
> I doubt about the reasons, but I think we should weigh the benefit
> first. If the vast majority of certificates will not have an email
> address included, you probably should advise about the limitations.
> Certainly your document is somewhat misleading.
Do you mean, the CPS should probably advise users that clients might not
like it? That's a commercial issue, outside our scope, I think.
>> Because of these reasons I want to ask you to reconsider your
>> recommendation not to enable the email trust bit for the Staat der
>> Nederlanden Root CA and Staat der Nederlanden Root CA – G2
>
> I suggest that we evaluate this together with you and Kathleen
> eventually. I'd recommend to actually implement a policy which would
> require email addresses for S/MIME certificates, if this is the purpose
> of these certificates.
Eddy, can you point to any doco that says that S/MIME certificates must
include the email address? And that the email address has to be checked
against the cert? And a mismatch here strikes down the S/MIME message?
> If it's not, then perhaps you should honestly
> agree that those certificates aren't meant for this purpose, specially
> in case your certificates don't have the required key extensions anyway
> (which I suspect is the case).
OK, that might be an other issue.
iang
Eddy Nigg
Which ones are required?
I mentioned it already;
Signing
Key Encipherment
Data Encipherment
E-mail protection
The RFCs allow many things in theory, however there is no point in
issuing an S/MIME certificates without an email address.
No, that's not true. The point here is quite clear: the relying party can rely on the Name that is presented, and presumably verified by the CA.
Sure, but that's not a unique property. How many Hans Muller, John Smith and Moshe Cohen are there? How should the application differentiate and confirm that this is the one you intended to talk to without a unique property?
In S/MIME certificates this is the VERIFIED email address. There should be only one possible.
The name is in many senses dominating, as it is far more useful than some random hotmail account.
E.g., an email address is not accepted in court as anything in particular, whereas a name is.
http://www.isi.edu/in-notes/rfc3851.txt
The application checks the certificate is signed correctly, and presents that information to the relying party. In this case, the information needs no more checking, it is up to the relying party.
The RFCs allow also some very different usages for x509 certificates, the implementation varies from case and application (am I a browser or VPN connection?)! Hence your argument is not valid.
In general PKI, there is no need for the application to check the consistency, it just happens to be that an email client can check that an email address in the headers happens to match the one in the cert. But it is likely not a problem if the email addresses don't match, because the cert info is dominating. A warning might be warranted, but the click-thru-to-doom approach from firefox certainly isn't.
But it would be good to establish what the harm is here to the end users of Mozilla before we wield the policy like a blunt instrument.
Eddy, can you point to any doco that says that S/MIME certificates must include the email address?
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;
And a mismatch here strikes down the S/MIME message?
Policy Authority PKIoverheid
Hi Eddy,
Our use of the KeyUsage attributes complies with paragraph 4.2.1.3. in
RFC 5280 (http://www.ietf.org/rfc/rfc5280.txt). So we use;
- the digitalSignature bit (for authentication services);
- the nonRepudiation bit (to provide a non-repudiation service);
- the keyEncipherment bit (for enciphering private or secret keys);
- the dataEncipherment bit (for directly enciphering raw user data);
- optional the keyAgreement bit may be used in combination with the
keyEncipherment bit and dataEncipherment bit.
See our CP part 3a (http://www.pkioverheid.nl/fileadmin/PKI/pve/
PvE_deel3a_v2.0.pdf) on page 34.
So to my opinion our certificates can be considered as S/MIME
certificates because they posses the required KeyUsages. In addition:
E-mail protection is not a KeyUsage bit but an ExtKeyUsage bit.
A lot of writing has been going on between you and iang. At this
moment I have no further comments on that. Generally I have to say I
agree with iang on most of the subjects. That doesn’t mean I
disrespect your opinion nor that I disrespect the Mozilla policy on
this subject.
Can we get to some final conclusion(s)?
Regards
Mark
Eddy Nigg
> A lot of writing has been going on between you and iang. At this
> moment I have no further comments on that. Generally I have to say I
> agree with iang on most of the subjects.
Which isn't surprising ;-)
But that's entirely OK, as you want to have the trust bit obviously set on.
> Can we get to some final conclusion(s)?
>
I expect Kathleen to finalize the discussion soon and she will come to a
decision eventually. In any case I thank you for your cooperation, your
involvement has been very positive and professional!
Kathleen Wilson
1) Email trust bit
My current inclination is to not enable the email trust bit, and to
only enable the websites and code signing trust bits.
My understanding is that some of the Staat der Nederlanden CSPs
include an email address for authentication (access control) purposes
within government organizations or commercial companies. However, I
don’t believe that this explains the need for the email trust bit to
be enabled.
I ask that Staat der Nederlanden reconsider their request to enable
the email trust bit. Please let me know if/what hardship not enabling
the email trust bit in NSS will cause.
2) OCSP
Due to recent activities with other CAs in regards to OCSP, I would
like to work with Staat der Nederlanden to confirm that OCSP works
within Firefox for all of the CSP’s under this root and the old root.
I will file a separate bug for this action item.
Kathleen
Kyle Hamilton
> On 11/05/2009 07:17 PM, Ian G:
>
> Which ones are required?
>
>
> I mentioned it already;
>
> Signing
> Key Encipherment
> Data Encipherment
> E-mail protection
>
>
> The RFCs allow many things in theory, however there is no point in
> issuing an S/MIME certificates without an email address.
>
>
>
> No, that's not true. The point here is quite clear: the relying party can
> rely on the Name that is presented, and presumably verified by the CA.
The relying party can also, as is currently done, keep that user's
certificate and compare keys as well as certificate contents. (A way
to query for an updated certificate from that CA for that person would
be WONDERFUL, though.) Besides, there's an extension which allows the
CA and clients to differentiate between multiple certificates with the
same name: the CA generates a GUID for the name and includes it.
CAcert used to put this in the Subject, and I don't know if it still
does, but the capability exists.
If we're talking about a set of building blocks, why can't we create
the aspects that we need? (Oh, that's right, because we're stuck
dealing with commercial certifying authorities built under X.509 --
which allows the CA to charge a premium for allowing certain
certificate usages simply by refusing to mint one which has the
desired usage without the payment of some usually-exorbitant fee --
who can't change their CPSes all that easily -- and a bunch of people
who have been kow-towing to them for so long that they can't see any
other possibilities, such as the user being able to use his own key
any way he wants for any purpose he wants.) This is why I will never
implement PKIX, and I don't think anyone else should either.
This includes Mozilla.
> Sure, but that's not a unique property. How many Hans Muller, John Smith and
> Moshe Cohen are there? How should the application differentiate and confirm
> that this is the one you intended to talk to without a unique property?
>
> In S/MIME certificates this is the VERIFIED email address. There should be
> only one possible.
How many email addresses can one person VERIFY? As many as he can
generate. Your insistence on including the email is actually a
sticking point: mail that's sent to the generic address in there is
automatically moved to spam, unless it's someone I've whitelisted --
and I don't check the spam that often. Only when I expect something
interesting.
Otherwise, that S/MIME cert is completely useless. I've managed to
communicate with you (Eddy) and Ian with it, and authenticate to
Startcom's servers. Big whoopdee do. Now, do something interesting:
> The name is in many senses dominating, as it is far more useful than some
> random hotmail account.
>
> Yes correct. It's very similar to the domain name space. I can create
> countless of domains and sub domains, it always remains the unique verified
> property. What the domain names referenced in the certificates are for
> server certificates, is the email address for S/MIME. This is what the
> application verifies.
Ah, but how many people have the namespace 'Hamilton'? Or 'Brown'?
Or 'Chin'? Where is the root of the namespace, anyway? The country?
The city? The locality? Given that lack of knowledge, how am I
supposed to accept what the CA seems to say?
> E.g., an email address is not accepted in court as anything in particular,
> whereas a name is.
>
> S/MIME certificates are for email messages, not courts. They might be used
> at court, but that depends on the local legislation if an email message
> signed or unsigned has any meaning. It's not what we care about here at the
> moment.
>
> http://www.isi.edu/in-notes/rfc3851.txt
>
> The application checks the certificate is signed correctly, and presents
> that information to the relying party. In this case, the information needs
> no more checking, it is up to the relying party.
If by "presents" you mean "is completely silent when things work, but
you've got the Vista-like, modal "THIS IS FAKE (for some unspecified
reason). Do you want to read this?" when there's an error?
> If you don't mind, the application, in our case is for example, Thunderbird
> and it checks against the email address. It presents an error to the user in
> case the email address doesn't match (amongst other errors which can occur).
This is a bug. Applications MUST be prepared to deal with
non-matching and non-existent email addresses in certificates.
> The RFCs allow also some very different usages for x509 certificates, the
> implementation varies from case and application (am I a browser or VPN
> connection?)! Hence your argument is not valid.
Your argument is, oddly, THE reason to do away with eKU. It's
inconsistently applied and utterly stupid (why is it that webservers
have "Web Client" in their eKU as well as "Web Server"?)
> In general PKI, there is no need for the application to check the
> consistency, it just happens to be that an email client can check that an
> email address in the headers happens to match the one in the cert. But it is
> likely not a problem if the email addresses don't match, because the cert
> info is dominating. A warning might be warranted, but the
> click-thru-to-doom approach from firefox certainly isn't.
>
> Here my discussion stops.
>
> But it would be good to establish what the harm is here to the end users of
> Mozilla before we wield the policy like a blunt instrument.
>
> Yes, and this is exactly hat you have been asking various times and again -
> if it's in the policy. Yes it is.
>
>
> Eddy, can you point to any doco that says that S/MIME certificates must
> include the email address?
>
> http://www.mozilla.org/projects/security/certs/policy/
>
> 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;
>
> There is no other clause saying "for S/MIME certificates which don't include
> an email address" - because that's the only assumed usage which works with
> Mozilla applications.
>
>
> And a mismatch here strikes down the S/MIME message?
>
> You can check that with your own Thunderbird if you want.
If it fails, report it as a standards-compliance bug.
-Kyle H
Ian G
> There are two remaining open items in this discussion:
>
> 1) Email trust bit
>
> My current inclination is to not enable the email trust bit, and to
> only enable the websites and code signing trust bits.
>
> My understanding is that some of the Staat der Nederlanden CSPs
> include an email address for authentication (access control) purposes
> within government organizations or commercial companies. However, I
> be enabled.
>
> I ask that Staat der Nederlanden reconsider their request to enable
> the email trust bit. Please let me know if/what hardship not enabling
> the email trust bit in NSS will cause.
I must admit, I have trouble understanding where this is going. Here's
my understanding.
1. No demonstrable harm to end-users has been indicated as far as I can
see. In the absence of some harm, I am not convinced that the customer
needs to "explain its need" for the email bit more than it has done.
2. We are in the presence of a material difference between the policy
and the applicable RFC. Clearly the policy suggests the presence of an
email address is important.
The RFC does not care, indeed it is probably out of scope; it doesn't
say so because it was probably deemed obvious to anyone who can
understand the subject matter. This is more clearly indicated in that
as an afterthought, there is an optional extension added in the later
document to protect "headers" but again no language to suggest any
headers are "checked".
3. Tbird and likely other email clients probably check the email
address. Why? The usage case here is not clear. By suggesting that an
email cannot come from the authenticating client cert, they are relating
two things that the RFC never said.
I would suggest that they do this because they can. And they've not
been called on it because client cert usage is so low (because of these
and like issues) that we are all living in our own theory world.
4. Reliance on an email address is mostly limited to technical issues
in most CPSs (e.g., the email address responds to a ping check). Nor is
it particularly expected to effect court, the bottom line in authentication.
5. Reliance on a Name is more defined in CPSs; in that you there is an
expectation that you can rely that this is a person and the person bears
some evidence of the name. The implication is also that you are dealing
with the right person. In court, this is highly relevant.
6. It is in the mission that Mozilla follows the standards. I don't
particularly like that because the standards can be wrong too, but it
has always been Mozilla's answer that they outsource the writing of
standards and architecture to others.
This means that when someone implements a product *according to the
standard* then they have a reasonable expectation that they can
communicate with other implementors of the standard. Adding additional
conditions is known as "embrace and extend" and it is a common criticism
of Microsoft.
7. The business context of client certificates in email can be
considered to be a disaster, a canonical case of theory before practice,
and end-user / market rejection. Small tweaks won't make much
difference, massive change is needed at all levels to make client certs
suitable for mainstream adoption. Which is to say, client certs and
S/MIME are a tiny unimportant area, and that situation is only going to
change when people start accepting real changes. If no change is
acceptable, then it is self-confirming: client certs are not supported
in a business sense, only a technical sense.
8. We are talking about a product -- email -- that was invented in the
1970s or so, and its current form was crystallised in the early 1980s.
S/MIME was designed early 1990s. There is little here that is
post-1994. Let's not get hung up on following too closely prescriptions
that were done in dim history, we've had approximately 3 revolutions in
design since then.
Mozilla can follow its policy. But at the end of the day, it really
should serve its users, and the policy should also aim to do that.
Elsewise it risks becoming another casualty.
It should be also noted that Tbird team have got this message. They
started out with an email client. But they aren't doing email any more,
they are doing messaging. Which is what users do.
Is the Mozilla policy group interested in that?
iang
> 2) OCSP
...
Policy Authority PKIoverheid
Hi Kathleen,
>My understanding is that some of the Staat der Nederlanden CSPs
>include an email address for authentication (access control) purposes
>within government organizations or commercial companies.
Your assumption is partially correct. The email address in a
certificate is indeed used for authentication (access control)
purposes. At the same time some CSPs within the PKIoverheid hierarchy
(ESG, DigiNotar and Getronics) include email addresses in S/MIME
certificates because this is the default situation for most
applications like Tbird and Outlook.
At this moment 2 CSPs within the PKIoverheid (UZI-rgister and
Defensie) don’t include an email address in the certificate. This
because of security concerns (privacy, spam).
PKIoverheid shares these security concerns but at the same time
recognizes the fact that it is common practice to include email
addresses in S/MIME certificates because this is the default situation
for most applications like Tbird and Outlook. That is why the
PKIoverheid policy states that the email address is deprecated BUT
permitted in the SubjectAltName.rfc822Name field.
Because 3 CSPs within the PKioverheid include an email address in a
certificate it is highly desirable that the Email trust bit is set for
the Staat der Nederlanden Root CA and the Staat der Nederlanden Root
CA G2.
>OCSP
I am glad that the OCSP worked within Firefox for all of the CSP’s.
Regards
Mark
Kathleen Wilson
> the Staat der Nederlanden Root CA and the Staat der Nederlanden Root
> CA G2.
Thank you for the clarification.
At this point I am inclined to recommend that all three trust bits
(email, websites, and code signing) be enabled for this new root.
Note that the OCSP responders of the CSP's that issue SSL certs have
been verified to work correctly within Firefox.
There are no further action items for this discussion.
Eddy Nigg
From where does this comment come from? I can't find anything matching
the above comment from ???
Nelson Bolyard
>> Because 3 CSPs within the PKioverheid include an email address in a
>> certificate it is highly desirable that the Email trust bit is set for
>> the Staat der Nederlanden Root CA and the Staat der Nederlanden Root
>> CA G2.
>
> Thank you for the clarification.
>
> At this point I am inclined to recommend that all three trust bits
> (email, websites, and code signing) be enabled for this new root.
Several people have written to me, asking me to "weigh in" on this subject.
So here goes. It's simple, really.
Regarding the question of whether or not to give the email trust bit to
SdN, IMO, the issue is NOT "do they put email addresses in their certs?",
but rather is "do they adequately verify the email addresses that they do
put into certs, when they do?". IMO, that has always been the issue.
I define "adequately verify" as testing and demonstrably proving read access
to the named mailbox, not merely showing a state identification card, taking
an oath, and saying "this is my email address, trust me".
As for the issue of Mozilla's mail clients requiring email certs to have
email addresses, there are several reasons for that, the simplest of which
is that that is how Mozilla finds the encryption certificate to use to
encrypt an email message being sent. If you stop relying on email addresses
in certs for that, then you must create a bunch of new UI to find the certs
for each of the recipients of an email being sent (and there may be many of
them). That UI doesn't exist today, and I see nobody volunteering to create
it.
The SMIME code in Mozilla's email clients (Thunderbird and SeaMonkey) is
an orphan. It has received no love for years. Remarkably, it still works,
mostly, about as well as it did 8 years ago, when it last received love.
It does not claim conformance to any SMIME/CMS RFCs newer than RFC 2630
(CMS 1) and RFC 2533 (S/MIME 3.0), both date June 1999. It does not claim
conformance to RFC 2634, also dated June 1999. AFAIK, no one in Mozilla
Messaging is interested in enhancing it, or improving its compliance to
more recent standards.
So, we can give the email trust bit to a CA that issues email certs without
email addresses, but Mozilla mail clients won't use those certs to encrypt
email.
Eddy Nigg
> On 11/10/2009 11:32 PM, Kathleen Wilson:
>>> Because 3 CSPs within the PKioverheid include an email address in a
>>> certificate it is highly desirable that the Email trust bit is set for
>>> the Staat der Nederlanden Root CA and the Staat der Nederlanden Root
>>> CA G2.
>> Thank you for the clarification.
>>
>> At this point I am inclined to recommend that all three trust bits
>> (email, websites, and code signing) be enabled for this new root.
>>
>> Note that the OCSP responders of the CSP's that issue SSL certs have
>> been verified to work correctly within Firefox.
>>
>> There are no further action items for this discussion.
>
> From where does this comment come from? I can't find anything matching
> the above comment from ???
>
Apparently not all messages arrive at the news server. Can Dave or
somebody have a look at this?
Kyle Hamilton
sending to the list and start sending only to Kathleen? If so, I
would ask that Kathleen forward all communications that have anything
to do with this request to the list, and smack PKioverheid (I don't
care if you DO represent the State of The Netherlands) for violation
of protocol.
In fact, if this has occurred, my recommendation is to reject them
outright. This is a community process... or if it's not, then tell me
so I can stop wasting my time.
-Kyle H
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Eddy Nigg
> I did not receive the original message, either. Did PKioverheid stop
> sending to the list and start sending only to Kathleen? If so, I
> would ask that Kathleen forward all communications that have anything
> to do with this request to the list, and smack PKioverheid (I don't
> care if you DO represent the State of The Netherlands) for violation
> of protocol.
>
> In fact, if this has occurred, my recommendation is to reject them
> outright. This is a community process... or if it's not, then tell me
> so I can stop wasting my time.
>
Calm, my friend :-)
It might be another glitch with the news <=> mail gateway. Except in
case you aren't using news, but the mailing list. That would be
something different and this really has been off-list.
But we really would like to understand the sudden mind change, since no
new information was provided which could warrant it.
Eddy Nigg
> So, we can give the email trust bit to a CA that issues email certs without
> email addresses, but Mozilla mail clients won't use those certs to encrypt
> email.
>
Thanks Nelson. So would it be on your opinion OK to enabled the web site
trust bit for CAs which issue server certificates without any domain
names in them? Because Firefox (and other Mozilla based apps) will treat
them as invalid, is this what you are saying?
Ian G
> Kathleen Wilson wrote:
> As for the issue of Mozilla's mail clients requiring email certs to have
> email addresses, there are several reasons for that, the simplest of which
> is that that is how Mozilla finds the encryption certificate to use to
> encrypt an email message being sent.
Right. That makes sense. Thanks for this explanation, it really makes
concrete where we are.
> If you stop relying on email addresses
> in certs for that, then you must create a bunch of new UI to find the certs
> for each of the recipients of an email being sent (and there may be many of
> them). That UI doesn't exist today, and I see nobody volunteering to create
> it.
Point.
> The SMIME code in Mozilla's email clients (Thunderbird and SeaMonkey) is
> an orphan. It has received no love for years. Remarkably, it still works,
> mostly, about as well as it did 8 years ago, when it last received love.
> It does not claim conformance to any SMIME/CMS RFCs newer than RFC 2630
> (CMS 1) and RFC 2533 (S/MIME 3.0), both date June 1999. It does not claim
> conformance to RFC 2634, also dated June 1999. AFAIK, no one in Mozilla
> Messaging is interested in enhancing it, or improving its compliance to
> more recent standards.
The thing about no love is no surprise. Developers may be
narrow-focussed, but they aren't stupid.
Corporates won't invest (pay for developers) until the model is fixed
and proves itself; individuals won't invest (spend their fun time) to
fix the model because they won't be allowed to make any model changes by
the corporates.
Deadlock. No love there.
Perhaps another way of saying it is ... only a paid developer will put
up with the abuse from the PKI crowd, and no corporate will pay for a
non-performing project.
If I was working at Mozilla Messaging, I'd be seriously thinking about
dropping the product. That's the business meaning of deadlock.
> So, we can give the email trust bit to a CA that issues email certs without
> email addresses, but Mozilla mail clients won't use those certs to encrypt
> email.
OK. As long as there is no demonstrable harm, we can allow others to
experiment. Who knows, maybe Staat der Nederlanden finds some of that love?
iang
Policy Authority PKIoverheid
Nelson refers to an incorrect assumption: ...."to a CA that issues
email certs without email addresses". As I stated: DigiNotar,
Getronics and ESG (CAs under our Staat der Nederlanden Root CA) do
issue email certs including email addresses. Mozilla mail clients will
use these certs to encrypt email (if of course the email trust bit
will be enabled for our root). So the Staat der Nederlanden Root CA
does issue email certs including email addresses.
The conclusion from Nelson is propably true for the certs issued by
the two other CAs under our Staat der Nederlanden Root CA: UZI-
register and Defensie. Because these CAs issue certs without email
addresses (this because of security concerns).
Kyle as you can see I didn't stop sending to the list. So don't smack
me man :-)
Kathleen can you please inform me, or rather the newsgroup, about the
next steps. As for as I know I answered all the questions.
Thanks in advance.
Mark
Moudrick M. Dadashov
> On 11/11/2009 00:19, Nelson Bolyard wrote:
>> Kathleen Wilson wrote:
>
>> email addresses, there are several reasons for that, the simplest of
>> which
>> is that that is how Mozilla finds the encryption certificate to use to
>> encrypt an email message being sent.
>
>
> makes concrete where we are.
>
>
>> in certs for that, then you must create a bunch of new UI to find the
>> certs
>> for each of the recipients of an email being sent (and there may be
>> many of
>> them). That UI doesn't exist today, and I see nobody volunteering to
>> create
>> it.
>
>
>
>
>> The SMIME code in Mozilla's email clients (Thunderbird and SeaMonkey) is
>> an orphan. It has received no love for years. Remarkably, it still
>> works,
>> mostly, about as well as it did 8 years ago, when it last received love.
>> It does not claim conformance to any SMIME/CMS RFCs newer than RFC 2630
>> (CMS 1) and RFC 2533 (S/MIME 3.0), both date June 1999. It does not
>> claim
>> conformance to RFC 2634, also dated June 1999. AFAIK, no one in Mozilla
>> Messaging is interested in enhancing it, or improving its compliance to
>> more recent standards.
>
>
> narrow-focussed, but they aren't stupid.
>
> Corporates won't invest (pay for developers) until the model is fixed
> and proves itself; individuals won't invest (spend their fun time) to
> fix the model because they won't be allowed to make any model changes
> by the corporates.
>
> Deadlock. No love there.
>
> Perhaps another way of saying it is ... only a paid developer will put
> up with the abuse from the PKI crowd, and no corporate will pay for a
> non-performing project.
>
> If I was working at Mozilla Messaging, I'd be seriously thinking about
> dropping the product. That's the business meaning of deadlock.
>
the serious arguments why some government institutions choose TB.
Thanks,
M.D.
cell: +370-699-2662
>
>> So, we can give the email trust bit to a CA that issues email certs
>> without
>> email addresses, but Mozilla mail clients won't use those certs to
>> encrypt
>> email.
>
>
> OK. As long as there is no demonstrable harm, we can allow others to
> experiment. Who knows, maybe Staat der Nederlanden finds some of that
> love?
>
>
> iang
Eddy Nigg
> On 11/11/2009 01:19 AM, Nelson Bolyard:
>
> Nelson refers to an incorrect assumption: ...."to a CA that issues
> email certs without email addresses". As I stated: DigiNotar,
> Getronics and ESG (CAs under our Staat der Nederlanden Root CA) do
> issue email certs including email addresses. Mozilla mail clients will
> use these certs to encrypt email (if of course the email trust bit
> will be enabled for our root). So the Staat der Nederlanden Root CA
> does issue email certs including email addresses.
>
Mark, it's not entirely clear to me what DigiNotar has to do with your
CA. Can you explain the connection - if any - beyond being in the same
country and perhaps compliant to the same laws?
PS. DigiNotar's root has the S/MIME bit NOT enabled, so how can this be
an argument for enabling your root's S/MIME bit? DigiNotar does NOT
issue S/MIME certificates as far as I know.
> The conclusion from Nelson is propably true for the certs issued by
> the two other CAs under our Staat der Nederlanden Root CA: UZI-
> register and Defensie. Because these CAs issue certs without email
> addresses (this because of security concerns).
>
Wait a minute. Which CAs are they? I request another clarification,
that's not what I understood from your answers previously.
> Kyle as you can see I didn't stop sending to the list. So don't smack
> me man :-)
>
There are some which haven't received certain messages.
Nelson Bolyard
> On 11/11/2009 01:19 AM, Nelson Bolyard:
>> So, we can give the email trust bit to a CA that issues email certs without
>> email addresses, but Mozilla mail clients won't use those certs to encrypt
>> email.
>
> Thanks Nelson. So would it be on your opinion OK to enabled the web site
> trust bit for CAs which issue server certificates without any domain
> names in them? Because Firefox (and other Mozilla based apps) will treat
> them as invalid, is this what you are saying?
Yes, I think that's essentially right. To be valid for a certain purpose,
a certificate must have a whole set of components. You take away any
one of them and it is no longer valid for that purpose. What's the
difference between an SSL server certificate without any host name, and
an SSL server certificate whose Extended Key Usage denies it to be used
for SSL service? Either way, Mozilla won't use it as an SSL server cert.
Likewise, what's the difference between issuing an email cert without an
email address, and issuing an email cert with an Extended Key Usage
extension that doesn't allow email protection? Either way, Mozilla mail
won't use it for email.
Eddy Nigg
> Yes, I think that's essentially right. To be valid for a certain purpose,
> a certificate must have a whole set of components. You take away any
> one of them and it is no longer valid for that purpose. What's the
> difference between an SSL server certificate without any host name, and
> an SSL server certificate whose Extended Key Usage denies it to be used
> for SSL service? Either way, Mozilla won't use it as an SSL server cert.
>
> Likewise, what's the difference between issuing an email cert without an
> email address, and issuing an email cert with an Extended Key Usage
> extension that doesn't allow email protection? Either way, Mozilla mail
> won't use it for email.
>
Yeah! But my question was a bit sarcastic...would you really want to
have CAs which issues server certs without any domain names in the CN
and SAN::DNS fields in the NSS cert DB? I mean, why include the root in
first place if it will not work? By CAs policy it will not work because
they don't do it - include domains in the server certs!
The same question I'm asking regarding S/MIME certs, why include such a
root (and enabled the email trust bit) if we know upfront that those
certs will not work?
Kyle Hamilton
-Kyle H
Policy Authority PKIoverheid
Question:
>Mark, it's not entirely clear to me what DigiNotar has to do with your
>CA. Can you explain the connection - if any - beyond being in the same
>country and perhaps compliant to the same laws?
>PS. DigiNotar's root has the S/MIME bit NOT enabled, so how can this be
>an argument for enabling your root's S/MIME bit? DigiNotar does NOT
>issue S/MIME certificates as far as I know.
Answer:
I can imagine that this is somewhat confusing. DigiNotar issue
certificates under their own root (http://www.mozilla.org/projects/
security/certs/included/#DigiNotar) and they have their own CPS for
that (http://www.diginotar.com/Portals/0/General%20terms/
DigiNotar_CPS_3.5_-_EN.pdf) and they have their own CRL (http://
service.diginotar.nl/crl/root/latestCRL.crl) and so on. With their own
root, DigiNotar service the business, government and consumer markets
in the Netherlands.
In addition DigiNotar is also one of the CSP CAs under the Staat der
Nederlanden Root CA. PKIoverheid created a CSP CA cert for DigiNotar.
With this CSP CA cert DigiNotar issue certs on behalf of PKIoverheid
to business and government in the Netherlands. DigiNotar has a
separate CPS for this (in Dutch) (https://www.diginotar.nl/Portals/7/
Voorwaarden/CPS%20DigiNotar%20PKIoverheid%20domein%20overheid
%20v1.2.3.pdf) and (https://www.diginotar.nl/Portals/7/Voorwaarden/CPS
%20DigiNotar%20PKIoverheid%20Services%20v1.2.2.pdf) and has created a
separate CRL (http://service.diginotar.nl/crl/PKIOverheidenBedrijven/
latestCRL.crl) and so on.
As I stated before there is no connection (no cross signing or
whatsoever) between the DigiNotar Root CA (and CPS etc.) and the Staat
der Nederlanden Root CA (and CP/CPS etc.). Actually DigiNotar with
their own root is a competitor for the Staat der Nederlanden Root CA
because they also issue certs to business and government in the
Netherlands.
With regard to the information above the argument that DigiNotar's
root has the S/MIME bit not enabled and for that reason the S/MIME bit
should not be enabled either for the Staat der Nederlanden Root, is
not a valid argument.
Mozilla should decide, solely based on the policy of PKIoverheid, if
she wants to enable the email trust bit for the Staat der Nederlanden
Root.
I hope that my explanation has given some clarity on this subject.
Question:
>Wait a minute. Which CAs are they? I request another clarification,
>that's not what I understood from your answers previously
Answer:
UZI-register (CIBG) and Defensie are CSP CAs under the Staat der
Nederlanden Root. Both CSP CAs do not include email addresses in their
certs. This is also stated in the summary of the information that has
been gathered and verified for each CSP:
https://bug436056.bugzilla.mozilla.org/attachment.cgi?id=407385
Regards
Mark
Jean-Marc Desperrier
> The SMIME code in Mozilla's email clients (Thunderbird and SeaMonkey) is
> conformance to RFC 2634, also dated June 1999. AFAIK, no one in Mozilla
> Messaging is interested in enhancing it, or improving its compliance to
> more recent standards.
Nelson, the french ministery of defence selected last year Thunderbird
as it's reference mail client (this means around 200 000 install of
Thunderbird) :
http://ascher.ca/blog/2008/01/31/more-on-thunderbird-in-france/
(french)
http://standblog.org/blog/post/2008/01/30/Questions-a-Thierry-Leblond-Ministere-de-la-Defense
This also means that they have decided to create and support an open
source project, trustedbird, which aims to give some love to those
*very* aspect of Thunderbird you are talking about here :
http://www.trustedbird.org/w/index.php?title=Main_Page&setlang=en
This means 3 things :
- an independent download with RFC 2634 supported (signed receipts,
triple wrapping for secure mailing-lists)
http://www.trustedbird.org/tb/Download
- a list of extension to Thunderbird to add those functionalities one by
one (same page)
- an effort to get those feature integrated inside the core Thunderbird.
I've just checked their roadmap, it's strange they never thought about
contacting and talking with the NSS team about some of the feature they
intend to implement in the future (ftp/ldap crl, tls 1.2, better
certificate integration in the address book) :
http://www.trustedbird.org/tb/Roadmap
Jean-Marc Desperrier
> On 2009-11-10 19:29 PDT, Eddy Nigg wrote:
>> > On 11/11/2009 01:19 AM, Nelson Bolyard:
>>> >> So, we can give the email trust bit to a CA that issues email certs without
>>> >> email addresses, but Mozilla mail clients won't use those certs to encrypt
>>> >> email.
>> >
>> > Thanks Nelson. So would it be on your opinion OK to enabled the web site
>> > trust bit for CAs which issue server certificates without any domain
>> > names in them? Because Firefox (and other Mozilla based apps) will treat
>> > them as invalid, is this what you are saying?
> Yes, I think that's essentially right. To be valid for a certain purpose,
> a certificate must have a whole set of components. You take away any
> one of them and it is no longer valid for that purpose.
But setting the corresponding trust bit means approval that the CA has
the correct architecture in place for issuing those cert, when in
practice the certs are not even technically correct.
That means that anything else the CA should be doing to insure the certs
are correctly issued is not actually exerted.
Here is a CA that's supposed to do a list of things that are not always
easy, and that in practice takes the subject so lightly or understand it
so badly that it won't even issue technically valid certificates.
Except if the CA can explain in detail why it issues those certificates
this way, find a convincing reason to do that (what can it be !?), it's
very hard to trust it.
Ian G
One has an explicit statement that doesn't permit email protection, the
other does not.
The difference in practical terms is whether there is a valid use case
for email protection without an email address. Demonstrably, there is
such a use case.
I'm not sure whether there is a valid use case for SSL server
certificates without a hostname. However there might be. One can
discuss it, and evidently things like EV go closer towards it. What EV
tries to do is authenticate the company name to the user. If we look at
the situation with confusing domain names within a corporate network,
this could start to make a lot of user sense. Just as a thought
experiment...
> Either way, Mozilla mail
> won't use it for email.
Right. So Mozilla mail is not conformant with the standard. But we
shouldn't confuse the two issues.
Validity for a purpose is defined in PKI by the CPS primarily, with
reference to a standard for interoperability. Both validity and
interoperability are important.
What is happening here is that Mozilla's Tbird and quite possibly others
are not fully interoperable according to the standard RFCs.
This happens. It is one of the reasons why PKI does not succeed. There
are too many cooks who can slow things down, so improvements can't be
made because everyone has to agree to every improvement.
In this case, we could easily decide that the best thing for
certificates is to enforce them having email addresses and have these
checked as part of the validity. In which case we would have to go back
to the RFC committee and ask for a modification to the RFC to state this...
I mention this because frequently when we come across bugs in the PKI,
developers often say "well, ok, you may be right, but now you have to go
to the RFC committee and convince them ..." So depending on how this
goes, credibility is on the line.
iang
Ian G
> On 11/12/2009 04:46 AM, Nelson Bolyard:
>> Yes, I think that's essentially right. To be valid for a certain purpose,
>> a certificate must have a whole set of components. You take away any
>> one of them and it is no longer valid for that purpose. What's the
>> difference between an SSL server certificate without any host name, and
>> an SSL server certificate whose Extended Key Usage denies it to be used
>> for SSL service? Either way, Mozilla won't use it as an SSL server cert.
>>
>> Likewise, what's the difference between issuing an email cert without an
>> email address, and issuing an email cert with an Extended Key Usage
>> extension that doesn't allow email protection? Either way, Mozilla mail
>> won't use it for email.
>
> Yeah! But my question was a bit sarcastic...would you really want to
> have CAs which issues server certs without any domain names in the CN
> and SAN::DNS fields in the NSS cert DB?
Users want that. The don't care about domains, they want to know that
when they go to their bank, they are going to their bank. Have a look
at how EV certs are displayed.
> I mean, why include the root in
> first place if it will not work? By CAs policy it will not work because
> they don't do it - include domains in the server certs!
>
> The same question I'm asking regarding S/MIME certs, why include such a
> root (and enabled the email trust bit) if we know upfront that those
> certs will not work?
Because it might be a good use case, it might be "right", and indeed it
might be "righter" than the way things are being done now. It might
improve security, and it might even lead to more cert sales.
It could even find new developers to work on Tbird. Even if they are
French ;) Jean-Marc, thanks for that. Are you in contact with them?
Can you provide/ask what their view is on the notion of email certs
without email addresses?
These are of course maybes. They need to be balanced against other
maybe-nots. Like support for example; maybe there will be a flood of
bugzilla complaints that Tbird doesn't work with email-agnostic certs.
iang
Ian G
> But setting the corresponding trust bit means approval that the CA has
> the correct architecture in place for issuing those cert, when in
> practice the certs are not even technically correct.
They follow the RFC. What is not technically correct about them?
> That means that anything else the CA should be doing to insure the certs
> are correctly issued is not actually exerted.
>
> Here is a CA that's supposed to do a list of things that are not always
> easy, and that in practice takes the subject so lightly or understand it
> so badly that it won't even issue technically valid certificates.
>
> Except if the CA can explain in detail why it issues those certificates
> this way, find a convincing reason to do that (what can it be !?), it's
> very hard to trust it.
They quoted the RFC. It is now up to others to find the technical
standard that insists that they have email addresses in them.
(It might be in there ... I looked and couldn't find it.)
Just because that is a switch in worldview doesn't give justification
for mobbing them. What ever happened to innovation and the free spirit
of the Internet?
iang
Eddy Nigg
Kathleen, at this point I request to hold up this request for the time being until I can review the whole thing again, ask the appropriate question, receive answers if needed and make my recommendation which might be the same or different than the previous one.
To cut this short, there is one answer Mark provided previously which was:
Answer: All future CSPs have to undergo an ETSI TS 101 456 audit and at the same time in addition, a separate audit with regard to the PKIoverheid requirements as stated in our CP, before they can enter the PKIoverheid hierarchy and issue certificates. So they also have to comply with the email and domain name validation requirements.
So this does apply to all the five CAs which are under your root? Is this correct?
Eddy Nigg
> On 12/11/2009 03:58, Eddy Nigg wrote:
>> On 11/12/2009 04:46 AM, Nelson Bolyard:
>>> Yes, I think that's essentially right. To be valid for a certain
>>> purpose,
>>> a certificate must have a whole set of components. You take away any
>>> one of them and it is no longer valid for that purpose. What's the
>>> difference between an SSL server certificate without any host name, and
>>> an SSL server certificate whose Extended Key Usage denies it to be used
>>> for SSL service? Either way, Mozilla won't use it as an SSL server
>>> cert.
>>>
>>> Likewise, what's the difference between issuing an email cert
>>> without an
>>> email address, and issuing an email cert with an Extended Key Usage
>>> extension that doesn't allow email protection? Either way, Mozilla mail
>>> won't use it for email.
>>
>> Yeah! But my question was a bit sarcastic...would you really want to
>> have CAs which issues server certs without any domain names in the CN
>> and SAN::DNS fields in the NSS cert DB?
>
>
> Users want that. The don't care about domains, they want to know that
> when they go to their bank, they are going to their bank. Have a look
> at how EV certs are displayed.
>
Yeah, just that the most care is taken to establish ownership / control
over the domain by the EV subscriber by various means. It just happens
to be the CORE part of the EV guidelines. The extended validation is to
establish the identity of the verified identity to rule out any
possibility that a specific web site can't get an EV certificate without
establishing without any doubt the domain control.
Besides that anybody with an EV cert would be able to MITM and pnw you,
but that's fine in the world of Ian Grigg, because that's what the
users want :-)
Jean-Marc Desperrier
> [...] the french ministry of defence [...]
> This also means that they have decided to create and support an open
> source project, trustedbird, which aims to give some love to those
> *very* aspect of Thunderbird you are talking about here :
> http://www.trustedbird.org/w/index.php?title=Main_Page&setlang=en
>
> I've just checked their roadmap, it's strange they never thought about
> contacting and talking with the NSS team about some of the feature they
> intend to implement in the future (ftp/ldap crl, tls 1.2, better
There's a list here of the developers involved in the Trustedbird
project : http://adullact.net/projects/milimail/
Read it, and you'll see names that you have seen on some NSS bugs,
providing patches (like 371522 - Auto-Update of CRLs stops after first
update)
Policy Authority PKIoverheid
> To cut this short, there is one answer Mark provided previously which was:
>
> Answer:
> All future CSPs have to undergo an ETSI TS 101 456 audit and at the
> same time in addition, a separate audit with regard to the PKIoverheid
> requirements as stated in our CP, before they can enter the
> PKIoverheid hierarchy and issue certificates. So they also have to
> comply with the email and domain name validation requirements.
>
> So this does apply to all the five CAs which are under your root? Is
> this correct?
That is correct. As stated by Kathleen Wilson 10/30/2009 08:34 PM:
PKIoverheid does not allow the email address to be included in the
Subject.emailAddress field. The email address is deprecated but
permitted in the
SubjectAltName.rfc822Name field. CP Part 3a: if the e-mail address is
included in the certificate the CSP must: let the subscriber agree on
this by signing an agreement and; verify that the e-mail address
belongs to the domain of the subscriber.
This also means that if a CSP CA under the Staat der Nederlanden Root
CA choose not to include an email address (because of security
concerns) than the requirement is not applicable (the text says: "IF
the e-mail address is included....etc"
I apologize if I was unclear about this.
Regards
Mark
Ian G
> Besides that anybody with an EV cert would be able to MITM and pnw you,
> but that's fine in the world of Ian Grigg, because that's what the users
> want :-)
Every time we see a personal attack, we see a reduction in
professionalism. In actuality and in perception.
This has a lot of effects. Every time the forum loses perception of
professionalism, we tell highly experienced professionals to not help us.
It is also implausible for any employee at any professional CA to
justify participating in the forum in a positive sense. No boss in his
or her right mind would want their workers to be associated with a forum
that accepts and encourages personal attacks. The code of professional
business does not accept association with such.
iang
Kathleen Wilson
comments and feedback to this discussion. Your contributions are
greatly appreciated.
This discussion was in regards to the request from Staat der
Nederlanden to add the “Staat der Nederlanden Root CA - G2” root
certificate and enable all three trust bits.
There are no action items resulting from this discussion.
There was significant discussion about whether or not the email trust
bit should be enabled for this root. While, according to spec,
certificates usable for S/MIME email may not be required to include
email addresses, our specific interest is how such certificates are
used in the context of Mozilla products like Thunderbird. If email
certificates cannot be used in the context of the Thunderbird model
then, from Mozilla's perspective, there is no point in accepting them
for purposes of email, even if they might be usable in other
applications that support S/MIME.
One of our goals is to operate the root program in terms of minimizing
risk. One way that we can minimize risk is by not giving roots more
trust than they absolutely require.
To summarize, to enable the email trust bit, the requirements in the
Mozilla CA Certificate policy must be met for the root and all of the
sub-CAs, and the email certificates should be usable within the
Mozilla context/products (eg Thunderbird).
Staat der Nederlanden may file a new bug to request enablement of the
email trust bit for this root.
I will post a summary of the request and my recommendation in the bug
to approve the inclusion of this root and to enable the websites and
code signing trust bits.
https://bugzilla.mozilla.org/show_bug.cgi?id=436056
I am now closing this discussion. Any further follow-up on this
request should be added directly to the bug.
Thanks,
Kathleen
Eddy Nigg
> On 12/11/2009 14:35, Eddy Nigg wrote:
>
>> Besides that anybody with an EV cert would be able to MITM and pnw you,
>> but that's fine in the world of Ian Grigg, because that's what the users
>> want :-)
>
>
> Every time we see a personal attack, we see a reduction in
> professionalism. In actuality and in perception.
Well, first of all I don't consider my comment as a "personal attack"
nor do I consider your comments professional. I wouldn't make such
replies either if you would launch your ideas and thoughts on a
different banner, for example "Breathtaking new ideas instead of the
established policies and practices by the ITU, PKI and public CAs". I
would perhaps might have even something useful to say in reply...
However you are doing this during the discussions of inclusion requests,
countering any and every argument which is made in order to make public
CAs comply to the policies and and towards the changing and increasing
security requirements and demands. Now, I have allocated about half an
hour per day of my time to this forum, out of a 16 hour daily schedule
and I have no interested in investing this time in order to provide
arguments repeatedly in favor of established practices and requirements.
Neither am I interested in relaxing those requirements - all indications
are, that the requirements will be more strict and demanding on part of
the CAs, not the other way around.
As such, speaking about professionalism, I consider some of your
comments highly unprofessional or disconnected to what happens in this
industry. I suspect that some of these are made by you on purpose in
order to disrupt and interfere in what is considered established
policies and practices. Regarding EV, did you read the EV guidelines?
Had the "users" any say about what they want and how browsers should
signal EV? As a side note, some other browsers have different
implementations and even highlight the base domain part...
Nelson Bolyard
And they provided rather large patches, years ago, on bugs
380624 ESS: Triple Wrapping (RFC2634 - 1.1)
386313 ESS: Signed Receipts (RFC2634 - 2)
and Mozilla Messaging (MoMo) has not exactly encouraged them to continue
to make those contributions. The fact that MoMo isn't taking those
contributions upstream is why milimail is now its own separate project.
But the fact that it is its own separate project means that Thunderbird
updates won't include it, and it will continue to be in French only.
Sigh.
Gervase Markham
>> Every time we see a personal attack, we see a reduction in
>> professionalism. In actuality and in perception.
>
> Well, first of all I don't consider my comment as a "personal attack"
> nor do I consider your comments professional.
Even if you think Ian is not being professional, then that is no reason
for you not to be.
But I also think what you said seems like a comparatively mild thing for
Ian to get upset about.
Can we all please assume good faith, and remember that written
communication is easier to misinterpret than face-to-face?
Gerv