Re: Cert expiry with Key Continuity Management
Thanks for your thoughts Nelson. There's one big problem with this idea of a certificate extension for additional signatures, which I hadn't thought of before (Thanks to Paul H for spotting it!)... For the additional signature(s) to become especially useful, the primary signature on the certificate would need to be substantially broken (e.g. by a pre-image attack on the hash algorithm). But if this happened, it is likely that the CA would revoke the certificate. Once the certificate is revoked, it's...errr...revoked. The additional signature(s) extension would simply be ignored. On Monday 19 January 2009 22:07:46 Nelson B Bolyard wrote: Rob Stradling wrote, On 2009-01-14 03:24 PST: To the NSS developers: If there existed a standardized certificate extension in which a CA could put additional signatures using different algorithms, do you think you'd consider adding support for it to NSS? Yes, I think the NSS team would consider it, if it really was a standard, at least an IETF RFC. If yes, might you do this before it was widely supported by CAs, or do you think you'd wait for the majority of CAs to start using it first? I think that largely depends on who does the work. If someone contributed a patch to NSS that implemented it, and was quite complete (including changes to test tools and test scripts), and didn't require much work at all to go in, I think it might go in basically as soon as it was standard. The contribution of the Japanese Camellia cipher was an example of a very well done contribution that went right in. But if the NSS must develop it, or if a contributed patch is incomplete or requires a lot of work that the contributor is unwilling or unable to do, then prioritizing and scheduling that work involves factors such as the priorities of the sponsors of NSS development. Looking at the new developments in standards of the last few years, we see a list of standardized features that are thought to be important by various members of the crypto community, but which are not yet available in NSS. To name just a few, there are TLS 1.2, AES GCM, OCSP stapling, server support for SNI. Together they constitute a pretty large back log of development waiting to be done. Another new proposal would contend with those for resources. Not all of the features that have been added to NSS in the last few years have been widely adopted by the applications that use NSS. Consequently, the sponsors are now evaluating possible future developments based on their projections for the demand of application developers for those features. I think that says that if they see a groundswell of demand from the application developers for a new feature such as multiple signatures in a certificate, they might go for it, but otherwise, it is likely to languish, IMO. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Rob Stradling wrote, On 2009-01-14 03:24 PST: To the NSS developers: If there existed a standardized certificate extension in which a CA could put additional signatures using different algorithms, do you think you'd consider adding support for it to NSS? Yes, I think the NSS team would consider it, if it really was a standard, at least an IETF RFC. If yes, might you do this before it was widely supported by CAs, or do you think you'd wait for the majority of CAs to start using it first? I think that largely depends on who does the work. If someone contributed a patch to NSS that implemented it, and was quite complete (including changes to test tools and test scripts), and didn't require much work at all to go in, I think it might go in basically as soon as it was standard. The contribution of the Japanese Camellia cipher was an example of a very well done contribution that went right in. But if the NSS must develop it, or if a contributed patch is incomplete or requires a lot of work that the contributor is unwilling or unable to do, then prioritizing and scheduling that work involves factors such as the priorities of the sponsors of NSS development. Looking at the new developments in standards of the last few years, we see a list of standardized features that are thought to be important by various members of the crypto community, but which are not yet available in NSS. To name just a few, there are TLS 1.2, AES GCM, OCSP stapling, server support for SNI. Together they constitute a pretty large back log of development waiting to be done. Another new proposal would contend with those for resources. Not all of the features that have been added to NSS in the last few years have been widely adopted by the applications that use NSS. Consequently, the sponsors are now evaluating possible future developments based on their projections for the demand of application developers for those features. I think that says that if they see a groundswell of demand from the application developers for a new feature such as multiple signatures in a certificate, they might go for it, but otherwise, it is likely to languish, IMO. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On Tuesday 13 January 2009 15:47:22 Paul Hoffman wrote: At 3:31 PM + 1/13/09, Rob Stradling wrote: Why almost every piece of PKIX validating software ? I think it would be worth it if, at a minimum... - the majority of CAs added the extension to the certificates they issue, and... - Mozilla implemented support for the extension in NSS. This would allow Mozilla to disable a weak algorithm quickly, without having to wait for the majority of certificates in the wild to stop using that algorithm for their main certificate signature. Fair enough. I think the biggest barrier to adoption would be convincing enough of the CAs to implement it. Really? :-) But perhaps the Mozilla CA Certificate Policy could be updated to require CAs to implement it? That seems kind of drastic for an extension that would only help on a security issue that has never been met True. That is, the extension will only be useful for hash functions for which practical pre-image attacks are discovered, or signature functions that quickly become drastically weaker than expected. It's like an insurance policy. CAs and PKIX validating software would pay a premium (i.e. development effort required to support the proposed certificate extension), but would hope that they never need to make a claim. I still think it is sufficient for the policy to list the acceptable signing algorithms of the day. If the extension is standardized and is used by any CAs, and if NSS implements it and allows Firefox to be able to shut off one of multiple algorithms in the extension, that would help the CAs who used the extension. if NSS implements it. To the NSS developers: If there existed a standardized certificate extension in which a CA could put additional signatures using different algorithms, do you think you'd consider adding support for it to NSS? If yes, might you do this before it was widely supported by CAs, or do you think you'd wait for the majority of CAs to start using it first? -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Rob, Rob Stradling wrote: If there existed a standardized certificate extension in which a CA could put additional signatures using different algorithms, do you think you'd consider adding support for it to NSS? If yes, might you do this before it was widely supported by CAs, or do you think you'd wait for the majority of CAs to start using it first? It's hard for us NSS developers to respond about such hypotheticals in the future. Typically the NSS priorities are dictated by the needs of the companies that employ most of the NSS developers, that is to say, Sun, Red Hat and Google, and these can change over time. I am sorry I can't be more specific. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On Friday 09 January 2009 02:04:59 Julien R Pierre - Sun Microsystems wrote: On Friday 09 January 2009 04:32:41 Ben Bucksch wrote: snip Can we create another extension? The signature itself is a shell around the certified bits. Add the second signature around that first signature. There must be a way to add signatures. It's a base feature in PGP! If it's entirely impossible to have two signatures, and no way to add it to the spec, that's a design error. It's hard to believe that it's so limited. If one wanted to have another signature, it wouldn't be as an extension, since, as Nelson pointed out, extensions are part of what gets signed. The current single signature is not an extension. Well, I guess somebody did it anyway : http://www.freepatentsonline.com/y2008/0270788.html sigh. Ben, Julien, That IBM patent application does not yet appear to have been reviewed and either granted or rejected. I made a similar suggestion to ietf.pkix in October 2006. See... http://www.imc.org/ietf-pkix/mail-archive/msg01964.html ...and the rest of that thread, including... http://www.imc.org/ietf-pkix/mail-archive/msg01984.html IANAL, but I think this should be sufficient prior art against the main claims in the IBM patent application. Ben, I agree that having multiple signatures in a certificate could be useful. If, for example, the certificates in the wild today contained both MD5/RSA and SHA-1/RSA signatures, Mozilla would be able to disable MD5 support *today* without breaking the internet, as long as the majority of relying party software could process the additional signatures. If the industry chose to introduce such a thing now, it could help us all in the future when we need to move from SHA-1 to SHA-2, or from SHA-1/SHA-2 to SHA-3, etc. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 13.01.2009 09:48, Rob Stradling wrote: I made a similar suggestion to ietf.pkix in October 2006. See... http://www.imc.org/ietf-pkix/mail-archive/msg01964.html ...and the rest of that thread, including... http://www.imc.org/ietf-pkix/mail-archive/msg01984.html ... Ben, I agree that having multiple signatures in a certificate could be useful. If, for example, the certificates in the wild today contained both MD5/RSA and SHA-1/RSA signatures, Mozilla would be able to disable MD5 support *today* without breaking the internet, as long as the majority of relying party software could process the additional signatures. If the industry chose to introduce such a thing now, it could help us all in the future when we need to move from SHA-1 to SHA-2, or from SHA-1/SHA-2 to SHA-3, etc. Rob, I think that's an excellent suggestion. Not only because it allows more advanced trust management, but also, as you point out, because it eases the transition away from SHA-1 significantly, which I think will be very important and may shorten the transition by years. I think your proposal is nice, as it would allow to use the existing extension mechanism, which means that it doesn't break current browsers. Also, given that software will have to be changed anyways to support SHA-2 or whatever, and we'll eventually use only that, I think there's - in addition to the backwards-compatible way you propose - a chance to introduce a new format which supports several signatures in a straightforward way, and also other improvements which were hindered by backwards-compatibility. Greetings, and thanks a lot! Ben ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Thanks Ben. Perhaps it's time to have another go at canvassing support for the idea. In 2006, the PKIX WG didn't seem interested in tackling the problem I was trying to solve. Paul, do you think it's worth re-raising this idea with the PKIX WG ? On Tuesday 13 January 2009 09:39:06 Ben Bucksch wrote: On 13.01.2009 09:48, Rob Stradling wrote: I made a similar suggestion to ietf.pkix in October 2006. See... http://www.imc.org/ietf-pkix/mail-archive/msg01964.html ...and the rest of that thread, including... http://www.imc.org/ietf-pkix/mail-archive/msg01984.html ... Ben, I agree that having multiple signatures in a certificate could be useful. If, for example, the certificates in the wild today contained both MD5/RSA and SHA-1/RSA signatures, Mozilla would be able to disable MD5 support *today* without breaking the internet, as long as the majority of relying party software could process the additional signatures. If the industry chose to introduce such a thing now, it could help us all in the future when we need to move from SHA-1 to SHA-2, or from SHA-1/SHA-2 to SHA-3, etc. Rob, I think that's an excellent suggestion. Not only because it allows more advanced trust management, but also, as you point out, because it eases the transition away from SHA-1 significantly, which I think will be very important and may shorten the transition by years. I think your proposal is nice, as it would allow to use the existing extension mechanism, which means that it doesn't break current browsers. Also, given that software will have to be changed anyways to support SHA-2 or whatever, and we'll eventually use only that, I think there's - in addition to the backwards-compatible way you propose - a chance to introduce a new format which supports several signatures in a straightforward way, and also other improvements which were hindered by backwards-compatibility. Greetings, and thanks a lot! Ben ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
At 9:55 AM + 1/13/09, Rob Stradling wrote: Thanks Ben. Perhaps it's time to have another go at canvassing support for the idea. In 2006, the PKIX WG didn't seem interested in tackling the problem I was trying to solve. Paul, do you think it's worth re-raising this idea with the PKIX WG ? Dunno. The WG seems willing to take on anything that will keep it alive longer. On the other hand, even if your spec is accepted by the WG, I highly doubt you will get enough implementation to make it worth your time. That is, unless almost every piece of PKIX validating software added the extension, it wouldn't really add much value. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Why almost every piece of PKIX validating software ? I think it would be worth it if, at a minimum... - the majority of CAs added the extension to the certificates they issue, and... - Mozilla implemented support for the extension in NSS. This would allow Mozilla to disable a weak algorithm quickly, without having to wait for the majority of certificates in the wild to stop using that algorithm for their main certificate signature. I think the biggest barrier to adoption would be convincing enough of the CAs to implement it. But perhaps the Mozilla CA Certificate Policy could be updated to require CAs to implement it? On Tuesday 13 January 2009 14:50:32 Paul Hoffman wrote: At 9:55 AM + 1/13/09, Rob Stradling wrote: Thanks Ben. Perhaps it's time to have another go at canvassing support for the idea. In 2006, the PKIX WG didn't seem interested in tackling the problem I was trying to solve. Paul, do you think it's worth re-raising this idea with the PKIX WG ? Dunno. The WG seems willing to take on anything that will keep it alive longer. On the other hand, even if your spec is accepted by the WG, I highly doubt you will get enough implementation to make it worth your time. That is, unless almost every piece of PKIX validating software added the extension, it wouldn't really add much value. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Julien R Pierre - Sun Microsystems wrote: [...] I think many CAs will keep the serial numbers of expired certs on their CRLs for a few years after expiration. But I don't think most do that indefinitely. One big problem is that there is currently no way to tell which CAs do and do not. [...] The policy could *strongly suggest* for CA to include the expiredCertsOnCRL extension ? http://www.imc.org/ietf-pkix/mail-archive/msg01962.html It's quite unfortunate that efforts to include the description of expiredCertsOnCRL inside RFC5280 from X.509 were not successful (it has already too many things like if it didn't have a lot of things that are massively less useful than expiredCertsOnCRL), but I don't think it a good enough reason to deter any effort to use this simple but effective extension to document which certs are and aren't removed from the CRL. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Eddy Nigg wrote: [...] No exception can be added for revoked certificates, but for expired ones it's possible - hence it suggests that revocation is more severe than expired (if one can think in those terms). Or how would you explain that? As I have already found myself in the situation of really needing to override an expired certificate, I beg to differ and find an explanation. In the case of revoked certificates, you have positive proof that the CA wants that cert to be revoked. In the case of expired certificates, you just don't know. So it leave the possibility that you have out of band information that the key is not compromised and that you should be able to access the site. Another way of seeing this : The trouble here is that the Firefox SSL model mixes two things, telling me that the site is invalid, and letting me access it or not. Which as a consequence means that I sometimes need to override it whilst knowing the site is really invalid but I just need to access it despite that. The mail security model doesn't do that : I'll have a broken key but I'll still be able to read the mail even if the signature is invalid. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 01/12/2009 11:56 AM, Jean-Marc Desperrier: Eddy Nigg wrote: [...] No exception can be added for revoked certificates, but for expired ones it's possible - hence it suggests that revocation is more severe than expired (if one can think in those terms). Or how would you explain that? As I have already found myself in the situation of really needing to override an expired certificate, I beg to differ and find an explanation. In the case of revoked certificates, you have positive proof that the CA wants that cert to be revoked. Indeed! That was the point I was trying to make (and why i believe that expired but revoked certificates should never be removed from the CRL). Considering that intermediate CAs are more and more common and the encouraged practice anyway (and required by EV), those CRLs shouldn't grow that badly until the issuing CA certificate expires. As Julien also mentioned, some CAs keep the revoked certs for a period of N years in the CRL - with intermediates assumed limited life-time, we aren't really far from that. In the case of expired certificates, you just don't know. So it leave the possibility that you have out of band information that the key is not compromised and that you should be able to access the site. Yes, I view an expired certificate differently than a revoked one. There are indeed situations which require to access a site with an expired cert. -- 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: Cert expiry with Key Continuity Management
and required by EV ? Eddy, the EV Guidelines impose certain requirements on Intermediate CAs *when* they are used, but AFAIK they don't mandate that Intermediate CAs MUST be used. Visit https://www.securetrust.com in FF3 for an example of an EV-enabled Root Certificate (CN = SecureTrust CA) that issues EV SSL Certificates without involving any Intermediate CA(s) in the certificate chain. On Monday 12 January 2009 10:28:42 Eddy Nigg wrote: On 01/12/2009 11:56 AM, Jean-Marc Desperrier: Eddy Nigg wrote: [...] No exception can be added for revoked certificates, but for expired ones it's possible - hence it suggests that revocation is more severe than expired (if one can think in those terms). Or how would you explain that? As I have already found myself in the situation of really needing to override an expired certificate, I beg to differ and find an explanation. In the case of revoked certificates, you have positive proof that the CA wants that cert to be revoked. Indeed! That was the point I was trying to make (and why i believe that expired but revoked certificates should never be removed from the CRL). Considering that intermediate CAs are more and more common and the encouraged practice anyway (and required by EV), those CRLs shouldn't grow that badly until the issuing CA certificate expires. As Julien also mentioned, some CAs keep the revoked certs for a period of N years in the CRL - with intermediates assumed limited life-time, we aren't really far from that. In the case of expired certificates, you just don't know. So it leave the possibility that you have out of band information that the key is not compromised and that you should be able to access the site. Yes, I view an expired certificate differently than a revoked one. There are indeed situations which require to access a site with an expired cert. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 01/12/2009 12:45 PM, Rob Stradling: and required by EV ? Eddy, the EV Guidelines impose certain requirements on Intermediate CAs *when* they are used, but AFAIK they don't mandate that Intermediate CAs MUST be used. Visit https://www.securetrust.com in FF3 for an example of an EV-enabled Root Certificate (CN = SecureTrust CA) that issues EV SSL Certificates without involving any Intermediate CA(s) in the certificate chain. Did just thatand this site's certificate is signed by SecureTrust CA which chains to Entrust.net Secure Server Certification Authority. But besides that, it's perhaps not clearly defined in the EV Guidelines, but section 7 suggests that there are no roots issuing directly. -- 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: Cert expiry with Key Continuity Management
On Monday 12 January 2009 11:00:59 Eddy Nigg wrote: On 01/12/2009 12:45 PM, Rob Stradling: and required by EV ? Eddy, the EV Guidelines impose certain requirements on Intermediate CAs *when* they are used, but AFAIK they don't mandate that Intermediate CAs MUST be used. Visit https://www.securetrust.com in FF3 for an example of an EV-enabled Root Certificate (CN = SecureTrust CA) that issues EV SSL Certificates without involving any Intermediate CA(s) in the certificate chain. Did just thatand this site's certificate is signed by SecureTrust CA which chains to Entrust.net Secure Server Certification Authority. The Entrust.net Secure Server Certification Authority is used for legacy ubiquity only. Entrust and SecureTrust (aka Trustwave) have different EV Certificate Policy OIDs. https://www.securetrust.com only gets the EV UI in FF3 (and other EV-capable browsers) because the SecureTrust CA self-signed Root Certificate is enabled for EV. That's why Larry says Verified by: SecureTrust Corporation, rather than Verified by: Entrust, Inc. for https://www.securetrust.com. But besides that, it's perhaps not clearly defined in the EV Guidelines, but section 7 suggests that there are no roots issuing directly. I disagree. Section 7 says that EV Subordinate CA Certificates may exist, and it imposes some restrictions relating to Certificate Policy OIDs. But it does not say that Root CA Certificates should not be used for issuing end-entity EV Certificates. In fact, it says... The Application Software Vendor identifies Root CAs that are approved to issue EV Certificates... ...which surely cannot mean Root CAs are not approved to issue EV Certificates ! -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 01/12/2009 01:20 PM, Rob Stradling: The Entrust.net Secure Server Certification Authority is used for legacy ubiquity only. Entrust and SecureTrust (aka Trustwave) have different EV Certificate Policy OIDs. https://www.securetrust.com only gets the EV UI in FF3 (and other EV-capable browsers) because the SecureTrust CA self-signed Root Certificate is enabled for EV. I can't find the SecureTrust CA request for enabling EV. It's not on the pending list, not on the included list, nor could I find bug for it... anybody know where the paper trail is for this CA? That's why Larry says Verified by: SecureTrust Corporation, rather than Verified by: Entrust, Inc. for https://www.securetrust.com. I'm almost certain that the Verified by usually lists the last CA certificate in the chain. At least for regular SSL certs. I disagree. Section 7 says that EV Subordinate CA Certificates may exist, and it imposes some restrictions relating to Certificate Policy OIDs. But it does not say that Root CA Certificates should not be used for issuing end-entity EV Certificates. In fact, it says... The Application Software Vendor identifies Root CAs that are approved to issue EV Certificates... ...which surely cannot mean Root CAs are not approved to issue EV Certificates ! Than this is another issue to suggest change. Perhaps I wanted it to read that EV roots which are approved to issue EV certs, but issuing from intermediate - as most CAs actually have done so. That includes Verisign (most notable) which transitioned to issuing from intermediate's a while ago. Mozilla doesn't enable intermediate CAs, it enables roots, even if only one intermediate issues EV and the root never does directly. -- 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: Cert expiry with Key Continuity Management
On 12/1/09 10:56, Jean-Marc Desperrier wrote: Eddy Nigg wrote: [...] No exception can be added for revoked certificates, but for expired ones it's possible - hence it suggests that revocation is more severe than expired (if one can think in those terms). Or how would you explain that? As I have already found myself in the situation of really needing to override an expired certificate, I beg to differ and find an explanation. In the case of revoked certificates, you have positive proof that the CA wants that cert to be revoked. And in the case of an expired certificate, you have positive proof that the CA wants that cert expired. These are word games. What is the definition of these words? If you look in the RFCs, likely (I have not, please correct me if I am wrong) it will defer the precise definition of these two words and their relationship up to the CPS. Which means they are anything that *each CA* decides upon. The end result is quite open in practice. There are some reason codes for revocation, but they are not necessarily followed. Some people revoke certs because they are no longer using them, not because they are compromised in any way. CAs can offer to unrevoke certs by taking them out of the CRLs. Some CAs apparently offer the suspended state... For some reason, revocation is not the killer-option it is in the OpenPGP world, where a key signs its own death warrant, and once released can never be called back. So we end up with revocation being approximately like expiry. About the only thing you can say is the CA doesn't want us to use that cert. Indeed if you consider the structure of certs over time, revocation has to be more or less the same as expiry, because the real reason for expiry is that the CRLs need to be bounded. PKI doesn't need expiry if it doesn't need revocation. We need revocation therefore we need expiry. (Need here means, to make the thing work, as opposed to a useful user-level feature of choice.) In the case of expired certificates, you just don't know. So it leave the possibility that you have out of band information that the key is not compromised and that you should be able to access the site. Perhaps a way to ask this is, when you see a revoked certificate listed in a CRL, do you have faith in the reason codes? If the reason codes tell you something mild, can you exclude the possibility of compromise? Are you going to go through the CPS and the RFCs and figure out where you stand? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On Monday 12 January 2009 12:10:17 Eddy Nigg wrote: On 01/12/2009 01:20 PM, Rob Stradling: The Entrust.net Secure Server Certification Authority is used for legacy ubiquity only. Entrust and SecureTrust (aka Trustwave) have different EV Certificate Policy OIDs. https://www.securetrust.com only gets the EV UI in FF3 (and other EV-capable browsers) because the SecureTrust CA self-signed Root Certificate is enabled for EV. I can't find the SecureTrust CA request for enabling EV. It's not on the pending list, not on the included list, nor could I find bug for it... anybody know where the paper trail is for this CA? https://bugzilla.mozilla.org/show_bug.cgi?id=409837 That's why Larry says Verified by: SecureTrust Corporation, rather than Verified by: Entrust, Inc. for https://www.securetrust.com. I'm almost certain that the Verified by usually lists the last CA certificate in the chain. At least for regular SSL certs. Ah yes, you may well be right. I was probably thinking of IE7's equivalent behaviour. In any case, if you compare the EV Policy OIDs mentioned in Bug #409837 (SecureTrust) and Bug #416544 (Entrust) with the EV Policy OID in the site certificate for www.securetrust.com, you'll see that it's the SecureTrust CA which gives that site the EV UI. I disagree. Section 7 says that EV Subordinate CA Certificates may exist, and it imposes some restrictions relating to Certificate Policy OIDs. But it does not say that Root CA Certificates should not be used for issuing end-entity EV Certificates. In fact, it says... The Application Software Vendor identifies Root CAs that are approved to issue EV Certificates... ...which surely cannot mean Root CAs are not approved to issue EV Certificates ! Than this is another issue to suggest change. Perhaps I wanted it to read that EV roots which are approved to issue EV certs, but issuing from intermediate - as most CAs actually have done so. That includes Verisign (most notable) which transitioned to issuing from intermediate's a while ago. Mozilla doesn't enable intermediate CAs, it enables roots, even if only one intermediate issues EV and the root never does directly. Just because VeriSign use Intermediates for EV, I don't think that means that Mozilla should require CAs such as SecureTrust to do the same. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 01/12/2009 02:56 PM, Rob Stradling: I can't find the SecureTrust CA request for enabling EV. It's not on the pending list, not on the included list, nor could I find bug for it... anybody know where the paper trail is for this CA? https://bugzilla.mozilla.org/show_bug.cgi?id=409837 It's even on my CC's list...but I used search: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=SecureTrust I think search is broken because it reports Zarro Boogs found. :S Or maybe the simple search only returns new and open bugs. Just because VeriSign use Intermediates for EV, I don't think that means that Mozilla should require CAs such as SecureTrust to do the same. No, it's because Mozilla itself views this as the correct practice. I would go as far and require it, simple as that. That should be really an issue for the CAB forum however. BTW, my point wasn't *because* of Verisign, but *even* Verisign does it ;-) -- 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: Cert expiry with Key Continuity Management
On Monday 12 January 2009 13:07:17 Eddy Nigg wrote: snip I would go as far and require it, simple as that. You are entitled to your opinion. That should be really an issue for the CAB forum however. So why don't you join the CA/Browser Forum and share your opinion? BTW, my point wasn't *because* of Verisign, but *even* Verisign does it ;-) OK. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 01/12/2009 03:17 PM, Rob Stradling: So why don't you join the CA/Browser Forum and share your opinion? Patience is one of the ingredients for success... getting there! -- 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: Cert expiry with Key Continuity Management
Jean-Marc, Jean-Marc Desperrier wrote: Julien R Pierre - Sun Microsystems wrote: [...] I think many CAs will keep the serial numbers of expired certs on their CRLs for a few years after expiration. But I don't think most do that indefinitely. One big problem is that there is currently no way to tell which CAs do and do not. [...] The policy could *strongly suggest* for CA to include the expiredCertsOnCRL extension ? http://www.imc.org/ietf-pkix/mail-archive/msg01962.html It's quite unfortunate that efforts to include the description of expiredCertsOnCRL inside RFC5280 from X.509 were not successful (it has already too many things like if it didn't have a lot of things that are massively less useful than expiredCertsOnCRL), but I don't think it a good enough reason to deter any effort to use this simple but effective extension to document which certs are and aren't removed from the CRL. Thanks for that link. NSS is still trying to catch up to RFC 3280, let alone 5280. I agree it's unfortunate that this extension didn't make it into RFC 5280 . I don't have the time to particpate in ietf-pkix discussions, though. Is this extension defined in any other RFC perhaps ? Note this extension is pretty much irrelevant for SSL which is a real-time protocol, but it is relevant to S/MIME where things may be verified at dates other than the current date. But this opens another can of worms since RFC 3280 / 5280 don't define an algorithm that works well for dates other than the current date. I think such an algorithm would require the use of an extension like expiredCertsOnCRL. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Ian G wrote, On 2009-01-08 16:42: On 9/1/09 00:46, Ben Bucksch wrote: Certs expire for the same reason that credit cards do. Do you understand why that is? No, quite frankly, I do not. First off, my credit cards (VISA, MasterCard) are valid until Jan 1, 2013. I had to think about it too ... I think it is because in the old days, the retailers had little pieces of paper with all the revoked credit card numbers. Shop assistants were paid a reward for spotting the bad credit cards. Back in the early days (I remember being trained on these papers, we kept them under the register) there were around 100-1000 numbers on them. In the mid-1960s, when I was a lad, my mother took me shopping with her. When time came to pay for her purchases, she pulled out her shiny brand new credit card and presented it to the cashier. The cashier looked abjectly terrified. She called her supervisor over to help her through the process. They pulled a book out of a drawer below the cash register. It was about the same size as the local phone book, and printed on the same sort of very thin slightly gray paper as used in phone books, but it was much thicker. She put it down and began to flip through the pages. I saw that each page had numerous columns, all containing numbers. The top outer corners of the pages showed the minimum and maximum number on each page, to make it easier to find the right page to search, just as a dictionary typically shows the alphabetically minimum and maximum words on each page in the upper corners. She found the right page and then scanned it in detail. When she was satisfied that the card number was not present, she asked her supervisor to double check and confirm it. Then they closed the book and on its cover I saw the words Revoked Card List and the month and year for which is was current. They published a new phone book like that for every participating merchant every month. Each book had the numbers of ALL unexpired revoked cards for the entire world (which was limited to parts of North America at that time for that issuer). The single most important thing that the cashier was required to check was the expiration date on the card. Cashiers were required to mark on the transaction slip that they had checked the expiration date. Being expired meant that the number would NOT be present in the RCL book, even if the card had been revoked before it expired. Expiration kept the size of that RCL book manageable. CRLs are the modern analog of those old RCLs, and OCSP is the analog of those ubiquitous card-swipe devices that contact the issuer and get approval. Despite this, many CAs still prefer to issue CRLs over using OCSP, perhaps because the cost of publishing CRLs is so much less than the cost of publishing those old phone-book sized documents. Also, as Julien has pointed out, for servers doing high volumes of revocation checking, having a full CRL locally is much more efficient than using OCSP for every cert. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Julien R Pierre - Sun Microsystems wrote: [...] As for case b, if I understand correctly, you are saying CRLs growing unbounded is not a problem in a world without CRLs. Right :) ? The fact is that both CRLs and OCSP have their uses, in different places. [...] Also the problem is that if only the CA in a central location can answer the OCSP response it becomes a single point of failure, so in many case you need to have several responding entity, or at least several response location. And need to transmit the revocation information between them. So again you have a size problem even with OCSP. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 01/09/2009 06:40 AM, Ben Bucksch: Obviously I trust the software I run, out of necessity. I do not trust the CA operations. If there was minimal hope that they'd do a decent job, that has been destroyed over last Christmas. I anticipated comments like this one, but the good thing is that stakes are rather high for CAs, hence they are improving and resolutions happen rather fast. This is at least true for some of the events we've seen (Verisign, StartCom). On the other hand, any flaw outside of CAs are up to individuals which couldn't care less sometimes (as shown in the Debian fiasco). But as Robert and Julien already said, those who care know in such cases. -- 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: Cert expiry with Key Continuity Management
Robert Relyea wrote: [...] KCM is good for a single pipe between to fixed and seldom changing computers, [...]. In the many to many or the one to many case, KCM trains the user to ignore the warning messages. [...] Mozilla is the same. Users are making lots of connections, often to new sites that they have never visited before. They trash their profiles. They reload their machines. [...] I wanted to make more or less the same point. KCM in SSH works well with a small number of computer, if you have to establish trust with a new one rarely, and if you keep connecting to the same computers again and again, and their config almost never changes. This really doesn't scale to the internet and SSL. Even casual users can visit hundred of sites in one day, and for most of them never come back to visit them again later. Also, there's another important pattern I notice with SSL use on the internet : - They are few sites on which SSL is both really important and that are misconfigured. - They are many sites (the most in those 8% of self-signed certs) where SSL is completely misconfigured but it's not so important, because whilst there's some info I want to *read* on the site I certainly don't intend to send it any sensitive info. Which means that more often than not the default checking of the Permanently store this exception check-box of Fx, is annoying for me. Because I just want to see what's on this site this one time, thank you Fx for warning me it hasn't proper protection, but don't clutter my profile with that, and on the whole I'd prefer to be warned again if I ever come back again to the same site. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
At 12:42 AM +0200 1/9/09, Eddy Nigg wrote: On 01/09/2009 12:15 AM, Nelson B Bolyard: It requires that CAs NEVER forget about any certs they previously issued, not even after they expire. It means that a CA's list of revoked certs will grow boundlessly. It makes CRLs become impractically big. Well...StartCom NEVER removes a certificate from the CRL once revoked. That's because people tend to view expired certificates as an annoyance, not critical. However a revoked certificate should never be accessible anymore. (Just think about the mozilla.com certificate. I bet that the majority would click through that certificate in case of expiration, whereas they can't because of revocation. There is an inherent difference between the two). Eddy, do your postings *always* have to sound like blatant advertising for StartCom, even when you are saying that you make one of the many valid choices? RFC 5280 explicitly allows CAs to only list unexpired certs in its CRLs. In fact, that is the only scenario that is listed; the one that you have chosen is allowed but not emphasized as much as the one that Nelson described. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Eddy, Eddy Nigg wrote: On 01/09/2009 03:41 AM, Julien R Pierre - Sun Microsystems: FYI, if a certificate is expired, NSS won't even bother performing a revocation check on it, either CRL or OCSP. Are you sure? Yes. The validity check is one of the earliest ones that happens on the cert. See http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#1091 Also http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#1326 There are a few new cert validation in libpkix for NSS 3.12 , but I think still the expiration check remains an early one, and it definitely is optimized to do revocation checks only when needed. Ie. the expiration of the cert is more critical information than its revocation status I think that's wrong as I explained in the previous mail. Well, we'll just have to agree to disagree :) IMO revocation really doesn't matter if you already know the certificate is invalid at the time you are checking it. It's like trying to check a dead person's pulse. Yet the PSM UI lets you click to override the expiration of a cert, but not for revocation. I don't think it makes much sense to override either case. Well...I think expiration has some use for control panels and such stuff, without it one would have a hard time updating the cert in case it was forgotten. The same is true for overriding an eventual exception for initial cases (on a temporary basis). It happens to me every time I install a new server. Time zone issues, perhaps. Or time sync. I have seen those kinds of problems before. They shouldn't last very long though. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Ben, Ben Bucksch wrote: Our CAs would not be allowed to do that. It's fairly trivial to keep the whole list. It's not going to grew over a Gigabyte, any MySQL could do that. Including the replication to have it redundant. Certainly it's trivial, but not inexpensive especially on large scales. And currently it just isn't guaranteed to happen in most CAs. It certainly should be allowed to a degree. I think many CAs will keep the serial numbers of expired certs on their CRLs for a few years after expiration. But I don't think most do that indefinitely. One big problem is that there is currently no way to tell which CAs do and do not. The warning, in turn, ensures that you cannot just walk to *any* CA, without any connection to the victim site, and get a valid cert. It *has* to be signed by the private key, which means the attacker *has* to break into my systems. You could also solve that problem by having only one trusted root, or having roots that use name constraints. Then everybody would have only one CA they could go to. No. If that one CA then doesn't do a decent job, makes an error, that's no help either. If that happens, then you could stop trusting it, and replace it with another root that does a better job. But overall I think it's better to have a system with multiple roots and ovelapping name spaces to maintain competition. However it definitely reduces security - the more roots we have, the more difficult it is to trust them all. That's why audits become even more important. If you assume that users ignore and override all warnings, we are already screwed with the current system, because the user can also override a self-signed cert. Yet, that warning is now a serious stopgap for attackers of a bank. And it definitely helps security-conscious users. Well, I do consider that a serious problem - most users don't understand PKI, and probably have no business overriding any self signed cert warning. What I am thinking of (which I think is different from that patent) is that we attach something to the end (or beginning) of the binary blob that is the cert, in a way that it treated as garbage by older browsers. Unfortunately, that wouldn't be possible, because it would violate the existing ASN.1 definition of the signed certificate. There is no optional field where you could fit a second signature. In any case, you can just get a second certificate with the same public key from another CA if you need that ability. It doesn't have to be in the same unique cert. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 01/09/2009 10:20 PM, Julien R Pierre - Sun Microsystems: Well, we'll just have to agree to disagree :) IMO revocation really doesn't matter if you already know the certificate is invalid at the time you are checking it. It's like trying to check a dead person's pulse. Then there isn't perhaps much logic in disallowing any override capability for revocations, whereas expiration can be overridden via exception. No exception can be added for revoked certificates, but for expired ones it's possible - hence it suggests that revocation is more severe than expired (if one can think in those terms). Or how would you explain 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: Cert expiry with Key Continuity Management
Eddy, Eddy Nigg wrote: On 01/09/2009 10:20 PM, Julien R Pierre - Sun Microsystems: Well, we'll just have to agree to disagree :) IMO revocation really doesn't matter if you already know the certificate is invalid at the time you are checking it. It's like trying to check a dead person's pulse. Then there isn't perhaps much logic in disallowing any override capability for revocations, whereas expiration can be overridden via exception. No exception can be added for revoked certificates, but for expired ones it's possible - hence it suggests that revocation is more severe than expired (if one can think in those terms). Or how would you explain that? I agree, the UI is not logical. IMO, there should be no override for either case. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 01/10/2009 01:35 AM, Julien R Pierre - Sun Microsystems: Then there isn't perhaps much logic in disallowing any override capability for revocations, whereas expiration can be overridden via exception. No exception can be added for revoked certificates, but for expired ones it's possible - hence it suggests that revocation is more severe than expired (if one can think in those terms). Or how would you explain that? I agree, the UI is not logical. IMO, there should be no override for either case. Can you open a bug (and propose a patch :-) ). Kai should be copied on it. -- 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: Cert expiry with Key Continuity Management
Ben, Thank you for starting this thread. This is a MUCH better place than in bugzilla for such a discussion to take place. A possible solution (already posted in comment 18 in the bug): I encourage people to read through that bug, especially the early comments, before contributing here. (The later comments are mostly me too) * Require website owners to continue using the same private key. This flies in the face of best current practices. * A fingerprint of that private key is put in the certificate. Such a fingerprint already exists in the cert. It is the public key. * After expiry of the cert (even now, only the cert expires, not the private key), the web site owner requests another cert from the CA, which certifies the same private key for another year, with a new certificate. Certs expire for the same reason that credit cards do. Do you understand why that is? * We see that the private key stayed the same, and we're happy - it's the same party. We can implement KCM. * Revocation in case of key loss via CRL or OSCP is still possible. It requires that CAs NEVER forget about any certs they previously issued, not even after they expire. It means that a CA's list of revoked certs will grow boundlessly. It makes CRLs become impractically big. CACert tried that once. They had a multi-megabyte CRL (maybe they still do). * If, for some reason - be it key stolen, cryptographic weakness, or that the admin prefers to generate a new private key all the time - the private key changes, the public cert *must* also be signed by the old private key, in addition to the CA. Certs do not have multiple signatures. This is what GPG does, too. This shows us that the new key is authorized by the old owner, so continuity is maintained. So, after a key is compromised, it remains desirable that replacement keys are authorized by a signature made with the compromised key? The only problem is if the admin is ignorant of this new scheme and does not sign the new cert or the private key is lost insofar as the admin cannot find it anymore. This is a separate discussion, see thread opener. Is it technically possible for a cert to have two or more signatures? No. X.509 certificates do not have multiple signatures. (I think it is - if I'm not mistaken, a cert can also have both MD5 and SHA2 signatures.) You are mistaken. If not, can it be added by extensions? No, because the content of all extensions are included in the computation of the signature. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 01/09/2009 12:15 AM, Nelson B Bolyard: It requires that CAs NEVER forget about any certs they previously issued, not even after they expire. It means that a CA's list of revoked certs will grow boundlessly. It makes CRLs become impractically big. Well...StartCom NEVER removes a certificate from the CRL once revoked. That's because people tend to view expired certificates as an annoyance, not critical. However a revoked certificate should never be accessible anymore. (Just think about the mozilla.com certificate. I bet that the majority would click through that certificate in case of expiration, whereas they can't because of revocation. There is an inherent difference between the two). CACert tried that once. They had a multi-megabyte CRL (maybe they still do). We manage however intermediate CA issuers per class and purpose, hence the CRLs stay relatively small. The intermediate CAs are valid for five years, whereas after the fourth year a new issuer takes over (leaving the fifth year for revocations only). That's perhaps another good practice...besides that, OCSP hasn't the draw-back of large downloads anyway - and Firefox doesn't use CRLs really. -- 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: Cert expiry with Key Continuity Management
On 08.01.2009 23:15, Nelson B Bolyard wrote: I encourage people to read through that bug, especially the early comments, before contributing here. (The later comments are mostly me too) Esp. because the first are from you (and are dissenting, and therefore important, while agreeing comments are just me too, right?). * Require website owners to continue using the same private key. This flies in the face of best current practices. I think the current practices, of the whole PKI system on many levels, are extremely bad. Please be specific and rational in your arguments. This is how we're doing things so far or This is how this system was defined is not an argument. Certs expire for the same reason that credit cards do. Do you understand why that is? No, quite frankly, I do not. First off, my credit cards (VISA, MasterCard) are valid until Jan 1, 2013. My GPG key expires in 10 years or something, and it hasn't been any problem. My SSH keys also never expire, and that's good. The CA root certs don't expire for 20 years. If the private key on the server is secure, all is fine. If somebody breaks into the server and the private key gets known to the attacker, it's being revoked. It means that a CA's list of revoked certs will grow boundlessly. It makes CRLs become impractically big. With OCSP, it's not a problem anymore, because the question is is *this* cert still valid? not tell me all revoked certs. It requires that CAs NEVER forget about any certs they previously issued, not even after they expire. They get paid for it, for each cert. Hotmail and Yahoo also never forget the email addresses that were issued (they may get deactivated, but the account still exists), and it's not even a paid service. This is what GPG does, too. This shows us that the new key is authorized by the old owner, so continuity is maintained. So, after a key is compromised, it remains desirable that replacement keys are authorized by a signature made with the compromised key? Yes. It - at worst - means that either rightful owner or the attacker endorses the new key, reducing the candidates from the whole world to two. The CA needs to approve the new key as well, though, so the attacker has to gain *both* the old private key and get the approval of the CA. More importantly, it helps the normal situation that a the owner decides to use a new key, for whatever reason, and prevents a spurious warning for users in that case. The warning, in turn, ensures that you cannot just walk to *any* CA, without any connection to the victim site, and get a valid cert. It *has* to be signed by the private key, which means the attacker *has* to break into my systems. This means that if I can manage to keep my systems secure, there's really no way an attacker can get between me and my existing users / communication partners. This is as secure as it gets. (If an attacker breaks into one of the partners' systems, all bets are off, in any system.) CAs and their verification processes are currently a potential vulnerability, even if my systems are entirely secure. They would no longer be for me and my friends. Is it technically possible for a cert to have two or more signatures? No. X.509 certificates do not have multiple signatures. No, because the content of all extensions are included in the computation of the signature. Can we create another extension? The signature itself is a shell around the certified bits. Add the second signature around that first signature. There must be a way to add signatures. It's a base feature in PGP! If it's entirely impossible to have two signatures, and no way to add it to the spec, that's a design error. It's hard to believe that it's so limited. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 9/1/09 00:46, Ben Bucksch wrote: Certs expire for the same reason that credit cards do. Do you understand why that is? No, quite frankly, I do not. First off, my credit cards (VISA, MasterCard) are valid until Jan 1, 2013. I had to think about it too ... I think it is because in the old days, the retailers had little pieces of paper with all the revoked credit card numbers. Shop assistants were paid a reward for spotting the bad credit cards. Back in the early days (I remember being trained on these papers, we kept them under the register) there were around 100-1000 numbers on them. Obviously that model didn't survive (there was real money involved) and now all CCs are checked online, real time. So expiry should not be a big deal anymore for *security* reasons. Business reasons may still play a part, I think my (awful huge) online bank wants to give me a new CC with a smart card, tell me its more secure, not to worry, and by the way, all the liability has shifted to me because I won't ever lose any money. Or somesuch complete travesty... With OCSP, it's not a problem anymore, because the question is is *this* cert still valid? not tell me all revoked certs. It's the net, dude! Only an online model makes sense. The 1980s telcos didn't really know what they were looking at with this whole telephone book in a cert thing. It requires that CAs NEVER forget about any certs they previously issued, not even after they expire. They get paid for it, for each cert. Hotmail and Yahoo also never forget the email addresses that were issued (they may get deactivated, but the account still exists), and it's not even a paid service. CAs probably have to remember the certs -- all of them -- for many years for verification reasons. It will be in the CPS somewhere. (OK, let me backtrack ...) it will be in the CPS for some CAs. The reasons are obscure and possibly only Verisign really has a good understanding of this, they are the only CA that seems to have a legal competence to use the word correctly.) Nelson's point was that CRLs become unbounded; but that's not a problem (a) if there are no disputes or (b) in an OCSP world. Pick (a) or (b). Is it technically possible for a cert to have two or more signatures? No. X.509 certificates do not have multiple signatures. No, because the content of all extensions are included in the computation of the signature. Can we create another extension? The signature itself is a shell around the certified bits. Add the second signature around that first signature. It is possible ... but you'd be better off trying to move Everest into China. One of the core assumptions of the x.509 world is ONE SIGNATURE, and ONE AUTHORITY. Nobody's going to agree with you. There must be a way to add signatures. It's a base feature in PGP! If it's entirely impossible to have two signatures, and no way to add it to the spec, that's a design error. It's hard to believe that it's so limited. Different school of thought. Sorry :) iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Advocacy: One of the core assumptions of the x.509 world is ONE SIGNATURE, and ONE AUTHORITY. Thing is: There is no one authority :-). God doesn't issue SSL certificates. Apart from him, I trust only me and my friends. Different school of thought. Yes, definitely. It's the reason why S/MIME never took off for private mail - it just doesn't fit. It's a 1:1 relationship, with no place for a CA (apart from first sight maybe). This proposal has the potential to let these two camps make peace. To let SSL be useful in the other scenario, too, where I need a strong, direct, continuous trust relationship with another party online. Please don't fend it off because the proposal is somewhat different from the old model. It has to be. It's a relatively small change in comparison to using an entirely different system for those other needs. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Ben Bucksch wrote:
On 08.01.2009 23:15, Nelson B Bolyard wrote:
I encourage people to read through that bug, especially the early
comments, before contributing here. (The later comments are mostly
me too)
Esp. because the first are from you (and are dissenting, and therefore
important, while agreeing comments are just me too, right?).
* Require website owners to continue using the same private key.
This flies in the face of best current practices.
I think the current practices, of the whole PKI system on many levels,
are extremely bad.
Please be specific and rational in your arguments. This is how we're
doing things so far or This is how this system was defined is not
an argument.
Oh, so let's replace it with something that is definately less secure!
Allowing the same private key over an extended time is a question of CA
policy. Such allowances are already questionable *CRYPTO* (not PKI)
policy. A system that requires the same key is a non-starter. This is
crypto 101, right up there with not signing data passed to you in mass
by an attacker, or encrypting 2 different streams of data with the same
key in a stream cipher.
Certs expire for the same reason that credit cards do. Do you
understand why that is?
No, quite frankly, I do not.
First off, my credit cards (VISA, MasterCard) are valid until Jan 1,
2013.
My GPG key expires in 10 years or something, and it hasn't been any
problem. My SSH keys also never expire, and that's good. The CA root
certs don't expire for 20 years.
Several of these are problem. Debian-weak SSH keys never expire. The
risk these keys pose to PKI based apps are small and shrinking. SSH has
to depend on actively detecting those keys proactively. Those that
weren't detected slowly expire out of the system. It's the built-in
safety valve that adds robustness even with a weak revocation model.
Debian-weak SSH keys will plague the backwaters of the internet for a
long time.
If the private key on the server is secure, all is fine. If somebody
breaks into the server and the private key gets known to the attacker,
it's being revoked.
The security value of a private key degrades over time. The rate of
this effective degradation depends on the usage of the key, the
strength, etc. 10-20 years for an RSA 1024 bit key issued today is
definitely too long (independent on how it's used). A private key that's
stored on a hard drive on a machine should be treated as having a
smaller potential life than one stored in secured hardware. A key which
many potential people may have access to (including administrators) will
have a smaller potential life than one that doesn't.
Re: Revocation
Revocation in any Key system is a hard and expensive problem. PKI's have
tools and infrastructures in place to allow this, but even today it's
not really turned on everywhere.
--
There's a more fundamental problem here, though. KCM is popular among
people who know a little security because it puts the burden of
security in the users own hands. It makes sense. I want to control my
own destiny. The big secret is few (and I mean a lot fewer than people
think) of us are sufficiently diligent enough to use such a scheme on a
regular basis.
KCM is good for a single pipe between to fixed and seldom changing
computers, which are set up by a conscientious, knowledgeable person. In
the day to day operations it is an accident waiting to happen. I use ssh
daily. The only way I've found to keep myself honest is to use 'client
auth' to make up for the risk posed by using KCM for a many to many
connection scenario. In the many to many or the one to many case, KCM
trains the user to ignore the warning messages. Machines get reloaded
with new operating systems, events cause rekeying, I visit new machines
that I don't deal with every day. The whole burden is placed on me to
decide if I'm being attacked. 99.9% of the time I get a warning that is
benign That .1 % when it's not, I'm now trained to ignore it and I
know what I'm doing. I know what is going on under the covers. I keep
myself safe by never typing a password in an SSH pipe. If I can't make a
connection with a cert, it means I'm probably not connecting to the
machine I thought.
Mozilla is the same. Users are making lots of connections, often to new
sites that they have never visited before. They trash their profiles.
They reload their machines. They visit sites from their mom's computers.
Even if you could get every website to follow the (poor security)
practice of never changing their keys, you are generating so much noise
that users will ignore key change warnings.
The only use that I see of KCM is for a small community of users that
have some security training and believe that they can manage this system
themselves. For those users we have a solution today rm
{firefox_bin_dir}/nssckbi.dll and add each site as a security exception.
bob
Re: Cert expiry with Key Continuity Management
Ben Bucksch wrote: Advocacy: One of the core assumptions of the x.509 world is ONE SIGNATURE, and ONE AUTHORITY. Thing is: There is no one authority :-). God doesn't issue SSL certificates. Apart from him, I trust only me and my friends. That's clearly not the case. You have admitted to owning a credit card. In very real ways you trust a lot more than yourself and your friends... for a lot more than whether this website is who it says it is...;). ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Eddy, Eddy Nigg wrote: On 01/09/2009 12:15 AM, Nelson B Bolyard: It requires that CAs NEVER forget about any certs they previously issued, not even after they expire. It means that a CA's list of revoked certs will grow boundlessly. It makes CRLs become impractically big. Well...StartCom NEVER removes a certificate from the CRL once revoked. That's because people tend to view expired certificates as an annoyance, not critical. However a revoked certificate should never be accessible anymore. FYI, if a certificate is expired, NSS won't even bother performing a revocation check on it, either CRL or OCSP. It would be a waste of time, CPU and network resources to do so, and the revocation information would be irrelevant since NSS already knows the cert is expired. Ie. the expiration of the cert is more critical information than its revocation status - NSS can be certain the cert is no longer valid, because the validity date has been signed, and there is no point in checking revocation status. Yet the PSM UI lets you click to override the expiration of a cert, but not for revocation. I don't think it makes much sense to override either case. Note that the the argument about keeping or removing expired certs from CRLs is mostly about non realtime protocols, eg. S/MIME, where old messages with old certs may need to be reverified. Of course, since NSS/PSM doesn't do secure timestamps for S/MIME messages, much of this is academic, even if the CRL grows forever. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Ben, Ben Bucksch wrote: With OCSP, it's not a problem anymore, because the question is is *this* cert still valid? not tell me all revoked certs. No, the question OCSP asks is not that . It is is this cert revoked, as of the current date ? Note that OCSP does not allow revocation checks for date prior to the current date (whether of not that makes sense without secure timestamps, is another discussion). CRLs do. The OCSP responder is also allowed to forget about the revocation status of any cert that's outside its validity period. For more info on this, see RFC 2560, section 4.4.4, Archive cutoff. It requires that CAs NEVER forget about any certs they previously issued, not even after they expire. They get paid for it, for each cert. Hotmail and Yahoo also never forget the email addresses that were issued (they may get deactivated, but the account still exists), and it's not even a paid service. Nevertheless, the X.509 and PKIX standards don't require them to remember revocation status after cert expiration. It is allowed, but not required. I heard that the Archive cutoff extension was also allowed for CRLs, but I haven't found any reference that confirms that. This is what GPG does, too. This shows us that the new key is authorized by the old owner, so continuity is maintained. So, after a key is compromised, it remains desirable that replacement keys are authorized by a signature made with the compromised key? Yes. It - at worst - means that either rightful owner or the attacker endorses the new key, reducing the candidates from the whole world to two. The CA needs to approve the new key as well, though, so the attacker has to gain *both* the old private key and get the approval of the CA. Sorry, but that just doesn't make sense. And old keys can and do get lost all the time. More importantly, it helps the normal situation that a the owner decides to use a new key, for whatever reason, and prevents a spurious warning for users in that case. When someone chooses to use a new key, they can simply get a new certificate containing the public key and get it signed by the CA. There doesn't need to be any spurious warnings for anybody. The warning, in turn, ensures that you cannot just walk to *any* CA, without any connection to the victim site, and get a valid cert. It *has* to be signed by the private key, which means the attacker *has* to break into my systems. You could also solve that problem by having only one trusted root, or having roots that use name constraints. Then everybody would have only one CA they could go to. That actually fits with x.500 pretty well. But of course that would mean the end of competition between CAs, and it would be a bad thing. This means that if I can manage to keep my systems secure, there's really no way an attacker can get between me and my existing users / communication partners. This is as secure as it gets. (If an attacker breaks into one of the partners' systems, all bets are off, in any system.) Given what we know about warnings and how they are ignored by most users who don't understand them, I certainly wouldn't put too much faith into that ! Having roots with name constraints would be much more secure - since you couldn't have other CAs issuing valid certs for your identity. No, because the content of all extensions are included in the computation of the signature. Can we create another extension? The signature itself is a shell around the certified bits. Add the second signature around that first signature. There must be a way to add signatures. It's a base feature in PGP! If it's entirely impossible to have two signatures, and no way to add it to the spec, that's a design error. It's hard to believe that it's so limited. If one wanted to have another signature, it wouldn't be as an extension, since, as Nelson pointed out, extensions are part of what gets signed. The current single signature is not an extension. Well, I guess somebody did it anyway : http://www.freepatentsonline.com/y2008/0270788.html sigh. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Ian, Ian G wrote: Nelson's point was that CRLs become unbounded; but that's not a problem (a) if there are no disputes or (b) in an OCSP world. Pick (a) or (b). Uh ? In case a, even if there are no disputes, the CRL consumers all have to update the ever-growing CRLs. This can consume gigantic amounts of network bandwidth over time, especially if both the CRL and the number of consumers of that CRL grows. As for case b, if I understand correctly, you are saying CRLs growing unbounded is not a problem in a world without CRLs. Right :) ? The fact is that both CRLs and OCSP have their uses, in different places. IMO, CRLs belong on backends, which have to process large volume of incoming transactions, and can't afford to send outgoing OCSP requests for all their incoming requests, under severe performance penalties. OCSP is better suited for client apps, which should encounter a relatively small number of certs from a given CA. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
First off, please note that this is a proposed *change* to the PKI system. A small change, but nevertheless a change, yes. We're trying to make it more secure. So, That goes against current definitions is not an argument, it's inherent. No, the question OCSP asks is ... is this cert revoked, as of the current date ? That's what we need, yes. The OCSP responder is also allowed to forget about the revocation status of any cert that's outside its validity period. Our CAs would not be allowed to do that. It's fairly trivial to keep the whole list. It's not going to grew over a Gigabyte, any MySQL could do that. Including the replication to have it redundant. Thanks for the note, though. [Key continuity by old key signing new one] When someone chooses to use a new key, they can simply get a new certificate containing the public key and get it signed by the CA. Currently, yes. But so could anybody else in the world who manages to get past the CA. And immediately get access to all customers. (See below) This is what I consider the inherent and most important weakness of the PKI system, what makes it impossible for me to trust it. This is exactly what this proposal is supposed to stop. The warning, in turn, ensures that you cannot just walk to *any* CA, without any connection to the victim site, and get a valid cert. It *has* to be signed by the private key, which means the attacker *has* to break into my systems. You could also solve that problem by having only one trusted root, or having roots that use name constraints. Then everybody would have only one CA they could go to. No. If that one CA then doesn't do a decent job, makes an error, that's no help either. With connection to the victim site, I meant that *I* (as cert owner) have to be involved somehow in approving the certificate when it wants to be valid for my existing users. Involved includes my site being hacked, but that's at least something I can influence to some degree. I have absolutely no control over how a CA does it job. I don't want it to get into the middle of my *existing* relationships, that's the core. This means that if I can manage to keep my systems secure, there's really no way an attacker can get between me and my existing users / communication partners. This is as secure as it gets. (If an attacker breaks into one of the partners' systems, all bets are off, in any system.) Given what we know about warnings and how they are ignored by most users who don't understand them, I certainly wouldn't put too much faith into that ! If you assume that users ignore and override all warnings, we are already screwed with the current system, because the user can also override a self-signed cert. Yet, that warning is now a serious stopgap for attackers of a bank. And it definitely helps security-conscious users. If one wanted to have another signature, it wouldn't be as an extension, since, as Nelson pointed out, extensions are part of what gets signed. Yes, sorry for the inprecision, I meant here extension in the sense that it's something added to the cert definition, not the existing extension mechanism. The current single signature is not an extension. Well, I guess somebody did it anyway : http://www.freepatentsonline.com/y2008/0270788.html Thanks for the link. What I am thinking of (which I think is different from that patent) is that we attach something to the end (or beginning) of the binary blob that is the cert, in a way that it treated as garbage by older browsers. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 09.01.2009 05:32, Ben Bucksch wrote: The OCSP responder is also allowed to forget about the revocation status of any cert that's outside its validity period. Our CAs would not be allowed to do that. It's fairly trivial to keep the whole list. P.S. That wouldn't even be strictly necessary, as I am not proposing to dishonor the CA certificate. If the CA says it's expired, we would consider it so, no change to now. There's merely an *additional* requirement of the new key being signed by the old one. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On 09.01.2009 02:15, Robert Relyea wrote: Ben Bucksch wrote: Advocacy: One of the core assumptions of the x.509 world is ONE SIGNATURE, and ONE AUTHORITY. Thing is: There is no one authority :-). God doesn't issue SSL certificates. Apart from him, I trust only me and my friends. That's clearly not the case. You have admitted to owning a credit card. In very real ways you trust a lot more than yourself and your friends... for a lot more than whether this website is who it says it is...;). I wasn't talking about money. There are more important things than money. I was talking about emails (where the damage can be far higher, even for private mails), application update, configuration frontends of my own systems etc.. Obviously I trust the software I run, out of necessity. I do not trust the CA operations. If there was minimal hope that they'd do a decent job, that has been destroyed over last Christmas. Ben ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
