Re: Policy: revoke on private key exposure
At 5:09 PM + 2/4/09, Frank Hecker wrote: 1. To what extent do typical CPSs and CPs address this issue? In other words, if we were to read the average CPS/CP, would it have language that would unambiguously tell us whether our policy requirement were met or not? Or is this something that's typically ambiguous and left to CAs' discretion, or that CAs are prohibited from unilaterally doing under the terms of their subscriber agreements? (E.g., CA can revoke only at the subscriber's request.) Whether or not the average CPS/CP has it is irrelevant. Let's look at the standards that all CAs are supposed to be using, in this case RFC 5280: 3.3. Revocation When a certificate is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA (e.g., an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate. the CA needs to revoke the certificate seems pretty definitive to me. 2. Assuming a CA becomes aware of a compromised key and doesn't revoke it, what courses of action are open to us other than pulling the CA's root? Is there serious consideration being given to implementing some alternative mechanism in NSS or PSM to blacklist certs which we think are suspect even if the CA does not? I do not think there should be an alternative mechanism. At 2:05 AM + 2/5/09, Frank Hecker wrote: * In the near term I think we should make it a recommended practice that CAs should revoke certificates whose private keys are known to be compromised, as well as certificates for which subscriber verification is known to be invalid. Kathleen can then add a check to determine whether a CA's CPS has language that is consistent with our recommendation, and we can discuss that as part of overall evaluation of CAs. I've add an item for this to the recommended practices page: https://wiki.mozilla.org/CA:Recommended_Practices Feel free to suggest tweaks to the language as appropriate. * In the longer term we can consider making this a policy requirement. There are likely some ambiguities and corner cases we need to worry about, which is one reason why I'd like us to first get some experience with what CAs are actually putting in their CPSs. The CA is not following the PKIX standard: pull their trust anchor. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
At 6:23 PM -0800 2/4/09, Kyle Hamilton wrote: There are two states in the NIST key state transition diagram that are appropriate to this entire concept... compromised (state entered when the private information associated with it -- i.e., the private key and its passphrase, and has only one possible state transition from it) and compromised destroyed (state entered either from compromised, when no information is protected with that key anymore, or from destroyed, when no information is protected with that key and it is later found to have been compromised during its non-destroyed period). Once a key is in compromised state, it can never become uncompromised again. Bingo. NIST makes that clear as well. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 11/2/09 17:20, Paul Hoffman wrote: At 5:09 PM + 2/4/09, Frank Hecker wrote: 1. To what extent do typical CPSs and CPs address this issue? In other words, if we were to read the average CPS/CP, would it have language that would unambiguously tell us whether our policy requirement were met or not? Or is this something that's typically ambiguous and left to CAs' discretion, or that CAs are prohibited from unilaterally doing under the terms of their subscriber agreements? (E.g., CA can revoke only at the subscriber's request.) Whether or not the average CPS/CP has it is irrelevant. Let's look at the standards that all CAs are supposed to be using, in this case RFC 5280: Where in the policy does it mention RFC 5280? The CA is not following the PKIX standard: pull their trust anchor. pull the policy? iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 02/11/2009 06:33 PM, Ian G: Whether or not the average CPS/CP has it is irrelevant. Let's look at the standards that all CAs are supposed to be using, in this case RFC 5280: Where in the policy does it mention RFC 5280? I guess Mozilla strives to follow standards. The CA is not following the PKIX standard: pull their trust anchor. pull the policy? Pull Ian G? :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 02/04/2009 07:39 PM, Frank Hecker: Re resellers, I think it is a fruitless task for us to try to move the entire CA industry to change the way it operates as a business. Our main interest is in having CAs maintain effective controls over their authorized agents, whether these be actual resellers, RAs in general, or whatever. If CAs outsource a lot of the work involved in subscriber verification (to an RA) or cert issuance (to a third-party subordinate) then I think it's reasonable to have them face increased questioning about measures they've taken to establish and maintain effective controls; +1 however I don't think it's reasonable to disqualify them entirely for using third-party agents, or to dictate exactly how they should operate wrt such third-party agents. 100% correct. I think this is exactly what should be applied. The mere existence of RAs, sub CAs and other third parties operating within a CAs infrastructure aren't in itself a reason to disqualify a CA. The policies and controls governing them are what matters. Actually if Kathleen can take over the bulk of the CA request processing then I think I would have time for dealing with some of these policy issues. The only unsustainable thing is having me be on the critical path for CA evaluation. This is excellent news! I understand that that Kathleen has taken over those additional tasks and it seems that we are all happy about it. I look very much forward of your spending of more time with policy matters! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Eddy Nigg wrote: On 02/05/2009 04:23 AM, Kyle Hamilton: Once a key is in compromised state, it can never become uncompromised again. Enforcing this is part of the trust that I have in the certification authorities -- and why I don't currently trust any of them to tell me who anyone happens to be, since any CPS which states that certificate revocation can only be done at the request of the Haha, it will be most amusing if you'll find such a CPS. :-) I agree that it would be unusual for a CPS to state that certificate revocation could be done only at the request of the subscriber. However I *can* imagine a CPS where this would be ambiguous. For example, your StartCom CPS is very slightly ambiguous, since it states that A certificate will be revoked ... but doesn't explicitly state that it's StartCom that will be doing the revoking; it also doesn't contain any language about this being done regardless of the subscriber's feelings about the matter. Note that I don't really think your CPS is problematic in any sense, it's that I can imagine CPSs where the ambiguity would be somewhat greater. For example, suppose a CPS said something like Causes for certificate revocation include ... compromise of the private key. This leaves it somewhat unclear whether the CA can unilaterally revoke or not. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Eddy Nigg wrote: On 02/05/2009 04:05 AM, Frank Hecker: * In the near term I think we should make it a recommended practice that CAs should revoke certificates whose private keys are known to be compromised, as well as certificates for which subscriber verification is known to be invalid. Well, a recommendation is just what it is I guess... I want to start with a recommendation, but not end with it. I want to use the recommendation for two purposes: * to have Kathleen start actively checking CPSs for revocation language * to fine-tune the exact language in which we want to state a policy requirement There are likely some ambiguities and corner cases we need to worry about, which is one reason why I'd like us to first get some experience with what CAs are actually putting in their CPSs. If however you intend to have any effect on the desired behavior, than Mozilla must make those things a requirement. I agree. I think this is a case where it definitely makes sense to have this be a requirement. I also think the case of revocation on key compromise is relatively clear, and I don't anticipate any major problems finding policy language to deal with it. However I'd also like us to consider including a requirement that CAs revoke certificates when it's clear that validation of subscribers was not done or was done wrong, like in the Comodo/CertStar problem or your StartCom bug. I don't quite know right now exactly how to word such a requirement properly, and I'd like to beta-test some language and see how it compares to what CAs are claiming in CPSs. Or Mozilla must create by-laws to the policy which may change more frequently. I think it is certainly reasonable to update the policy on an annual basis, and I think that should be our minimum target. We could also update it more frequently, but I don't want to be modifying it on a monthly basis. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 02/05/2009 04:03 PM, Frank Hecker: I agree that it would be unusual for a CPS to state that certificate revocation could be done only at the request of the subscriber. However I *can* imagine a CPS where this would be ambiguous. For example, your StartCom CPS is very slightly ambiguous, since it states that A certificate will be revoked ... but doesn't explicitly state that it's StartCom that will be doing the revoking; it also doesn't contain any language about this being done regardless of the subscriber's feelings about the matter. Fantastic! Isn't it interesting that there is always room for improvement? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 02/05/2009 04:13 PM, Frank Hecker: I agree. I think this is a case where it definitely makes sense to have this be a requirement. I also think the case of revocation on key compromise is relatively clear, and I don't anticipate any major problems finding policy language to deal with it. Terrific! However I'd also like us to consider including a requirement that CAs revoke certificates when it's clear that validation of subscribers was not done or was done wrong, like in the Comodo/CertStar problem or your StartCom bug. I don't quite know right now exactly how to word such a requirement properly, and I'd like to beta-test some language and see how it compares to what CAs are claiming in CPSs. Again from the StartCom CPS (ignoring any ambiguity): ● The subscriber’s private key is lost or suspected to be compromised ● The information in the subscriber’s certificate is suspected to be inaccurate Both of the above covers pretty much every possible circumstances for what we care (Payments and other issues aren't something we care about, right?). Also note the choice of suspected. In case of the weak keys this makes it clear. I think it is certainly reasonable to update the policy on an annual basis, and I think that should be our minimum target. I think it should be not more than every half year. Perhaps we can agree on two dates when Mozilla would update the policy. Then every concerned part y can check if and of what nature there was an update. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Michael Ströder wrote: Julien R Pierre - Sun Microsystems wrote: Paul Hoffman wrote: At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote: Perhaps Mozilla should change its policy to require CAs to revoke certs when the private key is known to be compromised, whether or not an attack is in evidence, as a condition of having trust bits in Firefox. Fully agree. Thirded. +1 I'm surprised that isn't already the case :-( Me too. :-/ (I'm catching up on CA-related stuff, and just finished reading quickly through this thread.) First, I have no problems with adding something in the problematic practices page about recommending that CAs revoke end-entity certificates when the associated private keys are known to be compromised. (And I agree that having private keys published on the Internet fits any reasonable definition of the word compromised.) This is a good thing to ask CAs about, and to put them on notice. Now, with regard to making this a formal policy requirement, I have the following questions: 1. To what extent do typical CPSs and CPs address this issue? In other words, if we were to read the average CPS/CP, would it have language that would unambiguously tell us whether our policy requirement were met or not? Or is this something that's typically ambiguous and left to CAs' discretion, or that CAs are prohibited from unilaterally doing under the terms of their subscriber agreements? (E.g., CA can revoke only at the subscriber's request.) 2. Assuming a CA becomes aware of a compromised key and doesn't revoke it, what courses of action are open to us other than pulling the CA's root? Is there serious consideration being given to implementing some alternative mechanism in NSS or PSM to blacklist certs which we think are suspect even if the CA does not? Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 4/2/09 18:09, Frank Hecker wrote: Now, with regard to making this a formal policy requirement, I have the following questions: 1. To what extent do typical CPSs and CPs address this issue? In other words, if we were to read the average CPS/CP, would it have language that would unambiguously tell us whether our policy requirement were met or not? Or is this something that's typically ambiguous and left to CAs' discretion, or that CAs are prohibited from unilaterally doing under the terms of their subscriber agreements? (E.g., CA can revoke only at the subscriber's request.) To be honest, I do not know what the typical CPS would say here [1]. I happen to be in that area at the moment as I am reading CAcert against the criteria, so I will pass on their CPS [2]: 4.9.1. Circumstances for revocation Certificates may be revoked under the following circumstances: 1. As initiated by the Subscriber through her online account. 2. As initiated in an emergency action by a support team member. Such action will immediately be referred to dispute resolution for ratification. 3. Under direction from the Arbitrator in a duly ordered ruling from a filed dispute. These are the only three circumstances under which a revocation occurs. 2. Assuming a CA becomes aware of a compromised key and doesn't revoke it, what courses of action are open to us other than pulling the CA's root? According to CAcert's policies on dispute resolution [3]: = 1.1 Filing Party Anyone may file a dispute. In filing, they become Claimants. = (Anyone is meant broadly, as other text makes clear.) iang, back to reviewing criteria (yawn!) [1] This is partly deliberate; over at CAcert I have encouraged the practice of not reading others' documents until they have finished their own. [2] Their CPS is only work-in-progress which means it has no standing. However I can strongly suggest that the above text is reliable for this conversation. https://svn.cacert.org/CAcert/policy.htm#p4.9.1 [3] DRP is at http://www.cacert.org/policy/DisputeResolutionPolicy.php and it is solid POLICY status. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 02/04/2009 07:09 PM, Frank Hecker: 1. To what extent do typical CPSs and CPs address this issue? In other words, if we were to read the average CPS/CP, would it have language that would unambiguously tell us whether our policy requirement were met or not? Or is this something that's typically ambiguous and left to CAs' discretion, or that CAs are prohibited from unilaterally doing under the terms of their subscriber agreements? (E.g., CA can revoke only at the subscriber's request.) Generally CAs can act upon mere knowledge about certain circumstances for revoking certificates. Because at times, the subscriber is interested in the misuse of a certificate and hasn't an interest in requesting revocation. For example Comodo didn't ask me nicely if I'd like to have the certificate revoked which was wrongfully issued to me. They just revoked it. Similar CAs can act upon knowing upon key compromise. I believe that the StartCom CPS isn't unique in regards to revocation which states: Circumstances for Revocation Revocation of a certificate is to permanently end the operational period of the certificate prior to reaching the end of its stated validity period. A certificate will be revoked when the information it contains is suspected to be incorrect or compromised. This includes situations where: ● The subscriber’s private key is lost or suspected to be compromised and many more points, but the first one is private key compromise. 2. Assuming a CA becomes aware of a compromised key and doesn't revoke it, what courses of action are open to us other than pulling the CA's root? Is there serious consideration being given to implementing some alternative mechanism in NSS or PSM to blacklist certs which we think are suspect even if the CA does not? Mozilla (Gerv, Nelson, me, others) evaluated the option to ship such a blacklist but the idea was rejected to be unpractical (the blacklist download would have been larger than that of Firefox itself). Don't know of any other action Mozilla could perform besides what you mentioned already. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Ian G wrote re revocation on compromise: I happen to be in that area at the moment as I am reading CAcert against the criteria, so I will pass on their CPS [2]: Thanks for this info! Certificates may be revoked under the following circumstances: 1. As initiated by the Subscriber through her online account. 2. As initiated in an emergency action by a support team member. Such action will immediately be referred to dispute resolution for ratification. 3. Under direction from the Arbitrator in a duly ordered ruling from a filed dispute. I'm guessing that item 2 would cover a case where CAcert became aware of a key compromise and for whatever reason the subscriber did not initiate a revocation request. (I guess a third party could also initiate a complaint with respect to a compromised key, but for something like the Debian case I don't see it as necessary, since the facts were known to all.) Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Eddy Nigg wrote re revocation on compromise: Generally CAs can act upon mere knowledge about certain circumstances for revoking certificates. snip I believe that the StartCom CPS isn't unique in regards to revocation which states: Circumstances for Revocation Revocation of a certificate is to permanently end the operational period of the certificate prior to reaching the end of its stated validity period. A certificate will be revoked when the information it contains is suspected to be incorrect or compromised. This includes situations where: ● The subscriber’s private key is lost or suspected to be compromised Thanks for your info as well. Mozilla (Gerv, Nelson, me, others) evaluated the option to ship such a blacklist but the idea was rejected to be unpractical (the blacklist download would have been larger than that of Firefox itself). Don't know of any other action Mozilla could perform besides what you mentioned already. Understood. After thinking about this, here is what I think we should do on this issue: * In the near term I think we should make it a recommended practice that CAs should revoke certificates whose private keys are known to be compromised, as well as certificates for which subscriber verification is known to be invalid. Kathleen can then add a check to determine whether a CA's CPS has language that is consistent with our recommendation, and we can discuss that as part of overall evaluation of CAs. I've add an item for this to the recommended practices page: https://wiki.mozilla.org/CA:Recommended_Practices Feel free to suggest tweaks to the language as appropriate. * In the longer term we can consider making this a policy requirement. There are likely some ambiguities and corner cases we need to worry about, which is one reason why I'd like us to first get some experience with what CAs are actually putting in their CPSs. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
There are two states in the NIST key state transition diagram that are appropriate to this entire concept... compromised (state entered when the private information associated with it -- i.e., the private key and its passphrase, and has only one possible state transition from it) and compromised destroyed (state entered either from compromised, when no information is protected with that key anymore, or from destroyed, when no information is protected with that key and it is later found to have been compromised during its non-destroyed period). Once a key is in compromised state, it can never become uncompromised again. Enforcing this is part of the trust that I have in the certification authorities -- and why I don't currently trust any of them to tell me who anyone happens to be, since any CPS which states that certificate revocation can only be done at the request of the subscriber inherently cannot allow the CA to do its job. -Kyle H On Wed, Feb 4, 2009 at 6:05 PM, Frank Hecker hec...@mozillafoundation.org wrote: Eddy Nigg wrote re revocation on compromise: Generally CAs can act upon mere knowledge about certain circumstances for revoking certificates. snip I believe that the StartCom CPS isn't unique in regards to revocation which states: Circumstances for Revocation Revocation of a certificate is to permanently end the operational period of the certificate prior to reaching the end of its stated validity period. A certificate will be revoked when the information it contains is suspected to be incorrect or compromised. This includes situations where: ● The subscriber's private key is lost or suspected to be compromised Thanks for your info as well. Mozilla (Gerv, Nelson, me, others) evaluated the option to ship such a blacklist but the idea was rejected to be unpractical (the blacklist download would have been larger than that of Firefox itself). Don't know of any other action Mozilla could perform besides what you mentioned already. Understood. After thinking about this, here is what I think we should do on this issue: * In the near term I think we should make it a recommended practice that CAs should revoke certificates whose private keys are known to be compromised, as well as certificates for which subscriber verification is known to be invalid. Kathleen can then add a check to determine whether a CA's CPS has language that is consistent with our recommendation, and we can discuss that as part of overall evaluation of CAs. I've add an item for this to the recommended practices page: https://wiki.mozilla.org/CA:Recommended_Practices Feel free to suggest tweaks to the language as appropriate. * In the longer term we can consider making this a policy requirement. There are likely some ambiguities and corner cases we need to worry about, which is one reason why I'd like us to first get some experience with what CAs are actually putting in their CPSs. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 02/05/2009 04:05 AM, Frank Hecker: * In the near term I think we should make it a recommended practice that CAs should revoke certificates whose private keys are known to be compromised, as well as certificates for which subscriber verification is known to be invalid. Well, a recommendation is just what it is I guess... * In the longer term we can consider making this a policy requirement. ...on the other hand, the issue of the weak Debian keys will in the longer term fade away since the systems get updated (hopefully) and certificates will expire within the next five to ten years. The same applies to MD5 hashes since I believe they will start to disappear now slowly as well. It would most likely have to be a principal decision, unrelated to the issues above. There are likely some ambiguities and corner cases we need to worry about, which is one reason why I'd like us to first get some experience with what CAs are actually putting in their CPSs. If however you intend to have any effect on the desired behavior, than Mozilla must make those things a requirement. As Robin (or was it Rob?) clearly pointed out just recently, as long as it's not in the policy it doesn't exist (even though I pointed out that problematic practices are influencing inclusions requests of roots, it's apparently non-binding for any CA already in the pile (using Paul's preferred definition ;-) ). Or Mozilla must create by-laws to the policy which may change more frequently. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 02/05/2009 04:23 AM, Kyle Hamilton: Once a key is in compromised state, it can never become uncompromised again. Enforcing this is part of the trust that I have in the certification authorities -- and why I don't currently trust any of them to tell me who anyone happens to be, since any CPS which states that certificate revocation can only be done at the request of the Haha, it will be most amusing if you'll find such a CPS. :-) But there are CAs apparently not adhering to their own policies for whatever reasons... subscriber inherently cannot allow the CA to do its job. ...who says that? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Ian G wrote: There have been a lot of calls to change the policy ... has someone thought to keep a record of all these? Here's what I recall so far: * MD5 should be dropped [1] * publication of private key is considered to be compromise + compromise should cause revocation * no resellers * drop the root of any rogue CA snip Are these things for policy changes, or are they just for troublesome practices pages? Or are they disputes? MD5 should definitely be a problematic practice. In terms of policy I think it should be handled as we did SSL2: Investigate what's out there, talk to CAs, and plan for a transition as soon as practicable. Re CA revocation of EE certs with published private keys, see my separate message. Re resellers, I think it is a fruitless task for us to try to move the entire CA industry to change the way it operates as a business. Our main interest is in having CAs maintain effective controls over their authorized agents, whether these be actual resellers, RAs in general, or whatever. If CAs outsource a lot of the work involved in subscriber verification (to an RA) or cert issuance (to a third-party subordinate) then I think it's reasonable to have them face increased questioning about measures they've taken to establish and maintain effective controls; however I don't think it's reasonable to disqualify them entirely for using third-party agents, or to dictate exactly how they should operate wrt such third-party agents. Re rogue CAs, rogue has no inherent meaning except with reference to some set of practices we define as unacceptable. So that's just part of the general discussion of what we should badger CAs about (problematic practices) vs. what we should take a strict line on and reject CAs for (policy requirements). If there are more than three things in the list, we are beyond minor tweaks, so we may find ourselves into a major revision cycle. I don't think Mozo has the resources for that, but that's just my view. Actually if Kathleen can take over the bulk of the CA request processing then I think I would have time for dealing with some of these policy issues. The only unsustainable thing is having me be on the critical path for CA evaluation. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
David, David Stutzman wrote: Jean-Marc Desperrier wrote: You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. I can personally attest to the fact that trying to load a CRL with ~250,000 entries destroys Java using the Sun API. I opened a bug with Sun on this issue. I can also tell you that NSS handles CRLs of that size just fine. In fact I was testing a CRL with 1.2 million entries as far back as 2002 when I implemented the CRL cache in NSS 3.6. It does take a lot of RAM, but that is generally not that much of an issue for servers, especially the 64-bit servers we have today. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Ian, Ian G wrote: On 31/1/09 03:56, Kyle Hamilton wrote: The PKIX standard can deal with problems of this extent. If an implementation of the standard cannot, then the implementation is nonconforming, and cannot be expected to interoperate. Do you mean, an implementation should be able to deal with a CRL of any size? I thought the whole OCSP thing was about the realisation that CRLs were basically impractical out in userland? Don't get me wrong, I'm not trying to start an argument here, but it seems pretty tough to blame an application for not being able to cope for something we've already moved on from. You thought wrong. OCSP is not a replacement for CRLs. They both have different use cases. On the server side, OCSP is not suitable, and CRLs must be used. Servers need to be prepared to handle large CRLs. NSS has been able to do so for a long time. On the client side, OCSP makes much more sense. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 31/1/09 17:08, Paul Hoffman wrote: On 31/1/09 03:56, Kyle Hamilton wrote: The PKIX standard can deal with problems of this extent. If an implementation of the standard cannot, then the implementation is nonconforming, and cannot be expected to interoperate. Do you mean, an implementation should be able to deal with a CRL of any size? I don't know whether it is what Kyle meant, but it is certainly what I meant. Yep, he confirmed it in other email. If a trust anchor has a CRL that is too large for for the implementation to handle, the implementation MUST remove that trust anchor from its pile. Wouldn't it be better to mark those certificates in the same way as expired and/or revoked? If a new CRL turns up and it is now readable (because it is smaller, or because it doesn't have any the bug in the earlier one), it seems drastic that the software MUST have removed the trust anchor. I thought the whole OCSP thing was about the realisation that CRLs were basically impractical out in userland? You thought wrong, then. OK. Don't get me wrong, I'm not trying to start an argument here, but it seems pretty tough to blame an application for not being able to cope for something we've already moved on from. We have not moved on from CRLs, as RFC 5280 makes clear. OK. On the primary question, I found this: ... and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate. Curiously, it doesn't say MUST revoke. And: Once the CA accepts a revocation report as authentic and valid, any query to the on-line service will correctly reflect the certificate validation impacts of the revocation. The way I read that RFC 5280's, revocation is a CA decision and responsibility (and consequent liability). Which makes sense, liability being the subject of a business arrangement between CAs, subscribers and RPs. A funny thing happened over at CAcert a while back. Someone asked whether they could get their certificate, and then publish the private key on the net as part of a demo pair in a software distro (or something). The request was denied, but nobody could quite pinpoint why the request should be denied. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
At 12:29 PM +0100 2/1/09, Ian G wrote: On 31/1/09 17:08, Paul Hoffman wrote: If a trust anchor has a CRL that is too large for for the implementation to handle, the implementation MUST remove that trust anchor from its pile. Wouldn't it be better to mark those certificates in the same way as expired and/or revoked? No. The certificate is not expired, and it is not revoked. Saying so is a lie. Trusted implementations should not lie, particularly when the lie comes from their own inabilities. If a new CRL turns up and it is now readable (because it is smaller, or because it doesn't have any the bug in the earlier one), it seems drastic that the software MUST have removed the trust anchor. It is drastic, but it is honest. On the primary question, I found this: ... and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate. Curiously, it doesn't say MUST revoke. Not curious. See RFC 2119 for the definition of MUST. There is no interoperability issue with having this be lower-case needs to. And: Once the CA accepts a revocation report as authentic and valid, any query to the on-line service will correctly reflect the certificate validation impacts of the revocation. The way I read that RFC 5280's, revocation is a CA decision and responsibility (and consequent liability). Which makes sense, liability being the subject of a business arrangement between CAs, subscribers and RPs. Correct. A funny thing happened over at CAcert a while back. Someone asked whether they could get their certificate, and then publish the private key on the net as part of a demo pair in a software distro (or something). The request was denied, but nobody could quite pinpoint why the request should be denied. It is discouraging that the people who run CAs don't understand the standards that they are supposedly upholding. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 31/1/09 03:56, Kyle Hamilton wrote: The PKIX standard can deal with problems of this extent. If an implementation of the standard cannot, then the implementation is nonconforming, and cannot be expected to interoperate. Do you mean, an implementation should be able to deal with a CRL of any size? I thought the whole OCSP thing was about the realisation that CRLs were basically impractical out in userland? Don't get me wrong, I'm not trying to start an argument here, but it seems pretty tough to blame an application for not being able to cope for something we've already moved on from. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 31/1/09 03:56, Kyle Hamilton wrote: The PKIX standard can deal with problems of this extent. If an implementation of the standard cannot, then the implementation is nonconforming, and cannot be expected to interoperate. Do you mean, an implementation should be able to deal with a CRL of any size? I don't know whether it is what Kyle meant, but it is certainly what I meant. If a trust anchor has a CRL that is too large for for the implementation to handle, the implementation MUST remove that trust anchor from its pile. I thought the whole OCSP thing was about the realisation that CRLs were basically impractical out in userland? You thought wrong, then. Don't get me wrong, I'm not trying to start an argument here, but it seems pretty tough to blame an application for not being able to cope for something we've already moved on from. We have not moved on from CRLs, as RFC 5280 makes clear. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/31/2009 06:08 PM, Paul Hoffman: On 31/1/09 03:56, Kyle Hamilton wrote: The PKIX standard can deal with problems of this extent. If an implementation of the standard cannot, then the implementation is nonconforming, and cannot be expected to interoperate. Do you mean, an implementation should be able to deal with a CRL of any size? I don't know whether it is what Kyle meant, but it is certainly what I meant. If a trust anchor has a CRL that is too large for for the implementation to handle, the implementation MUST remove that trust anchor from its pile. Seconded, I love clear words. Apparently NSS has no problem with it (I haven't tested it because it seems ridiculous), therefore this leaves it an isolated problem for Java. (However can anybody tell me what the use of this CRL is and if this is a CRL which potentially would be used in software which relies on CRL checking and automated fetching of the CRL?) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
An implementation should be able to deal with a CRL of any size, that is indeed what I'm saying. CRLs are also the ONLY revocation mechanism specified by X.509. (As well, they're also still specified in RFC 5280, which means that a fully-conforming implementation of the Internet PKI must handle CRLs as-specified.) OCSP was created due to realizations about the problems associated with CRLs, including transfer time. OCSP is also ONLY defined by PKIX, and is only an adjunct to the CRL mechanism. (Put another way, the CRL is the least common denominator. If an implementation can't deal with it, it is opening itself to an attack for any CA that only issues CRLs and does not provide an OCSP responder.) -Kyle H On Sat, Jan 31, 2009 at 6:05 AM, Ian G i...@iang.org wrote: On 31/1/09 03:56, Kyle Hamilton wrote: The PKIX standard can deal with problems of this extent. If an implementation of the standard cannot, then the implementation is nonconforming, and cannot be expected to interoperate. Do you mean, an implementation should be able to deal with a CRL of any size? I thought the whole OCSP thing was about the realisation that CRLs were basically impractical out in userland? Don't get me wrong, I'm not trying to start an argument here, but it seems pretty tough to blame an application for not being able to cope for something we've already moved on from. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Paul Hoffman wrote: [...] That feels insufficient to me. I also disagree that there are practical problems of revoking a very large number of certificates. The worst problem is that the CRL will grow; that's no big deal, it is supposed to grow. You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. And just count how many 3% of the certs Verisign issued under it's main CA makes. PS : Yes, it's outdated, they did a reset of the CA architecture, generated new roots, and I think the new one is not yet as big. But there's no reason why it won't be some day. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Jean-Marc Desperrier wrote: You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. I can personally attest to the fact that trying to load a CRL with ~250,000 entries destroys Java using the Sun API. I opened a bug with Sun on this issue. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/30/2009 01:25 PM, Jean-Marc Desperrier: Paul Hoffman wrote: [...] That feels insufficient to me. I also disagree that there are practical problems of revoking a very large number of certificates. The worst problem is that the CRL will grow; that's no big deal, it is supposed to grow. You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Jean-Marc, I can't hold back but must tell you that these are clear failures of the CA to assess and plan its infrastructure correctly, assess its design and provide adequate security. A CRL with the size of 34 MB is simply useless - it's like having no CRL and no way to revoke certificates. Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. And just count how many 3% of the certs Verisign issued under it's main CA makes. If the CA doesn't take measures which enables it it revoke 3% of issued certificates, then the infrastructure isn't up to its task. The EV guidelines for example requires ongoing or yearly security planning where issues like this must be addressed. Simply refusing to revoke the certificates is simply not dealing with the issue. There are various ways a CA can deal with this - even in case of Verisign and other CAs which issue a lot of certs. Not doing so is negligence either way, not revoking those weak and potentially compromised keys or letting CRLs grow to non-proportional sizes. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Florian Weimer wrote: * Michael Ströder: Florian Weimer wrote: What about requiring that all certificates must be published by the CA (including sub-CAs)? No, this might lead to also revealing internal DNS names never meant to be public. Huh? Typical CA policies Whatever a typical CA policy is. Note that the requirement mentioned by you above explicitly includes corporate sub-CAs which may issue server certs for servers not publicly accessible over Internet. explicitly state that subscriber certificates are not confidential, and are not treated as such by the CA Keeping certs really confidential and publishing certs in a public searchable database is something different. (so that they can be used by marketing, for instance). This is a different topic. Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
It is kind of sad that this discussion has become CAs should not revoke certificates when the private keys are exposed because Java cannot handle CRLs reliably. That says more about the failures of Java than it does failures in PKIX. --Paul Hoffman -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
The PKIX standard can deal with problems of this extent. If an implementation of the standard cannot, then the implementation is nonconforming, and cannot be expected to interoperate. in other words, it's the implementation's fault, not the standard's. (Yes, a standard has the responsibility to make it *possible* to implement it properly, but if other PKIX implementations can handle it and Java cannot, then the problem is squarely in Java's court, and can only be appropriately dealt with there.) -Kyle H On Fri, Jan 30, 2009 at 8:39 AM, Paul Hoffman phoff...@proper.com wrote: It is kind of sad that this discussion has become CAs should not revoke certificates when the private keys are exposed because Java cannot handle CRLs reliably. That says more about the failures of Java than it does failures in PKIX. --Paul Hoffman -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Jean-Marc Desperrier wrote, On 2009-01-30 03:25: Paul Hoffman wrote: [...] That feels insufficient to me. I also disagree that there are practical problems of revoking a very large number of certificates. The worst problem is that the CRL will grow; that's no big deal, it is supposed to grow. You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Ah, yes, the proverbial 35 Megabyte CRL, which even at T1 speeds takes 3.5 minutes (211 seconds) to download. Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. Years ago, NSS used a general purpose BER/DER decoder everywhere. It was used to decode a single 35 MB CRL (from the DoD, as I recall), and IIRC it took 24 hours to decode it and used some large portion of a gigabyte of RAM to do so. The problem was that it allocated space for and copied the value of every component, and every subcomponent of every constructed (structured) member of the document. So, Julien wrote a new DER-only decoder that uses the same templates as the old decoder, specifically motivated to handle that whopping CRL. It does not make unnecessary copies. Today, NSS uses that Quick DER Decoder for anything that is DER encoded. I just ran it against that 35 MB CRL cited above. It took less than 2 seconds to parse the whole thing. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Eddy Nigg wrote: [...] Well, this thread started out with the request that Mozilla should change it's policy to require CAs revoke certificate when the private key is known to be compromised. Given the practical problems of revoking a very large number of certificates, I'd consider it acceptable if the policy only requires the CA to : - make the client aware of the situation - get the certificate promply replaced if it is actually used on an open network. - revoke it if there's a failure to get it replaced within an acceptable timeframe -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
At 1:21 PM +0100 1/29/09, Jean-Marc Desperrier wrote: Eddy Nigg wrote: [...] Well, this thread started out with the request that Mozilla should change it's policy to require CAs revoke certificate when the private key is known to be compromised. Given the practical problems of revoking a very large number of certificates, I'd consider it acceptable if the policy only requires the CA to : - make the client aware of the situation - get the certificate promply replaced if it is actually used on an open network. - revoke it if there's a failure to get it replaced within an acceptable timeframe That feels insufficient to me. I also disagree that there are practical problems of revoking a very large number of certificates. The worst problem is that the CRL will grow; that's no big deal, it is supposed to grow. Again, I support must revoke as soon as you believe that the private key has been compromised. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/29/2009 02:21 PM, Jean-Marc Desperrier: Eddy Nigg wrote: [...] Well, this thread started out with the request that Mozilla should change it's policy to require CAs revoke certificate when the private key is known to be compromised. Given the practical problems of revoking a very large number of certificates, I'd consider it acceptable if the policy only requires the CA to : - make the client aware of the situation - get the certificate promply replaced if it is actually used on an open network. - revoke it if there's a failure to get it replaced within an acceptable timeframe I think that this is the approach taken by CAs which decided to revoke them (there are those which don't). Making the client aware and have him make the needed preparations is by far the best. Those which ignore (or fail to receive messages/phone calls) should be revoked within reasonable time. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 22/1/09 02:17, lots of people wrote: At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote: Perhaps Mozilla should change its policy to require CAs to revoke certs when the private key is known to be compromised, whether or not an attack is in evidence, as a condition of having trust bits in Firefox. Fully agree. There have been a lot of calls to change the policy ... has someone thought to keep a record of all these? Here's what I recall so far: * MD5 should be dropped [1] * publication of private key is considered to be compromise + compromise should cause revocation * no resellers * drop the root of any rogue CA I'm just wondering how far we are away from what people think is the right place. Are these things for policy changes, or are they just for troublesome practices pages? Or are they disputes? If there are more than three things in the list, we are beyond minor tweaks, so we may find ourselves into a major revision cycle. I don't think Mozo has the resources for that, but that's just my view. iang [1] http://www.heise-online.co.uk/security/MD5-attack-on-Microsoft-s-Authenticode--/news/112448 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 25/1/09 22:06, Florian Weimer wrote: * Ian G.: What I know of, not exclusive or reliable: ... 2. while certificates by their nature and name are often public (public key), that doesn't mean that anyone else can use them. Indeed, some CAs go to the extent of making their certificates proprietary under the doctrine of copyright, etc. CAcert does this, and also AFAIK, Verisign does this although for perhaps different motives. In this case, the direct concern appears to be to establish the RPA or equivalent. This also affects the certificates in the browser list, right? Yes. So technically if someone comes up with a new use model for certificates, they might be infringing on copyright. For example, statistics collection might fall under that (and did in one case that was observed / documented). What bugs me about the lack of certificate disclosure is that it typicall covers less data which ICANN requires from registries and accredited registrars to make available (at a few in some cases). DNS provides quite a bit of transparency in this area (data accuracy issues notwithstanding). The browser PKI is supposed to cover matching data and to be more secure, yet very little data is published (or made available for a fee) in searchable form by the certification authorities themselves. Well. Publication is not the same thing as security. Although there are some communities where open is promoted as the source of all bounty, some things want to be private to be secure. Certificates kind of walk the line between privacy and publication, trying to have their cake and eat it too. They publish (by means of the so-called public key) some verified data about the person like the real name, but they also promise security. Which clashes with privacy, because you should be able to do net stuff while being private. Nudity isn't security, neither in names nor other forms of commerce. The old x.509 invention came from telcos, who thought in terms of telephone books. In the old days, everyone had an entry in the telephone book, and the privacy derived from the fact that it was hard to find any particular J. Smith. Sort of. They charged you for privacy, or an unlisted number, and this was good. They thought. They covered other problems with laws and an iron grip on the copper. Yet, when x.509 actually hit the internet world in the early 1990s, a lot of privacy conscious organisations (e.g., banks) looked at this and realised it was a non-starter (here, read any rant by Lynn Wheeler with the word bloat in it). But by then it was too late; the code was in the infrastructure, PKI had won the war of models. So the privacy and other communities like banks rejected it. We still see this clash of concepts in the anonymous v. fully named contrast within PKI. Which brings us full circle to the question about security. As long as the CA knows who you are, and can do something about it, why do we need publication? Well, the answer to that is that the business model of the CAs is fundamentally limited by the need to sell verifications of names, while avoiding any liability (see below). It is harder to achieve this balance while the name is anonymous, because the CA then has to specifically take on the liability (as it is the one hiding the name). I don't think this makes any sense whatsoever --until you cynically assume that the opacity is there to protect CAs from PR blunders and worse. 8-( Well, many words could be said about that, but let me put forward my standard rant: CAs have protected themselves [1]. Successfully, whether you like it or not. The task of Mozilla and points further south [2] is to figure out what to do, given that situation [3]. My advice is this: Mozilla sets liability to zero, and does so loudly. That is, it recognises reality, and moves to align systems, documents and processes with reality. The reason this works is because once we recognise reality, and put Mozilla on a liability footing that is approximately close to that reality, then everyone can stop dancing around the thing that nobody dare say. Once we stop dancing around the impossible, and stop telling fairy stories to each other and to the end-users ... then and only then will real solutions and real improvements be encouraged to emerge [4] for the benefit of end-users. iang [1] I have skimmed the RPAs of most popular CAs at one time or another, and presented the language on this group. Most have the key language in it. So my view covers the market in general. Although some specific CAs may not have subscribed to this theory, or incompletely implemented it. Also, this is views of legal positions so the normal caveat of consult your own lawyer applies. [2] End-users, other relying parties, other vendors, standards committees, governments, developer communities and others that might have something to do with certificates.
Re: Policy: revoke on private key exposure
* Eddy Nigg: On 01/22/2009 11:59 AM, Florian Weimer: http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt The list doesn't include sub-CAs, which are equivalent to listed CAs for all practical purposes. Well, if you ping a web site then you'll most likely also know the issuer and ultimately the CA root. Scripts can do that too... ...but since CAs know to whom they issued certificates and have the certificates themselves, it's very easy for them to find the compromised keys. The Mozilla-listed CA does not know which certificates have been issued if there's an intermediate CA. Mozilla does not know which intermediate CAs exist. So there's not much room for proactive action. You can only run after individual certificates. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
* Ian G.: Huh? Typical CA policies explicitly state that subscriber certificates are not confidential, and are not treated as such by the CA (so that they can be used by marketing, for instance). What I know of, not exclusive or reliable: 1. privacy, as Eddy has pointed out. The reason that certificate info is treated as non-confidential is fundamentally a statement that reduces the liability for the CA in the event of a breach. As far as I understand it, that is. Losing data that is non-confidential is a lower class of sin than losing daya that is confidential, so it is good for the CA to state it as policy. If there's a certificate in the path with a working DN constraint (I don't know if such a beast exists for domain/server certificates), I suppose little additional transparency is gained from publication of additional subject certificates. In any case, the above is also an argument for anonymous EV certificates, not just against keeping searchable records of certificates. 2. while certificates by their nature and name are often public (public key), that doesn't mean that anyone else can use them. Indeed, some CAs go to the extent of making their certificates proprietary under the doctrine of copyright, etc. CAcert does this, and also AFAIK, Verisign does this although for perhaps different motives. In this case, the direct concern appears to be to establish the RPA or equivalent. This also affects the certificates in the browser list, right? What bugs me about the lack of certificate disclosure is that it typicall covers less data which ICANN requires from registries and accredited registrars to make available (at a few in some cases). DNS provides quite a bit of transparency in this area (data accuracy issues notwithstanding). The browser PKI is supposed to cover matching data and to be more secure, yet very little data is published (or made available for a fee) in searchable form by the certification authorities themselves. I don't think this makes any sense whatsoever --until you cynically assume that the opacity is there to protect CAs from PR blunders and worse. 8-( -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/25/2009 11:02 PM, Florian Weimer: The Mozilla-listed CA does not know which certificates have been issued if there's an intermediate CA. Mozilla does not know which intermediate CAs exist. So there's not much room for proactive action. You can only run after individual certificates. Well, this thread started out with the request that Mozilla should change it's policy to require CAs revoke certificate when the private key is known to be compromised. We've got a lot of information about web sites which have broken or weak keys (a compromise is very likely). We've got now another list of 250,000 web sites, some of them have such keys most likely as well. It's easy to track those to the CA, even when issued by an intermediate. Actually this is the only way to detect if CAs revoked such keys or not. Even for CAs which issue directly from the root it won't help a lot if you don't know any web sites. It basically doesn't matter if a end-user certificate is issued directly from a root or from an intermediate, in the end they all chain to a root. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
* Eddy Nigg: As a matter of fact, most CAs have policies in place which require them upon knowledge of potential or *suspected* compromise to revoke ANY certificate. I'm certain those policies exist for the top CAs covering the majority of certificates. The keys are compromised, not only suspected to be compromised. It's known which keys and certificates are affected (by the CAs themselves). Yes, but we don't know all the CAs that exist and are recognized by Mozilla. 8-( If you've got a sub-CA under a browser-listed root CA, it's kind of hard for Mozilla or the root CA to enforce any rules (let alone detect violations). What about requiring that all certificates must be published by the CA (including sub-CAs)? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/22/2009 11:04 AM, Florian Weimer: * Eddy Nigg: As a matter of fact, most CAs have policies in place which require them upon knowledge of potential or *suspected* compromise to revoke ANY certificate. I'm certain those policies exist for the top CAs covering the majority of certificates. The keys are compromised, not only suspected to be compromised. It's known which keys and certificates are affected (by the CAs themselves). Yes, but we don't know all the CAs that exist and are recognized by Mozilla. 8-( Of course we know. It's right here: http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt If you've got a sub-CA under a browser-listed root CA, it's kind of hard for Mozilla or the root CA to enforce any rules (let alone detect violations). No it's quite easy to do that. What about requiring that all certificates must be published by the CA (including sub-CAs)? I don't know the benefit for it, but I guess that sub CAs could be published, end-user certificates most likely not. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
* Eddy Nigg: On 01/22/2009 11:04 AM, Florian Weimer: * Eddy Nigg: As a matter of fact, most CAs have policies in place which require them upon knowledge of potential or *suspected* compromise to revoke ANY certificate. I'm certain those policies exist for the top CAs covering the majority of certificates. The keys are compromised, not only suspected to be compromised. It's known which keys and certificates are affected (by the CAs themselves). Yes, but we don't know all the CAs that exist and are recognized by Mozilla. 8-( Of course we know. It's right here: http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt The list doesn't include sub-CAs, which are equivalent to listed CAs for all practical purposes. It's also difficult to match the blobs to legal entities (Equifax comes to my mind). If you've got a sub-CA under a browser-listed root CA, it's kind of hard for Mozilla or the root CA to enforce any rules (let alone detect violations). No it's quite easy to do that. For Mozilla? How so? What about requiring that all certificates must be published by the CA (including sub-CAs)? I don't know the benefit for it, Transparency. You can actually check what's in those CRLs and what kind of mistakes are being covered up. but I guess that sub CAs could be published, end-user certificates most likely not. Why not? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On Thu, Jan 22, 2009 at 1:59 AM, Florian Weimer f...@deneb.enyo.de wrote: * Eddy Nigg: but I guess that sub CAs could be published, end-user certificates most likely not. Why not? Among other things: - The ability for other entities to mine that data for improper contact - The ability for the information in the certificates to be otherwise misused - Not every certificate user wants to identify as being a part of a given PKI system - Requiring full disclosure of the linkage of legal name to email address (for end-user certs, not necessarily end-entity certs) violates the end-entity's ability to control dissemination of information * nobody has yet signed up for this * if this becomes common, it'll be the death knell for client certificate authentication (nobody will participate) - No CA wants to reveal its actual subscriber numbers I'm pretty sure that Eddy'll be able to come up with more, as well as Rob, and representatives from other CAs. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/22/2009 11:59 AM, Florian Weimer: http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt The list doesn't include sub-CAs, which are equivalent to listed CAs for all practical purposes. Well, if you ping a web site then you'll most likely also know the issuer and ultimately the CA root. Scripts can do that too... ...but since CAs know to whom they issued certificates and have the certificates themselves, it's very easy for them to find the compromised keys. It's also difficult to match the blobs to legal entities (Equifax comes to my mind). I agree, but this is a different matter really. No it's quite easy to do that. For Mozilla? How so? A certificate always has to chain to a valid root, otherwise the certificate isn't viewed at as valid (by Mozilla software anyway). Transparency. You can actually check what's in those CRLs and what kind of mistakes are being covered up. Well, there is apparently a problem publishing end-user details so bluntly as also a recent incident has shown. Not that it's impossible to obtain the certificates for many sites as Johnathan demonstrated with his robot and as a certain reseller of certificates did that as well. But I agree that it would however be interesting to review such a list and compare to the published CRLs :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/22/2009 12:17 PM, Kyle Hamilton: - The ability for other entities to mine that data for improper contact - The ability for the information in the certificates to be otherwise misused - Not every certificate user wants to identify as being a part of a given PKI system - Requiring full disclosure of the linkage of legal name to email address (for end-user certs, not necessarily end-entity certs) violates the end-entity's ability to control dissemination of information * nobody has yet signed up for this * if this becomes common, it'll be the death knell for client certificate authentication (nobody will participate) - No CA wants to reveal its actual subscriber numbers I'm pretty sure that Eddy'll be able to come up with more, as well as Rob, and representatives from other CAs. I think you covered it even better than me :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Julien R Pierre - Sun Microsystems wrote: Paul Hoffman wrote: At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote: Perhaps Mozilla should change its policy to require CAs to revoke certs when the private key is known to be compromised, whether or not an attack is in evidence, as a condition of having trust bits in Firefox. Fully agree. Thirded. +1 I'm surprised that isn't already the case :-( Me too. :-/ Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Florian Weimer wrote: What about requiring that all certificates must be published by the CA (including sub-CAs)? No, this might lead to also revealing internal DNS names never meant to be public. Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Policy: revoke on private key exposure
At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote: Perhaps Mozilla should change its policy to require CAs to revoke certs when the private key is known to be compromised, whether or not an attack is in evidence, as a condition of having trust bits in Firefox. Fully agree. --Paul Hoffman -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Paul Hoffman wrote: At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote: Perhaps Mozilla should change its policy to require CAs to revoke certs when the private key is known to be compromised, whether or not an attack is in evidence, as a condition of having trust bits in Firefox. Fully agree. Thirded. I'm surprised that isn't already the case :-( -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On Wed, Jan 21, 2009 at 5:50 PM, Julien R Pierre - Sun Microsystems julien.pierre.nos...@nospam.sun.com wrote: Paul Hoffman wrote: At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote: Perhaps Mozilla should change its policy to require CAs to revoke certs when the private key is known to be compromised, whether or not an attack is in evidence, as a condition of having trust bits in Firefox. Fully agree. Thirded. I'm surprised that isn't already the case :-( Fourthed. If this isn't already the case, the already-minimal amount of trust I have in the PKI (which is already in abeyance) is completely undermined. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
