WISeKey root CA certificate inclusion request
Frank Hecker
root store, as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=371362
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#WISeKey
I have evaluated their request, as per the mozilla.org CA certificate
policy:
http://www.mozilla.org/projects/security/certs/policy/
and plan to approve this request in two weeks time. If you have any
objections, or know of facts which might influence this decision, please
make them known before then.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg (StartCom Ltd.)
Concerning this request I'd like to know a little bit more about the
physical protection requirements of the current and future sub CAs
according to what was stated at the bug. I've been reading the
information (and documents) mentioned in comment 12
https://bugzilla.mozilla.org/show_bug.cgi?id=371362#c12 and I'd prefer
to receive some more information....shall I post the question on the bug
directly in order to receive a reply or do you have the answer perhaps?
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Frank Hecker
> Concerning this request I'd like to know a little bit more about the
> physical protection requirements of the current and future sub CAs
> according to what was stated at the bug. I've been reading the
> information (and documents) mentioned in comment 12
> https://bugzilla.mozilla.org/show_bug.cgi?id=371362#c12 and I'd prefer
> to receive some more information....shall I post the question on the bug
> directly in order to receive a reply or do you have the answer perhaps?
At the moment I can't recall what the situation was here, please feel
free to ask in the bug.
Eddy Nigg (StartCom Ltd.)
Eddy Nigg (StartCom Ltd.)
https://bugzilla.mozilla.org/show_bug.cgi?id=371362 after a request for
more information was made by me. Is there a way to wake them up somehow?
Just want to make sure, that they are aware that there are some
questions and that the comment period (and eventual approval) will not
be delayed unnecessary.
Eddy Nigg (StartCom Ltd.)
> https://bugzilla.mozilla.org/show_bug.cgi?id=371362 after a request for
> more information was made by me. Is there a way to wake them up somehow?
> Just want to make sure, that they are aware that there are some
> questions and that the comment period (and eventual approval) will not
> be delayed unnecessary
representative of WISeKey at the bug
https://bugzilla.mozilla.org/show_bug.cgi?id=371362
My impression from the exchange of information is positive (professional
and honest)!
However I'm concerned about a by-product WISeKey is marketing, called
Blackbox. Specially the lower range products as outlined in
http://www.wisekey.com/NR/rdonlyres/BA29BF9E-C56E-4FB2-A780-A85617892096/0/cidclassed.pdf
are in my view very problematic what physical security, control and
governance concerns. Basically a customer will be able to download a
piece of software from the Internet, which gives him a sub CA of
WISeKey. Auditing of the system, the physical conditions or compliance
to the CPS are not guarantied, neither by the auditor of WISeKey,
WISeKey themselves or any other third party. Modification of the
software can go undetected, so does other non-compliance by such a
customer. There are some other points together with the ones mentioned
above which in my opinion may make such a sub CA unsuitable for
inclusion in NSS. Since these sub CAs are signed from the WISeKey CA
root, this could be a valid reason for objecting to the inclusion request.
At this stage I highly suggest that other members of the list study this
subject and the points I have raised here in order to get a clearer
picture and a second or third opinion. Please review the comments at the
bug and the documents provided by WISeKey.
Frank Hecker
> In the meantime I've received some very good comments from the
> representative of WISeKey at the bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=371362
> My impression from the exchange of information is positive (professional
> and honest)!
Thanks for your looking at the WISeKey documents in detail.
> However I'm concerned about a by-product WISeKey is marketing, called
> Blackbox. Specially the lower range products as outlined in
> http://www.wisekey.com/NR/rdonlyres/BA29BF9E-C56E-4FB2-A780-A85617892096/0/cidclassed.pdf
> are in my view very problematic what physical security, control and
> governance concerns. Basically a customer will be able to download a
> piece of software from the Internet, which gives him a sub CA of
> WISeKey.
>
> Auditing of the system, the physical conditions or compliance
> to the CPS are not guarantied, neither by the auditor of WISeKey,
> WISeKey themselves or any other third party. Modification of the
> software can go undetected, so does other non-compliance by such a
> customer.
It would be good to get more information about what WISeKey's practices
are, especially in terms of any agreements it puts in place with
customers of the Blackbox product. However I think in the end we also
have to look at the possible security threats for typical users of
Mozilla-based products (which is what our policy is designed to
address), and how any such security threats relate to similar threats
not addressed by our policy.
As I understand it from reading bug 371362, the customer CAs enabled by
the Blackbox product are so-called "standard" CAs constrained to issuing
certificates within the customer's domain. So the consequence of a
security failure on the part of the Blackbox customer (e.g., failure to
properly secure the CA private key) would be that an attacker could
issue fraudulent certificates for SSL servers or email accounts within
that domain. (Code signing certs are not an issue here, since WISeKey
hasn't requested that the code signing trust bit be enabled.) Such
fraudulent certificates could be "clones" of existing certificates
(e.g., referencing the same FQDN as an existing SSL-enabled server) or
new certificates (e.g., for a new server with a FQDN appearing to be
within the customer's domain).
Maybe I'm missing something here, but the level of security threat here
appears to be roughly comparable to that posed by the Blackbox customer
having a server hacked or having a server's SSL key compromised. In
essence the attacker can impersonate one of the customer's sites for
malicious purposes (e.g., collecting credit card info or whatever);
however the threat is limited to that customer's domain. Our policy
doesn't address server hacking at all, and doesn't impose any special
requirements relating to key protection for individual servers. (Many if
not most such servers store SSL private keys on disk in any case,
without any protection other than OS access controls).
It's true that compromise of a customer's subordinate CA private key
would actually be more equivalent to a key compromise on all of that
customer's servers, not just one, since an attacker could forge a cert
for any server in the customer's domain. However IMO that's still not
comparable to a CA compromise that allows forging of arbitrary certs in
any domain.
Now in practice it would be good if WISeKey had agreements in place with
Blackbox customers that put some onus on customers to protect their
Blackbox subordinate CA keys, and imposed some sort of consequence if
they failed to do so, most notably revoking the subordinate CA
certificate. (This would be comparable to typical subscriber agreements
for organizations obtaining end entity certs.) I think it's reasonable
to ask WISeKey to provide information on what types of agreements, if
any, it uses with Blackbox customers.
However I'm not sure I want to base a decision on WISeKey's inclusion on
the exact details of how Blackbox customers are required to protect
keys or related issues. Our policy really doesn't extend to specifying
such things, and as discussed above I don't think the potential security
threat necessarily rises to a level that would warrant special action on
our part over and above what the policy says.
(I should also note that I think this is not a unique situation with
WISeKey. Someone can correct me on this, but I think we have other CAs
in the root list that authorize individual customers to act as
subordinate CAs, using either CA-provided software or third-party PKI
software. To the degree that these are legacy CAs whose roots were in
the NSS list prior to our adopting our policy, we've never taken a hard
look at what such CAs are doing in terms of customer agreements, etc.
That's another factor that I have to take into consideration; I've been
and remain reluctant to hold new CA applicants to standards that aren't
clearly spelled out in our policy, if we're not yet applying those same
standards to older CAs.)
Eddy Nigg (StartCom Ltd.)
> It would be good to get more information about what WISeKey's practices
> are, especially in terms of any agreements it puts in place with
> customers of the Blackbox product. However I think in the end we also
> have to look at the possible security threats for typical users of
> Mozilla-based products (which is what our policy is designed to
> address), and how any such security threats relate to similar threats
> not addressed by our policy.
>
> As I understand it from reading bug 371362, the customer CAs enabled by
> the Blackbox product are so-called "standard" CAs constrained to issuing
> certificates within the customer's domain. So the consequence of a
> security failure on the part of the Blackbox customer (e.g., failure to
> properly secure the CA private key) would be that an attacker could
> issue fraudulent certificates for SSL servers or email accounts within
> that domain.
compromised system - no matter why and how it was compromised - is a
compromised system. In such a case, any limitation put into place by the
CA will be essentially _useless_!!!! The system is already compromised,
why would you believe that it's still bound to a certain domain? There
is no way to limit a CA certificate to a certain domain name only.
> (Code signing certs are not an issue here, since WISeKey
> hasn't requested that the code signing trust bit be enabled.)
opinion!
> Such fraudulent certificates could be "clones" of existing certificates
> (e.g., referencing the same FQDN as an existing SSL-enabled server) or
> new certificates (e.g., for a new server with a FQDN appearing to be
> within the customer's domain).
>
> Maybe I'm missing something here, but the level of security threat here
> appears to be roughly comparable to that posed by the Blackbox customer
> having a server hacked or having a server's SSL key compromised.
event, which must be recovered accordingly (disaster recovery). Many CA
policies require under such circumstances a full review of the CA
systems, policy review and re-audit. This is one of the most sever
events a CA could ever have!
> In essence the attacker can impersonate one of the customer's sites for
> malicious purposes (e.g., collecting credit card info or whatever);
> however the threat is limited to that customer's domain. Our policy
> doesn't address server hacking at all, and doesn't impose any special
> requirements relating to key protection for individual servers. (Many if
> not most such servers store SSL private keys on disk in any case,
> without any protection other than OS access controls).
>
does very much indirectly. There are various conditions the CA policy
does require, just take for example certain minimal validation methods.
Now, without adequate security requirements, which are common industry
standard usually, the minimal validations of certificates are
jeopardized, like if they are non-existent. Hence this would be
non-conformance of the CA policy, even so the policy doesn't anywhere
explicitly say so.
Please also note that the AICPA criteria doesn't _require_ any specific
security standard, but confirms the policies and CSPs of the CA. This
could be actually just anything, including having the CA servers
connected at an Internet Kiosk somewhere... Because of that we are still
reading the CP/CPSs of the CAs requesting inclusion. Now, adequate
security implementations, being it physical protection or hardware and
software related are a _pre-condition_ for fulfilling other obligations
and conditions of the Mozilla CA policy!
> It's true that compromise of a customer's subordinate CA private key
> would actually be more equivalent to a key compromise on all of that
> customer's servers, not just one, since an attacker could forge a cert
> for any server in the customer's domain. However IMO that's still not
> comparable to a CA compromise that allows forging of arbitrary certs in
> any domain.
I believe something must have seriously distracted your attention when
you wrote this (why shouldn't a compromised system be able to issue
certificates for anything, hey, it's already compromised?!).
But to take it a step further, the sub CA and application (software) are
going to be downloaded from the WISeKey, installed (correctly or not) on
a server without WISeKey having never, ever seen the physical conditions
nor other common requirements placed usually on on-line CA systems. I'm
not speaking here about auditing by a third party, but about taking
responsibility and control by the CA!
Since this is admitted by WISeKey - and I really appreciate their
honesty in that - I must object to the inclusion for now on the grounds
that adequate security requirements aren't met, which are a
pre-condition to fulfilling various parts of the Mozilla CA policy.
> Now in practice it would be good if WISeKey had agreements in place with
> Blackbox customers that put some onus on customers to protect their
> Blackbox subordinate CA keys, and imposed some sort of consequence if
> they failed to do so, most notably revoking the subordinate CA
> certificate. (This would be comparable to typical subscriber agreements
> for organizations obtaining end entity certs.) I think it's reasonable
> to ask WISeKey to provide information on what types of agreements, if
> any, it uses with Blackbox customers.
>
I believe that WISeKey does have such agreements, however if they aren't
enforced they are pretty useless! I wouldn't object if the CP/CPS of
WISeKey has clear procedures in place to control and audit such systems,
including physical delivery of the CA systems/servers to the customer,
adequate security requirements in place and more. But that's not what it
is....
> However I'm not sure I want to base a decision on WISeKey's inclusion on
> the exact details of how Blackbox customers are required to protect
> keys or related issues. Our policy really doesn't extend to specifying
> such things, and as discussed above I don't think the potential security
> threat necessarily rises to a level that would warrant special action on
> our part over and above what the policy says.
>
As explained earlier it does that very much, guess I made the point
clearly enough above, otherwise I'll try to explain that again and better.
> (I should also note that I think this is not a unique situation with
> WISeKey. Someone can correct me on this, but I think we have other CAs
> in the root list that authorize individual customers to act as
> subordinate CAs, using either CA-provided software or third-party PKI
> software. To the degree that these are legacy CAs whose roots were in
> the NSS list prior to our adopting our policy, we've never taken a hard
> look at what such CAs are doing in terms of customer agreements, etc.
> That's another factor that I have to take into consideration; I've been
> and remain reluctant to hold new CA applicants to standards that aren't
> clearly spelled out in our policy, if we're not yet applying those same
> standards to older CAs.)
Not only legacy roots! However to all of my knowledge the CAs I know
don't deliver the software to the customer over the Internet without
having been present at the premise nor placed and confirmed various
conditions for operating such a sub CA. I think there are lines we
shouldn't cross and I believe that this is one. Additionally I suggest
that if somebody knows of any similar practice by a CA already included
in NSS to come forward and have it examined accordingly here!
Nelson Bolyard
> As I understand it from reading bug 371362, the customer CAs enabled by
> the Blackbox product are so-called "standard" CAs constrained to issuing
> certificates within the customer's domain. So the consequence of a
> security failure on the part of the Blackbox customer (e.g., failure to
> properly secure the CA private key) would be that an attacker could
> issue fraudulent certificates for SSL servers or email accounts within
> that domain. (Code signing certs are not an issue here, since WISeKey
> hasn't requested that the code signing trust bit be enabled.)
If the CA cert that Wisekey issues to the blackbox CA has the appropriate
"name constraints" extension present, then your description above *should*
be correct. However, see bug 394919. I would add that I have never seen
a CA cert with a name constraints extension outside of a PKI test suite.
Do we have URLs of live SSL servers on the Internet that have server certs
issued by these "blackbox" CAs? If so, we could easily examine those
CA certs ...
> (I should also note that I think this is not a unique situation with
> WISeKey. Someone can correct me on this, but I think we have other CAs
> in the root list that authorize individual customers to act as
> subordinate CAs, using either CA-provided software or third-party PKI
> software.
Yes, we do. IINM, at least one of the root CAs in our list does NOTHING
but sell CA certs to subordinate CAs. It does not issue any EE certs at
all.
If it doesn't already, Mozilla's policy may well need to put in place
some sort of explicit requirements about the controls that a trusted
root CA must impose on its subordinates.
> That's another factor that I have to take into consideration; I've been
> and remain reluctant to hold new CA applicants to standards that aren't
> clearly spelled out in our policy, if we're not yet applying those same
> standards to older CAs.)
Well, there's no time like the present to get started on applying the
policy to all certs in the list. :) Doing so would lay a lot of long
standing criticism to rest, I think.
/Nelson
Nelson Bolyard
> [...] any limitation put into place by the
> CA will be essentially _useless_!!!! The system is already compromised,
> why would you believe that it's still bound to a certain domain? There
> is no way to limit a CA certificate to a certain domain name only.
Eddy, I think perhaps you misunderstand what Frank was saying.
The rest of your argument in the message to which I am reply seems to
hinge on this assumption that "there is no way to limit a [subordinate]
CA to a certain domain". But in fact there *IS* a way for a superior
CA to constrain the name space in which a subordinate CA may issue certs.
Certs issued by the subordinate CA that attempt to certify names outside
of the constrained space fail to pass validation checks.
The superior CA puts a "Name Constraints" extension into the subordinate
CA's cert. Those extensions will be examined in the course of verifying any
cert issued by the subordinate CA. If the extension says (say)
"Only names in the domain foo.com" and the subordinate CA attempts to
issue a cert for a name in bar.com, that cert will not pass verification.
Or it shouldn't. But see bug 394919.
/Nelson
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote, On 2008-02-08 14:47:
>
>
>> [...] any limitation put into place by the
>> CA will be essentially _useless_!!!! The system is already compromised,
>> why would you believe that it's still bound to a certain domain? There
>> is no way to limit a CA certificate to a certain domain name only.
>>
>
> Eddy, I think perhaps you misunderstand what Frank was saying.
>
> The rest of your argument in the message to which I am reply seems to
> hinge on this assumption that "there is no way to limit a [subordinate]
> CA to a certain domain". But in fact there *IS* a way for a superior
> CA to constrain the name space in which a subordinate CA may issue certs.
> Certs issued by the subordinate CA that attempt to certify names outside
> of the constrained space fail to pass validation checks.
>
did I ever see such a restricted CA in real life. If this is the case
with the intermediate CA issued by WISeKey, one quarter or my argument
wouldn't be valid. Maybe....
...and only maybe, because the user using an application with NSS (being
it FF, TB or anything else) is the relying party, not the XYZ customer
of some sub CA. It could be me, you or anybody else receiving a mail or
visiting a site which was issued from such a compromised system. Hence
it just limits the scope of the compromise, not the severity itself.
Therefore even if the CA indeed limits the domain with the name
constraints, the relying party can still fall victim. It's a very common
mistake to think that digital certification is about the subscriber or
issuer, but it's really about the relying parties, Mozilla itself being
one...
> The superior CA puts a "Name Constraints" extension into the subordinate
> CA's cert. Those extensions will be examined in the course of verifying any
> cert issued by the subordinate CA. If the extension says (say)
> "Only names in the domain foo.com" and the subordinate CA attempts to
> issue a cert for a name in bar.com, that cert will not pass verification.
>
> Or it shouldn't. But see bug 394919.
>
This bug actually confirms that NSS can't handle name constraints
correctly....not nice...
Nelson Bolyard
> Nelson Bolyard wrote:
>> Eddy Nigg (StartCom Ltd.) wrote, On 2008-02-08 14:47:
>>
>>> [...] any limitation put into place by the
>>> CA will be essentially _useless_!!!! The system is already compromised,
>>> why would you believe that it's still bound to a certain domain? There
>>> is no way to limit a CA certificate to a certain domain name only.
>>>
>> Eddy, I think perhaps you misunderstand what Frank was saying.
>>
>> The rest of your argument in the message to which I am reply seems to
>> hinge on this assumption that "there is no way to limit a [subordinate]
>> CA to a certain domain". But in fact there *IS* a way for a superior
>> CA to constrain the name space in which a subordinate CA may issue certs.
>> Certs issued by the subordinate CA that attempt to certify names outside
>> of the constrained space fail to pass validation checks.
>>
> Thanks Nelson! As you indicated in your previous mail, neither you nor
> did I ever see such a restricted CA in real life. If this is the case
> with the intermediate CA issued by WISeKey, one quarter or my argument
> wouldn't be valid. Maybe....
>
> ...and only maybe, because the user using an application with NSS (being
> it FF, TB or anything else) is the relying party, not the XYZ customer
> of some sub CA. It could be me, you or anybody else receiving a mail or
> visiting a site which was issued from such a compromised system. Hence
> it just limits the scope of the compromise, not the severity itself.
Yes, and (assuming that our name constraints extension handling code is
working properly), we would not be fooled at all. We would find the cert
to be invalid.
Name constraints don't stop the issuer from issuing bogus certs. They stop
the relying party from mistakenly relying on bogus certs.
> Therefore even if the CA indeed limits the domain with the name
> constraints, the relying party can still fall victim. It's a very common
> mistake to think that digital certification is about the subscriber or
> issuer, but it's really about the relying parties, Mozilla itself being
> one...
If a subordinate CA's cert is constrained to issue certs only for names
in the domain foo.com, and the CA issues a cert for a name in bar.com,
and a relying party has correctly working name constraints handling,
then the relying party will not compromised by that bar.com cert, because
the relying party will find it to be invalid.
Now the question has arisen as to whether other software (than NSS)
implements name constraints correctly, or at all. There is an open question
as to whether or not Windows (and IE) implement it correctly
or at all. If not, IE users would be vulnerable to certs that violate
their name constraints.
But I submit that that question is irrelevant. Mozilla's policy governs
certificates that will be used by NSS-based software, which includes most
(not all) of Mozilla's products. Mozilla's policy attempts to ensure that
the security of Mozilla's products' users will be adequately protected when
certs issued by CAs in its trusted root list are relied upon by Mozilla's
NSS-based software. Mozilla's policy does not state that the CA certs
approved for Mozilla's trusted CA list are "safe" for use in any other
products than Mozilla's NSS-based products. (Right Frank? :)
This suggests to me that Mozilla should NOT approve for inclusion any
certs for root CAs that rely on any constraining cert extensions
(name constraints aren't the only ones) that are not implemented in NSS.
It also speaks to a question you asked in another thread, about some other
product, not NSS based, that is relying on the CA certs in Mozilla's trusted
CA list. If that product does not implement all the certificate controls
implemented in NSS, then it could be that users of that product will NOT
be adequately protected by relying on the root CA certs chosen by mozilla
for its own products.
I might even suggest that Mozilla's root CA policy be amended to explicitly
disclaim any responsibility for security of users who rely on the certs in
Mozilla's root CA list, but use them with other non-Mozilla software.
/Nelson
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote, On 2008-02-08 18:01:
>
> ...and only maybe, because the user using an application with NSS (being
> it FF, TB or anything else) is the relying party, not the XYZ customer
> of some sub CA. It could be me, you or anybody else receiving a mail or
> visiting a site which was issued from such a compromised system. Hence
> it just limits the scope of the compromise, not the severity itself.
>
>
> Yes, and (assuming that our name constraints extension handling code is
> working properly), we would not be fooled at all. We would find the cert
> to be invalid.
>
> Name constraints don't stop the issuer from issuing bogus certs. They stop
> the relying party from mistakenly relying on bogus certs.
>
But back to our issue, if a compromised server issues a certificate from
within the name constraint and uses it to attack another user (by
claiming to send mail from re...@allowed-domain.com or setting up a fake
site for https://really.allowed-domain.com), this would be the classical
MITM vector SSL is meant to prevent. Hence it doesn't matter really if
there is or isn't a name constraint, just the range of possible attacks
is limited.
CAs which issue sub CAs without taking responsible actions to control,
verify and guide them, are suspected to being compromised right from the
beginning. Without insisting on this, we can just stop reviewing CAs
altogether and save us the hassle...
>
> Now the question has arisen as to whether other software (than NSS)
> implements name constraints correctly, or at all. There is an open question
> as to whether or not Windows (and IE) implement it correctly
> or at all. If not, IE users would be vulnerable to certs that violate
> their name constraints.
>
Which is completely off-topic ;-)
>
> This suggests to me that Mozilla should NOT approve for inclusion any
> certs for root CAs that rely on any constraining cert extensions
> (name constraints aren't the only ones) that are not implemented in NSS.
>
This argument however might be very important when evaluating CAs for
inclusion...I'm not aware of any such circumstances right now. Even
WISeKey hasn't yet confirmed if they use constraints at all. Haven't
seen anything in their CP/CPS, but might have missed it? No, the
limitations are in the software to all of my knowledge...
> It also speaks to a question you asked in another thread, about some other
> product, not NSS based, that is relying on the CA certs in Mozilla's trusted
> CA list. If that product does not implement all the certificate controls
> implemented in NSS, then it could be that users of that product will NOT
> be adequately protected by relying on the root CA certs chosen by mozilla
> for its own products.
>
> I might even suggest that Mozilla's root CA policy be amended to explicitly
> disclaim any responsibility for security of users who rely on the certs in
> Mozilla's root CA list, but use them with other non-Mozilla software.
A valid argument which deserves its own thread perhaps. I'm not sure if
Mozilla takes any responsibility to start with (strictly legalese
speaking)..
Frank Hecker
> Eddy, I think perhaps you misunderstand what Frank was saying.
Yes.
> The rest of your argument in the message to which I am reply seems to
> hinge on this assumption that "there is no way to limit a [subordinate]
> CA to a certain domain". But in fact there *IS* a way for a superior
> CA to constrain the name space in which a subordinate CA may issue certs.
And WISeKey in fact claims that it does impose such constraints, as
noted in various comments in bug 371362 and in its technical security
controls document (as I mentioned in a previous message).
Eddy Nigg (StartCom Ltd.)
>
> And WISeKey in fact claims that it does impose such constraints, as
> noted in various comments in bug 371362 and in its technical security
> controls document (as I mentioned in a previous message).
>
>
https://bugzilla.mozilla.org/show_bug.cgi?id=371362#c14 which says
/"However customers are STILL constrained to using domain names that
they own, *but this is done at the application level*, without relying
on the name constraints"/
Not that it really matters for the relying party too much as I mentioned
earlier, even a certificate or email within the allowed domain range in
the hands of the wrong party is an attack. Even more if it remains
undetected...it's not the web site (or individual) which is the victim,
it's the party which relies on it...
/
/
Frank Hecker
> Mozilla's policy governs
> certificates that will be used by NSS-based software, which includes most
> (not all) of Mozilla's products. Mozilla's policy attempts to ensure that
> the security of Mozilla's products' users will be adequately protected when
> certs issued by CAs in its trusted root list are relied upon by Mozilla's
> NSS-based software. Mozilla's policy does not state that the CA certs
> approved for Mozilla's trusted CA list are "safe" for use in any other
> products than Mozilla's NSS-based products. (Right Frank? :)
Our policy addresses certs as included in NSS, and thence in
Mozilla-based products shipped under Foundation auspices that
incorporate NSS. People may choose to use our root CA certificate set in
other contexts, but they are on their own in doing so. (Strictly
speaking we can't even take responsibility for use of NSS and its root
list in Mozilla-based products shipped by third parties; however in
practice the security issues for such products are likely to be the same
as for Firefox et.al.)
> This suggests to me that Mozilla should NOT approve for inclusion any
> certs for root CAs that rely on any constraining cert extensions
> (name constraints aren't the only ones) that are not implemented in NSS.
This sounds reasonable at first glance, but I admit to being a bit leary
about adopting such a policy. If we generalized this to something like
"Mozilla should NOT approve for inclusion any certs for root CAs that
rely on features not implemented in NSS", then, for example, it seems we
would never approve any CAs that provide CRLs for EE cert revocation
checking but not OCSP, given that NSS doesn't currently implement CRL
checking by default.
(Begin digression. This takes me back to a previous offer of mine: If
there are features gaps in NSS that should be fixed, and they're not
going to get fixed given resource constraints on the current NSS
developer groups, I'd be happy to entertain requests to have the Mozilla
Foundation fund the work. End digression.)
Getting back to the point under discussion: Perhaps it would help if you
could describe exactly which other constraining cert extensions a CA
might use that are not implemented in NSS. Then we could determine what
the practical effect would be of your suggested policy change.
> I might even suggest that Mozilla's root CA policy be amended to explicitly
> disclaim any responsibility for security of users who rely on the certs in
> Mozilla's root CA list, but use them with other non-Mozilla software.
That might not be a bad idea for a future revision.
Eddy Nigg (StartCom Ltd.)
> This sounds reasonable at first glance, but I admit to being a bit leary
> about adopting such a policy. If we generalized this to something like
> "Mozilla should NOT approve for inclusion any certs for root CAs that
> rely on features not implemented in NSS", then, for example, it seems we
> would never approve any CAs that provide CRLs for EE cert revocation
> checking but not OCSP, given that NSS doesn't currently implement CRL
> checking by default.
>
...but it's also a said issue. As I understood from Nelson, this has
something to do with some patents, so even I think it to be outright
ridiculous, how following a URI for fetching a file can be patented.
This is perhaps the greatest shortcoming of NSS up to date.
Gervase Markham
> This suggests to me that Mozilla should NOT approve for inclusion any
> certs for root CAs that rely on any constraining cert extensions
> (name constraints aren't the only ones) that are not implemented in NSS.
This seems wise to me.
I take Frank's point about CRL revocation checking. However, that's a
historically unusual case. It does seem to me that if Mozilla is not
correctly respecting name constraints, then that's a serious problem
that needs to be fixed and, if there is a CA whose security model relies
on such constraints, we should not admit them until we can meet that
requirement.
Of course, WISeKey themselves may want to fund the work, if they see
that it's blocking their inclusion.
> I might even suggest that Mozilla's root CA policy be amended to explicitly
> disclaim any responsibility for security of users who rely on the certs in
> Mozilla's root CA list, but use them with other non-Mozilla software.
This too seems wise.
Gerv
Gervase Markham
> within the name constraint and uses it to attack another user (by
> claiming to send mail from re...@allowed-domain.com or setting up a fake
> site for https://really.allowed-domain.com), this would be the classical
> MITM vector SSL is meant to prevent. Hence it doesn't matter really if
> there is or isn't a name constraint, just the range of possible attacks
> is limited.
As I understand it, if a Blackbox customer loses control of their
private key, the only person who has a problem is that customer (their
websites and email can be spoofed). So it's in their best interests to
keep it secure, and I'm sure WISeKey will make that clear to them.
The point is that their security destiny is in their own hands. This is
not like a root CA key compromise, where even people who aren't
customers of that CA can be affected.
> CAs which issue sub CAs without taking responsible actions to control,
> verify and guide them, are suspected to being compromised right from the
> beginning. Without insisting on this, we can just stop reviewing CAs
> altogether and save us the hassle...
There's a difference between "sub-CAs" (where your point is valid) and
"sub-CAs with name constraints" (where I suggest that it is not).
Gerv
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> But back to our issue, if a compromised server issues a certificate from
>> within the name constraint and uses it to attack another user (by
>> claiming to send mail from re...@allowed-domain.com or setting up a fake
>> site for https://really.allowed-domain.com), this would be the classical
>> MITM vector SSL is meant to prevent. Hence it doesn't matter really if
>> there is or isn't a name constraint, just the range of possible attacks
>> is limited.
>>
>
> As I understand it, if a Blackbox customer loses control of their
> private key, the only person who has a problem is that customer (their
> websites and email can be spoofed).
email (even encrypted) and you are going to trust your VISA and other
personal data to a spoofed email or web site, issued by such a Blackbox
CA? Is it really, really only the problem of the customer?
So lets play with it a little bit:
Take #1:
The "First International Bank of Thailand" is the proud owner of a
Blackbox CA root with naming constraints for only their domain names for
emails .
The bank hosts it's server, an oldish Pentium, in the kitchen room under
the kitchen sink where the staff makes their coffee in the morning
hours. Nobody cares about this little server, not the bank and not the
issuing CA. The server reports every day to the issuing CA about the
certificates it issued to the parent CA through the software which the
bank IT stuff received over Internet downloaded and dutifully installed.
Take #2:
The bank also contracted a manpower company for cleaning their offices
during the night. Now every night the cleaning boy, hired by the
manpower company, is visiting our nice little "Kitchen Sink CA". During
the day he is studying at the University of Thailand, during the night
he earns some money to finance his studies....but soon he will have
another nice income.
Take #3:
Our cleaning boy is a smart person and learns about our little CA
server. He takes his time during his nightly visits and learns the
system and also that there is no hardware intrusion detection. He
creates a perfect image of the disk, which is btw. unencrypted and
starts issuing client certificates in the name of the bank of Thailand.
Once finished, he returns the server to its initial state. During the
day our little server keeps ticking as usual and is dutifully sending
its audit report to the issuing CA.
Take #4:
Gerv and Frank, both tech savvy and long standing customers of the bank
are used to receive correspondence from the bank via emails signed with
a digital certificate. Gerv and Frank always check the digital signature
and know it's issued from a CA their software trusts. So they don't get
suspicious the day they receive an email requesting some information.
However they don't know that they are in fact sending their social
security number and VISA number and (insert whatever you want here) to
our ambitious friend, the cleaning boy.
Take #5:
The cleaning boy is now busy during the day with sending emails to the
customers of the bank and selling the information to the hAckrz gr0up of
China. And so the personal details of Frank and Gerv are floating
around....After a while they realized that their information has been
compromised, however they don't suspect anybody initially, certainly not
their trustful bank. Only after a long time and after many affected
customers of the bank, is the bank suspected. It takes even longer to
suspect our cleaning boy and month pass until this successful scheme is
stopped.
Take #6:
The issuing CA doesn't takes any responsibility, because they acted
perfectly according to their own policies. They never promised auditing
of the systems and customers in first place. The bank of Thailand has
its "Kitchen Sink CA" suspended, the IT manager fired, but Frank and
Gerv have no way to prove that their privacy was invaded and that they
potentially lost some money because of the bank's actions. Also the bank
has much better lawyers, so Frank and Gerv never recover the damage.
Conclusion: A compromised CA can affect any party involved, even for
client certificates and even with name constraints. Of course you
understand that the above is just an example and can be played in many
different ways....
> So it's in their best interests to
> keep it secure, and I'm sure WISeKey will make that clear to them.
>
And what if not? There is nobody going to control and verify that. There
are no guaranties given. This simply isn't how CAs work. You don't build
the trust on assumptions and goodwill, but by implementing controls. Not
even speaking about multiple locations for CRLs for the case the CA
server is down and other issues, which is simply not worth investing the
time right now...
> The point is that their security destiny is in their own hands.
No, not at all! It's _your_ security in _their_ hands - because you rely
on it. Also note that the CA is as strong as its weakest link. NSS and
the software which make use of it are as weak as its weakest CA. Mozilla
has a established a policy to define exactly what the weakest link is
going to be in order to protect its users. (In relation to that, there
is currently an article published at Netcraft's Secure Server Survey:
http://news.netcraft.com/SSL-Survey/ (Scroll down to StartCom), which
was viewed back then perhaps as the weakest link ;-))
> This is
> not like a root CA key compromise, where even people who aren't
> customers of that CA can be affected.
>
For CAs which need a PKI implementation for their internal use, they
should use only a self-issued CA root, which they decided to trust. If
others from outside that circle should be able to trust those
certificates and if the CA has a relevance for users of Mozilla
products, than that root must conform to an accepted norm and security
standard.
There must be a line drawn between these two cases, either it has
relevance for the users of Mozilla and in that case is a relying party
with all its implications or it has no relevance to the users of Mozilla
products and mustn't be part of NSS! It can't be both IMO.
>
>> CAs which issue sub CAs without taking responsible actions to control,
>> verify and guide them, are suspected to being compromised right from the
>> beginning. Without insisting on this, we can just stop reviewing CAs
>> altogether and save us the hassle...
>>
>
> There's a difference between "sub-CAs" (where your point is valid) and
> "sub-CAs with name constraints" (where I suggest that it is not).
>
>
In which case it perhaps shouldn't be there anyway, see above.
Gervase Markham
> So it would be fine with you, if you've received a signed document or
> email (even encrypted) and you are going to trust your VISA and other
> personal data to a spoofed email or web site, issued by such a Blackbox
> CA?
It wouldn't be fine with me; my point is that (speaking as the Mozilla
Project) it's Not Our Problem. When the customer finds out there's a
problem, he should revoke his cert, and our products should honour the
revocation - just as for any compromised cert. (If we don't honour the
revocation, that's a separate problem.) That's what happens when certs
are compromised.
> Is it really, really only the problem of the customer?
>
> So lets play with it a little bit:
You don't need to invent a long scenario. Simply: disgruntled bank
employee steals private key and, using it, steals customer data. How is
this different to them stealing the private key for the bank's email
signing cert? Or web server cert?
The point is, it's not the problem of the Mozilla Foundation to make
sure that the First International Bank of Thailand has good security, as
long as any breaches of it can only affect the FIBOT and its customers.
If I'm a customer of FIBOT and I get scammed because of something they
did, I change bank and tell all my friends to do the same. That's how a
marketplace works.
> The issuing CA doesn't takes any responsibility, because they acted
> perfectly according to their own policies. They never promised auditing
> of the systems and customers in first place. The bank of Thailand has
> its "Kitchen Sink CA" suspended, the IT manager fired, but Frank and
> Gerv have no way to prove that their privacy was invaded and that they
> potentially lost some money because of the bank's actions. Also the bank
> has much better lawyers, so Frank and Gerv never recover the damage.
Yeah, life sucks, doesn't it?
All of your scenario could still happen if we forced the CA to make the
FIBOT sign some contract about keeping their key safe. Just because
there's a contract doesn't mean the FIBOT would keep to it; even if they
did, that doesn't mean that no insider has a copy of the private key.
>> The point is that their security destiny is in their own hands.
> No, not at all! It's _your_ security in _their_ hands - because you rely
> on it. Also note that the CA is as strong as its weakest link. NSS and
> the software which make use of it are as weak as its weakest CA.
I only agree that this is true for root certificates.
Gerv
Kyle Hamilton
recently pointed out to me. The business models of commercial CAs
involves what is essentially "selling trust".
If you look at the fact that they have no real accountability, no
procedure in place in any of the browsers to revoke their trust as a
matter of policy if they violate their CSPs, and a need to maintain a
positive cash flow, you will quickly see that there are severe
conflicts of interest inside the individual organizations.
(If you don't believe my assertion that there is no means to remove
root certificate trust as a matter of policy, I am still waiting for
action on Thawte's issuing of SSL123 certificates by a root which had
a CSP which stated that no SSL server certificates would be issued
without at least "medium assurance" of identity. This issue was
brought up before I moved to my Mac as my primary machine, so over a
year and a half ago.)
Frankly, this entire discussion is utterly and disgustingly ludicrous
in light of this.
Add to this the fact that there is no legal recourse available for
"relying parties" if the CA somehow fails to live up to its CSP, and
the entire argument falls completely on its face.
You all seem to be frighteningly disconnected from the realities of
the situation if you're still arguing the minutae of trust models
allowed by CSPs. I lost my faith in the process you're trying to
follow long ago.
-Kyle H
On Feb 9, 2008, at 6:19, "Eddy Nigg (StartCom Ltd.)" <eddy...@startcom.org
> wrote:
> Gervase Markham wrote:
>> Eddy Nigg (StartCom Ltd.) wrote:
>>
>>> But back to our issue, if a compromised server issues a
>>> certificate from
>>> within the name constraint and uses it to attack another user (by
>>> claiming to send mail from re...@allowed-domain.com or setting up a
>>> fake
>>> site for https://really.allowed-domain.com), this would be the
>>> classical
>>> MITM vector SSL is meant to prevent. Hence it doesn't matter
>>> really if
>>> there is or isn't a name constraint, just the range of possible
>>> attacks
>>> is limited.
>>>
>>
>> As I understand it, if a Blackbox customer loses control of their
>> private key, the only person who has a problem is that customer
>> (their
>> websites and email can be spoofed).
> So it would be fine with you, if you've received a signed document or
> email (even encrypted) and you are going to trust your VISA and other
> personal data to a spoofed email or web site, issued by such a
> Blackbox
> CA? Is it really, really only the problem of the customer?
>
> So lets play with it a little bit:
>
> The issuing CA doesn't takes any responsibility, because they acted
> perfectly according to their own policies. They never promised
> auditing
> of the systems and customers in first place. The bank of Thailand has
> its "Kitchen Sink CA" suspended, the IT manager fired, but Frank and
> Gerv have no way to prove that their privacy was invaded and that they
> potentially lost some money because of the bank's actions. Also the
> bank
> has much better lawyers, so Frank and Gerv never recover the damage.
>
> Conclusion: A compromised CA can affect any party involved, even for
> client certificates and even with name constraints. Of course you
> understand that the above is just an example and can be played in many
> different ways....
>
>> So it's in their best interests to
>> keep it secure, and I'm sure WISeKey will make that clear to them.
>>
> And what if not? There is nobody going to control and verify that.
> There
> are no guaranties given. This simply isn't how CAs work. You don't
> build
> the trust on assumptions and goodwill, but by implementing controls.
> Not
> even speaking about multiple locations for CRLs for the case the CA
> server is down and other issues, which is simply not worth investing
> the
> time right now...
>> The point is that their security destiny is in their own hands.
> No, not at all! It's _your_ security in _their_ hands - because you
> rely
> on it. Also note that the CA is as strong as its weakest link. NSS and
> the software which make use of it are as weak as its weakest CA.
> Mozilla
> has a established a policy to define exactly what the weakest link is
> going to be in order to protect its users. (In relation to that, there
> is currently an article published at Netcraft's Secure Server Survey:
> http://news.netcraft.com/SSL-Survey/ (Scroll down to StartCom), which
> was viewed back then perhaps as the weakest link ;-))
>> This is
>> not like a root CA key compromise, where even people who aren't
>> customers of that CA can be affected.
>>
> For CAs which need a PKI implementation for their internal use, they
> should use only a self-issued CA root, which they decided to trust. If
> others from outside that circle should be able to trust those
> certificates and if the CA has a relevance for users of Mozilla
> products, than that root must conform to an accepted norm and security
> standard.
>
> There must be a line drawn between these two cases, either it has
> relevance for the users of Mozilla and in that case is a relying party
> with all its implications or it has no relevance to the users of
> Mozilla
> products and mustn't be part of NSS! It can't be both IMO.
>>
>>> CAs which issue sub CAs without taking responsible actions to
>>> control,
>>> verify and guide them, are suspected to being compromised right
>>> from the
>>> beginning. Without insisting on this, we can just stop reviewing CAs
>>> altogether and save us the hassle...
>>>
>>
>> There's a difference between "sub-CAs" (where your point is valid)
>> and
>> "sub-CAs with name constraints" (where I suggest that it is not).
>>
>>
> In which case it perhaps shouldn't be there anyway, see above.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
> Jabber: star...@startcom.org <xmpp:star...@startcom.org>
> Blog: Join the Revolution! <http://blog.startcom.org>
> Phone: +1.213.341.0390
>
>
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
Eddy Nigg (StartCom Ltd.)
Kyle Hamilton wrote:
> I'm just going to point out something that a couple of friends
> recently pointed out to me. The business models of commercial CAs
> involves what is essentially "selling trust".
>
> If you look at the fact that they have no real accountability, no
> procedure in place in any of the browsers to revoke their trust as a
> matter of policy if they violate their CSPs, and a need to maintain a
> positive cash flow, you will quickly see that there are severe
> conflicts of interest inside the individual organizations.
>
I'm aware of that very much!
> (If you don't believe my assertion that there is no means to remove
> root certificate trust as a matter of policy, I am still waiting for
> action on Thawte's issuing of SSL123 certificates by a root which had
> a CSP which stated that no SSL server certificates would be issued
> without at least "medium assurance" of identity. This issue was
> brought up before I moved to my Mac as my primary machine, so over a
> year and a half ago.)
>
Of course I'm understanding your disappointment of such a violation.
However the Mozilla CA policy defines only a minimum requirement in its
policy, should this one be breached, it would be a reason for removal.
There is, to my very big disappointment, no way to distinguish between
domain validation and identity validated and/or organization validated
certificates. The only thing which exists today is EV and all the rest.
> Frankly, this entire discussion is utterly and disgustingly ludicrous
> in light of this.
>
Ridiculous? I think, placing a CA root (even with limits) into just
anybodies hands without any verifications and controls in place is
unacceptable. So why should any CA bother to provide third party
attestations, not speaking about actually writing and implementing a
policy etc.? Because some CAs had sloppy procedures in place before that?
> Add to this the fact that there is no legal recourse available for
> "relying parties" if the CA somehow fails to live up to its CSP, and
> the entire argument falls completely on its face.
>
I agree that it's difficult, but not impossible. But you can't sue a CA
which told you upfront what they are not going to do. In this case they
tell us quite frankly that they have no intention to perform any
acceptable controls and verifications. Their CP/CPS says so and with
being that the legal framework, you can't even thinking about suing.
> You all seem to be frighteningly disconnected from the realities of
> the situation if you're still arguing the minutae of trust models
> allowed by CSPs. I lost my faith in the process you're trying to
> follow long ago.
If this is the case, we should allow any CA into NSS, most notably a
certain Australian project. The barrier would be a self-audit, as in the
case of the WISeKey subordinate CAs.
Frank Hecker
> You all seem to be frighteningly disconnected from the realities of the
> situation if you're still arguing the minutae of trust models allowed by
> CSPs. I lost my faith in the process you're trying to follow long ago.
We're all aware that the traditional SSL/PKI/CA mechanism/model/industry
has major problems in both theory and practice. Nevertheless, SSL
exists, CAs exist, and we have to deal with them one way or the other.
As evidenced by past discussions in relation to our Mozilla CA policy,
some people are basically of the opinion that it doesn't matter anyway,
and we should just not worry about vetting CAs; other people think it's
vitally important that we hold CAs to very strict standards. The present
Mozila policy and its application in practice essentially are attempts
to find a middle way; like all compromises, these attempts by nature
will annoy almost everyone and satisfy almost no one. (And I count myelf
among those annoyed and not satisfied.)
We also have the problem that the cure (removal of root certs) is often
seen as worse than the disease (problems with particular CAs), in the
sense that the actual security threat to users is perceived as not
justifying provoking user annoyance at having a whole set of SSL sites
suddenly stop working. So instead of going with the "nuclear option" of
removing root certs, in practice we've fallen back on the alternative of
nagging CAs to improve their practices (of which the issue at hand is
yet another example).
I harbor no illusions that nagging CAs is going to "fix" the SSL/PKI/CA
problem, but I think it has been useful to some degree in terms of
getting CAs to publish better information, make changes to some
practices, and so on. I can't speak for other people, but in this case
(WISeKey) I think it would be useful to have a little more information
about what's going on with regard to these customer-hosted CAs, without
necessarily thinking that that information is going to radically change
my view of the situation one way or another. I'll look again through the
information WISeKey has provided already (which is a fair amount), and
then ask a few more questions if needed.
David E. Ross
After following the discussion about Black Box. Perhaps I don't really
understand. It seems to me, however, that this is not much different
from the situation that prompted my bug report #376853.
That situation involves the AllTrust certificate authority (part of
Comodo), which issued a certificate to USERTRUST Network. USERTRUST
Network then used this certificate (neither one of its USERTRUST Network
root certificates that are in the NSS store nor an intermediate
certificate signed by one of those root certificates) as an intermediate
certificate to act as a certificate authority and issued a certificate
to Network Solutions. In turn, Network Solutions used its certificate
as an intermediate certificate to act as a certificate authority and
issued a site certificate to my bank.
In my bug report, I raised the question regarding what control
AllTrust/Comodo has over Network Solutions given the intermediate role
of USERTRUST Network between them.
See <https://bugzilla.mozilla.org/show_bug.cgi?id=376853>. In comment
#1 to this bug report, Bolyard stated:
> The PKI model really depends on trusting the CAs to control their subordinate
> issuers at all levels. If a root CA proves unworthy in that regard, we should
> expunge its cert from our list.
If this is true -- at ALL levels -- then I don't understand the concern
about Black Box. If this is not true, then I don't understand why my
RFE has not receive serious consideration.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> So it would be fine with you, if you've received a signed document or
>> email (even encrypted) and you are going to trust your VISA and other
>> personal data to a spoofed email or web site, issued by such a Blackbox
>> CA?
>>
>
> It wouldn't be fine with me; my point is that (speaking as the Mozilla
> Project) it's Not Our Problem.
such CA is potentially compromised right from the start. If this CA gets
accepted without requiring changes to their commitment and procedures,
this is exactly what Mozilla is going to approve - knowingly and
willingly! In this case Mozilla will breach indirectly its own policy
perhaps the first time - because adherence to various parts of the
conditions put forward in that policy can't be even assumed.
> When the customer finds out there's a
> problem, he should revoke his cert, and our products should honour the
> revocation - just as for any compromised cert.
first place, the issuing CA being the one not bothering to control its
intermediate CAs...and you still believe that they A) Find out about an
intrusion and compromise, B) Also bother to revoke it (with all the
hassle which might be involved? This makes me laugh...
>
> You don't need to invent a long scenario. Simply: disgruntled bank
> employee steals private key and, using it, steals customer data. How is
> this different to them stealing the private key for the bank's email
> signing cert? Or web server cert?
>
issued certificates, possibly without leaving a trail to whom it was
issued...and most likely there isn't "The One And Only Email Cert Of The
Bank", but perhaps hundreds of them...
> The point is, it's not the problem of the Mozilla Foundation to make
> sure that the First International Bank of Thailand has good security, as
> long as any breaches of it can only affect the FIBOT and its customers.
>
who can be a relying party...
>
> Yeah, life sucks, doesn't it?
>
> All of your scenario could still happen if we forced the CA to make the
> FIBOT sign some contract about keeping their key safe.
to control and verify the implementation of that contract. That's my
point here.
> Just because
> there's a contract doesn't mean the FIBOT would keep to it; even if they
> did, that doesn't mean that no insider has a copy of the private key.
>
system, access control systems and regulations (preferable foolproof as
possible), create the private key together with a representative of the
CA together with other witnesses (called a signing party in CA jargon),
than one can expect a better and more secure system out there. Of course
I'm touching here only the basics of proper subordinate CA
implementations hosted at an external location.
Eddy Nigg (StartCom Ltd.)
> The present Mozila policy and its application in practice essentially are attempts
> to find a middle way; like all compromises, these attempts by nature
> will annoy almost everyone and satisfy almost no one. (And I count myelf
> among those annoyed and not satisfied.)
>
subject (almost obvious? ;-) )...
But I also believe that _because_ of that, Mozilla shouldn't have the
_need_ to compromise further than that. Meaning, if you want to have CAs
improve their practices when needed, you must have also a stick in your
hand, not only a carrot. If you want CAs take you (Mozilla) serious, we
must all take the policy serious in first place. I believe that there is
a line which must be drawn somewhere....I for my part would really like
to know, where this line is, what are the do's and what are the dont's.
> I can't speak for other people, but in this case
> (WISeKey) I think it would be useful to have a little more information
> about what's going on with regard to these customer-hosted CAs, without
> necessarily thinking that that information is going to radically change
> my view of the situation one way or another.
I'm not sure if we need more information, because the information
provided is sufficient enough. We need a decision if their practices in
this specific case are sufficient to satisfy the Mozilla policy or if
the risk is perhaps too high. I believe that WISeKey should be persuaded
to change that practice and I sincerely believe that if they agree to
it, they actually commit and stick to it. I've found ,that they are
knowing very well what they are doing and what they aren't doing. So
there is no issue of honesty or lack of information, but about what they
are prepared to do for their products.
> I'll look again through the
> information WISeKey has provided already (which is a fair amount), and
> then ask a few more questions if needed.
>
>
--
Kyle Hamilton
> We also have the problem that the cure (removal of root certs) is often
> seen as worse than the disease (problems with particular CAs), in the
> sense that the actual security threat to users is perceived as not
> justifying provoking user annoyance at having a whole set of SSL sites
> suddenly stop working. So instead of going with the "nuclear option" of
> removing root certs, in practice we've fallen back on the alternative of
> nagging CAs to improve their practices (of which the issue at hand is
> yet another example).
See, that's the problem... there's also a conflict of interest in
Mozilla (and the other browser vendors). They have to maintain market
share, which means ensuring compatibility -- even when the
compatibility flies in the face of one of the reasons why the CA
program exists in the first place (basically, it was started by
Netscape to make it possible for people to have faith in the
identities of the entities they were giving their credit card numbers
to, in order to facilitate electronic commerce).
The end result is that anyone who chooses to spend a hundred thousand
bucks or so on a single audit can then go around selling the benefit
of their inclusion in the trust list to the highest bidder without
fear of repercussion. Which is what they've been doing. And nobody
has the balls to stand up and say "user security is more important
than user convenience". (In addition, roots have been sold to other
companies, which have not passed continuing conformance audits.)
With this kind of a view, it's more of a "you have to have money and
spend money to make money" game than any kind of attempt to adhere to
the principles that actually allow the system to be 'secure'.
Without fear of delisting and decertification, CAs are running
roughshod (not just 'are going to run roughshod', but 'ARE RUNNING
roughshod'), making a farce of the process and the 'trust' in place.
Without a clear view of user security held by a majority of the
Mozilla Foundation board, everything that happens on this list with
respect to CA inclusion requests is as effective as pseudointellectual
masturbation.
Not that my vote counts for anything since I'm not a member of MoFo,
but until these issues are resolved I must vote 'nay' to any
additional inclusion requests under the current guidelines.
-Kyle H
Nelson Bolyard
> (If you don't believe my assertion that there is no means to remove
> root certificate trust as a matter of policy, I am still waiting for
> action on Thawte's issuing of SSL123 certificates by a root which had
> a CSP which stated that no SSL server certificates would be issued
> without at least "medium assurance" of identity. This issue was
> brought up before I moved to my Mac as my primary machine, so over a
> year and a half ago.)
Kyle, If you believe that some trusted root CA in mozilla's list is
continuing to operate in violation of its own CPS (not CSP), then
you should file a bug in bugzilla.mozilla.org about that
(product: mozilla.org, component: CA Certificates).
Have you done so?
/Nelson
Eddy Nigg (StartCom Ltd.)
> Without fear of delisting and decertification, CAs are running
> roughshod (not just 'are going to run roughshod', but 'ARE RUNNING
> roughshod'), making a farce of the process and the 'trust' in place.
> Without a clear view of user security held by a majority of the
> Mozilla Foundation board, everything that happens on this list with
> respect to CA inclusion requests is as effective as pseudointellectual
> masturbation.
>
>
great injustice to some of us here, specially to the ones which bother
to review the CAs. Also Frank and Gerv invest quite some time into
getting this right, starting from reviewing the bugs, keeping track of
all the CAs respective statuses and so forth (see
http://www.mozilla.org/projects/security/certs/pending/ for example).
The handling of everything related to CAs has reached levels, I believe
Frank never envisioned. There is a huge amount of work to be done and in
this respect I suggest that instead of ranting you lend a hand and start
to influence the process.
This might perhaps surprise you, but I know of CAs which are already
rejected or pending for various reasons at the bug level and aren't
even considered for inclusion (of course they all have the chance to
correct and/or provide whatever is missing). And just last summer a few
CAs were not included after the comment period because I submitted an
extensive review of the CAs in questions, backed up with facts and
arguments. This isn't "pseudointellectual masturbation" (so I liked this
phrase...I had a good laugh)!
However there must be valid reasons and objections which must brought
forward at the latest at the comment periods in order to prevent an
inclusion of a CA which shouldn't be included. This comment period is
very unique and I learned to appreciate the fact that the community has
a chance to review the CAs put up for inclusion, before actually doing
so. Conclusion: Pick on the CAs up for inclusion, read the CP/CPs, check
the auditors and audits submitted, check out the root certificates, read
the comments in the bugs and make your arguments.
Concerning CAs which are already included and you suspect fraudulent
behavior, non-adherence to the Mozilla CA policy or other issues, you
should provide the information and make your voice heard. I'm not aware
that you've done so lately...
Frank Hecker
> The end result is that anyone who chooses to spend a hundred thousand
> bucks or so on a single audit can then go around selling the benefit
> of their inclusion in the trust list to the highest bidder without
> fear of repercussion. Which is what they've been doing. And nobody
> has the balls to stand up and say "user security is more important
> than user convenience". (In addition, roots have been sold to other
> companies, which have not passed continuing conformance audits.)
You're correct that the way that CAs got incorporated into browsers
originally had the effect of establishing an artificial scarcity, where
commercial CAs already preloaded in the browsers could take advantage of
their oligopolistic position to in effect "sell their slots" to others,
either by having other commercial CAs pay a fee to be able to chain up
to the existing roots, or by selling existing roots outright to other
commercial CA operators.
My position was and is that the best way to correct that situation is to
eliminate the artificial scarcity by allowing more CAs to have their
roots in browsers on reasonable terms. Among other things, that means
applying a "cost/benefit" (security vs. inconvenience) analysis on
requirements placed on new entrants, especially where such requirements
are significantly more onerous that those that were applied in practice
to incumbent CAs (i.e., those already in the preload list).
Eddy characterizes this as a "pragmatic" approach, and I make no
apologies for being pragmatic in this regard. I've consistently said
that I think that security issues with respect to CAs are simply a
special case of security issues in general, and should be judged
accordingly, especially when it comes to evaluating threats that are
mainly theoretical as opposed to threats that have been consistently
exploited in the real world.
That's basically what I've been trying to do in the case of WISeKey and
its Blackbox product: Figure out how real any possible threats actually
are, and whether they would rise to the level that would warrant denying
a request for inclusion. That also includes looking at the issue of the
standards we're applying to WISeKey vs. what's been applied in the past
(bothe before and after we adopted our policy).
Kyle Hamilton
<eddy...@startcom.org> wrote:
>
> Kyle, even so part of your argument might be correct, you are doing a great
> injustice to some of us here, specially to the ones which bother to review
> the CAs. Also Frank and Gerv invest quite some time into getting this right,
> starting from reviewing the bugs, keeping track of all the CAs respective
> statuses and so forth (see
> http://www.mozilla.org/projects/security/certs/pending/ for example). The
> handling of everything related to CAs has reached levels, I believe Frank
> never envisioned. There is a huge amount of work to be done and in this
> respect I suggest that instead of ranting you lend a hand and start to
> influence the process.
I perhaps do an injustice to those who do a lot of work in attempting
to fulfill the current policy requirements... and I am in full
agreement that there is a lot of work to be done. I am certainly not
going to dismiss the work done -- it is a huge amount of work, to be
certain, and I feel it has been well-done thus far -- and as far as it
goes, thus far.
However, the process itself is broken. The set of requirements are
broken. The only weapon which can be used -- decertification -- is
never (and will never, based on the Foundation's view of user
convenience as trumping user security) used. This puts Frank into a
position (posited earlier in this thread) where the only remaining
option is to nag the CAs in question -- nagging which can never be
seen as having any enforceable weight.
My griping is to expose the flaw in the design of the process. Not to
defame the excellent work of those who are administering the process
as it stands.
> This might perhaps surprise you, but I know of CAs which are already
> rejected or pending for various reasons at the bug level and aren't even
> considered for inclusion (of course they all have the chance to correct
> and/or provide whatever is missing). And just last summer a few CAs were not
> included after the comment period because I submitted an extensive review of
> the CAs in questions, backed up with facts and arguments. This isn't
> "pseudointellectual masturbation" (so I liked this phrase...I had a good
> laugh)!
I am not surprised by this. The vetting process is superb, for what
it is -- and I am not complaining about that at all. The problem that
I'm complaining about, as I've said, is that once a root is in the
store it's politically impossible to get it removed. Once this is
possible, I will withdraw ALL of my objections to the way the
situation exists. But, user convenience trumps user security. This
is the Way Things Are, and until it's fixed, the security which the
vetting process is supposed to be able to ensure is unensurable and
untrustable.
> However there must be valid reasons and objections which must brought
> forward at the latest at the comment periods in order to prevent an
> inclusion of a CA which shouldn't be included. This comment period is very
> unique and I learned to appreciate the fact that the community has a chance
> to review the CAs put up for inclusion, before actually doing so.
> Conclusion: Pick on the CAs up for inclusion, read the CP/CPs, check the
> auditors and audits submitted, check out the root certificates, read the
> comments in the bugs and make your arguments.
-- and then after the audits are done, and the CAs included, they can
do whatever they want in flagrant disregard for anything they said
they did, and there is no accountability for them. THAT is the
problem, not the initial vetting.
There is no process by which a CA which has already been included to
have a "CPS violation complaint" filed against them. Yes, there's a
comment period before the root is included -- but there's no way to
open a comment period after the root is included when known examples
of violations are found. THAT is my complaint. There is no policy in
place to review them, and even if they are reviewed the political
considerations are simply too powerful to delist the root if they
refuse to cooperate.
> Concerning CAs which are already included and you suspect fraudulent
> behavior, non-adherence to the Mozilla CA policy or other issues, you should
> provide the information and make your voice heard. I'm not aware that you've
> done so lately...
I have not. I must point out, though, that Frank has essentially
stated that it's impossible to remove an already-vetted CA. I feel
that the word of the administrator is appropriate evidence of the
issue.
Everything you have stated thus far looks solely at the pre-flight
inclusion checklist. I'm looking at the fact that Mozilla, which
accepts trust statements on behalf of its users, refuses to take any
action to remove trust from CAs which, once accepted, are then
operated in violation of those trust statements.
I see that Thawte has updated its CPS several times since I made my
initial complaint. Why is there no requirement that a certificate
include the version of the CPS used when it is certified? Why do I,
the user, have to keep fighting to view the (very difficult to see,
incidentally) Subject on every website I go to to see if it's an
SSL123 certificate or if it's a higher-validation certificate? (oh,
wait, that's "chrome", and it can't be changed. :P)
And is a bug automatically opened when a CPS changes, to re-vet the
revised CPS against the Mozilla policy? Is it a policy that the CA
must inform Mozilla when a CPS change is proposed? when a CPS change
is approved? when a CPS change is implemented?
And who enforces this? What is the enforcement? What is the action
that can be brought? What is the action that is politically allowed
to be brought?
And why, for the sake of all the gods, is the best place to discuss
this on the dev-tech-crypto list? This is not a development issue,
this is a policy issue.
(Also, Frank: You state that the concept of 'artificial scarcity'
could be used to abuse oligopolistic positioning. The problem,
though, is that once a root is in the store, that root can completely
misbehave. The sheer number of conflicts of interest involved makes
it very likely that a root is going to violate its CPS at some point
just to be able to do something business-related, like 'maintain cash
flow' or 'pay employees'. With the sheer number of roots, the chances
are that much higher. Until roots can be properly and appropriately
constrained, the current vetting policy doesn't do anything more than
cause problems. EV certs help, but nowhere near enough.)
-Kyle H
Eddy Nigg (StartCom Ltd.)
> However, the process itself is broken. The set of requirements are
> broken. The only weapon which can be used -- decertification -- is
> never (and will never, based on the Foundation's view of user
> convenience as trumping user security) used. This puts Frank into a
> position (posited earlier in this thread) where the only remaining
> option is to nag the CAs in question -- nagging which can never be
> seen as having any enforceable weight.
>
Kyle, first of all I believe that it depends a lot on the severity and
it's not a position per se of MoFo or Frank, but rather the preferred
approach. I agree (with Frank), that if the issue at hand can be solved
by dialog with the CA in question and it doesn't directly and severely
impact the users security, this to be the right approach. Nevertheless,
if the severity of the issue has a direct impact on the users basic
security, the CA root in question will be immediately and expressly
distrusted and an update of the affected products published. See also
bug https://bugzilla.mozilla.org/show_bug.cgi?id=413375#c8 which Nelson
is working on currently.
> -- and then after the audits are done, and the CAs included, they can
> do whatever they want in flagrant disregard for anything they said
> they did, and there is no accountability for them.
Absolutely not!
>
> There is no process by which a CA which has already been included to
> have a "CPS violation complaint" filed against them. Yes, there's a
> comment period before the root is included -- but there's no way to
> open a comment period after the root is included when known examples
> of violations are found.
Sorry? Are you saying you don't know where and how to complain against a
CA? Don't make me laugh...
This mailing list is one way, the other by opening a bug report.
> There is no policy in
> place to review them,
Yes, there is *one* Mozilla CA policy which governs the CA inclusions
and the reversal thereof. If you've found a CA not conforming to the CA
policy of Mozilla (and there indeed might be some) I'm sure, that after
reviewing the information provided by you, which proved to be correct,
the members of this community will support your call for action. Of
course, again it depends on the severity of the violation as stated above.
> and even if they are reviewed the political
> considerations are simply too powerful to delist the root if they
> refuse to cooperate.
>
Since I'm not aware that ever such a case was brought forward in a
serious manner and fashion, your statement above is simply a myth.
>
> I have not. I must point out, though, that Frank has essentially
> stated that it's impossible to remove an already-vetted CA.
Did Frank say that? I don't think so...rather other members like Nelson
said very clearly, that any such claim against a CA should be brought
forward and if proved correct, such a root might be yanked.
>
> I see that Thawte has updated its CPS several times since I made my
> initial complaint. Why is there no requirement that a certificate
> include the version of the CPS used when it is certified? Why do I,
> the user, have to keep fighting to view the (very difficult to see,
> incidentally) Subject on every website I go to to see if it's an
> SSL123 certificate or if it's a higher-validation certificate? (oh,
> wait, that's "chrome", and it can't be changed. :P)
>
Just a year ago I made a call for improving the way certificate details
are displayed. I haven't received sufficient support for
it...Nevertheless in FF3 it has been improved somewhat - not enough for
my taste however.
> And is a bug automatically opened when a CPS changes, to re-vet the
> revised CPS against the Mozilla policy? Is it a policy that the CA
> must inform Mozilla when a CPS change is proposed? when a CPS change
> is approved? when a CPS change is implemented?
>
No, but you can suggest it.
> And who enforces this? What is the enforcement? What is the action
> that can be brought? What is the action that is politically allowed
> to be brought?
>
> And why, for the sake of all the gods, is the best place to discuss
> this on the dev-tech-crypto list? This is not a development issue,
> this is a policy issue.
>
Is dev-security better or do we need a different channel for it? Policy
issues are handled on this mailing list on a regular basis. And bug
reports are opened accordingly each time... Not sure, but I don't see a
problem here.
David E. Ross
You raise some very valid points. However, reducing the present backlog
of requests to include new certificates appears to have priority over
reviewing certificates already in the NSS store.
Periodic audits of CAs are required by WebTrust to maintain their seal
of approval and should thus be required by Mozilla for continued
inclusion in the NSS store. The "Mozilla CA Certificate Policy" focuses
mainly on approving new certificates. The small portion regarding
removing certificates in section 4 should instead be part of a separate
policy that focuses on keeping and deleting existing certificates. I
suggest that such a policy provide for retaining existing certificates
until there is substantive evidence of misfeasance or malfeasance by the
CA; that is, instead of re-approving certificates as standard operating
procedure, they should be disapproved and removed by exception.
When I wrote bug #333272 -- which resulted in the list at
<http://www.mozilla.org/projects/security/certs/included/> -- I
requested that the list flag removed certificates or that such
certificates be moved to a separate list. Yes, I support the idea of
removing certificates when their CAs misbehave. However, I think that
merely warning a CA that its certificates are in danger of being both
removed and listed as removed -- with the reasons for removal -- would
be sufficient to induce a CA to reform. If the CA refuses to reform,
then definitely removal and publicity about that removal would be most
appropriate.
However, all of this discussion is now generalized well beyond the scope
of WISeKey and bug #371362.
Frank Hecker
<wnip>
>> I have not. I must point out, though, that Frank has essentially
>> stated that it's impossible to remove an already-vetted CA.
> Did Frank say that? I don't think so...
I didn't quite say that, but I can understand why Kyle interpreted my
comments that way. What I have said in the past is that because of the
impact of removing a root, particular a root that has lots of server
certs chained up to it, we're not going to remove a root unless the
security threat is high enough to warrant it, and in practice we're
likely to set that bar pretty high. It's analogous to having a security
vulnerability in Firefox's implementation of JavaScript; we're not
likely to just disable JavaScript in order to fix the problem.
Of course, with JavaScript problems we have the option of actually
fixing the bug, and trying to do so in a way that affect existing
JavaScript-based applications as little as possible. By contrast we seem
to have but one option, removing the root and breaking things. However
I'm not sure it's really that back and white. We can certainly make
public comments and complaints about CAs, and can threaten to remove
roots in some future release if problems were not fixed; in some cases
just the threat might be enough.
Also, if we had appropriate technical infrastructure for this in NSS or
PSM, we could also put CAs into a form of "probation", where their roots
were still included but sites chained to that root would be a warning
message of some sort. (As always, if people think something like this
would be worthwhile, we can always consider funding the work.)
Gervase Markham
> Periodic audits of CAs are required by WebTrust to maintain their seal
> of approval and should thus be required by Mozilla for continued
> inclusion in the NSS store.
I don't know if it's in the policy explicitly, but it's always been my
view that if a CA failed its WebTrust audit, its root would be removed.
I once asked for an RSS feed or similar notifications from WebTrust of
changes to the list of certified CAs (both additions and removals) but
this has not yet happened. Perhaps someone needs to push them a bit
harder on this.
Gerv
Gervase Markham
> I didn't quite say that, but I can understand why Kyle interpreted my
> comments that way. What I have said in the past is that because of the
> impact of removing a root, particular a root that has lots of server
> certs chained up to it, we're not going to remove a root unless the
> security threat is high enough to warrant it, and in practice we're
> likely to set that bar pretty high.
It's worth pointing out that, whether you think it's fair or not, it's
undeniably a reality that we would have far fewer worries about removing
a root which supported 50 certs on the public web than one which
supported 500,000. And it's also worth noting that most of the roots in
the store are closer to the former category.
Gerv
Kyle Hamilton
CPS was in the latter category.
My question is this:
Why, as a user, am I being asked by ANYONE in this forum if I can
point to any CA that is violating their CPS, or 'not keeping up with
their auditing'? Why does anyone even remotely think that this is
appropriate? The fact that I caught Thawte violating their CPS at the
time that I did was a fluke. Why am I suddenly being demanded to do
the jobs of all of the auditors for all the CAs that the Mozilla
Foundation has approved for inclusion in the trust store?
The fact that I as a user DID catch Thawte violating their
CPS-at-the-time, and then brought it to your attention, and that no
(visible, at least to me) changes in the policies and procedures that
the Mozilla Foundation has and follows has occurred, AND I'm being
told essentially that Thawte got off the hook because of the large
number of certificates it's signed (thus making the problem WORSE and
MORE ENDEMIC than if a 50-certificate CA were violating its CPS)...
why should I trust you?
-Kyle H
Gervase Markham
> Why, as a user, am I being asked by ANYONE in this forum if I can
> point to any CA that is violating their CPS, or 'not keeping up with
> their auditing'? Why does anyone even remotely think that this is
> appropriate? The fact that I caught Thawte violating their CPS at the
> time that I did was a fluke. Why am I suddenly being demanded to do
> the jobs of all of the auditors for all the CAs that the Mozilla
> Foundation has approved for inclusion in the trust store?
Are you realistically expecting that the Mozilla Foundation should be
doing the jobs of all the auditors for all the CAs that we have approved
for inclusion in the trust store?
If an auditor brings a matter to our attention (by failing an audit) we
will take action. Aside from throwing the entire SSL model away and
starting again, what else do you want?
> The fact that I as a user DID catch Thawte violating their
> CPS-at-the-time, and then brought it to your attention, and that no
> (visible, at least to me) changes in the policies and procedures that
> the Mozilla Foundation has and follows has occurred, AND I'm being
> told essentially that Thawte got off the hook because of the large
> number of certificates it's signed (thus making the problem WORSE and
> MORE ENDEMIC than if a 50-certificate CA were violating its CPS)...
Has Thawte passed an audit while performing this action which (I assume)
you are saying should cause them to fail? (I suspect the answer is Yes,
but I want to check.) If so, who was the auditor?
Gerv
Kyle Hamilton
>
> Has Thawte passed an audit while performing this action which (I assume)
> you are saying should cause them to fail? (I suspect the answer is Yes,
> but I want to check.) If so, who was the auditor?
As a user, how on earth do you think that I'm supposed to have this
information? Thawte was at the time a South African corporation. I
haven't got the faintest clue where to start looking for this
information.
I'm not a member of the Mozilla Foundation. I just use its products.
The Foundation exists to provide a legal entity which has appropriate
standing to -- among other things -- enforce its rules (through the
court system, if necessary).
You're a member. You have an @mozilla.org email address. You're
telling me that you don't have a clue what your organization's
responsibilities are, or how to bring them to the attention of those
who can enforce them?
The Thawte roots should have, as a matter of policy for being shown to
be untrustworthy with following their own CPS, been banished and
applications for them to be reincluded should have been denied. Since
this happened several years ago, I'll be okay with giving them a pass
-- but this should be the policy for ALL roots which fail their
audits, and the policy for ALL roots which are found to be in
violation of their CPSes. (A single pass for confusion, if the
certificate thus validly questioned is revoked, should be allowed --
but no more.)
You want "throw out the entire SSL security model"? The SSL security
model RELIES on roots following their own rules. This is -- *gasp!*
-- the reason why the rules are audited! The fact that you haven't
grasped that, and the fact that you haven't grasped how serious a
matter it truly is, shows that YOU have ALREADY thrown out the SSL
security model.
-Kyle H
Eddy Nigg (StartCom Ltd.)
> Why, as a user, am I being asked by ANYONE in this forum if I can
> point to any CA that is violating their CPS, or 'not keeping up with
> their auditing'?
Obtaining the web seal of the Web Trust audit is optional and not a
requirement. Re-auditing never was a requirement and CAs are/were free
to implement their own criteria. It might be, that at the time of the
incident you are referring to, this wasn't a requirement on the part of
the CA. This differs, compared to the requirements of EV.
> Why does anyone even remotely think that this is
> appropriate? The fact that I caught Thawte violating their CPS at the
> time that I did was a fluke.
Kyle, if you "caught" a CA violating their CPS than you must prove it.
You should perhaps provide the certificate, screen shots and other
documents , the section of the CPS being violated etc. I think it also
matters if it violated the minimum requirements of the Mozilla CA policy.
> The fact that I as a user DID catch Thawte violating their
> CPS-at-the-time,
Could you prove it?
> and then brought it to your attention,
Oh, you did report it to Frank?
> ....AND I'm being
> told essentially that Thawte got off the hook because of the large
> number of certificates it's signed (thus making the problem WORSE and
> MORE ENDEMIC than if a 50-certificate CA were violating its CPS)...
>
I guess that's because Thawte corrected the problem? Perhaps this is
what they did, which would prove the approach Frank was taken as
effective. After all, Mozilla wants to provide good software which a
user can rely on...would the CA have refrained from addressing the
issue, perhaps Frank would have found different ways....
...so I can understand what upsets you and you really would like to see
a CA like Thawte punished by Mozilla :-)
...which in return would reinstate your faith in Mozilla and the PKI
trust model.
Paul Hoffman
>Why, as a user, am I being asked by ANYONE in this forum if I can
>point to any CA that is violating their CPS, or 'not keeping up with
>appropriate?
Because you, alone, brought it up. It is reasonable for a group who
hears of a violation from a single person, who does not show any
proof in the violation, to assume that the person might be mistaken.
If we hear from additional people, or you show some proof, our
responsibility increases.
>The fact that I caught Thawte violating their CPS at the
>time that I did was a fluke.
You still have not shown us that you "caught" Thawte doing anything
they should not have.
>Why am I suddenly being demanded to do
>the jobs of all of the auditors for all the CAs that the Mozilla
>Foundation has approved for inclusion in the trust store?
You are not being demanded to do anything (not even treating people
politely or professionally). Nothing in *anyone's* CPS says "our
auditors will review every single transaction we make". You feel that
Thawte made a bad transaction. If you can back that up, this group
can do something about it, such as bring it to the auditors.
>The fact that I as a user DID catch Thawte violating their
>CPS-at-the-time, and then brought it to your attention, and that no
>(visible, at least to me) changes in the policies and procedures that
>the Mozilla Foundation has and follows has occurred,
Maybe I missed it, but I still have not seen what you think Thawte
did and any proof that they did it, much less proof that they are
still doing it.
>AND I'm being
>told essentially that Thawte got off the hook because of the large
>number of certificates it's signed (thus making the problem WORSE and
>MORE ENDEMIC than if a 50-certificate CA were violating its CPS)...
Nice use of the word "essentially" to cover a statement that is,
essentially, a bald-faced lie.
>why should I trust you?
Because we have done what we think is a good job over a number of
years. If you don't think so, please feel free not to trust us. We
are no different than any other organization that does or does not
earn your trust. Well, we are different in that we have a mailing
list on which you can use to complain...
Gervase Markham
> On Feb 13, 2008 4:08 AM, Gervase Markham <ge...@mozilla.org> wrote:
>> Has Thawte passed an audit while performing this action which (I assume)
>> you are saying should cause them to fail? (I suspect the answer is Yes,
>> but I want to check.) If so, who was the auditor?
>
> As a user, how on earth do you think that I'm supposed to have this
> information?
But you aren't jusr "a user". You are Kyle Hamilton.
> I'm not a member of the Mozilla Foundation. I just use its products.
> The Foundation exists to provide a legal entity which has appropriate
> standing to -- among other things -- enforce its rules (through the
> court system, if necessary).
Right...
> You're a member. You have an @mozilla.org email address. You're
> telling me that you don't have a clue what your organization's
> responsibilities are, or how to bring them to the attention of those
> who can enforce them?
I've lost your train of thought here.
> The Thawte roots should have, as a matter of policy for being shown to
> be untrustworthy with following their own CPS, been banished and
> applications for them to be reincluded should have been denied. Since
> this happened several years ago, I'll be okay with giving them a pass
> -- but this should be the policy for ALL roots which fail their
> audits, and the policy for ALL roots which are found to be in
> violation of their CPSes. (A single pass for confusion, if the
> certificate thus validly questioned is revoked, should be allowed --
> but no more.)
It seems to me that if we receive a report, with some sort of evidence,
that a CA is not obeying their own CPS, we should look into it and ask
them what they think they are playing at. It would seem (although you
haven't referenced the bug number, so I'm working from memory) that this
wasn't done in this case. If it were to happen again, I hope things
would be different.
> You want "throw out the entire SSL security model"?
No; I was suggesting that you did.
Gerv
Kevin Blackman <kblackmawisekey.com>
news:47910180...@mozillafoundation.org:
> WISeKey has applied to add its (one) root CA certificate to the
> Mozilla root store, as documented in the following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=371362
>
> and in the pending certificates list here:
>
> http://www.mozilla.org/projects/security/certs/pending/#WISeKey
>
> I have evaluated their request, as per the mozilla.org CA certificate
> policy:
>
> http://www.mozilla.org/projects/security/certs/policy/
>
> and plan to approve this request in two weeks time. If you have any
> objections, or know of facts which might influence this decision,
> please make them known before then.
>
> Frank
>
Hi Frank,
Can you advise on the status of the approval of this request?
Best regards,
Kevin