DRAFT Communication to CAs
Kathleen Wilson
Here is a draft of a communication that I am writing to send to CAs with
roots included in NSS. I would appreciate your feedback on it.
Thanks,
Kathleen
--
Title: Mozilla Communication to CAs regarding Policy updates
Dear Certification Authority,
On behalf of Mozilla, I am contacting you in regards to five important
points that we would like to bring to your attention.
1) Mozilla has started a project to update the Mozilla CA Certificate
Policy (http://www.mozilla.org/projects/security/certs/policy/). The
proposed changes may impact the operation of your root certificates that
are included in NSS. Therefore, we request that all CAs participate in
the discussions, which will be held in the mozilla.dev.security.policy
newsgroup and the corresponding dev-secur...@lists.mozilla.org
mailing list. For information about the potential changes, please see
https://wiki.mozilla.org/CA:CertPolicyUpdates.
2) As per the CA/Browser Forum’s Guidelines for EV Certs, we are
planning to update Mozilla products such that EV treatment will not be
given for end-entity certs that are issued after December 31, 2010 if
they do not have an OCSP URI in the AIA. This change is being tracked
here: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23
Additionally, we urge all CAs to provide OCSP for all certs, even when
they are not EV.
3) We expect that all new certificates contain randomness (preferably in
the serial number), especially when using the SHA-1 hash function or an
RSA key size smaller than 2048 bits. For more information, please see
http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period
and serial number prediction”, and section 7, “Countermeasures.”
4) As per the NIST guidelines, it is our expectation that all CAs are
transitioning from issuing certs with RSA key sizes smaller than 2048
bits. For more information, please see
https://wiki.mozilla.org/CA:MD5and1024.
5) We are planning to implement a code change to stop accepting MD5 as a
hash algorithm for intermediate and end-entity certs. For more
information, please see https://wiki.mozilla.org/CA:MD5and1024.
We look forward to your continued involvement and contributions to
improving Mozilla’s CA Certificate Policy and practices.
Regards,
Kathleen Wilson
--
David E. Ross
> All,
>
> Here is a draft of a communication that I am writing to send to CAs with
> roots included in NSS. I would appreciate your feedback on it.
>
> Thanks,
> Kathleen
[actual notice snipped]
I have no problem with the wording of the notice.
However, I would be concerned if comments by CAs were given equal weight
to comments by users. Mozilla's focus should be on what users need and
want, not on what CAs want. Protecting the security of users should
have a priority far above protecting the profits of CAs.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross
Gervase Markham
> 1) Mozilla has started a project to update the Mozilla CA Certificate
> Policy (http://www.mozilla.org/projects/security/certs/policy/). The
> proposed changes may impact the operation of your root certificates that
> are included in NSS. Therefore, we request that all CAs participate in
> the discussions, which will be held in the mozilla.dev.security.policy
> newsgroup and the corresponding dev-secur...@lists.mozilla.org
> mailing list.
At this point, I would link here:
http://www.mozilla.org/about/forums/#dev-security-policy
and just call it the "Mozilla dev.security.policy forum".
> 2) As per the CA/Browser Forum’s Guidelines for EV Certs, we are
> planning to update Mozilla products such that EV treatment will not be
> given for end-entity certs that are issued after December 31, 2010 if
> they do not have an OCSP URI in the AIA.
I personally am still uncertain that this is the right thing (with the
suggested alternative being to require OCSP validation, but allowing
stapling as well, so the OCSP URI would not necessarily need to be in
the AIA, if the CA contracted only with clients whose servers supported
stapling). Can we resolve that question before sending this email?
> 4) As per the NIST guidelines, it is our expectation that all CAs are
> transitioning from issuing certs with RSA key sizes smaller than 2048
> bits. For more information, please see
> https://wiki.mozilla.org/CA:MD5and1024.
Should we mention a deadline?
Gerv
Eddy Nigg
> I personally am still uncertain that this is the right thing (with the
> suggested alternative being to require OCSP validation, but allowing
> stapling as well, so the OCSP URI would not necessarily need to be in
> the AIA, if the CA contracted only with clients whose servers
> supported stapling).
I just wonder, how do you intend to check the certificate status without
that? If and when stapling is supported, the AIA extension can be
ignored by the browser obviously.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Paul Tiemann
>> planning to update Mozilla products such that EV treatment will not be
>> given for end-entity certs that are issued after December 31, 2010 if
>> they do not have an OCSP URI in the AIA.
>
What about something like this: "EV treatment will not be given for end-entity certs that are issued after December 31, 2010 if the certificate's status cannot be verified by a valid OCSP response--either through a stapled OCSP response sent by the server, or by checking the OCSP URI in the cert's Authority Information Access extension."
>> 4) As per the NIST guidelines, it is our expectation that all CAs are
>> transitioning from issuing certs with RSA key sizes smaller than 2048
>> bits. For more information, please see
>> https://wiki.mozilla.org/CA:MD5and1024.
>
> Should we mention a deadline?
On the wiki page for MD5and1024, I'm curious about the specifics on this sentence:
"Note: DRAFT Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes: Key lengths providing 80 bits of security using approved digital signature algorithms are allowed for legacy use after 2010."
Two weeks ago I talked with someone who wanted to know if DigiCert could still issue a certificate with a 1024 bit RSA key. He was running an older load balancer or firewall product (I can't remember which now) and it wouldn't take a 2048 bit certificate . . . Would this use case be allowed for by the text above referring to "legacy use" after 2010?
Paul Tiemann
CTO, DigiCert Inc
Gervase Markham
> I just wonder, how do you intend to check the certificate status without
> that? If and when stapling is supported, the AIA extension can be
> ignored by the browser obviously.
My understanding is that stapling means that the OCSP response gets sent
by the webserver as part of the handshake, and so can be checked as
valid in the normal way without the browser needing an AIA URL.
Am I wrong?
Gerv
Gervase Markham
> What about something like this: "EV treatment will not be given for
> end-entity certs that are issued after December 31, 2010 if the
> certificate's status cannot be verified by a valid OCSP
> response--either through a stapled OCSP response sent by the server,
> or by checking the OCSP URI in the cert's Authority Information
> Access extension."
The difficulty is deciding if this is something we want to do, not in
drafting language to say it :-) But thank you - that will do nicely, if
we decide to say this.
Gerv
Eddy Nigg
There is a big IF - IF the web server sends a valid OCSP response, but
if not? How does an AIA extension prevent OCSP stapling? Can the CA
enforce and guaranty that every web server sends a correct, always valid
OCSP response? How should the browser find the OCSP responder if it doesn't?
Paul Tiemann
> On 01/10/10 12:40, Eddy Nigg wrote:
>> I just wonder, how do you intend to check the certificate status without
>> that? If and when stapling is supported, the AIA extension can be
>> ignored by the browser obviously.
>
> My understanding is that stapling means that the OCSP response gets sent by the webserver as part of the handshake, and so can be checked as valid in the normal way without the browser needing an AIA URL.
It just occurred to me that if the AIA lacked the OCSP URL, the web servers doing the OCSP stapling would have to be manually configured to get OCSP responses from the "hidden origin" since the web server would have no idea how to fetch a response by looking at the certificate.
While I don't think it's a good idea for most certificates, I can think of two cases where it would be useful:
1) Very security or privacy sensitive certificates. Imagine you want a certificate from a 3rd party CA, but you don't want them to be able to analyze their OCSP traffic to determine _anything_ at all about the people who are visiting your site (not even a rough picture of how many people are doing SSL handshakes with you) -- in a case like this it would be useful to still provide stapled OCSP responses from the server, and force all the other clients to fetch the CRL instead of trying the OCSP URL.
2) Extremely active websites. If a CA's OCSP responder is taking 10K hits per second for just one super-active certificate, it would be great to yank the OCSP URL from the certificate and just depend on the server to pass out stapled responses. This would still actually leak a lot of the pain to the CA if the stapled OCSP response can't include a response for each certificate in the chain: the end entity and the intermediate certificate(s). At the moment, 36% of all OCSP requests that come to DigiCert are for checking our 2 main intermediate certificates. I wonder if checking intermediate certificates via CRL instead of OCSP would be a good way to sidestep this problem -- I know Opera is checking CA certs via CRLs, but I'm not sure if this is the reason.
Paul Tiemann
CTO DigiCert
Gervase Markham
> There is a big IF - IF the web server sends a valid OCSP response, but
> if not? How does an AIA extension prevent OCSP stapling? Can the CA
> enforce and guaranty that every web server sends a correct, always valid
> OCSP response? How should the browser find the OCSP responder if it
> doesn't?
It shouldn't; it should treat it as an OCSP fail. And CAs and clients
entering into such arrangements should be aware of this truth.
Gerv
Paul Tiemann
> On 04/10/10 14:23, Eddy Nigg wrote:
>> There is a big IF - IF the web server sends a valid OCSP response, but
>> if not? How does an AIA extension prevent OCSP stapling? Can the CA
>> enforce and guaranty that every web server sends a correct, always valid
>> OCSP response? How should the browser find the OCSP responder if it
>> doesn't?
>
> It shouldn't; it should treat it as an OCSP fail. And CAs and clients entering into such arrangements should be aware of this truth.
>
Well, if the EE cert doesn't have an OCSP URL listed, and it gets no stapled response, then it would head for the CRL right?
But if the server gave a not-good-enough OCSP stapled response, and the AIA didn't have the OCSP URL, shouldn't Mozilla just head for the CRL in that case as well (NOT giving EV treatment, but at the same time NOT giving up on the connection?)
Paul Tiemann
CTO DigiCert
Kathleen Wilson
> At this point, I would link here:
> http://www.mozilla.org/about/forums/#dev-security-policy
> and just call it the "Mozilla dev.security.policy forum".
Changed in my draft copy.
>> 2) As per the CA/Browser Forum’s Guidelines for EV Certs, we are
>> planning to update Mozilla products such that EV treatment will not be
>> given for end-entity certs that are issued after December 31, 2010 if
>> they do not have an OCSP URI in the AIA.
>
> I personally am still uncertain that this is the right thing (with the
> suggested alternative being to require OCSP validation, but allowing
> stapling as well, so the OCSP URI would not necessarily need to be in
> the AIA, if the CA contracted only with clients whose servers supported
> stapling). Can we resolve that question before sending this email?
Understood. This is the primary thing holding up the communication. It
may take a few weeks before this is resolved. I'm wondering if I can
still send the communication if I change the wording to "we are
considering..."
e.g:
2) As per the CA/Browser Forum’s Guidelines for EV Certs, we are
considering updating Mozilla products such that EV treatment will not be
given for end-entity certs that are issued after December 31, 2010 if
they do not have an OCSP URI in the AIA. This proposed change is being
tracked here:
https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23
Additionally, we urge all CAs to provide OCSP for all certs, even when
they are not EV.
>> 4) As per the NIST guidelines, it is our expectation that all CAs are
>> transitioning from issuing certs with RSA key sizes smaller than 2048
>> bits. For more information, please see
>> https://wiki.mozilla.org/CA:MD5and1024.
>
> Should we mention a deadline?
Changed to:
5) We are planning to implement a code change to stop accepting MD5 as a
hash algorithm for intermediate and end-entity certs. After June 30,
2011, software published by Mozilla will return an error when a
certificate with an MD5-based signature is used. Mozilla will take this
action earlier and at its sole discretion if necessary to keep our users
safe. For more information, please see
https://wiki.mozilla.org/CA:MD5and1024.
Thanks,
Kathleen
Kathleen Wilson
> On 02.10.2010 21:43, David E. Ross wrote:
>> I generally agree. However, I would like to know if a CA feels that
>> something in the policies cannot be implemented for technical reasons.
>> I have no concern if a CA feels something cannot be implemented for
>> financial, operational, or business reasons.
>
> We have at least 2 CAs here, plus NSS guys. That should be enough
> technical knowledge.
>
> In other words, if these CAs can do it, the other CAs can as well
> (otherwise that's just "operational and business reasons" as you said).
The Mozilla project is a public project in which anyone may participate.
We therefore include in our process a period for public comment during
which interested parties may review the information, ask additional
questions, and provide their opinions. This is done for policy updates
as well as root inclusion/change requests.
In my opinion, the more CAs are aware of the discussions in
m.d.s.policy, the better. And I encourage their participation in all
m.d.s.policy discussions.
Kathleen
Kathleen Wilson
That is one of the situations that other CAs have mentioned in regards
to their difficulties transitioning off of 1024-bit certs.
I've added some more information to the December 31, 2010 date in
https://wiki.mozilla.org/CA:MD5and1024
--
# December 31, 2010 – CAs should stop issuing intermediate and
end-entity certificates from roots with RSA key sizes smaller than 2048
bits. All CAs should stop issuing intermediate and end-entity
certificates with RSA key size smaller than 2048 bits under any root.
* DRAFT Recommendation for the Transitioning of Cryptographic
Algorithms and Key Sizes: Key lengths providing 80 bits of security
using approved digital signature algorithms are allowed for legacy use
after 2010.
o This means that the CA must assess the risk involved in
issuing such a certificate for legacy use/interoperability, and
determine if the risk is acceptable.
* If a CA has particular need to continue issuing certificates with
RSA key size smaller than 2048 bits beyond this date, then they must
ensure that all of those certificates will expire by the end of 2013.
* CAs who continue to issue certificates with RSA key size smaller
than 2048 bits must use randomness in the serial number or in one of the
fields in the DN.
--
Kathleen
Kyle Hamilton
>
> The Mozilla project is a public project in which anyone may participate. We
> therefore include in our process a period for public comment during which
> interested parties may review the information, ask additional questions, and
> provide their opinions. This is done for policy updates as well as root
> inclusion/change requests.
This is (imo) a good policy. People who have no asserted affiliation
can participate, thus any one of us could be affiliated with a CA and
not make it publicly known -- which means that people who work at a CA
and have made it publicly known that they do would suddenly be
disenfranchised if CAs were suddenly prohibited from making comments.
I'm sorry, but I think that Rob, Robin, Eddy, and the others who
represent CAs in this forum deserve a bit more dignity than that.
> In my opinion, the more CAs are aware of the discussions in m.d.s.policy,
> the better. And I encourage their participation in all m.d.s.policy
> discussions.
The more that CAs are aware of the discussions, the more capability
they have to protect their interests. Further, the more capacity they
have to not be blindsided by changes in requirements.
If they are given the opportunity to take part and don't choose to,
the onus is on them. If they want to take part and are prevented, the
onus is on Mozilla.
-Kyle H
Eddy Nigg
>
> That is one of the situations that other CAs have mentioned in regards
> to their difficulties transitioning off of 1024-bit certs.
>
> I've added some more information to the December 31, 2010 date in
> https://wiki.mozilla.org/CA:MD5and1024
> --
> # December 31, 2010 – CAs should stop issuing intermediate and
> end-entity certificates from roots with RSA key sizes smaller than
> 2048 bits. All CAs should stop issuing intermediate and end-entity
> certificates with RSA key size smaller than 2048 bits under any root.
>
> * DRAFT Recommendation for the Transitioning of Cryptographic
> Algorithms and Key Sizes: Key lengths providing 80 bits of security
> using approved digital signature algorithms are allowed for legacy use
> after 2010.
> o This means that the CA must assess the risk involved in
> issuing such a certificate for legacy use/interoperability, and
> determine if the risk is acceptable.
>
> * If a CA has particular need to continue issuing certificates
> with RSA key size smaller than 2048 bits beyond this date, then they
> must ensure that all of those certificates will expire by the end of
> 2013.
>
> * CAs who continue to issue certificates with RSA key size smaller
> than 2048 bits must use randomness in the serial number or in one of
> the fields in the DN.
>
Kathleen, if that's the language than I suggest to scrap this item
entirely, It has no teeth and is entirely useless as any CA will claim
any of the above exceptions. Either it's enforced or not, but exactly
that wishy-washy language is something we should omit entirely in my
opinion. The goal should be to provide clear guidelines and policy
requirements and then stick to it.
Eddy Nigg
>> * If a CA has particular need to continue issuing certificates
>> with RSA key size smaller than 2048 bits beyond this date, then they
>> must ensure that all of those certificates will expire by the end of
>> 2013.
>>
> entirely, It has no teeth and is entirely useless as any CA will claim
> any of the above exceptions. Either it's enforced or not, but exactly
> that wishy-washy language is something we should omit entirely in my
> opinion. The goal should be to provide clear guidelines and policy
> requirements and then stick to it.
>
Correction. In that case the requirement should be set to the end of
2013 instead of end of 2010. Simply as that.
Paul Tiemann
On Oct 4, 2010, at 3:28 PM, Eddy Nigg wrote:
> On 10/04/2010 11:20 PM, From Kathleen Wilson:
>>
>> That is one of the situations that other CAs have mentioned in regards to their difficulties transitioning off of 1024-bit certs.
>>
>> I've added some more information to the December 31, 2010 date in https://wiki.mozilla.org/CA:MD5and1024
>> --
>> # December 31, 2010 – CAs should stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits. All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root.
>>
>> * DRAFT Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes: Key lengths providing 80 bits of security using approved digital signature algorithms are allowed for legacy use after 2010.
>> o This means that the CA must assess the risk involved in issuing such a certificate for legacy use/interoperability, and determine if the risk is acceptable.
>>
>> * If a CA has particular need to continue issuing certificates with RSA key size smaller than 2048 bits beyond this date, then they must ensure that all of those certificates will expire by the end of 2013.
>>
>> * CAs who continue to issue certificates with RSA key size smaller than 2048 bits must use randomness in the serial number or in one of the fields in the DN.
>>
>
> Kathleen, if that's the language than I suggest to scrap this item entirely, It has no teeth and is entirely useless as any CA will claim any of the above exceptions. Either it's enforced or not, but exactly that wishy-washy language is something we should omit entirely in my opinion. The goal should be to provide clear guidelines and policy requirements and then stick to it.
It seems to me that _something_ is better than _nothing_. Does it always have to be all sticks and teeth and no carrots? What about a version of Nelson's "hall of shame" idea from before, except you call it the "hall of fame" and spin it positively (people won't want to sue you for libel) where CAs get ranked according to how well they're performing as a "good citizen" and the good citizens get put on the fast track when they have roots to embed or bits to enable. Or they just sit there looking good on a web page--that's not a bad reward either.
One admittedly self-aggrandizing case in point: I started issuing ALL of our certs with a SAN extension, even when there's just one name to put into the cert. We made the change because I listen in on this forum and others, and it seemed like it would help to improve the state of things. Within a few days we had one customer call us who couldn't get his cert to work on an older legacy server platform. I feared we'd start hearing a lot more of that, so I rolled back to not putting SANs in all the time. Then after a few days I decided there'd be no way to know whether it's a big problem or a small problem unless I went back to putting SANs in all certs. We haven't had an issue since, and now it's been months... Now, I know some CAs may have been putting the Subject Alternative Name extension in all the time, but there are others who aren't. Does trying to participate count for anything? Does making improvements count, even small ones? Sometimes trying to be a good CA citizen is a little like doing good deeds in the dark. :)
I'd be perfectly happy disallowing 1024 bit RSA keys up front, and allowing overrides on a case-by-case basis. Shouldn't that count for something if I am issuing 95%+ 2048 bit certs after 2010? A 2048 bit RSA certificate is roughly 7x more CPU intensive than a 1024 bit RSA key for SSL handshakes. Do we really need to force every static content site (content.bigcompany.com) serving images to run over 2048 bit? Are the static images that you can also get over http really that cryptographically sensitive? Do we need to sacrifice common sense at the altar of an ivory tower recommendation? NIST's guidelines themselves say you should use 2048 bits for SENSITIVE data. Can a CA and its client determine on their own what is sensitive, or do we want the SSL universe to be patrolled by automated tell-on-eachother scanner drones turning up 1024 bit keys here and there? I hope at least part of this imagery is humorous to someone besides me, but I gotta say, sometimes you never know in a security-oriented forum. ;)
Paul Tiemann
CTO, DigiCert
Eddy Nigg
> It seems to me that _something_ is better than _nothing_. Does it always have to be all sticks and teeth and no carrots? What about a version of Nelson's "hall of shame" idea from before, except you call it the "hall of fame" and spin it positively (people won't want to sue you for libel) where CAs get ranked according to how well they're performing as a "good citizen" and the good citizens get put on the fast track when they have roots to embed or bits to enable. Or they just sit there looking good on a web page--that's not a bad reward either.
That would be actually a nice idea and exists already in some form:
http://www.sslshopper.com/certificate-authority-reviews.html
I'm sure you are not surprised about the reviews and the ranks ;-)
> Then after a few days I decided there'd be no way to know whether it's a big problem or a small problem unless I went back to putting SANs in all certs. We haven't had an issue since, and now it's been months...
And if you'd loose one in a thousand customers, so long.... and it's
really (as you probably heard elsewhere) that sometimes 0.05% of users
(which use certain devices or operating systems) can prevent enforcing
certain requirements. But is it really worth it?
> Now, I know some CAs may have been putting the Subject Alternative Name extension in all the time, but there are others who aren't. Does trying to participate count for anything? Does making improvements count, even small ones? Sometimes trying to be a good CA citizen is a little like doing good deeds in the dark. :)
Right. But it sucks if your neighbor doesn't give a damn and pollutes
your environment. We are all breathing the same air in the end of the
day. Eventually it's always the CAs which are blamed and can't be
trusted etc. - not name-some-name.
> I'd be perfectly happy disallowing 1024 bit RSA keys up front, and allowing overrides on a case-by-case basis.
We are happily issuing minimum 2K keys for a year now. I can't report of
a sudden stop in growth. At the most they go elsewhere - and if all CAs
would be required to comply to this requirement than they'd nowhere else
to go. Just buy a new device.
(We get an inquiry about every three month about this requirement.
Certainly no high volume on our support line because of it)
> Shouldn't that count for something if I am issuing 95%+ 2048 bit certs after 2010? A 2048 bit RSA certificate is roughly 7x more CPU intensive than a 1024 bit RSA key for SSL handshakes.
You should read
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
> Do we really need to force every static content site (content.bigcompany.com) serving images to run over 2048 bit?
If one of those keys becomes compromised, what does it matter? If
browsers keep accepting them they'll accept that one too.
> Can a CA and its client determine on their own what is sensitive, or do we want the SSL universe to be patrolled by automated tell-on-eachother scanner drones turning up 1024 bit keys here and there?
How do you control for what a certificate will be eventually used. Now,
in one month, in one year?
> I hope at least part of this imagery is humorous to someone besides me, but I gotta say, sometimes you never know in a security-oriented forum.
Well, at least I always appreciate your input :-)
Eddy Nigg
>> Do we really need to force every static content site
>> (content.bigcompany.com) serving images to run over 2048 bit?
>
> If one of those keys becomes compromised, what does it matter? If
> browsers keep accepting them they'll accept that one too.
I should have added here, that bigcompany.com is the one that gets most
of the damage, not the old.device.com user for which you made the exception.
Besides, bigcompany.com should make up their mind if the want to have
better keys or faster images. Apparently you can't have both.
Gervase Markham
> Well, if the EE cert doesn't have an OCSP URL listed, and it gets no
> stapled response, then it would head for the CRL right?
>
> But if the server gave a not-good-enough OCSP stapled response, and
> the AIA didn't have the OCSP URL, shouldn't Mozilla just head for the
> CRL in that case as well (NOT giving EV treatment, but at the same
> time NOT giving up on the connection?)
Yes, indeed. That :-) Although it depends on the OCSP response; if it's
a FAIL, then obviously one doesn't check the CRL!
Gerv
Gervase Markham
> Understood. This is the primary thing holding up the communication. It
> may take a few weeks before this is resolved. I'm wondering if I can
> still send the communication if I change the wording to "we are
> considering..."
Sounds fine to me. :-) The other alternative is explicitly listing the
two proposed courses of action.
Gerv
Gervase Markham
I sympathise with your points :-) It would be good for us to find some
way of rewarding virtue, although doing so while maintaining the
appropriate level of neutrality is tricky.
On 04/10/10 23:59, Paul Tiemann wrote:
> I'd be perfectly happy disallowing 1024 bit RSA keys up front, and
> allowing overrides on a case-by-case basis. Shouldn't that count for
> something if I am issuing 95%+ 2048 bit certs after 2010? A 2048
> bit RSA certificate is roughly 7x more CPU intensive than a 1024 bit
> RSA key for SSL handshakes.
Well, that's OK, because computers will be 7x faster in 2013 ;-)
> Do we really need to force every static
> content site (content.bigcompany.com) serving images to run over 2048
> bit? Are the static images that you can also get over http really
> that cryptographically sensitive?
It would be nice if we didn't have to hit everything with the big
hammer... Is there significant computational speed gain by using a value
somewhere in the middle?
NIST only says 1024 is bad and 2048 is good. Are other intermediate key
lengths viable and widely supported?
Gerv
Eddy Nigg
> Yes, indeed. That :-) Although it depends on the OCSP response; if
> it's a FAIL, then obviously one doesn't check the CRL!
>
Just to clarify that FAIL would be the failure to obtain a valid
response from the OCSP responder. And then checking the CRL makes a lot
of sense.
REVOKED is not FAIL as I see it, it's a valid response.
Kyle Hamilton
> On 02.10.2010 21:43, David E. Ross wrote:
>>
>> I generally agree. However, I would like to know if a CA feels that
>> something in the policies cannot be implemented for technical reasons.
>> I have no concern if a CA feels something cannot be implemented for
>> financial, operational, or business reasons.
>
> We have at least 2 CAs here, plus NSS guys. That should be enough technical
> knowledge.
There are relatively few CA products in the world, that I'm aware of.
Instead of trying to ask the CAs themselves... why not try a dialog
with the CA software makers?
(Of course, it helps that some of the people on this group actually
did write a CA management system...)
> In other words, if these CAs can do it, the other CAs can as well (otherwise
> that's just "operational and business reasons" as you said).
"operational and business reasons" are valid concerns, if they involve
having to migrate to a different CA software platform. In this case,
"operational" might have to include "how to import previously-issued
certificates and certificate data into the new system", and "business"
is along the lines of "we don't make enough money on the CA operation
to justify that expense".
Of course, just because they're valid concerns doesn't mean that
they're particularly valid to us. (They're certainly valid to the
shareholders.)
-Kyle H
Kyle Hamilton
>> Do we really need to force every static
>> content site (content.bigcompany.com) serving images to run over 2048
>> bit? Are the static images that you can also get over http really
>> that cryptographically sensitive?
>
> Is there significant computational speed gain by using a value somewhere in
> the middle?
>
> NIST only says 1024 is bad and 2048 is good. Are other intermediate key
> lengths viable and widely supported?
The smart cards (ACS ACOS5) I'm currently working with support "512,
1024, or 2048 bits". I haven't been able to get them to do anything
with 1536.
The problem is not so much "is it cryptographically sensitive", it's
"is the point of origin worth more than 80 bits of entropy".
And my personal domains secure everything with 2048 bit, because
StartCom won't certify anything less.
-Kyle H
Paul Tiemann
> On 04/10/10 15:27, Paul Tiemann wrote:
>> Well, if the EE cert doesn't have an OCSP URL listed, and it gets no
>> stapled response, then it would head for the CRL right?
>>
>> But if the server gave a not-good-enough OCSP stapled response, and
>> the AIA didn't have the OCSP URL, shouldn't Mozilla just head for the
>> CRL in that case as well (NOT giving EV treatment, but at the same
>> time NOT giving up on the connection?)
>
> Yes, indeed. That :-) Although it depends on the OCSP response; if it's a FAIL, then obviously one doesn't check the CRL!
>
Ah, yes - certainly! If the OCSP stapled response says "This cert is revoked" then no point reaching for the CRL. Actually that makes me wonder if an SSL server should just refuse to accept connections on a channel whose certificate it knows to be revoked... I wonder if that case has been coded in Apache+mod_ssl stapling support.
Paul Tiemann
CTO, DigiCert
Ben Bucksch
> Instead of trying to ask the CAs themselves... why not try a dialog
> with the CA software makers?
Just like CAs, these software makers are able to join this group, too, FWIW.
>> In other words, if these CAs can do it, the other CAs can as well (otherwise
>> that's just "operational and business reasons" as [David Ross] said).
> "operational and business reasons" are valid concerns, if they involve
> having to migrate to a different CA software platform. In this case,
> "operational" might have to include "how to import previously-issued
> certificates and certificate data into the new system", and "business"
> is along the lines of "we don't make enough money on the CA operation
> to justify that expense".
I think both of these are fairly irrelevant. If we make a requirement,
then because we think it's essential to ensure the proper operation of
the SSL system and keep users secure (in the sense of fulfilling the SSL
promise).
If the CA's software can't do that, then it needs to change. (The
requirements we make will apply to all CAs, so if they use a standard
software, that will have to adapt anyway. If the CA uses custom
software, that's also their private problem.)
If the CA doesn't make enough money to ensure that, then it needs to
raise the prices. Nobody says that certs must cost only 10 bucks.
There's a price race to the bottom (which is good), but it's *us* who
need to ensure that the quality doesn't suffer from it.
If a CA has 7000 "RAs" that can create certs for any domain, or you can
get a valid cert by hijacking an *unsecured* connection to the mail
server, the whole system is fairly useless in my book.
Quality *has* suffered from that race to that point where the whole SSL
system is in danger. The alternative to that is dropping the old CA
certs entirely and only using EV validation in the client UI - something
we have considered.
Ben
Robin Alden
I still quibble with (at least) the lead in to point #2..
"2) As per the CA/Browser Forum’s Guidelines for EV Certs, ....
not ... if they do not have an OCSP URI in the AIA"
The requirement for an OCSP URI in the AIA is not as per the CA/Browser Forum’s Guidelines.
My rant on this is already recorded at https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c26
---
from https://wiki.mozilla.org/CA:CertPolicyUpdates..
> https://wiki.mozilla.org/CA:Recommended_Practices#Revocation_of_Compromised_Certificates
You require revocation on key compromise. I doubt anyone will argue with that, but this requires a definition of "compromise" for it to be useful.
The example you give (of the private key being published) is clear cut and unequivocal, but what about Debian weak keys, were they compromised? Some CAs said "yes", some said "no".
If a 2048 bit key is weakened by (effectively) 2 bits is it compromised?
If a 2048 bit key is weakened by (effectively) 2000 bits is it compromised?
Where do you draw the line?
You might say it is compromised if it becomes computationally feasible to determine the key, but one woman's feasible might be another man's infeasible.
---
from https://wiki.mozilla.org/CA:CertPolicyUpdates..
> Audit Renewals
> Update Mozilla CA certificate policy to require regular (eg annual) audit. (Bug #528303)
https://wiki.mozilla.org/CA:Problematic_Practices#Max_Time_Between_Audits
I think your requirement is reasonable, but (as far as I understand) ETSI does not require a published audit statement each year.
They issue a Certificate of Registration every three years. (e.g. https://bug361957.bugzilla.mozilla.org/attachment.cgi?id=401406) and failing a subsequent annual audit would cause the certification to be cancelled.
This doesn't stop you demanding an annual public statement from the ETSI auditors, of course, but you will need to specify exactly what you need it to say because it will be produced solely for your consumption.
I'm afraid we don't currently use the ETSI scheme so I have no expertise to offer in this field.
Keep up the good work!
Regards
Robin Alden
Comodo CA Limited.
> -----Original Message-----
> From: On Behalf Of Kathleen Wilson
> Sent: 04 October 2010 19:06
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: DRAFT Communication to CAs
>
<snip>
> >> 2) As per the CA/Browser Forum’s Guidelines for EV Certs, we
> are
> >> planning to update Mozilla products such that EV treatment will
> not
> >> be given for end-entity certs that are issued after December 31,
> 2010
> >> if they do not have an OCSP URI in the AIA.
> >
> > I personally am still uncertain that this is the right thing (with the
> > suggested alternative being to require OCSP validation, but
> allowing
> > stapling as well, so the OCSP URI would not necessarily need to
> be in
> > the AIA, if the CA contracted only with clients whose servers
> > supported stapling). Can we resolve that question before
> sending this email?
>
> Understood. This is the primary thing holding up the
> communication. It may take a few weeks before this is resolved.
> I'm wondering if I can still send the communication if I change the
> wording to "we are considering..."
>
> e.g:
> 2) As per the CA/Browser Forum’s Guidelines for EV Certs, we are
> considering updating Mozilla products such that EV treatment will
> not be given for end-entity certs that are issued after December
> 31, 2010 if they do not have an OCSP URI in the AIA. This proposed
> change is being tracked here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23
> Additionally, we urge all CAs to provide OCSP for all certs, even
> when they are not EV.
>
<snip>
> Thanks,
> Kathleen
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Ben Bucksch
> The Mozilla project is a public project in which anyone may participate.
> We therefore include in our process a period for public comment during
> which interested parties may review the information, ask additional
> questions, and provide their opinions.
Yes. I didn't question that at all. And we have 2 CAs already
participating, and I value them a lot.
I just don't want this discussion to be invaded by lawyers (apparently
the CABForum is full of them, judging from the documents they produce -
they even confuse Internet and Web) and managers/spokespersons who just
yell "too expensive" and "that's not how we do things around here",
interested only in their position, instead of an interest for end users.
End users don't even *appear* in their latest CABForum proposal for
minimal CA standards - no consideration for them *at all*. Browsers
appear only as "relying parties". That shows their strong interest in
end users.
That's why I questioned the purpose of explicitly asking CAs to comment.
I think it's unnecessary (we already have CA knowledge here) and biased.
Gary Gapinski
> Yes, indeed. That :-) Although it depends on the OCSP response; if it's
> a FAIL, then obviously one doesn't check the CRL!
http://tools.ietf.org/html/rfc2560#section-4.2.1 does not admit
(specific) FAIL, though deferred success is possible. OCSPResponseStatus
can assume the values «successful», «malformedRequest», «internalError»,
«tryLater», «sigRequired», and «unauthorized».
The normal (i.e., OCSPResponseStatus=successful) responses are «good»,
«revoked», and «unknown».
Not all of these should induce or preclude CRL use. successful+good,
successful+revoked are sufficient, but other combinations such as
tryLater would (IMO) necessitate CRL use.
Gary Gapinski
> a FAIL, then obviously one doesn't check the CRL!
http://tools.ietf.org/html/rfc2560#section-4.2.1 does not admit
Gary Gapinski
> a FAIL, then obviously one doesn't check the CRL!
http://tools.ietf.org/html/rfc2560#section-4.2.1 does not admit
Kathleen Wilson
> Kathleen,
> I still quibble with (at least) the lead in to point #2..
> "2) As per the CA/Browser Forum’s Guidelines for EV Certs, ....
> not ... if they do not have an OCSP URI in the AIA"
>
> The requirement for an OCSP URI in the AIA is not as per the CA/Browser Forum’s Guidelines.
>
> My rant on this is already recorded at https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c26
How about the following:
2) As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must
provide an OCSP capability for end-entity certificates that are issued
after Dec 31, 2010. Mozilla is considering technical ways to enforce
this OCSP requirement such that if Firefox cannot obtain a valid
response from the OCSP responder, then the certificate will not be given
EV treatment. We are considering requiring the end-entity certificate to
provide the OCSP URI in the AIA:
https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23
Additionally, we urge all CAs to provide OCSP for all certs, even when
they are not EV.
>
> ---
> from https://wiki.mozilla.org/CA:CertPolicyUpdates..
>> https://wiki.mozilla.org/CA:Recommended_Practices#Revocation_of_Compromised_Certificates
> You require revocation on key compromise. I doubt anyone will argue with that, but this requires a definition of "compromise" for it to be useful.
> The example you give (of the private key being published) is clear cut and unequivocal, but what about Debian weak keys, were they compromised? Some CAs said "yes", some said "no".
> If a 2048 bit key is weakened by (effectively) 2 bits is it compromised?
> If a 2048 bit key is weakened by (effectively) 2000 bits is it compromised?
> Where do you draw the line?
> You might say it is compromised if it becomes computationally feasible to determine the key, but one woman's feasible might be another man's infeasible.
>
Added as sub-bullet to the "Compromised Certificates" item in First Phase.
> ---
> from https://wiki.mozilla.org/CA:CertPolicyUpdates..
>> Audit Renewals
>> Update Mozilla CA certificate policy to require regular (eg annual) audit. (Bug #528303)
> https://wiki.mozilla.org/CA:Problematic_Practices#Max_Time_Between_Audits
> I think your requirement is reasonable, but (as far as I understand) ETSI does not require a published audit statement each year.
> They issue a Certificate of Registration every three years. (e.g. https://bug361957.bugzilla.mozilla.org/attachment.cgi?id=401406) and failing a subsequent annual audit would cause the certification to be cancelled.
> This doesn't stop you demanding an annual public statement from the ETSI auditors, of course, but you will need to specify exactly what you need it to say because it will be produced solely for your consumption.
> I'm afraid we don't currently use the ETSI scheme so I have no expertise to offer in this field.
>
Yes, that is what I've seen too. I've updated the "Audit Renewals" item
in First Phase to reflect this.
Thanks,
Kathleen
Kathleen Wilson
>>> Do we really need to force every static
>>> content site (content.bigcompany.com) serving images to run over 2048
>>> bit? Are the static images that you can also get over http really
>>> that cryptographically sensitive?
>>
>> It would be nice if we didn't have to hit everything with the big hammer...
>> Is there significant computational speed gain by using a value somewhere in
>> the middle?
>>
>> NIST only says 1024 is bad and 2048 is good.
I updated the wiki page again.
https://wiki.mozilla.org/CA:MD5and1024
--
# December 31, 2010 – CAs should stop issuing intermediate and
end-entity certificates from roots with RSA key sizes smaller than 2048
bits. All CAs should stop issuing intermediate and end-entity
certificates with RSA key size smaller than 2048 bits under any root.
* DRAFT Recommendation for the Transitioning of Cryptographic
Algorithms and Key Sizes: Key lengths providing 80 bits of security
using approved digital signature algorithms are allowed for legacy use
after 2010.
o This means that the CA must assess the risk involved in
issuing such a certificate for legacy use/interoperability, and
determine if they are willing to accept the risk, as well as any
possible liability. The subject and relying parties also need to
determine if they will accept any risks and liabilities.
* Under no circumstances should any party expect continued support
for RSA key size smaller than 2048 bits past December 31, 2013. This
date could get moved up substantially if necessary to keep our users
safe. We recommend all parties involved in secure transactions on the
web move away from 1024-bit moduli as soon as possible.
o All certificates with RSA key size smaller than 2048 bits
must expire by the end of 2013.
* CAs who continue to issue certificates with RSA key size smaller
than 2048 bits must use randomness in the serial number or in one of the
fields in the DN.
--
Eddy, the changes don't address your concern, but I still think it's
worthwhile to have this intermediate date and guidance documented and
communicated. If we have just one deadline of 2013 nothing will happen.
Kathleen
Eddy Nigg
>
> Eddy, the changes don't address your concern, but I still think it's
> worthwhile to have this intermediate date and guidance documented and
> communicated. If we have just one deadline of 2013 nothing will happen.
Of course in this way there is a risk that certificates might stop
working at some point and who wants that. Still, the hard cut off is
apparently end of 2013 which is still more than two years from now. So
lets hope that those keys keep holding until then ;-)
(Which is entirely possible, just not guarantied)
David E. Ross
>
> It would be nice if we didn't have to hit everything with the big
> hammer... Is there significant computational speed gain by using a value
> somewhere in the middle?
>
> NIST only says 1024 is bad and 2048 is good. Are other intermediate key
> lengths viable and widely supported?
1024 in binary is 100 0000 0000. 2048 in binary is 1000 0000 0000, one
additional bit position. You can't have a half-bit position. Thus,
anything greater than 1024 and not greater than 2048 involves as much
memory and CPU usage as 2048.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross
Rob Stradling
Why "NOT giving EV treatment" ?
If a CRL is obtained, its signature is valid, and the site's EV Certificate
serial number is not listed on that CRL, then why shouldn't EV treatment be
given?
IIUC, Mozilla's objective here is to encourage CAs to support OCSP. That's
great. But I doubt that (m)any CAs can offer a cast iron guarantee that the
availability of their OCSP Responders will never drop below 100%. Why should
site owners and the browsing public be punished during this (small amount of)
OCSP Responder downtime if the CRL is available?
When a CA makes no effort to provide an "OCSP capability", I concede that it
is reasonable for Mozilla to NOT give EV treatment. But when a CA does make
an effort to provide an "OCSP capability" (i.e. AIA OCSP URL and/or Stapled
OCSP Response), then I think Firefox/NSS should fall back to CRL if necessary
and *should* give EV treatment (as long as the CRL is verified successfully
and the certificate is found to be unrevoked).
The EV Guidelines demand an "OCSP capability" post-2010, but set no timeline
for the deprecation of CRLs as a valid revocation checking mechanism for EV.
On Tuesday 05 October 2010 11:23:16 Gervase Markham wrote:
> On 04/10/10 15:27, Paul Tiemann wrote:
> > Well, if the EE cert doesn't have an OCSP URL listed, and it gets no
> > stapled response, then it would head for the CRL right?
> >
> > But if the server gave a not-good-enough OCSP stapled response, and
> > the AIA didn't have the OCSP URL, shouldn't Mozilla just head for the
> > CRL in that case as well (NOT giving EV treatment, but at the same
> > time NOT giving up on the connection?)
>
> Yes, indeed. That :-) Although it depends on the OCSP response; if it's
> a FAIL, then obviously one doesn't check the CRL!
>
> Gerv
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Eddy Nigg
> The EV Guidelines demand an "OCSP capability" post-2010, but set no timeline
> for the deprecation of CRLs as a valid revocation checking mechanism for EV.
Obviously Rob is right here. On OCSP failure, the next step should be to
traverse through all CRL distribution points.
EV treatment should not be given in case no valid certificate status can
be obtained at all (actually shouldn't it fail for all certificates)?
Today Firefox presents a nasty error when the OCSP fails, which is
probably not good thing to do when CRL DPs are also available.
Paul Tiemann
That's a great point, thanks for mentioning it! When Firefox has the capability to fallback to CRLs, it would be great to still give EV treatment based on succesful CRL checks if the OCSP check(s) fail to yield a usable result. Perhaps to get EV treatment, the cert would have to have the OCSP URI listed in the AIA extension, and Firefox has to attempt the OCSP responder (not just get a bad stapled response) and the attempt has to fail, then it can depend on the CRL. Should timeliness conditions be placed on the CRL, so it can't be > 48 hours into its validity window?
Some hopefully-not-too-dense pseudo code of how that looks in my mind:
if handshake contains stapled response:
if stapled response is usable: # not expired, correct signature, status=good or revoked
done, give EV treatment if status=good, stop sign if status=revoked
else:
if cert contains ocsp uri in aia:
check ocsp directly
if ocsp response obtained is usable:
done, give EV treatment if status=good, stop sign if status=revoked
else if ocsp attempt failed: # network timeouts, no route to host, connection refused, empty response returned, bad signature, expired
try the crl
if crl check succeeded:
done, give EV treatment if not listed in crl, stop sign otherwise.
else:
stop sign because no revocation check method succeeded
Paul Tiemann
CTO, DigiCert
On Oct 6, 2010, at 4:33 AM, Rob Stradling wrote:
> Paul, Gerv,
>
> Why "NOT giving EV treatment" ?
>
> If a CRL is obtained, its signature is valid, and the site's EV Certificate
> serial number is not listed on that CRL, then why shouldn't EV treatment be
> given?
>
> IIUC, Mozilla's objective here is to encourage CAs to support OCSP. That's
> great. But I doubt that (m)any CAs can offer a cast iron guarantee that the
> availability of their OCSP Responders will never drop below 100%. Why should
> site owners and the browsing public be punished during this (small amount of)
> OCSP Responder downtime if the CRL is available?
>
> When a CA makes no effort to provide an "OCSP capability", I concede that it
> is reasonable for Mozilla to NOT give EV treatment. But when a CA does make
> an effort to provide an "OCSP capability" (i.e. AIA OCSP URL and/or Stapled
> OCSP Response), then I think Firefox/NSS should fall back to CRL if necessary
> and *should* give EV treatment (as long as the CRL is verified successfully
> and the certificate is found to be unrevoked).
>
Paul Tiemann
On Oct 6, 2010, at 5:12 AM, Eddy Nigg wrote:
> Today Firefox presents a nasty error when the OCSP fails, which is probably not good thing to do when CRL DPs are also available.
+1
Not knowing all the history of it, I'm curious... When EV support was built in, were there other considerations that affected the decision to only give EV treatment after a successful OCSP check?
Paul Tiemann
CTO DigiCert
Ben Bucksch
> On 10/04/2010 11:20 PM, From Kathleen Wilson:
>> end-entity certificates from roots with RSA key sizes smaller than
>> 2048 bits. All CAs should stop issuing intermediate and end-entity
>> certificates with RSA key size smaller than 2048 bits under any root.
>>
>> * DRAFT Recommendation for the Transitioning of Cryptographic
>> Algorithms and Key Sizes: Key lengths providing 80 bits of security
>> using approved digital signature algorithms are allowed for legacy
>> use after 2010.
>> o This means that the CA must assess the risk involved in issuing
>> such a certificate for legacy use/interoperability, and determine if
How about "only the subscriber specifically asks for a cert with smaller
key size, and can justify it. The normal subscriber must get at least
2048bit certs."?
Ben Bucksch
I.e. solve 95% this year and the remaining 5% of sites in 2013.
Rob Stradling
> Hi Rob,
Hi Paul.
> That's a great point, thanks for mentioning it! When Firefox has the
> capability to fallback to CRLs, it would be great to still give EV
> treatment based on succesful CRL checks if the OCSP check(s) fail to yield
> a usable result.
I agree.
> Perhaps to get EV treatment, the cert would have to have the OCSP URI listed
> in the AIA extension, and Firefox has to attempt the OCSP responder (not
> just get a bad stapled response)
I think it depends on *why* the stapled response is "bad".
If the stapled response is invalid ASN.1 data, or has an invalid signature, or
does not match (serial number, issuer name/key hashes) the server certificate
sent in the TLS handshake, then there is no proof that the Response originated
at an Authorized Responder. Therefore, there is no proof that the CA made any
attempt to offer an "OCSP capability".
In such cases, and where there is no AIA OCSP URL in the certificate, I
concede that it would be OK to *not* give EV treatment even if a successful
CRL check is then performed (and the certificate is found to be unrevoked).
But if the stapled response is valid ASN.1 data, has a valid signature, does
match (serial number, issuer name/key hashes) the server certificate, but is
"bad" only because it has expired, then there is proof that the Response
originated at an Authorized Responder. Therefore, there is proof that the CA
made some attempt to offer an "OCSP capability".
In such cases, and where there is no AIA OCSP URL in the certificate, I think
that a successful CRL check (which shows the CRL to be unrevoked) should be
enough to get the EV treatment.
> and the attempt has to fail, then it can depend on the CRL. Should
> timeliness conditions be placed on the CRL, so it can't be > 48 hours into
> its validity window?
I don't think so. The EV Guidelines v1.2 say:
"11.1.1 Repository
The CA MUST maintain an online 24x7 Repository mechanism whereby relying-party
application software can automatically check online the current status of all
certificates.
(1) For EV Certificates or Subordinate CA Certificates issued to entities not
controlled by the entity that controls the Root CA:
(A) CRLs MUST be updated and reissued at least every seven days, and the
nextUpdate field value SHALL NOT be more than ten days after the current
update; or
(B) If the CA provides revocation information via an Online Certificate Status
Protocol (OCSP) service, it MUST update that service at least every four days.
OCSP responses from this service MUST have a maximum expiration time of ten
days."
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +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.
Peter Gutmann
>How about "only the subscriber specifically asks for a cert with smaller key
>size, and can justify it. The normal subscriber must get at least 2048bit
>certs."?
Has anyone actually asked any CAs outside the US how they feel about being
held hostage to some arbitrary NIST agenda? We currently have a multibillion
dollar cybercrime industry that's built around the failure of PKI UI, PKI
procedures, PKI implementation issues, PKI business practice, PKI... well, you
get the idea, and exactly zero percent of this is built around anyone
factoring a key of any size, 1024 bits, 512 bits, whatever. So the net
improvement in security of this measure is the same as the percentage of
occurrence of factoring attacks on keys in certs, zero. OTOH the order-of-
magnitude increase in work required in the move from 1K -> 2K keys should be
enough to actively discourage further uptake of SSL/TLS, which is now mostly
cheap enough that you may as well use it whether you really need it or not,
the "SSL everywhere" design.
So it's likely that the overall effect of forcing people to move to longer,
and therefore much slower to process, keys, will be a net decrease in
security, and certainly won't lead to any real increase. Apart from
compliance with the NIST silly-walk requirements (which doesn't affect anyone
outside the US), there is no benefit to moving to longer keys because it's not
defending against anything that anyone's attacking. Even in the US, whether
you want to engage in the silly-walk or not should be up to RPs and not
something that's forced on people at gunpoint by the choice of browser they
use.
So I'd argue that making the roots 2K bits is a good idea, intermediate CAs
perhaps 1.5K, and EEs whatever the EE and/or RP feel is appropriate. Forcing
everyone to 2K bit keys seems to lead to a net loss in overall security, and
certainly no actual gain since it's not addressing anything that the attackers
are targetting.
Peter.
Rob Stradling
https://bugzilla.mozilla.org/show_bug.cgi?id=321755#c5 triggered the
development effort to get CRLDP support added to NSS/PSM/Firefox. It could
not have happened before then. EV support was required before CRLDP support
was ready.
Today, ignoring stapling for the sake of simplicity, Firefox will give EV
treatment when:
1. AIA OCSP URL is present and the OCSP check succeeds.
2. AIA OCSP URL is absent, but CRLDP is present and the CRL check succeeds.
> Paul Tiemann
> CTO DigiCert
Rob Stradling
Owen Shepherd
The reason we do not get factoring attacks against 1024-bit keys is quite simple: It is infeasible with current equipment. However, we are reaching the point where malicious entities could put together sufficient computing equipment to break 1024-bit keys. Therefore, said keys are beginning to look insecure.
This is not a 'NIST silly-walk' - it is a genuine near future issue. It is a something that needs solving - or are you just proposing that we sit around and wait until somebody actually builds an RSA factoriser?
The approach "2048-bit by default; 1024-bit by special request until 2013 or vulnerabilities" seems appropriate. It gives the ability to be confident in the security of our security infrastructure.
Now, what is this "order of magnitude increase in work"? 2048 bit keys take, according to Google (who have SSL deployed - by default - across much of their infrastructure) 7 times as much computing power as 1024-bit keys. This is not an insignificant increase, granted - but it is when you consider the percentage of CPU time that servers send doing RSA calculations (Not much, and only at connection setup), it is acceptable.
Finally, lets not forget that two non-US CAs have been active in this discussion: StartCom and Comodo. Neither have raised any major exceptions to the general policy being to issue 2048-bit keys.
- Owen
Medin, Steven
be somehow deficient to OCSP? Many of you who date back to the early
discussions in the CAB Forum will recall the exchange at San Antonio on the
subject of OCSP hub and spoke versus CRL DP dynamic distribution via network
access provider caching.
We discussed that OCSP is essentially an end run on every hit, there is very
little value in caching a response. I contrasted this to CRL DP where one
hosted object can speak for the corpus of an issuer rather than a single
certificate. I explained the proxy cache architecture of the major US
broadband provider market, and this was before I worked for an organization
with xx million residential access customers and xx million commercial
access customers.
Comcast, Road Runner, Verizon, BT, DT, FT, Belgacom, Saritel will own
bandwidth and infrastructure to handle the natural load of offering Mbit
broadband service, and they'll operate dynamic caching servers to minimize
peering point pull outside their owned networks. An OCSP response for a
single site won't generate enough hit count to stay in an access frequency
based cache for very long.
On Cyber Friday, we can be confident that the CRL of any CA who has issued
to a major e-commerce property is resting in caches at the major access
providers serving the major consumer audiences. Spikes occur at nextUpdate
around e-commerce catalyzing events, followed by sharp decline in hits over
time that appears to be too fast to be consistent with the impact that an
end run to each consumer would cause.
We lose that valley with OCSP. We gain what?
Kind regards,
Steven Medin
Product Manager, Identity and Access Management
Verizon Cybertrust Security
-----Original Message-----
From:
dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.or
g
[mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mo
zilla.org] On Behalf Of Rob Stradling
Sent: Wednesday, October 06, 2010 11:19 AM
To: dev-secur...@lists.mozilla.org
Cc: Eddy Nigg; Paul Tiemann; mozilla-dev-s...@lists.mozilla.org
Subject: Re: DRAFT Communication to CAs
Medin, Steven
Kathleen Wilson
> Ben Bucksch<ben.buck...@beonex.com> writes:
>
>> How about "only the subscriber specifically asks for a cert with smaller key
>> size, and can justify it. The normal subscriber must get at least 2048bit
>> certs."?
I updated https://wiki.mozilla.org/CA:MD5and1024 as follows:
* DRAFT Recommendation for the Transitioning of Cryptographic Algorithms
and Key Sizes: Key lengths providing 80 bits of security using approved
digital signature algorithms are allowed for legacy use after 2010.
o This means that CAs should only consider issuing a 1024-bit
certificate if it is requested and justified by the subscriber for a
specific reason, such as interoperability with devices that do not yet
support certificates with larger key sizes.
o The CA must assess the risk involved in issuing such a
certificate for legacy use/interoperability, and determine if they are
willing to accept the risk, as well as any possible liability. The
subject and relying parties also need to determine if they will accept
any risks and liabilities.
> Has anyone actually asked any CAs outside the US how they feel about being
> held hostage to some arbitrary NIST agenda?
Well, I haven't asked CAs that particular question, but I have exchanged
email with the CAs who have 1024-bit root certs included in NSS. The
common concerns have to do with interoperability with devices that still
only support 1024-bit certs. In regards to outside the US, in the APAC
mobile market it appears that transitioning off of 1024-bit certs is
problematic. However, the affected CA's are targeting the 2013 date.
Kathleen
aero...@gmail.com
On Mon, Oct 4, 2010 at 6:23 AM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 10/04/2010 12:11 PM, From Gervase Markham:
>> My understanding is that stapling means that the OCSP response gets sent
>> by the webserver as part of the handshake, and so can be checked as valid in
>> the normal way without the browser needing an AIA URL.
>
> There is a big IF - IF the web server sends a valid OCSP response, but if
> not? How does an AIA extension prevent OCSP stapling? Can the CA enforce and
> guaranty that every web server sends a correct, always valid OCSP response?
> How should the browser find the OCSP responder if it doesn't?
I believe Gerv was thinking about ways to remove the AIA URL from the certificate, if status revocation information was always provided alongside.
(sorry for the stapled OCSP primer, trying to get more people on board with the discussion)
If the server provides a stapled OCSP response, then the following are propositions that must be proven:
1) The stapled OCSP response must be within its "freshness period" -- that is, the period of time defined on the RP to be the maximum for its acceptance of freshness data must not have elapsed since the response was generated. (In the case of EV, this is a policy that they must accept from the CA/B Forum.)
2) The OCSP response must be valid for the certificate in question.
3) The OCSP response must come from a responder authorized (per the RP's policy) to provide certificate freshness information for the certificate, either by being designated by the issuer OR by being locally configured.
4) The RP must, notwithstanding all other evidence, have a policy which permits the acceptance of the stapled response.
If and only if those are proven can the RP (the 'verifier') not have to get a new OCSP response.
It turns out that the RP has a good reason for wanting the assertor to provide this kind of stapled response (and, vice-versa, the assertor can have a good reason for the RP to accept it if he provides it). Only in this way can the fact and time of the RP communicating in some way and in some manner with the assertor can be concealed from the OCSP responder(s) configured. If either is unwilling to implement the policy required for this to work, it doesn't.
(This could be vital for high-level communications between companies, to avoid stampeding the stock market, for example.)
It sounds like a lot of work to reduce traffic analysis capability, but we're seeing right now (on the US federal stage) how important the paranoia (and how prescient the fear) that led to its development has turned out to be.
The disclosure of either the fact of communication preparation or the fact of communication is made to either a local entity which can easily be tasked with keeping track of who the employees are talking with, or to the original PKI issuer. This is a not-insignificant threat. Knowing who and when someone verified a certificate's status can be implicating, and it's too easy to use these minimal facts to establish guilt on a false charge. Or on a true one.
Now, having said that, and with the knowledge that this is not the best place to bring this up:
I think that AIA in the EE cert is a bad idea unless supplemented by an Issuer Information Access in the issuing cert to cross-reference the normal place where revocation information could be found.
A certificate is simply a piece of evidence, and we must accept the evidence for what it is. However, that requires us to evaluate what it is before we can accept it for what it is. If it has the same MD5 hash as something legitimate, but has wildly strange fields, it's impossible to detect it as a forgery at this point -- and the same type of attack is going to be found in the future against our other hash algorithms and systems.
The cryptography is not infallible, and we cannot allow ourselves to be lax on ways to beef up its security. The concept of adding randomness to the certificate to thwart preimage attacks addresses the particular hash preimaging attack discovered, but ongoing defense of the certificate structure is an important enough topic to break it out into its own ongoing discussion.
-Kyle H
Peter Gutmann
>This is not a 'NIST silly-walk' - it is a genuine near future issue. It is a
>something that needs solving - or are you just proposing that we sit around
>and wait until somebody actually builds an RSA factoriser?
How many actual (not academic proof-of-concept, but actual) factoring attacks
on keys in certificates have been documented, even weak 512-bit keys? Nobody
is bothering to attack these because there are dozens (hundreds?) of easier
attack vectors, many of them with close to zero cost, that make it unnecesary.
So this is a silly-walk because it's a non-fix to a non-problem, while very
serious, and very real, problems remain unfixed.
>The approach "2048-bit by default; 1024-bit by special request until 2013 or
>vulnerabilities" seems appropriate. It gives the ability to be confident in
>the security of our security infrastructure.
Right, because PKI is doing such a great job at the moment of keeping us safe
from phishing and the like that we can be completely confident in it. The
key-size issue is a complete non-problem, what needs to be fixed is all the
other attack vectors in PKI that are being actively exploited, not something
that no attacker has ever exploited, even with weak 512-bit keys.
>Now, what is this "order of magnitude increase in work"? 2048 bit keys take,
>according to Google (who have SSL deployed - by default - across much of their
>infrastructure) 7 times as much computing power as 1024-bit keys.
There are other figures out there as well, some rather higher than that, "an
order of magnitude" seemed like a good generalisation. Again, you're missing
the point, at the moment with 1024-bit keys it's getting close to being
possible to apply the "SSL everywhere" approach because the cost is just about
low enough. With an order-of-magnitude performance hit, you can't do that any
more.
Even more serious is the issue with embedded devices. I get the feeling from
the discussion here that no-one's even considered these, there are probably
more embedded devices acting as SSL servers out there than there are
conventional SSL servers, that can't be easily upgraded, and for which many
don't have the horsepower to deal with larger keys even if they could be
upgraded. What will Firefox do when it's used to administer one of these?
There's already considerable anguish over the problems with handling certs
with duplicate serial numbers in things like ILOM systems (for which
admittedly there's technical justification, although FF does handle the
situation particularly badly compared to, say, IE or Opera), and now you're
going to tell users that they can't admin their embedded devices at all?
>Finally, lets not forget that two non-US CAs have been active in this
>discussion: StartCom and Comodo.
They may be physically outside the US, but I'd rate them as logically US CAs.
What I meant were things like Deutsche Telekom, SwissSign, Turktrust, Unizeto,
Chungwa, Diginotar, Haloz... the unpronounceable Hungarian one, ones subject
to their own national laws and considerations who presumably won't give a toss
about NIST's particular agenda, but are being forced to follow it by the
proposed change.
Note that I'm not saying "don't encourage people to move to 2K keys", I'm
saying that the decision should be up to users as to what they consider
appropriate. Let the user or RP decide whether they want to accept keys < 2K
bits, don't force the decision on them at gunpoint, which is what the current
proposal seems to be doing.
Peter.
Ben Bucksch
> what needs to be fixed is all the other attack vectors in PKI that
> are being actively exploited
I agree. And I think this discussion of higher minimal standards for CAs
(not the key length, but all the other changes) is part of the road to
that goal.
> at the moment with 1024-bit keys it's getting close to being possible
> to apply the "SSL everywhere" approach because the cost is just about
> low enough.
Do you have any data how long an SSL handshake takes, esp. when doing
over the Atlantic? With 1024bit and 2048bit RSA (and with plain HTTP)?
And how much of that time is the key generation?
And how much CPU time the whole handshake costs, and how much of that is
the RSA key calculation?
If you cannot supply that information, please don't claim "an order of
magnitude higher", because the RSA calculation may be fairly irrelevant
overall.
> Even more serious is the issue with embedded devices. I get the feeling from
> the discussion here that no-one's even considered these, there are probably
> more embedded devices acting as SSL servers out there than there are
> conventional SSL servers
That's true. Any bigger site using SSL is using appliances, they are
placed before the servers: client <-HTTPS over Internet-> SSL applicance
<-HTTP over local network-> Webserver .
E.g. Mozilla does it like that for addons.mozilla.org, many email
providers do it for IMAP, POP and SMTP over SSL.
> What will Firefox do when it's used to administer one of these?
It's not about administering them. These boxen do the real SSL heavy
load on the Internet.
> the decision should be up to users as to what they consider appropriate.
End users (browser users) have no idea what all this means.
As for certificate subscribers, that my exactly my suggestion (that you
originally responded to), to let them decide.
Ben
Rob Stradling
https://bugzilla.mozilla.org/show_bug.cgi?id=585122
On Thursday 07 October 2010 04:37:19 aero...@gmail.com wrote:
> On Mon, Oct 4, 2010 at 6:23 AM, Eddy Nigg <eddy...@startcom.org> wrote:
> > On 10/04/2010 12:11 PM, From Gervase Markham:
> >> My understanding is that stapling means that the OCSP response gets sent
> >> by the webserver as part of the handshake, and so can be checked as
> >> valid in the normal way without the browser needing an AIA URL.
> >
> > There is a big IF - IF the web server sends a valid OCSP response, but if
> > not? How does an AIA extension prevent OCSP stapling? Can the CA enforce
> > and guaranty that every web server sends a correct, always valid OCSP
> > response? How should the browser find the OCSP responder if it doesn't?
>
> I believe Gerv was thinking about ways to remove the AIA URL from the
> certificate, if status revocation information was always provided
> alongside.
>
> (sorry for the stapled OCSP primer, trying to get more people on board with
> the discussion)
>
> If the server provides a stapled OCSP response, then the following are
> propositions that must be proven:
>
> 1) The stapled OCSP response must be within its "freshness period" -- that
> is, the period of time defined on the RP to be the maximum for its
> acceptance of freshness data must not have elapsed since the response was
> generated. (In the case of EV, this is a policy that they must accept
> from the CA/B Forum.) 2) The OCSP response must be valid for the
Rob Stradling
Gervase Markham
> IIUC, Mozilla's objective here is to encourage CAs to support OCSP. That's
> great. But I doubt that (m)any CAs can offer a cast iron guarantee that the
> availability of their OCSP Responders will never drop below 100%. Why should
> site owners and the browsing public be punished during this (small amount of)
> OCSP Responder downtime if the CRL is available?
Another reasonable point. We don't want to create "single points of
failure" for the Internet or for EV.
> When a CA makes no effort to provide an "OCSP capability", I concede that it
> is reasonable for Mozilla to NOT give EV treatment. But when a CA does make
> an effort to provide an "OCSP capability" (i.e. AIA OCSP URL and/or Stapled
> OCSP Response), then I think Firefox/NSS should fall back to CRL if necessary
> and *should* give EV treatment (as long as the CRL is verified successfully
> and the certificate is found to be unrevoked).
Do you have a suggestion for how, in code, it is possible to distinguish
between CAs which make an effort to provide an OCSP capability, and
those who do not? Or is your suggestion that Firefox not attempt to
enforce this in code?
Gerv
Gervase Markham
> Not knowing all the history of it, I'm curious... When EV support
> was built in, were there other considerations that affected the
> decision to only give EV treatment after a successful OCSP check?
Other considerations which may have been in the minds of some people
might be:
- Wanting to encourage OCSP use
- Wanting to improve the state of the art in OCSP servers by
encouraging the vendors to expect business
- Wanting to improve performance (downloading CRLs is slow)
- Wanting to avoid patents on reading the CRLDP from a cert (possibly
no longer an issue)
- Wanting to improve timeliness (OCSP has the possibility of providing
much fresher revocation information than CRLs)
Gerv
Gervase Markham
> How many actual (not academic proof-of-concept, but actual) factoring attacks
> on keys in certificates have been documented, even weak 512-bit keys? Nobody
> is bothering to attack these because there are dozens (hundreds?) of easier
> attack vectors, many of them with close to zero cost, that make it unnecesary.
> So this is a silly-walk because it's a non-fix to a non-problem, while very
> serious, and very real, problems remain unfixed.
So your argument is that we shouldn't bother mandating longer key
lengths until they become the easiest thing to attack?
> Right, because PKI is doing such a great job at the moment of keeping us safe
> from phishing and the like that we can be completely confident in it.
If we ripped out PKI and replaced it with something utterly different,
it would make very little difference to phishing - because phishing is
(generally) a failure of the user to understand what his browser is
telling him (and therefore, often, a failure of the browser to explain
it adequately).
Whatever system you replaced it with, you'd still have the concept of
"am I where I think I am?", with the phisher hoping you'll mistakenly
answer Yes when you should answer No, and the browser trying to help you
to answer correctly every time.
Gerv
Gervase Markham
> We lose that valley with OCSP. We gain what?
One answer is: immediacy.
What sort of cache policy do you set on your CRLs? How often to these
major ISPs need to update their cached copy?
The aim is to reduce the value of a mis-issued cert for phishing to zero
as soon as possible. Phishing sites generally have a lifetime measured
in hours anyway.
Gerv
Steve Roylance
Do we know how many 'new' phishing sites actually bother to even use any
type of SSL certificate to add legitimacy to their attack? I would think
very few, as today it's not necessary at all. You can fool most of the
people most of the time without one.
So if the risk is hacking into a live, currently valid web site with a valid
SSL certificate, then it's game over with OCSP stapling, as the hacker
simply needs to stop the OCSP response from renewing and to keep sending out
the false (but still valid) stapled response during the attack window, which
as you say maybe only hours. In effect stapling OCSP responses would surely
be worse in this case? (Unless the stapling period is very small indeed...
;-) )
Bottom line (and if I'm correct) means there's no easy answer here.
Does anyone on the list have any stats about how SSL certificates are used
on phishing sites so the group can assess current and future risks and
trends?
Steve
-----Original Message-----
From:
dev-security-policy-bounces+steve.roylance=globals...@lists.mozilla.org
[mailto:dev-security-policy-bounces+steve.roylance=globals...@lists.mozi
lla.org] On Behalf Of Gervase Markham
Sent: 07 October 2010 11:04
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DRAFT Communication to CAs
On 06/10/10 17:51, Medin, Steven wrote:
> We lose that valley with OCSP. We gain what?
One answer is: immediacy.
What sort of cache policy do you set on your CRLs? How often to these
major ISPs need to update their cached copy?
The aim is to reduce the value of a mis-issued cert for phishing to zero
as soon as possible. Phishing sites generally have a lifetime measured
in hours anyway.
Gerv
Rob Stradling
<snip>
> Do you have a suggestion for how, in code, it is possible to distinguish
> between CAs which make an effort to provide an OCSP capability, and
> those who do not? Or is your suggestion that Firefox not attempt to
> enforce this in code?
Hi Gerv. I'd prefer to see Firefox not attempt to enforce this in code.
Consider this scenario:
A website wants an EV Certificate, but is concerned about their users'
privacy. Therefore, they will not accept an AIA OCSP URL in their EV
certificate. They would be happy to switch on OCSP Stapling, but their
webserver software does not (yet) support it.
The CA operates an OCSP Responder which is able to serve Authoritative
Responses for this EV Certificate.
Even if/when Firefox does gain support for OCSP Stapling, the only way it
would be able to check this EV Certificate's revocation status would be to use
the CRL.
Perhaps the "OCSP capability" requirement could be enforced during "Root
Inclusion Request" reviews and/or by periodic review of EV CAs already
included in NSS/PSM ?
Rob Stradling
> On Thursday 07 October 2010 10:49:22 Gervase Markham wrote:
> <snip>
>
> > Do you have a suggestion for how, in code, it is possible to distinguish
> > between CAs which make an effort to provide an OCSP capability, and
> > those who do not? Or is your suggestion that Firefox not attempt to
> > enforce this in code?
>
> Hi Gerv. I'd prefer to see Firefox not attempt to enforce this in code.
But having said that, I do agree with the (majority?) opinion that OCSP is
preferable to CRL in many (most?) cases. I think we should be doing whatever
we can to encourage the use of OCSP wherever possible, so...
> Consider this scenario:
> A website wants an EV Certificate, but is concerned about their users'
> privacy. Therefore, they will not accept an AIA OCSP URL in their EV
> certificate. They would be happy to switch on OCSP Stapling, but their
> webserver software does not (yet) support it.
> The CA operates an OCSP Responder which is able to serve Authoritative
> Responses for this EV Certificate.
> Even if/when Firefox does gain support for OCSP Stapling, the only way it
> would be able to check this EV Certificate's revocation status would be to
> use the CRL.
...perhaps it would be a fair trade-off to say that you can't have Privacy and
the EV Green Bar unless you use OCSP Stapling.
If anyone strongly believes that this would not be a fair trade-off, please
say so. Thanks.
<snip>
Peter Gutmann
>So your argument is that we shouldn't bother mandating longer key lengths
>until they become the easiest thing to attack?
Given all the evidence we have today about the relative strengths of different
PKI mechanisms, that will be decades, if not centuries, so playing the who-
blinks-first card for this one isn't the smartest move :-).
What we need is decisions based on cost/benefit analysis, not dogma. As I've
already pointed out earlier, forcing a move to 2K bit keys without any
consideration of the effects this has is at the very best a no-op, but more
likely a net loss in security.
I've since had someone forward a link to a blog post expressing this in a bit
more detail, and just for the record I wasn't aware of this writeup until it
was pointed out to me a few minutes ago:
Cryptographic Numerology - our number is up
http://financialcryptography.com/mt/archives/001286.html
Peter.
Ben Bucksch
> On 07/10/10 12:34, Peter Gutmann wrote:
>> http://financialcryptography.com/mt/archives/001286.html
>
> Re: the blog post, I don't see how "SSL Everywhere" is a) achievable
> or b) improves security.
FWIW, we're seeing that move with mail servers. And it's great.
Mail has been sending passwords in the client since decades. AUTH
CRAM-MD5 is little used. Being able to sniff my mail is not nice anyway.
At Thunderbird, we (dascher, me and others) are actively trying to get
SSL on all mail server connections. The ISPDB that you (Gerv) and me
started helps a lot with that. I am feeding users the SSL server config
whenever I can find them, irregardless of whether the ISP instructs its
users to use them or not - most ISPs indeed instruct the non-SSL config
on their help pages and hotline.
And in fact the majority of ISPs by now have a working SSL mail server,
even if they don't advertise it. They have the SSL servers up 1) for
those users who insist on it 2) because it is indeed achievable with SSL
proxy appliances standing in front of the actual servers. If it wasn't
for those appliances, I believe we wouldn't have even closely as many
SSL services. Talk to the mozilla.org infrastructure guys.
So, Peter has a point: Raising the cost of SSL can indeed do notable
security harm.
What has not been established is how high the cost is.
How much longer (in ms) does the SSL handshake take for end users, esp.
over the Atlantic? (Shouldn't be too hard to measure, with the right
tools.) How much more load does it generate on the servers or
appliances? How many would have to be replaced to support 2048bit? I
take the stance that replacing appliances *is* an option, if financially
feasible (e.g. compared to the cost of the main servers).
Ben
Michał Proszkiewicz
[....]
>
> They may be physically outside the US, but I'd rate them as logically US CAs.
> What I meant were things like Deutsche Telekom, SwissSign, Turktrust, Unizeto,
> Chungwa, Diginotar, Haloz... the unpronounceable Hungarian one, ones subject
> to their own national laws and considerations who presumably won't give a toss
> about NIST's particular agenda, but are being forced to follow it by the
> proposed change.
But NIST isn't the only one organistaion. Take a look at this:
http://www.etsi.org/deliver/etsi_ts/102100_102199/10217601/02.00.00_60/ts_10217601v020000p.pdf
There are other organistaion than NIST that make recommendation for that
sort of things.
> Let the user or RP decide whether they want to accept keys< 2K
> bits, don't force the decision on them at gunpoint, which is what the current
> proposal seems to be doing.
That's the worst thing that could be done. Most of the users have no
idea what they really need. At first we should educate them, than they
could make conscious choice. But at the moment we have to decide for them.
Michal
Eddy Nigg
> I think we should continue this discussion back at:
> https://bugzilla.mozilla.org/show_bug.cgi?id=585122
The convention is to keep such discussion at the mailing lists and not
in the bug. Those are usually for the actual action. Therefore I'm going
to reply on your comment here:
It seems that you propose when servers implement stapling of OCSP
responses, that AIA OCSP URI doesn't have to be in the certificate. I'm
not sure if this is correct, because I believe implementing servers will
fetch their OCSP responses from exactly that AIA URI as well.
Additionally if the response from the server should fail for some
reason, clients can still go to the original responder and fetch the
response from there. And clients that don't support stapling will got
there in first place.
The OCSP requirement in the EV guidelines seems to me kind of useless
without having an AIA OCSP URI in the certificate. It's about the same
as providing a CRL capability without stating the CRL distribution point
in the certificate.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Paul Tiemann
> What we need is decisions based on cost/benefit analysis, not dogma. As I've
> already pointed out earlier, forcing a move to 2K bit keys without any
> consideration of the effects this has is at the very best a no-op, but more
> likely a net loss in security.
Here's an angle I've been worried about ever since I tried putting 2048 bit certs on our main web servers and our CPU utilization went through the roof and I had to roll back:
If you raise the cost of doing an SSL handshake by 7x, then you make it 7x easier for a bad guy to generate enough fake SSL handshake traffic to overwhelm your CPU and achieve a denial of service on your SSL server just because you have a 2048 bit SSL certificate.
It's apparently an attack vector that has been probed by bad guys already:
http://news.cnet.com/8301-27080_3-10445337-245.html
It might not have taken down the huge sites, which most likely already run SSL accelerators, but it might not even require a botnet to generate enough traffic to overwhelm most CPU based SSL servers using 2048 bit RSA certs, and it would be extremely easy to do it for a 4096 or 8192 bit RSA server certificate. The server side that has to encrypt the pre-master secret using a big RSA operation, so the client just has to call in with hundreds of bogus SSL handshake attempts and then hang up the phone...)
I don't have an easy way to quantify it, but sites that do 50+ SSL handshakes per second are definitely going to feel that RSA pain in their CPU graphs when they bump from 1024 to 2048 bits. It shouldn't be hard for anyone skeptical of my claim here to reproduce it -- just compare an identical 'ab' or 'http_load' benchmark test against a server with a 1024 bit cert, then run the test again after installing a 2048 bit cert. I'd love to see how poorly a 4096 bit cert performs, if anyone actually goes ahead with a test...
Paul Tiemann
CTO, DigiCert
Rob Stradling
> On 10/07/2010 09:20 AM, From Rob Stradling:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=585122
>
> in the bug. Those are usually for the actual action. Therefore I'm going
> to reply on your comment here:
>
> It seems that you propose when servers implement stapling of OCSP
> responses, that AIA OCSP URI doesn't have to be in the certificate.
Yes.
> I'm not sure if this is correct, because I believe implementing servers will
> fetch their OCSP responses from exactly that AIA URI as well.
Not necessarily, Eddy. If you'd looked at the bug, you would hopefully have
seen https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c11 where I wrote:
"Some (mainly smaller) CAs might be reluctant to include AIA OCSP URLs at all,
for fear that their OCSP Responders' (modest) server hardware might not cope
with the (hard to predict) peak loads.
However, those same CAs might be happy to deploy OCSP Responders that are
intended to be used only by Servers that support OCSP "stapling", because the
peak loads would be easier to predict.
For certificate holders that use Apache: This could be achieved if the CA
omits the AIA OCSP URL from the end-entity certificate, and instructs the
certificate holder to use the "SSLStaplingForceURL" directive."
> Additionally if the response from the server should fail for some
> reason, clients can still go to the original responder and fetch the
> response from there. And clients that don't support stapling will got
> there in first place.
Alternatively, if the stapled response is "bad" and/or the client doesn't
support stapling, the client could check the CRL. The EV Guidelines do not
deprecate CRLs.
> The OCSP requirement in the EV guidelines seems to me kind of useless
> without having an AIA OCSP URI in the certificate. It's about the same
> as providing a CRL capability without stating the CRL distribution point
> in the certificate.
Not it isn't "about the same". You can staple OCSP Responses. You can't
staple CRLs.
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Rob Stradling
> On 10/07/2010 09:20 AM, From Rob Stradling:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=585122
>
Yes.
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
David E. Ross
> All,
>
> Here is a draft of a communication that I am writing to send to CAs with
> roots included in NSS. I would appreciate your feedback on it.
>
> Thanks,
> Kathleen
> --
> Title: Mozilla Communication to CAs regarding Policy updates
>
> Dear Certification Authority,
>
> On behalf of Mozilla, I am contacting you in regards to five important
> points that we would like to bring to your attention.
>
> 1) Mozilla has started a project to update the Mozilla CA Certificate
> Policy (http://www.mozilla.org/projects/security/certs/policy/). The
> proposed changes may impact the operation of your root certificates that
> are included in NSS. Therefore, we request that all CAs participate in
> the discussions, which will be held in the mozilla.dev.security.policy
> newsgroup and the corresponding dev-secur...@lists.mozilla.org
> mailing list. For information about the potential changes, please see
> https://wiki.mozilla.org/CA:CertPolicyUpdates.
>
> 2) As per the CA/Browser Forum’s Guidelines for EV Certs, we are
> planning to update Mozilla products such that EV treatment will not be
> given for end-entity certs that are issued after December 31, 2010 if
> they do not have an OCSP URI in the AIA. This change is being tracked
> here: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23
> Additionally, we urge all CAs to provide OCSP for all certs, even when
> they are not EV.
>
> 3) We expect that all new certificates contain randomness (preferably in
> the serial number), especially when using the SHA-1 hash function or an
> RSA key size smaller than 2048 bits. For more information, please see
> http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period
> and serial number prediction”, and section 7, “Countermeasures.”
>
> 4) As per the NIST guidelines, it is our expectation that all CAs are
> transitioning from issuing certs with RSA key sizes smaller than 2048
> bits. For more information, please see
> https://wiki.mozilla.org/CA:MD5and1024.
>
> 5) We are planning to implement a code change to stop accepting MD5 as a
> hash algorithm for intermediate and end-entity certs. For more
> information, please see https://wiki.mozilla.org/CA:MD5and1024.
>
> We look forward to your continued involvement and contributions to
> improving Mozilla’s CA Certificate Policy and practices.
>
This discussion has gone far from the question about sending a notice to
the certificate authorities. Much of it now involves how the policy
should be revised and what RFEs should be implemented.
Rather than highlight what policy changes or NSS enhancements are being
considered, I think the notice should merely indicate that changes are
being considered, where the Wiki is, and how the changes are being
discussed. If the CAs cannot find the details on their own -- given
links to the Wiki and the name of this newsgroup -- they really should
not be CAs.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross
Eddy Nigg
> A website wants an EV Certificate, but is concerned about their users'
> privacy. Therefore, they will not accept an AIA OCSP URL in their EV
> certificate.
This is kind of "we don't trust or own CA" which is kind of bad anyway.
Why not go with a CA they trust not to use this information? And CAs can
only know which certificate was requested from which host. That's not
that much really.
As such I wonder about your agenda since your own CA has a highly
efficient and strong OCSP responder(s). I'm just curious :-)
Eddy Nigg
> What we need is decisions based on cost/benefit analysis, not dogma. As I've
> already pointed out earlier, forcing a move to 2K bit keys without any
> consideration of the effects this has is at the very best a no-op, but more
> likely a net loss in security.
No matter what's decided here, please note that another significant
software vendor has already set the death of 1K keys:
http://technet.microsoft.com/en-us/library/cc751157.aspx
Quote:
CAs that are members of the Program are advised to begin their
transition to issuing 2048-bit end-certificates now, and to make the
transition to 2048-bit RSA certificate chains complete no later than the
NIST deadline, December 31, 2010. CAs should consider transitioning to
2048-bit certificates even earlier, as it would reduce the risk to their
operations and their customers in the event of a successful attack on
1024-bit RSA.
Eddy Nigg
> For certificate holders that use Apache: This could be achieved if the CA
> omits the AIA OCSP URL from the end-entity certificate, and instructs the
> certificate holder to use the "SSLStaplingForceURL" directive."
Well, yes, but I don't know how this can be set in policies and
compliance. Some will have stapling, some will not bother. Do you intend
to omit the AIA OCSP URI on some agreement with the subscriber? And how
should Mozilla handle it?
> Alternatively, if the stapled response is "bad" and/or the client doesn't
> support stapling, the client could check the CRL. The EV Guidelines do not
> deprecate CRLs.
Correct. My preference is indeed that CRLs should serve as a backup for
OCSP responders. And in the future this might be something like [OCSP
stapling response from server] on fail [OCSP responder from AIA OCSP
URI] on fail [CRL from CRLDP].
>> The OCSP requirement in the EV guidelines seems to me kind of useless
>> without having an AIA OCSP URI in the certificate. It's about the same
>> as providing a CRL capability without stating the CRL distribution point
>> in the certificate.
> Not it isn't "about the same". You can staple OCSP Responses. You can't
> staple CRLs.
Yes, but if stapling fails or isn't implement or not understood by the
client, it's useless.
Same as CRLs were pretty useless for Firefox for a long time.
Kathleen Wilson
> On 9/29/10 10:28 AM, Kathleen Wilson wrote:
>> All,
>>
>> Here is a draft of a communication that I am writing to send to CAs with
>> roots included in NSS. I would appreciate your feedback on it.
>>
>
> the certificate authorities. Much of it now involves how the policy
> should be revised and what RFEs should be implemented.
>
> Rather than highlight what policy changes or NSS enhancements are being
> considered, I think the notice should merely indicate that changes are
> being considered, where the Wiki is, and how the changes are being
> discussed. If the CAs cannot find the details on their own -- given
> links to the Wiki and the name of this newsgroup -- they really should
> not be CAs.
>
Here is the current draft of the communication, which I believe is ready.
--
Dear Certification Authority,
On behalf of Mozilla, I am contacting you in regards to five important
points that we would like to bring to your attention.
1) Mozilla has started a project to update the Mozilla CA Certificate
Policy (http://www.mozilla.org/projects/security/certs/policy/). The
proposed changes may impact the operation of your root certificates that
are included in NSS. Therefore, we request that all CAs participate in
the discussions, which will be held in the Mozilla.dev.security.policy
forum, http://www.mozilla.org/about/forums/#dev-security-policy. For
information about the potential changes, please see
https://wiki.mozilla.org/CA:CertPolicyUpdates.
2) As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must
provide an OCSP capability for end-entity certificates that are issued
after Dec 31, 2010. Mozilla is considering technical ways to enforce
this OCSP requirement such that if Firefox cannot obtain a valid
response from the OCSP responder, then the certificate will not be given
EV treatment. We are considering requiring the end-entity certificate to
provide the OCSP URI in the AIA:
https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23
Additionally, we urge all CAs to provide OCSP for all certs, even when
they are not EV.
3) We expect that all new certificates contain randomness (preferably in
the serial number), especially when using the SHA-1 hash function or an
RSA key size smaller than 2048 bits. For more information, please see
http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period
and serial number prediction”, and section 7, “Countermeasures.”
4) As per the NIST guidelines, it is our expectation that all CAs are
transitioning from issuing certs with RSA key sizes smaller than 2048
bits. For more information, please see
https://wiki.mozilla.org/CA:MD5and1024.
5) We are planning to implement a code change to stop accepting MD5 as a
hash algorithm for intermediate and end-entity certs. After June 30,
2011, software published by Mozilla will return an error when a
certificate with an MD5-based signature is used. Mozilla will take this
action earlier and at its sole discretion if necessary to keep our users
safe. For more information, please see
https://wiki.mozilla.org/CA:MD5and1024.
We look forward to your continued involvement and contributions to
improving Mozilla’s CA Certificate Policy and practices.
Regards,
Kathleen Wilson
--
Moudrick M. Dadashov
> On 10/07/2010 09:20 AM, From Rob Stradling:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=585122
>
> in the bug. Those are usually for the actual action. Therefore I'm
> going to reply on your comment here:
>
> It seems that you propose when servers implement stapling of OCSP
> responses, that AIA OCSP URI doesn't have to be in the certificate.
> servers will fetch their OCSP responses from exactly that AIA URI as
> well.
>
additional requirements (e.g. SLA etc.) that your "normal" OCSP server
for one or another reason can't satisfy. A substitute OCSP URI designed
to serve this customer is the only way you can make it work and AIA URI
in this case is simply ignored.
Thanks,
M.D.
cell: Žęų0-š99-čšššč
> Additionally if the response from the server should fail for some
> reason, clients can still go to the original responder and fetch the
> response from there. And clients that don't support stapling will got
> there in first place.
>
> The OCSP requirement in the EV guidelines seems to me kind of useless
> without having an AIA OCSP URI in the certificate. It's about the same
> as providing a CRL capability without stating the CRL distribution
> point in the certificate.
>
>
--
M.D.
Cell: +370-699-26662
Rob Stradling
> On 10/07/2010 04:41 PM, From Rob Stradling:
> > omits the AIA OCSP URL from the end-entity certificate, and instructs the
> > certificate holder to use the "SSLStaplingForceURL" directive."
>
> compliance. Some will have stapling, some will not bother. Do you intend
> to omit the AIA OCSP URI on some agreement with the subscriber?
Yes, it would only be by special request, and there would have to be a good
justification for actually doing it.
> And how should Mozilla handle it?
Perhaps by not giving EV treatment when there is both no AIA OCSP URL *and* no
valid Stapled Response.
Or perhaps by only policing the "OCSP capability" rule at Root Inclusion
Request time and/or by periodic review of each Included CA.
Or perhaps by not bothering to police the "OCSP capability" rule at all.
<snip>
> > Not it isn't "about the same". You can staple OCSP Responses. You can't
> > staple CRLs.
>
> Yes, but if stapling fails or isn't implement or not understood by the
> client, it's useless.
When Stapling is "useless", then fallback to AIA OCSP URL (if present). If
the AIA OCSP URL fails or is not present, then fallback to CRL.
But when Stapling is useful, everybody wins!
> Same as CRLs were pretty useless for Firefox for a long time.
Rob Stradling
Rob Stradling
> On 10/07/2010 12:47 PM, From Rob Stradling:
> > privacy. Therefore, they will not accept an AIA OCSP URL in their EV
> > certificate.
>
> Why not go with a CA they trust not to use this information? And CAs can
> only know which certificate was requested from which host. That's not
> that much really.
It's a big enough concern for enough users for it to get a mention in the
Wikipedia article on OCSP Stapling.
http://en.wikipedia.org/wiki/OCSP_Stapling says:
"OCSP checking also creates a privacy concern for some users, since it
requires the client to contact a third party (albeit a party trusted by the
client software) to confirm certificate validity. A way to verify validity
without disclosing browsing behaviour would be desirable for this group of
users.
OCSP Stapling...also means that the client software no longer needs to
disclose users' browsing habits to any third party."
> As such I wonder about your agenda since your own CA has a highly
> efficient and strong OCSP responder(s). I'm just curious :-)
Since you ask, my agenda is...
...(with my CABForum Member hat on)...to try to ensure that the EV Guidelines
are properly interpreted and implemented. This is my primary concern. If the
end result of this discussion is that Mozilla decide to press ahead with
requiring AIA OCSP URLs in end-entity EV certificates, but at the same time
the EV Guidelines are updated to explicitly support this decision, then I will
be happy enough.
...(with my Comodo CA Techie hat on)...to try to retain the Stapling-only,
Stapling/CRL-only and (perhaps) CRL-only options for EV. AIA OCSP URLs would
still be the default for all certs issued by Comodo, but it would be nice to
have these other options available as a last resort (for particularly privacy-
conscious or extremely busy sites). It's very possible that we might never
use these options, but nevertheless, it would be nice for them to be
available.
...(with my Comodo OCSP Responder Developer hat on)...to try to get as much
OCSP traffic as possible, so I can boast about how scalable my code is. ;-)
Obviously, I'm letting my other two hats override this last hat. ;-)
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Eddy Nigg
> When Stapling is "useless", then fallback to AIA OCSP URL (if present). If
> the AIA OCSP URL fails or is not present, then fallback to CRL.
>
> But when Stapling is useful, everybody wins!
I believe we have agreement here on both accounts from above. The
question is how to set the policy - specially in terms of generally
working OCSP responders (I believe this is the expectation). Hence I
believe there should be always a AIA OCSP URI, but who knows, maybe
something smarter than can shows up.
Eddy Nigg
> but who knows, maybe something smarter than can shows up.
>
Wicked English...smarter than that shows up. That happens when rewriting
a sentence in the middle of writing it...oh well.
Eddy Nigg
> It's a big enough concern for enough users for it to get a mention in the
> Wikipedia article on OCSP Stapling.
> http://en.wikipedia.org/wiki/OCSP_Stapling says:
Oh Wikipedia - I believe there is a [citation needed]. :-)
> "OCSP checking also creates a privacy concern for some users, since it
> requires the client to contact a third party (albeit a party trusted by the
> client software) to confirm certificate validity. A way to verify validity
> without disclosing browsing behaviour would be desirable for this group of
> users.
> OCSP Stapling...also means that the client software no longer needs to
> disclose users' browsing habits to any third party."
I wouldn't expect anything else from the Wiki Cowboys. My advice? Turn
OCSP checking off.
> It's very possible that we might never
> use these options, but nevertheless, it would be nice for them to be
> available.
For this possibility I believe it's not worth to compromise. Stapling
will work also with an AIA pointer.
> ....(with my Comodo OCSP Responder Developer hat on)...to try to get as much
> OCSP traffic as possible, so I can boast about how scalable my code is. ;-)
> Obviously, I'm letting my other two hats override this last hat. ;-)
Cheers to that....until the pipes break :-)
Peter Gutmann
>4) As per the NIST guidelines, it is our expectation that all CAs are
>transitioning from issuing certs with RSA key sizes smaller than 2048 bits.
>For more information, please see https://wiki.mozilla.org/CA:MD5and1024.
One comment on this page, it's currently very ambiguously worded, making it
quite confusing to tell whether it's talking about 2048 bit keys in CA or EE
certs, e.g. for:
CAs should stop issuing intermediate and end-entity certificates from roots
with RSA key sizes smaller than 2048 bits
the "2048 bits" could be interpreted to refer to the CA roots or the EE certs.
In a discussion on another list, several people pointed out that as far as
they could see the change applied to CA roots only, while others worked their
way through the later text and decided that it applied to EE certs. The text
should really be rewritten to make very explicit that EE certs are affected as
well, and in which cases EE certs and where CA certs are affected..
Peter.
Peter Gutmann
>Do you have any data how long an SSL handshake takes, esp. when doing over
>the Atlantic? With 1024bit and 2048bit RSA (and with plain HTTP)? And how
>much of that time is the key generation? And how much CPU time the whole
>handshake costs, and how much of that is the RSA key calculation?
>
>If you cannot supply that information, please don't claim "an order of
>magnitude higher", because the RSA calculation may be fairly irrelevant
>overall.
By selectively picking pathological worst cases you can always claim that the
overhead of the crypto is insignificant, but for more realistic SSL-everywhere
scenarios it's a major factor. For example for STARTTLS most clients are
within the same organisation or one DSLAM hop away and there's no HTTP
involved, just a TLS handshake and then a bulk download of data, and the
crypto is done in software with conventional servers, not any kind of fancy
load balancer. I don't have figures for that, but I do have ones for embedded
devices (which are usually on the same LAN or maybe a switch or two away, and
which serve basic static web pages with effectively zero overhead). In this
case the single biggest factor is the crypto overhead, everything else is
effectively free compared to that, see "Performance Characteristics of
Application-level Security Protocols",
http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf (which contains
summaries/single instances of much larger datasets). I've done a fair bit of
work with crypto in embedded devices and the choice of key size often boils
down to "the maximum we can get away with before it appears to the user that
the device has crashed", or as I've already mentioned, "the maximum we can
process in a single op before the system watchdog kills the process". In
extreme cases it's not even any of the above, it's "we'll use 512-bit keys and
document the fact that users will have to wait n seconds for the crypto op to
complete". Good luck with getting those folks to move to 2Kbit keys.
You're also confusing latency with throughput, if my server can handle (say)
1000 connections with a 1Kbit key and (say) 50 with a 2Kbit one then the
result of forcing a minimum of 2Kbit keys will be that the server admins turn
crypto off, not to buy another 20 servers just to make a crypto fashion
statement. You're forcing them to make a choice between "unusable performance
and compliance with a crypto fashion statement" or "usable performance but no
noticeable security", guess what option they'll take?
>> What will Firefox do when it's used to administer one of these?
>
>It's not about administering them. These boxen do the real SSL heavy load on
>the Internet.
And how do you administer a server using a 1K bit key when FF rejects keys <
2K bits?
>> the decision should be up to users as to what they consider appropriate.
>
>End users (browser users) have no idea what all this means.
And browser developers have even less of an idea. How can a browser developer
applying an arbitrary blanket requirement tell whether a SCADA device on a
private LAN using a 512-bit key is an effective security measure or not?
Peter.
aero...@gmail.com
On Thu, Oct 7, 2010 at 8:20 AM, Eddy Nigg <eddy...@startcom.org> wrote:
>
> This is kind of "we don't trust or own CA" which is kind of bad anyway. Why
> not go with a CA they trust not to use this information? And CAs can only
> know which certificate was requested from which host. That's not that much
> really.
"That's not that much really" is potentially, as I posted elsewhere in the group, a much bigger thing than you seem to think it can be. The easiest way to ensure that information is not misused, or used against you, is to ensure that you don't give it. That's the view of various hardware key storage modules, and they seem to be doing alright.
And with the US Federales trying to stick their noses into everything that uses strong encryption, I believe that it's very appropriate to be paranoid about anything that gives cause to be paranoid.
I don't doubt that Comodo is taking the same kind of cautious view that I am. Traffic analysis is only going to go up in value over time.
-Kyle H
Gervase Markham
> Consider this scenario:
> A website wants an EV Certificate, but is concerned about their users'
> privacy. Therefore, they will not accept an AIA OCSP URL in their EV
> certificate. They would be happy to switch on OCSP Stapling, but their
> webserver software does not (yet) support it.
> The CA operates an OCSP Responder which is able to serve Authoritative
> Responses for this EV Certificate.
> Even if/when Firefox does gain support for OCSP Stapling, the only way it
> would be able to check this EV Certificate's revocation status would be to use
> the CRL.
Or if we hard-coded the OCSP URL into Firefox. Which would then mean
that website's privacy concerns would not be met, because the OCSP
requests would be being sent anyway.
Gerv
Rob Stradling
> On 07/10/10 11:47, Rob Stradling wrote:
> > A website wants an EV Certificate, but is concerned about their users'
> > privacy. Therefore, they will not accept an AIA OCSP URL in their EV
> > certificate. They would be happy to switch on OCSP Stapling, but their
> > webserver software does not (yet) support it.
> > The CA operates an OCSP Responder which is able to serve Authoritative
> > Responses for this EV Certificate.
> > Even if/when Firefox does gain support for OCSP Stapling, the only way it
> > would be able to check this EV Certificate's revocation status would be
> > to use the CRL.
>
> that website's privacy concerns would not be met, because the OCSP
> requests would be being sent anyway.
And if the OCSP Responder is queried directly anyway, there is no advantage
(real or perceived) in omitting AIA OCSP URLs.
There are already some hard-coded OCSP URLs in Firefox, but these are slated
to be removed at some point:
https://bugzilla.mozilla.org/show_bug.cgi?id=531067
> Gerv
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Ben Bucksch
> By selectively picking pathological worst cases you can always
I didn't.
(If you mean the Atlantic: That's very common. I bet it's worse in
Australia or New Zealand where you come from.)
> see "Performance Characteristics of
> Application-level Security Protocols",
> http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf (which contains
> summaries/single instances of much larger datasets). I've done a fair bit of
> work with crypto in embedded devices and the choice of key size often boils
> down to "the maximum we can get away with before it appears to the user that
> the device has crashed"
Which "embedded devices" are you talking about? Home DSL / WiFi routers
and the like? Anything produced en masse and zero-setup?
I fail to see how to properly deploy SSL there anyway, because you can't
put a proper cert on it in the factory. a) the key needs to be secret,
so you can't put the same key on every device, b) you cannot sign
192.168.1.1 or "fritzbox.local" (this is an open debate).
If you use self-signed certs (again, different debate), you're not
subject to any of this discussion! This is about CA policies (see below).
> You're also confusing latency with throughput
I'm not confusing. I was asking from 2 perspectives: end users and
server admins. For end users, latency matters. For server admins,
throughput matters (and indirectly latency).
> if my server can handle (say) 1000 connections with a 1Kbit key and (say) 50 with a 2Kbit one then
That's precisely the question I asked you 2-3 times already. You keep
throwing numbers around, but what we need are *real* numbers for *real*
usage scenarios.
Otherwise please don't even *mention* performance as reason.
> And how do you administer a server using a 1K bit key when FF rejects keys<
> 2K bits?
First, we're talking about 2013. That's 3 more years to replace your key.
Second, where do you get this "Firefox rejects keys" from? We're talking
about rules / policies for CAs here, for creating certs and keys, not
about client changes. We may or may not enforce it in the client, but
that's a different debate.
> And browser developers have even less of an idea.
OK, fine.
Ben
Kathleen Wilson
The current wording is:
"December 31, 2010 – CAs should stop issuing intermediate and end-entity
certificates from roots with RSA key sizes smaller than 2048 bits. All
CAs should stop issuing intermediate and end-entity certificates with
RSA key size smaller than 2048 bits under any root."
The intent of the first sentence is for CA's to stop issuing from root
certs with smaller key sizes.
The intent of the second sentence is for CA's to stop issuing
intermediate and end-entity certs with smaller key sizes.
Both points need to be there.
Would it help if I re-ordered the sentences?
e.g.
"December 31, 2010 – All CAs should stop issuing intermediate and
end-entity certificates with RSA key size smaller than 2048 bits under
any root. CAs should stop issuing intermediate and end-entity
certificates from roots with RSA key sizes smaller than 2048 bits."
Thanks,
Kathleen
Ben Bucksch
> The intent of the first sentence is for CA's to stop issuing from root
> certs with smaller key sizes.
>
> The intent of the second sentence is for CA's to stop issuing
> intermediate and end-entity certs with smaller key sizes.
>
> Both points need to be there.
>
> Would it help if I re-ordered the sentences?
>
> e.g.
> "December 31, 2010 – All CAs should stop issuing intermediate and
> end-entity certificates with RSA key size smaller than 2048 bits under
> any root. CAs should stop issuing intermediate and end-entity
> certificates from roots with RSA key sizes smaller than 2048 bits."
Ah, now I understand, I didn't understand before. I was parsing the last
sentence as "stop ... end-entity certificates (from roots) with RSA <
2048", making the two sentences identical.
maybe replace "roots" with "root certs" and add: "I.e. neither root key
nor intermediate nor end-entity keys must have less than 2048bit RSA
keys" or similar.
Kathleen Wilson
I see. How about the following:
December 31, 2010 – All CAs should stop issuing intermediate and
end-entity certificates with RSA key size smaller than 2048 bits.
Additionally, CAs with root certificates that have RSA key size smaller
than 2048 bits should stop issuing intermediate and end-entity
certificates from those roots.
Kathleen
Ben Bucksch
> How about the following:
>
> December 31, 2010 – All CAs should stop issuing intermediate and
> end-entity certificates with RSA key size smaller than 2048 bits.
> Additionally, CAs with root certificates that have RSA key size
> smaller than 2048 bits should stop issuing intermediate and end-entity
> certificates from those roots.
Much better, thanks!
Ben
Kathleen Wilson
Peter Gutmann
>How about the following:
That seems to fix it, thanks.
Peter.
Peter Gutmann
>Second, where do you get this "Firefox rejects keys" from? We're talking
>about rules / policies for CAs here, for creating certs and keys, not about
>client changes. We may or may not enforce it in the client, but that's a
>different debate.
Well, the text (https://wiki.mozilla.org/CA:MD5and1024) says:
Under no circumstances should any party expect continued support for RSA key
size smaller than 2048 bits past December 31, 2013.
That's either a really long and remarkably coherent typo or it's saying that
Firefox (Mozilla/NSS/whatever, I'm using "FF" as a representative value for
"all products covered by the wiki article" here) won't support keys smaller
than 2048 bits past December 31, 2013.
Peter.
Eddy Nigg
> That's either a really long and remarkably coherent typo or it's saying that
> Firefox (Mozilla/NSS/whatever, I'm using "FF" as a representative value for
> "all products covered by the wiki article" here) won't support keys smaller
> than 2048 bits past December 31, 2013.
The same way you can't expect any RSA key bigger than 8K to work with
Firefox either :-)
Jean-Marc Desperrier
> you can't put a proper cert on it in the factory.
As implementer of a solution already used for several millions devices
in such conditions, I can't help chiming in here.
> a) the key needs to be
> secret, so you can't put the same key on every device,
That's perfectly solvable, the question is more about the security of
the key. But either the device will be able to keep it secure later on,
and then they are solutions, at a banking level of security if needed,
or it won't, and then the security will be lower but it will be coherent
with the security level of the key in the device after it's shipped.
> b) you cannot
> sign 192.168.1.1 or "fritzbox.local" (this is an open debate).
The industry standard is to sign the serial number and/or the mac
address, elements that the manufacturer is already liable for
guarantying unique (they are required for traceability).
Then either you have a local database that links that identifier to
something more usable, or the device certificate is just a bootstrap,
and you later use a second certificate, but using the security brought
in by the device certificate for it's issuance.
Ben Bucksch
> The industry standard is to sign the serial number and/or the mac address
But that doesn't help with an HTTPS-secured web frontend, does it?
Kathleen Wilson
Looks like it's time for me to actually send this communication.
Kathleen
Nelson Bolyard
> Let the user or RP decide whether they want to accept keys < 2K bits,
Would that be the same user who always "clicks through" every security
decision, against which you rant so often and vociferously, Peter?
--
/Nelson Bolyard
Nelson Bolyard
> Right, because PKI is doing such a great job at the moment of keeping
> us safe from phishing and the like that we can be completely confident
> in it.
Peter, You know very well that PKI is about providing authentication
assurances to those who want them. You also know that phishing exists
because most users simply don't care, and will ignore any attempt to
tell them "You're not talking to who you think you are", no matter from
WHAT source that message originates, or how it is stated.
As you know, good authentication, knowing that one is connected to the
party to which one desires to be connected and not some impostor, is a
necessary part of a secure network connections and communication.
But NO authentication mechanism can overcome people's disregard for
authentication.
Peter Gutmann
>On 2010-10-06 20:49 PDT, Peter Gutmann wrote:
>
>Would that be the same user who always "clicks through" every security
>decision, against which you rant so often and vociferously, Peter?
The term "users" covers a bit too much ground here, what I meant in this case
was "users of TLS", i.e. a system administrator charged with deploying a
security system, who would have a far better idea of what is and isn't
appropriate for their environment than a one-size-(mis)fits-all value
hardcoded into a browser.
(Also, in terms of clicking through warnings, my complaints aren't about the
users but about the design and UI that habituates them into this type of
behaviour).
Peter.