Re: DigiNotar EV root inclusion request

2008-04-30 Thread Frank Hecker
Frank Hecker wrote:
> Rather than delay this application indefinitely until those questions 
> get resolved, I've decided to proceed in two steps. For step 1 I'll be 
> formally approving inclusion of the DigiNotar root in NSS, with SSL and 
> object signing trust bits enabled (no email trust bit). In step 2 I'll 
> make a decision about approving the DigiNotar root for EV, once we have 
> more information.
> 
> Formal approval for step 1 will follow shortly.

Done. The relevant NSS bug is as follows:

https://bugzilla.mozilla.org/show_bug.cgi?id=431621

I'll let you all know when there's any new information relating to the 
email and/or EV re-audit issues.

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-30 Thread Eddy Nigg (StartCom Ltd.)

Frank Hecker:
P.S. Note that I'm shortening the normal public comment period somewhat. 
  I'm doing that because based on the public comments I see no 
impediment to including the root for basic SSL and object signing, and 
I'd like to have Kai include it with the NSS changes for Network 
Solutions. The issues still under discussion are the email issue and the 
EV audit issue. The comment period remains open as far as those issues 
are concerned.
  


I suggest that when something new is going to happen (at the bug or 
otherwise) you renew the discussion and public comment period here again.


--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-30 Thread Frank Hecker
Frank Hecker wrote:
> DigiNotar has applied to add a new root CA certificate to the Mozilla 
> root store and enable it for EV, as documented in the following bug:
> 
>   https://bugzilla.mozilla.org/show_bug.cgi?id=369357

> I have evaluated this request, as per the mozilla.org CA certificate 
> policy:
> 
>   http://www.mozilla.org/projects/security/certs/policy/
> 
> and plan to officially approve the request after a public comment period.

Based on the results of the public comment period, this application is 
in sort of a half-way state: The basic inclusion request (for SSL and 
object signing trust bits only) looks good, but there are some remaining 
open questions regarding enabling DigiNotar for EV (mainly Eddy's 
concern about EV re-audit).

Rather than delay this application indefinitely until those questions 
get resolved, I've decided to proceed in two steps. For step 1 I'll be 
formally approving inclusion of the DigiNotar root in NSS, with SSL and 
object signing trust bits enabled (no email trust bit). In step 2 I'll 
make a decision about approving the DigiNotar root for EV, once we have 
more information.

Formal approval for step 1 will follow shortly.

Frank

P.S. Note that I'm shortening the normal public comment period somewhat. 
  I'm doing that because based on the public comments I see no 
impediment to including the root for basic SSL and object signing, and 
I'd like to have Kai include it with the NSS changes for Network 
Solutions. The issues still under discussion are the email issue and the 
EV audit issue. The comment period remains open as far as those issues 
are concerned.

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-27 Thread Eddy Nigg (StartCom Ltd.)

Frank Hecker:
First, DigiNotar first submitted its request several months ago, at a 
time when its EV audit would have been current had I processed 
DigiNotar's application in a timely manner. 


...and you would be today in a situation where you would have to remove 
this CA already from EV status.



I'm not inclined to penalize DigiNotar for my own delays.
  


No, you only adhere to your own criteria. Who do you penalize here 
really (if they don't have an updated audit and not conform to the EV 
criteria)? Just adding them to have them removed?


First, based on my experience a lot of CAs have experienced delays in 
getting their EV audits completed and published. 


So? (Sorry for being nasty, but I want to get my point through to you ;-) )

I'm guessing that this 
has been primarily due to the large number of CAs wanting to get EV 
audits, and the limited number of auditors available to do them. You may 
also recall that the first batch of EV reports was not published on the 
webtrust.org site, apparently due to delays by the AICPA/WebTrust folks 
and/or the various auditors in setting up arrangements to incorporate EV 
reports into the standard WebTrust SealFile system. 


The seals are not required. We need the audits. Apparently auditing 
works without problems...


So in general I've been willing to give CAs some leeway in terms of the 
audit dates, and see no reason not to do so in this case.
  


Some leeway is fine, but don't forget that we need to be in sync at some 
point (better before FF3 gets out). I see a reason to insist this time 
because the audit is very old in terms of EV. They've got KPMG next 
door, so I don't see a reason why this should be a problem (and I know 
what I'm talking about). And you won't be alone, MS will pull their EV 
status as well if they haven't already (assuming there is no updated 
audit, otherwise all is fine).


--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-27 Thread Frank Hecker
Eddy Nigg (StartCom Ltd.) wrote:
> In relation to that and after reviewing the audit report I suggest to 
> request from DigiNotar an updated audit report confirming current 
> implementations and assertion.

I'll look into the status of DigiNotar's re-audit. However I'll note up 
front that I'm not inclined to take a hard line on this particular 
issue, for a couple of reasons.

First, DigiNotar first submitted its request several months ago, at a 
time when its EV audit would have been current had I processed 
DigiNotar's application in a timely manner. I'm not inclined to penalize 
DigiNotar for my own delays.

First, based on my experience a lot of CAs have experienced delays in 
getting their EV audits completed and published. I'm guessing that this 
has been primarily due to the large number of CAs wanting to get EV 
audits, and the limited number of auditors available to do them. You may 
also recall that the first batch of EV reports was not published on the 
webtrust.org site, apparently due to delays by the AICPA/WebTrust folks 
and/or the various auditors in setting up arrangements to incorporate EV 
reports into the standard WebTrust SealFile system. Finally, there were 
further delays introduced due to trying to synchronize the second round 
of EV audits with the CAs' normal WebTrust audit cycles.

So in general I've been willing to give CAs some leeway in terms of the 
audit dates, and see no reason not to do so in this case.

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-27 Thread Eddy Nigg (StartCom Ltd.)

Frank Hecker:
Note that there was an issue with DigiNotar's EV audit because at the 
time its production CA software did not have the necessary features to 
issue EV certificates; the software has since been upgraded and 
DigiNotar has since successfully issued EV certificates. 
In relation to that and after reviewing the audit report I suggest to 
request from DigiNotar an updated audit report confirming current 
implementations and assertion. The audit report is from December 2006 
covering a period before that. That was way before EV was approved final 
and before DigiNotar implemented and issued EV themselves. Since yearly 
re-auditing is a requirement of the EV guidelines (and also Microsoft 
requires that, supposed that their CA root is shipped with MS software), 
I expect this to be not an issue.


As a matter of fact, according to the EV criteria, DigiNotar must have a 
newer audit report already ready and I suggest to carefully review this 
issue. Should no re-audit have taken place, then DigiNotar is not 
conforming to the EV criteria and must not receive EV status in NSS.



--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-27 Thread Eddy Nigg (StartCom Ltd.)

+1

Thank you Frank!

--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390



Frank Hecker:

Nelson B Bolyard wrote:
  

Eddy, I'm finding it difficult to track exactly which certs are the
subject of discussion here.  You and Frank seem to be discussing
other certs than the DigiNotar certs here.



The primary focus is DigiNotar, since it's their application being 
considered right now. The secondary focus is on Staat der Nederlanden, 
since it's another CA based in the Netherlands offering similar cert 
services and already included in Mozilla, and DigiNotar has commented 
that as a matter of fairness they should not be held to a different 
standard than that applied to Staat der Nederlanden. (Staat der 
Nederlanden was approved at a time when the current policy did not 
exist, and successful completion of a WebTrust audit was sufficient.)


Anyway, you and Eddy are right here, and I was wrong; simple as that. 
Here's my plan for proceeding for here:


1. I'll go ahead and consider the DigiNotar application as applying to 
SSL and code signing only, and any final approval will be for those two 
uses only.


2. I'll postpone any action on approving DigiNotar for email certs until 
such time as we determine that they are doing some suitable form of 
verifing email account control.


3. I'll look into what the current state of affairs is with regard to 
Staat der Nederlanden. I want to look at Staat der Nederlanden's own 
documentation (e.g., CPS, CP) and also get some feedback from people in 
the Netherlands who might be familiar with real-world use of Staat der 
Nederlanden certs. (The latter is to determine the possible impact of 
any future decision to turn off recognition of Staat der Nederlanden 
email certs.)


Frank

  


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-27 Thread Frank Hecker
Nelson B Bolyard wrote:
> Eddy, I'm finding it difficult to track exactly which certs are the
> subject of discussion here.  You and Frank seem to be discussing
> other certs than the DigiNotar certs here.

The primary focus is DigiNotar, since it's their application being 
considered right now. The secondary focus is on Staat der Nederlanden, 
since it's another CA based in the Netherlands offering similar cert 
services and already included in Mozilla, and DigiNotar has commented 
that as a matter of fairness they should not be held to a different 
standard than that applied to Staat der Nederlanden. (Staat der 
Nederlanden was approved at a time when the current policy did not 
exist, and successful completion of a WebTrust audit was sufficient.)

Anyway, you and Eddy are right here, and I was wrong; simple as that. 
Here's my plan for proceeding for here:

1. I'll go ahead and consider the DigiNotar application as applying to 
SSL and code signing only, and any final approval will be for those two 
uses only.

2. I'll postpone any action on approving DigiNotar for email certs until 
such time as we determine that they are doing some suitable form of 
verifing email account control.

3. I'll look into what the current state of affairs is with regard to 
Staat der Nederlanden. I want to look at Staat der Nederlanden's own 
documentation (e.g., CPS, CP) and also get some feedback from people in 
the Netherlands who might be familiar with real-world use of Staat der 
Nederlanden certs. (The latter is to determine the possible impact of 
any future decision to turn off recognition of Staat der Nederlanden 
email certs.)

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-26 Thread Eddy Nigg (StartCom Ltd.)

Nelson B Bolyard:


IMO, Mozilla should NOT trust this CA for email in that case.
  


Correct.


If that is true, then IMO Mozilla should remove the email trust bit
from the Staat der Nederlanden CA.
  

Right.


When I receive bug comments (such as comment 37) in email, I read them
by themselves, in a rather context-free way, so I may not pick up on
issues that are not explicitly stated but are only inferred in context.
  


OK, understood.



I see.  Well, I join you in objecting to giving email trust to a CA
that doesn't validate ownership/control of email boxes.  Do you think
I should register that view in the bug?
  


Thanks for your opinion. I think it's not necessary to put this in the 
bug, it's enough to that you voiced it here. Frank will read this mail 
and take notice. IMO Frank will have to make a decision on that and 
reply accordingly in the bug itself.




Thanks for your diligence.  You and Frank are contributing to the
development of Mozilla just as much as any code writer.  I appreciate
the contributions you both are making.


You are welcome! It's in my interest to have the Mozilla policy 
implemented and not to degrade NSS (and if possible higher the standard 
a little). I rely on Firefox, Thunderbird and NSS fully, so do many of 
our users too and I view this as my contribution to Mozilla (giving 
something back as we say ;-) )



--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-26 Thread Nelson B Bolyard
Eddy Nigg (StartCom Ltd.) wrote, On 2008-04-25 18:44:

> We are discussing the CA roots of "DigiNotar" and "Staat der Nederlanden
> Root CA". The first is due that they apparently don't perform any email
> validation for their client certificates and requested email bit set,
> but seem not to understand why it's needed
> (https://bugzilla.mozilla.org/show_bug.cgi?id=369357#c34 ). 

IMO, Mozilla should NOT trust this CA for email in that case.

> The later is due to a claim by the representative of DigiNotar that the
> Staat der Nederlanden CA doesn't validate email addresses either
> (https://bugzilla.mozilla.org/show_bug.cgi?id=369357#c37 ). 

If that is true, then IMO Mozilla should remove the email trust bit
from that CA.

> The response was to you Nelson, so you should know about it actually

Not really.  Comment 35 asked a simple question: how to tell if a CA was
or was not trusted for email.  I answered that in comment 36.

When I read comment 37, I see the writer making a simple statement about
the Netherlands CA, but I don't see any statement saying "but they don't
verify the email addresses".  That appears to be an inference from
other comments.

When I receive bug comments (such as comment 37) in email, I read them
by themselves, in a rather context-free way, so I may not pick up on
issues that are not explicitly stated but are only inferred in context.
Comment 35 asked a simple question, which can be answered without knowing
any context of the rest of the comments in that bug, and that's how I
answered it.  Comment 37 made no obvious accusation, and seemed (out of
context) to be affirming expected behavior, so I did not respond to it.

I was one of the people who really pushed to get the Policy created and
enacted, but now I rely on it being effectively and competently administered
by others.  I simply don't have time to study and evaluate each of the CA
proposals in detail.  That task, like each of the tasks involved in
developing the Mozilla products, has a group of people who are interested in
it and who carry the primarily responsibility for it.  In my view, that task
has been delegated to them.  I trust them to do that job well, just as they
trust me to implement the crypto code well.

>> Is this not already the policy?
> 
> Yes, it is! However as I complained in a previous mail, Frank initiated
> his intention to approve this CA nevertheless, including having the
> email bits set to true. Otherwise this inclusion request wouldn't have
> reached the comments period as it stands now.

I see.  Well, I join you in objecting to giving email trust to a CA
that doesn't validate ownership/control of email boxes.  Do you think
I should register that view in the bug?

>> Are there now CAs that are trusted for purposes for which they do not
>> verify the relevant identity info in their certs?
> 
> Yes, the "Staat der Nederlanden Root CA" is suspected of that. It's not
> confirmed however and I expect that Frank makes the needed inquires now.

Yes, I expect that also.

> I might do so later if nobody else does...

Thanks for your diligence.  You and Frank are contributing to the
development of Mozilla just as much as any code writer.  I appreciate
the contributions you both are making.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-25 Thread Eddy Nigg (StartCom Ltd.)

Nelson B Bolyard:

Eddy, I'm finding it difficult to track exactly which certs are the
subject of discussion here.  You and Frank seem to be discussing
other certs than the DigiNotar certs here.
  


We are discussing the CA roots of "DigiNotar" and "Staat der Nederlanden 
Root CA". The first is due that they apparently don't perform any email 
validation for their client certificates and requested email bit set, 
but seem not to understand why it's needed 
(https://bugzilla.mozilla.org/show_bug.cgi?id=369357#c34 ). The later is 
due to a claim by the representative of DigiNotar that the Staat der 
Nederlanden CA doesn't validate email addresses either 
(https://bugzilla.mozilla.org/show_bug.cgi?id=369357#c37 ). The response 
was to you Nelson, so you should know about it actually



I think the question of principle at issue here is whether Mozilla
policy ought to require that, at a minimum, any field in a cert that
the Mozilla product(s) programmatically evaluate in the course of cert path
validation MUST be validated by some means strong than assertion (:-).

If the Mozilla policy requires is, then in certs capable of being used
for SSL service, any DNS names that Firefox might check must have been
verified by the CA, and in cert capable of being used for S/MIME, any
email addresses that can be checked by Thunderbird must have been
verified by the CA.

I totally agree that this should be the policy.  We ought not trust CAs
that issue email certs without verifying ownership of email addresses
in those certs.  We ought not trust CAs that issue SSL certs without
verifying ownership of the domain name(s) in the certs.

Is this not already the policy?
  


Yes, it is! However as I complained in a previous mail, Frank initiated 
his intention to approve this CA nevertheless, including having the 
email bits set to true. Otherwise this inclusion request wouldn't have 
reached the comments period as it stands now.


See also the carefully phrased statements in the bug 
(https://bugzilla.mozilla.org/show_bug.cgi?id=369357#c44 ) which isn't 
the usual phrase Frank likes to put before the comments period (I think 
so, sorry Frank  :-) ).


Quote: "* Email: DigiNotar verifies identity for applicants issued 
certificates suitable for use with email."

Are there now CAs that are trusted for purposes for which they do not
verify the relevant identity info in their certs?
  


Yes, the "Staat der Nederlanden Root CA" is suspected of that. It's not 
confirmed however and I expect that Frank makes the needed inquires now. 
I might do so later if nobody else does...



Does the DigiNotar inclusion request propose to add such a CA?
  


Yes.


Note that for client authentication, there is NO field in the cert that
is automatically checked.  It is up to the server application to determine
if the cert is authorized for whatever purposes.  I'm not sure what
requirements Mozilla should impose on issuers of client auth only certs.
  


None as far as I'm aware, which is perfectly correct. As you indicated 
above, NO fields are verified for this use and ownership of the keys is 
enough. However email protection extensions (Signing, Key Encipherment, 
Data Encipherment) must not appear in this type of certificates nor 
should the email trust bits for the CA set to true in case no email 
validation is performed.



--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-25 Thread Nelson B Bolyard
Eddy, I'm finding it difficult to track exactly which certs are the
subject of discussion here.  You and Frank seem to be discussing
other certs than the DigiNotar certs here.

I think the question of principle at issue here is whether Mozilla
policy ought to require that, at a minimum, any field in a cert that
the Mozilla product(s) programmatically evaluate in the course of cert path
validation MUST be validated by some means strong than assertion (:-).

If the Mozilla policy requires is, then in certs capable of being used
for SSL service, any DNS names that Firefox might check must have been
verified by the CA, and in cert capable of being used for S/MIME, any
email addresses that can be checked by Thunderbird must have been
verified by the CA.

I totally agree that this should be the policy.  We ought not trust CAs
that issue email certs without verifying ownership of email addresses
in those certs.  We ought not trust CAs that issue SSL certs without
verifying ownership of the domain name(s) in the certs.

Is this not already the policy?

Are there now CAs that are trusted for purposes for which they do not
verify the relevant identity info in their certs?
Does the DigiNotar inclusion request propose to add such a CA?

Note that for client authentication, there is NO field in the cert that
is automatically checked.  It is up to the server application to determine
if the cert is authorized for whatever purposes.  I'm not sure what
requirements Mozilla should impose on issuers of client auth only certs.

Now, perhaps there is some question about whether a particular cert can
or cannot be used for email, or client authentication, or any other purpose.
Spelling that all out in detail would make this reply absurdly huge, but
let me say that the guiding principle is that a cert is valid for any
usages not prohibited by the extensions.  Extensions, when present, serve
to further limit a cert's acceptability.  For example, a cert without an
Extended Key Usage (EU) extension is implicitly valid for all EKUs, as
constrained by any other extensions present (some extensions overlap).

/Nelson
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-25 Thread Eddy Nigg (StartCom Ltd.)

Frank Hecker:

Eddy Nigg (StartCom Ltd.) wrote:
** Concerning the Staat der Nederlanden CA, this is currently just a 
claim brought forward in the bug by the representative of DigiNotar and 
must be confirmed first. Maybe you know for certain that this is 
correct, I haven't verified that claim.



No, I haven't verified it either, that's why we need further investigation.
  


OK, undestood! If this is what you mean by "further investigation"...

I suggest to review their CP/CPS and request information from the CA about:

A) If no email verification is done.
B) If email protection extensions (Signing, Key Encipherment, Data 
Encipherment) are used.


Your initial response was, to "talk to /some/ people in the Netherlands 
familiar with use of these certs. It may be that certs issued to 
individuals by these CAs in the context of Dutch law, business and 
government services, etc., are primarily used in non-email contexts..."


I feel it irrelevant for what the certificates are primarily used, 
rather what their validation practices are and which key extensions are 
set in the client certificates.


Also I'm somewhat surprised, that this claim was brought forward to Gerv 
and he didn't acted upon it, certainly not typical for him...strange...


--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-25 Thread Frank Hecker
Eddy Nigg (StartCom Ltd.) wrote:
> Fank, I suggest that you balance what impact it has on the relying 
> parties in first place (e.g. the users of your software) before you take 
> care about the effects of the CA.

In case it wasn't clear, my primary concern is for end users of 
Thunderbird who might be currently relying on email certs to send and 
receive encrypted and signed mail. I don't want us to suddenly disable 
such functionality without a clear rationale as to why we're doing it -- 
and that includes evaluating the relative security benefits and risks of 
both courses of action.

> ** Concerning the Staat der Nederlanden CA, this is currently just a 
> claim brought forward in the bug by the representative of DigiNotar and 
> must be confirmed first. Maybe you know for certain that this is 
> correct, I haven't verified that claim.

No, I haven't verified it either, that's why we need further investigation.

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-25 Thread Eddy Nigg (StartCom Ltd.)

Frank Hecker:

Eddy Nigg (StartCom Ltd.) wrote:
Considering for a minute your statement above, what are the CAs in 
question doing in order to guaranty domain/email ownership? What are the 
controls in place which let them rely on identity validation only?



This is where I think we need further investigation, and is partly why I 
  suggested talking to some people in the Netherlands familiar with use 
of these certs. It may be that certs issued to individuals by these CAs 
in the context of Dutch law, business and government services, etc., are 
primarily used in non-email contexts (e.g., client authentication to SSL 
sites, digital signing of documents separate from email, etc.), and 
email addresses are put in the certs just for completeness.
  


In which case you can turn email singing and encryption off, because the 
client certificates would still work for client authentication (presumes 
by me that the EE certs have client authentication extension set). In 
that respect, if the certificates CAN be used for signing of email 
messages, than this would be a flaw from our (Mozilla) side.


In any case, if it comes to that we can certainly move forward with this 
application for SSL and code signing, and leave the email trust bit 
turned off until such time as this gets sorted out.
  


As I understood from the bug and CPS (only checked the relevant 
sections), they verify domain or IP control/ownership and I think it's 
possible to move forward without email until they resolve it from their 
side.




Actually I approved the Staat der Nederlanden application back in 
September of 2004 (see bug 243424), but it didn't get added to NSS until 
several months later. At the time Staat der Nederlanden was approved we 
were in the midst of discussing a new CA policy, but hadn't yet 
finalized it. 


Yes, looking at the page at your site, the dates seem to suggest that too...

So during that period I was operating under an interim 
policy that basically matched Microsoft's policy at the time, of 
approving CAs based on completion of a WebTrust audit. That's why the 
issue of validating email account control didn't come up at that time.
  


OK

As for doing something about Staat der Nederlanden now, and in 
particular turning off the email trust bit for its certs, that warrants 
further discussion. 


Here I am :-)

Even if the CA is not in compliance with our current 
policy, I still have to balance that against the potential impact of 
having Staat der Nederlanden certs no longer work with S/MIME email in 
Thunderbird, etc. (Because disabling signed and encrypted email for an 
existing user base itself has security implications.) 


Fank, I suggest that you balance what impact it has on the relying 
parties in first place (e.g. the users of your software) before you take 
care about the effects of the CA. I'm not against taking an approach to 
work in cooperation with the affected CA (something which you will 
certainly do), but IMO this situation - if proved correct **, must be 
solved within a reasonable time (reasonable is weeks, not month).


That's another 
reason why I'd like more input from people more familiar with how the 
certs are used in practice.
What does it matter? If one can sign (and encrypt) email without being 
the actual owner of the email account, who cares about how the 
certificates are used usually? I mean, otherwise lets declare that test 
certificates for servers don't require domain validation - because in 
practice their or used for testing purpose usually...hope you get my 
comparison...



** Concerning the Staat der Nederlanden CA, this is currently just a 
claim brought forward in the bug by the representative of DigiNotar and 
must be confirmed first. Maybe you know for certain that this is 
correct, I haven't verified that claim. Certainly something we should do 
now, before jumping to conclusions. If confirmed, we should act 
accordingly and firmly in that respect.


--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-25 Thread Frank Hecker
Eddy Nigg (StartCom Ltd.) wrote:
> Well, I consider this the minimal technical validation required. 
> Identity/Organization validation for S/MIME implies prove of ownership 
> of the email account/address. Thunderbird doesn't validate the common 
> name or organization field, but the email address.

A fair point; it's the distinction between what the software checks 
(from address vs. address in cert) and what the person could check (name 
in cert).

> Considering for a minute your statement above, what are the CAs in 
> question doing in order to guaranty domain/email ownership? What are the 
> controls in place which let them rely on identity validation only?

This is where I think we need further investigation, and is partly why I 
  suggested talking to some people in the Netherlands familiar with use 
of these certs. It may be that certs issued to individuals by these CAs 
in the context of Dutch law, business and government services, etc., are 
primarily used in non-email contexts (e.g., client authentication to SSL 
sites, digital signing of documents separate from email, etc.), and 
email addresses are put in the certs just for completeness.

In any case, if it comes to that we can certainly move forward with this 
application for SSL and code signing, and leave the email trust bit 
turned off until such time as this gets sorted out.

>> Staat der Nederlanden is not a legacy root in the sense of being 
>> approved in the Netscape days. I approved it myself a while back, though 
>> at the moment I can't recall whether it was before or after adoption of 
>> our current policy.
>>   
> Nelson added this root at the 2005-04-11, certainly when the CA policy 
> already existed, but maybe still unapproved.

Actually I approved the Staat der Nederlanden application back in 
September of 2004 (see bug 243424), but it didn't get added to NSS until 
several months later. At the time Staat der Nederlanden was approved we 
were in the midst of discussing a new CA policy, but hadn't yet 
finalized it. So during that period I was operating under an interim 
policy that basically matched Microsoft's policy at the time, of 
approving CAs based on completion of a WebTrust audit. That's why the 
issue of validating email account control didn't come up at that time.

As for doing something about Staat der Nederlanden now, and in 
particular turning off the email trust bit for its certs, that warrants 
further discussion. Even if the CA is not in compliance with our current 
policy, I still have to balance that against the potential impact of 
having Staat der Nederlanden certs no longer work with S/MIME email in 
Thunderbird, etc. (Because disabling signed and encrypted email for an 
existing user base itself has security implications.) That's another 
reason why I'd like more input from people more familiar with how the 
certs are used in practice.

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-25 Thread Eddy Nigg (StartCom Ltd.)

Eddy Nigg (StartCom Ltd.):


Taking it one step further, would you ever accept server certificates 
which were ID/OV validated without sufficient prove of domain 
ownership? I made just recently the call, that for certain types of 
certificates domain validation isn't enough and additional validations 
should be performed. However this always implies domain (respectively 
email) validation.


Just one more note on this one: Server certificates which were ID/OV 
validated, but domain ownership was not valdiated, would mean 
practically that I could never know if this is indeed the right server 
I'm talking to, until making additional verifications of the whois 
records and certificate details. Maybe I could never find out if the 
domain stated in the certificate really belongs the holder of the 
certificate. It would make NSS effectively useless, the very reason why 
there are "trusted" CAs included in first place.


The same happens with email addresses. If the email address isn't 
validated, I need to perform additional checks in order to know if I'm 
indeed talking to the right person. Also here I might never know.


--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-25 Thread Eddy Nigg (StartCom Ltd.)

Frank Hecker:

Eddy Nigg (StartCom Ltd.) wrote:
  
Before going any further and after reading the entries in the bug, it 
seems to me that issue concerning email validation hasn't been 
positively resolved...can you confirm that or provide some explanation?



This was/is another judgment call. IIRC when we formulated the Mozilla 
CA policy the idea of email validation was basically seen as a 
(less-desirable) fallback position for CAs that did not do full identity 
validation. When I originally evaluated the Staat der Nederlanden 
application I was following this line of thought, and considering 
validation of identity as sufficient.
  


Well, I consider this the minimal technical validation required. 
Identity/Organization validation for S/MIME implies prove of ownership 
of the email account/address. Thunderbird doesn't validate the common 
name or organization field, but the email address. Any additional 
validation certainly implies validation of the email address.


Taking it one step further, would you ever accept server certificates 
which were ID/OV validated without sufficient prove of domain ownership? 
I made just recently the call, that for certain types of certificates 
domain validation isn't enough and additional validations should be 
performed. However this always implies domain (respectively email) 
validation.


Considering for a minute your statement above, what are the CAs in 
question doing in order to guaranty domain/email ownership? What are the 
controls in place which let them rely on identity validation only? 
Saying that the subscribers identity has been validated isn't enough if 
domain/email ownership isn't enforced. If nobody governs it, there are 
no controls in place. Supposed - and according to some statements in the 
bug, there are tens, maybe hundred of thousands client certificates 
issued without proper validations done, with nobody enforcing adherence 
to the minimal requirements either. If the CAs in question don't 
actively pursue adherence to the supposed minimal requirements, they 
shouldn't have affected trust bits set on and I question their 
understanding of how S/MIME works, considering comment 
https://bugzilla.mozilla.org/show_bug.cgi?id=369357#c34


Now, both domain and email validations stated above are the minimum 
requirements set forth by the Mozilla CA policy. These are the minimal 
steps which must be performed! Personally I start to seriously question 
the value of this process...I have mentioned it before. But Frank, you 
must make a decision perhaps in your argumentations. Once when it fits 
you, you say "this or that is not a requirement of the Mozilla CA 
policy" when I argue that something should be addressed nevertheless, 
and when it fits you otherwise you say "our intention was this or that" 
and with it you effectively circumvent the very basic requirements of 
the policy. I'm somewhat disillusioned about what I can expect from CAs 
included in NSS. Right now it looks very bad (and no, I'm not joining 
the chorus of some cry-baby's here, I'm actively contributing to this 
process and to the quality thereof).


Staat der Nederlanden is not a legacy root in the sense of being 
approved in the Netscape days. I approved it myself a while back, though 
at the moment I can't recall whether it was before or after adoption of 
our current policy.
  
Nelson added this root at the 2005-04-11, certainly when the CA policy 
already existed, but maybe still unapproved. I'd call for a urgent 
review of this CA.


I think it's worth discussing this issue further. As noted in the bug 
report, one argument is that (assuming identity validation is effective) 
  


Yes, can you exactly explain how this is effective and how it is governed?

any vulnerability is restricted to cases where people share the same 
name (e.g., someone else named "Frank Hecker" and I both apply for a 
cert).


Huuu? I'm not aware that Thunderbird checks your name when signing 
and/or encrypting mail. Effectively if I receive a signed (and 
encrypted) email from "Frank Hecker <[EMAIL PROTECTED]>" in 
the the name of "Van Der Dutch", Thunderbird treats it as valid, because 
the email address in the certificate matches the actual address. The 
common name isn't even displayed initially...


 It might also be useful to have input from some people in the 
Netherlands who have first-hand experience with these CAs and can 
describe actual practices.


Why? Are there no CP/CPS to review? Are the comments from the bug not 
enough to confirm their practices?



--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-24 Thread Frank Hecker
Eddy Nigg (StartCom Ltd.) wrote:
> Before going any further and after reading the entries in the bug, it 
> seems to me that issue concerning email validation hasn't been 
> positively resolved...can you confirm that or provide some explanation?

This was/is another judgment call. IIRC when we formulated the Mozilla 
CA policy the idea of email validation was basically seen as a 
(less-desirable) fallback position for CAs that did not do full identity 
validation. When I originally evaluated the Staat der Nederlanden 
application I was following this line of thought, and considering 
validation of identity as sufficient.

> Also do you have any intention doing something concerning the comment 
> https://bugzilla.mozilla.org/show_bug.cgi?id=369357#c37 about the "Staat 
> der Nederlanden Root CA" in respect to email validation? Judging from 
> the details of that root, this is a legacy root.

Staat der Nederlanden is not a legacy root in the sense of being 
approved in the Netscape days. I approved it myself a while back, though 
at the moment I can't recall whether it was before or after adoption of 
our current policy.

I think it's worth discussing this issue further. As noted in the bug 
report, one argument is that (assuming identity validation is effective) 
any vulnerability is restricted to cases where people share the same 
name (e.g., someone else named "Frank Hecker" and I both apply for a 
cert). It might also be useful to have input from some people in the 
Netherlands who have first-hand experience with these CAs and can 
describe actual practices.

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: DigiNotar EV root inclusion request

2008-04-24 Thread Eddy Nigg (StartCom Ltd.)

Frank Hecker:
DigiNotar has applied to add a new root CA certificate to the Mozilla 
root store and enable it for EV, as documented in the following bug:


   https://bugzilla.mozilla.org/show_bug.cgi?id=369357

and in the pending certificates list:

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

I have evaluated this request, as per the mozilla.org CA certificate policy:

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

and plan to officially approve the request after a public comment period.

  
Before going any further and after reading the entries in the bug, it 
seems to me that issue concerning email validation hasn't been 
positively resolved...can you confirm that or provide some explanation?


Also do you have any intention doing something concerning the comment 
https://bugzilla.mozilla.org/show_bug.cgi?id=369357#c37 about the "Staat 
der Nederlanden Root CA" in respect to email validation? Judging from 
the details of that root, this is a legacy root.


--
Regards 


Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto