Google about to fix the CRL download mechanism in Chrome

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Google about to fix the CRL download mechanism in Chrome

Jean-Marc Desperrier-4
Hi,

Google just published the changes they are about to do in the revocation
checking in Chrome :
http://www.imperialviolet.org/2012/02/05/crlsets.html

In my opinion, maybe somewhat opposite to the way they describe it,
fundamentally they are not *at* *all* changing the standard PKI method
of revocation check.

They are instead just solving a number of flaws in the way the CRL
revocation information is fetched by browser, therefore implementing a
new CRL fetching method that *works*, replacing the current *broken* one.

To work properly, CRL fetching must be done in advance of accessing the
site. This never worked properly when you had to individually, locally
determine the list of CRL to download.
Therefore establishing  centrally the list of public CRL to download,
and pushing the result to browsers *is* the proper solution.

The other trouble with CRL in that in practice the only solution that's
available is to download complete CRL, that include all revocation
reason, resulting in awful bandwidth requirements.

Whereas the optimal solution would be to download each day a delta CRL,
with only the difference with the previous day, and containing only the
revocation reasons you *really* care about (key compromise).

By centrally converting the CRL format to a proprietary optimized format
that contains only that, they can do it, without implementing in the
browser the complex "delta", "by reason", CRL splitting mechanism that
theoretically exists, but that nobody ever got right (and nobody will,
as getting it right also depends on every CA getting it right, when
their solution just *doesn't*).

The cross-signing (replacing the original signature on CRL by a new
signature/integrity layer) this solution requires is certainly not a
problem, it just has to be done right, which is not difficult when you
already have a secure software update diffusion channel.

In conclusion I'm 100% in favor of Mozilla adopting this solution,
instead of trying to invent new schemes, that are very hard to get right
: Most people spend a lot of time on them only to realize at the end
that making things differently usually only means making a very slightly
differently weighted choice between all the possible parameters of a
security solution, that ends up not really much better than the
original, even thought you were initially convinced the original was
very broken.

I hope I have convinced you Google's solution is not new at all, which
is great. If it's not actually new, it's much easier to be convinced
it's pure *enhancement*, and not change, on the current solution, so
there's no significant drawback, and no initially non-obvious potential
danger, at adopting it.

PS : I probably won't be much on-line in the next one-and-half week,
just had to post this before :-)
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Kai Engert-4
My criticism:

(a)
I don't like it that the amount of CRLs will be a subset of all CRLs.
What about all the revoked certificates that aren't included in the list?

With a dynamic mechanism like OCSP (and in the future OCSP stapling) you
don't have to make a selection.

(b)
I don't like it that the CRLs are supposed to be filtered. How can you
ensure that no important revocation will be missed?

(c)
What about mobile browsers, what about people with expensive mobile data
plans, or when roaming?

Won't the set of CRLs be too big for download?

Even if they use diffs, what about people who use their mobile browser
only once or twice a week, and will keep the data connection off during
the remainder of the time?

Will there be a full set of diffs for the past days still be available
to recreate the latest set of signed CRLs, or will browsers end up
re-downloading the full set of CRLs on each of those infrequent occassions?

But we will have to see numbers in order to judge whether this point is
valid criticism.


In my opinion we should rather get our homework done: finally get
on-demand downloading of CRLs done (which depends on more helping hands
to get the bugs in libPKIX fixed), get OCSP stapling deployed and find a
way to require strict revocation checking. The latter will involve
creating user interface that allows users to override a temporary OCSP
outage, e.g. when using a captive portal in order to get the payment done.

Kai

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Eddy Nigg (StartCom Ltd.)
In reply to this post by Jean-Marc Desperrier-4
On 02/08/2012 09:58 PM, From Jean-Marc Desperrier:
> Whereas the optimal solution would be to download each day a delta
> CRL, with only the difference with the previous day, and containing
> only the revocation reasons you *really* care about (key compromise).
>

A certificate can be either valid, expired or revoked. A revoked
certificate is not valid, no matter the reason (which does not have to
be present in the CRL).

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:    [hidden email]
Blog:   http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Nelson B Bolyard-2
In reply to this post by Kai Engert-4
On 2012/02/08 12:57 PDT, Kai Engert wrote:
>
> My criticism:
[snip]
> Won't the set of CRLs be too big for download?
[snip]

This is my question as well.
Will they really include the CRLs from all of mozilla's trusted CAs?
Won't the union of all those CRLs be huge, even if they strip off certain
reason codes?
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Sean Leonard-6
In reply to this post by Jean-Marc Desperrier-4
Without expressing my opinions on the wisdom of whatever Google is
proposing...

What Jean-Marc has described (and what the Google post also describes)
is already covered by RFC 5280 in the concept of "indirect CRL", which
you can see in Section 5.

It is also worth pointing out that "indirect OCSP" exists in the form of
"designated OCSP responders". So, you have your online as well as your
offline options.

The nice thing about indirect CRLs is that they are a standardized
format. What Mozilla currently does with its internal blacklist, written
in C++, is basically a highly proprietary form of an indirect CRL. The
problem (if any) with indirect CRLs is lack of automatic support in the
crypto stacks: all the more reason to beef up libpkix and the NSS entry
points to libpkix. Also consider that revocation is cumulative: if you
have an authoritative list for some reasons (keyCompromise) and a cert
is not on the list, it doesn't mean that it's valid--just that it's not
revoked for keyCompromise reasons. You don't need a single CRL (indirect
or otherwise) for everything; rather, you are supposed to be able to
compare against multiple lists.

Each valid list you check against reduces the overall risk profile of
using the certificate. That's the deal. Therefore (in view of Nelson's
recent comment about size), a list that is very small but lists the
whole world's keyCompromise certificates, will offer more bang for the
buck than a huge list from one CA that covers all of the reason codes,
like affiliationChanged or whatever. You can never drive the risk to
zero, but you can make it low enough to be pretty acceptable for certain
applications (e.g., "low assurance web browsing", as opposed to "high
assurance EV web browsing").

Put it another way. Suppose that for *every* improper reliance, the CA
is responsible for paying the damages. But, the CA has 100K of silver
bullets to immunize itself from liability. The CA is going to use those
100K bullets on reliances where the risk of loss is high, right? (I.e.,
keyCompromise, or caCompromise.) The long tail of everything else is
then just a cost of doing business.

-Sean
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Eddy Nigg (StartCom Ltd.)
In reply to this post by Kai Engert-4
On 02/09/2012 12:18 AM, From Nelson B Bolyard:
> Will they really include the CRLs from all of mozilla's trusted CAs?
> Won't the union of all those CRLs be huge, even if they strip off
> certain reason codes?

BTW, this proposal wouldn't be a problem if it would cover, lets say the
top 500 sites and leave the rest to the CAs. There would be probably
also the highest gains.

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:    [hidden email]
Blog:   http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Brian Smith-31
Eddy Nigg wrote:
> On 02/09/2012 12:18 AM, From Nelson B Bolyard:
> BTW, this proposal wouldn't be a problem if it would cover, lets say
> the top 500 sites and leave the rest to the CAs. There would be
> probably also the highest gains.

Effectively, we would be making the most popular servers on the internet faster, and giving them a significant competitive advantage over less popular servers. I am not sure this is compatible with Mozilla's positions on net neutrality and related issues.

AFAICT, improving the situation for the top 500 sites (only) would be the argument for *mandatory* OCSP stapling and against implementing Google's mechanism. The 500 biggest sites on the internet all have plenty of resources to figure out how to deploy OCSP stapling. The issue with OCSP stapling is the long tail of websites, that don't have dedicated teams of sysadmins to very carefully change the firewall rules to allow outbound connections from some servers (where previously they did not need to) and/or implement deploy DNS resolvers on their servers (where, previously, they might not have needed any), and/or upgrade and configure their web server to support OCSP stapling (which is a bleeding edge feature and/or not available, depending on the server product).

A better (than "favor the Alexa 500") solution may be to do auto-load CRLs for the sub-CA that handles EV roots (assuming that CAs that do EV have or could create sub-CAs for EV roots for which there would be very few revocations, which may require standardizing some of the business-level decision making regarding when/why certificates can be revoked), or similar things. This would at least reduce the cost for the long tail of websites to a low* fixed yearly fee. I am not sure this would be completely realistic or sufficient though.

I am also concerned about the filtering based on reason codes. Is it realistic to expect that every site that has a key compromise to publicly state that fact? Isn't it pretty likely that after a server's EE certificate has been revoked, that people will tend to be less diligent about protecting the private key and/or asking for the cert to be revoked with a new reason code?

However, I don't think we should reject Google's improvement here because it isn't perfect. OCSP fetching is frankly a stupid idea, and AFAICT, we're all doing it mostly because everybody else is doing it and we don't want to look less secure. In the end, for anything serious, we have been relying (and continue to rely) on browser updates to *really* protect users from certificate-related problems. And, often we're making almost arbitrary decisions as to which breaches of which websites are worth issuing a browser update for. Google is just improving on that. Props to Adam, Ben, Wan-Teh, Ryan, and other people involved.

Cheers,
Brian

* Yes, I consider the price of even EV certificates to be almost inconsequential, compared to the overall (opportunity) cost of a person needed to securely set up and maintain even the most basic HTTPS server.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

ianG-2
In reply to this post by Jean-Marc Desperrier-4
On 9/02/12 06:58 AM, Jean-Marc Desperrier wrote:

> In conclusion I'm 100% in favor of Mozilla adopting this solution,

+1

I haven't looked closely but I'm confident they will do the right thing
in this area.

iang
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Robert Relyea
In reply to this post by Brian Smith-31
On 02/08/2012 04:20 PM, Brian Smith wrote:
> However, I don't think we should reject Google's improvement here because it isn't perfect. OCSP fetching is frankly a stupid idea, and AFAICT, we're all doing it mostly because everybody else is doing it and we don't want to look less secure. In the end, for anything serious, we have been relying (and continue to rely) on browser updates to*really*  protect users from certificate-related problems. And, often we're making almost arbitrary decisions as to which breaches of which websites are worth issuing a browser update for. Google is just improving on that. Props to Adam, Ben, Wan-Teh, Ryan, and other people involved.
We do OCSP fetching because CRL fetching on the internet as a whole
didn't scale when it was tried. OCSP may not be perfect, but we do it
because it's the best thing we have today.

OCSP stapling would certainly improve things, which is why it was
created, what was it, oh at least 5 years ago. Part of what we are
fighting is the general inertia of the web. It took close to 15 years to
get OCSP generally turned on!

bob

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

ianG-2
In reply to this post by Nelson B Bolyard-2
On 9/02/12 09:18 AM, Nelson B Bolyard wrote:

> On 2012/02/08 12:57 PDT, Kai Engert wrote:
>>
>> My criticism:
> [snip]
>> Won't the set of CRLs be too big for download?
> [snip]
>
> This is my question as well.
> Will they really include the CRLs from all of mozilla's trusted CAs?
> Won't the union of all those CRLs be huge, even if they strip off certain
> reason codes?

The reason I have confidence in them to make this work, or back off in
the event, is that for all Google's many flaws, they are rather good at
Internet engineering.  This might be considered to be their core competence.

iang
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Eddy Nigg (StartCom Ltd.)
In reply to this post by Jean-Marc Desperrier-4
On 02/09/2012 02:20 AM, From Brian Smith:
> Effectively, we would be making the most popular servers on the
> internet faster, and giving them a significant competitive advantage
> over less popular servers. I am not sure this is compatible with
> Mozilla's positions on net neutrality and related issues.

Yes certainly it isn't - this is about Google and not Mozilla. And I
don't expect Mozilla not to check the status of a certificate either (or
at least attempting to check...).

> AFAICT, improving the situation for the top 500 sites (only) would be the argument for *mandatory* OCSP stapling and against implementing Google's mechanism.

Agreed. (I would like to add that we should consider the top 500 secured
sites when speaking about those, where essential traffic is generation
in SSL mode).

>   The 500 biggest sites on the internet all have plenty of resources to figure out how to deploy OCSP stapling.

Absolutely.

>   The issue with OCSP stapling is the long tail of websites, that don't have dedicated teams of sysadmins to very carefully change the firewall rules to allow outbound connections from some servers.

I believe stapling will be successful when web servers will do it by
default. This is entirely possible and wouldn't require from the admins
lots of knowledge. The majority will never turn it on if it's only optional.

> A better (than "favor the Alexa 500") solution may be to do auto-load CRLs for the sub-CA that handles EV roots

That's a very good idea (and for the reasons you stated).

> However, I don't think we should reject Google's improvement here because it isn't perfect. OCSP fetching is frankly a stupid idea, and AFAICT, we're all doing it mostly because everybody else is doing it and we don't want to look less secure.

Well, in fact the Mozilla based browsers were one of the first to
successfully support OCSP. Most, if not all other browsers either didn't
even exist at that time or didn't support OCSP (and CRL checking was not
turned on by default either).

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:    [hidden email]
Blog:   http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Rob Stradling
In reply to this post by Nelson B Bolyard-2
FYI, Adam Langley told me "The hope is that everything is <100KB".

I asked him if I could share that figure here and he just replied "No
problem. It's not a strict limit that we set and we'll have to see
how well we do".

We've calculated that there are currently ~53,000 revoked Server
Authentication certs that were issued by Comodo's CA systems, each with
a serial number of 16 bytes (+ a leading zero byte if required to ensure
it's not treated as a negative number).  That adds up to well over
800KB.  And obviously we're not the only CA!

On 08/02/12 22:18, Nelson B Bolyard wrote:

> On 2012/02/08 12:57 PDT, Kai Engert wrote:
>>
>> My criticism:
> [snip]
>> Won't the set of CRLs be too big for download?
> [snip]
>
> This is my question as well.
> Will they really include the CRLs from all of mozilla's trusted CAs?
> Won't the union of all those CRLs be huge, even if they strip off certain
> reason codes?

--
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.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Gervase Markham
In reply to this post by Nelson B Bolyard-2
On 09/02/12 12:54, Rob Stradling wrote:
> We've calculated that there are currently ~53,000 revoked Server
> Authentication certs that were issued by Comodo's CA systems, each with
> a serial number of 16 bytes (+ a leading zero byte if required to ensure
> it's not treated as a negative number). That adds up to well over 800KB.
> And obviously we're not the only CA!

Which is why he's obviously not going to transmit the information as a
list of serial numbers :-)

He's probably planning something vaguely like this:
http://en.wikipedia.org/wiki/Bloom_filter

Gerv
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Rob Stradling
On 09/02/12 13:10, Gervase Markham wrote:
> On 09/02/12 12:54, Rob Stradling wrote:
>> We've calculated that there are currently ~53,000 revoked Server
>> Authentication certs that were issued by Comodo's CA systems, each with
>> a serial number of 16 bytes (+ a leading zero byte if required to ensure
>> it's not treated as a negative number). That adds up to well over 800KB.
>> And obviously we're not the only CA!
>
> Which is why he's obviously not going to transmit the information as a
> list of serial numbers :-)

Actually, he is.

> He's probably planning something vaguely like this:
> http://en.wikipedia.org/wiki/Bloom_filter

I know Adam was looking at Bloom filters and related techniques last
year [1], but I understand that he abandoned those approaches.  I'm not
sure why.

The current CRLSet format is described in the Chromium source code [2]
(search for "CRLSet format").

Also, he's published a tool for downloading and parsing CRLSets [3].


[1] http://www.imperialviolet.org/2011/04/29/filters.html

[2]
http://src.chromium.org/viewvc/chrome/trunk/src/net/base/crl_set.cc?revision=97640&view=markup

[3] https://github.com/agl/crlset-tools


> Gerv

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Ondrej Mikle-2
In reply to this post by Brian Smith-31
On 02/09/2012 01:20 AM, Brian Smith wrote:
> I am also concerned about the filtering based on reason codes. Is it realistic to expect that every site that has a key compromise to publicly state that fact? Isn't it pretty likely that after a server's EE certificate has been revoked, that people will tend to be less diligent about protecting the private key and/or asking for the cert to be revoked with a new reason code?

You're right, relying on revocation reasons is not a good idea. There are CAs
that reportedly "don't know" how to use them:

A quote from Lucky Green
(http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html):

> Most (but not all) of the CAs that I worked with over the years did not
> have anybody on the operations side full time that would know how to
> place a revocation reason into the CRL. Which is why the majority of CRL
> entries include an unspecified reason code or the ever popular reason
> code "NULL".

Even the CAs that do use revocation reasons in CRLs do not always put them in.
For instance, GlobalSign did not state any reason for the certificates revoked
due to compromise of their server by the alleged ComodoHacker.

Ondrej
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Erwann ABALEA-3
In reply to this post by Brian Smith-31
Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit :
[...]
> A quote from Lucky Green
> (http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html):
>
> > Most (but not all) of the CAs that I worked with over the years did not
> > have anybody on the operations side full time that would know how to
> > place a revocation reason into the CRL.

What kind of CA are these?

> > Which is why the majority of CRL
> > entries include an unspecified reason code or the ever popular reason
> > code "NULL".

Before Google announce, what was the revocation reason used for? Nothing.
One can use it to distinguish certificateHold and removeFromCrl reasons, but its use is seldom. One could eventually perform CRL partitionning, but I've never seen it in practice (and it's not really useful).

So even if the revocation reason is taken into account during the revocation action, and stored in the CA database, outputing this reason in a CRL parsed by a machine that doesn't care about why a certificate has been revoked is useless.

Now, after some thought (thanks, Jean-Marc), if Google could come up with an efficient mechanism so that revocation is really checked, that's cool. The "less than 100k" is a challenge, I'd like to see how it will be solved, given the large CA base and unequal technical expertise of them.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Erwann ABALEA-3
In reply to this post by Jean-Marc Desperrier-4
Le mercredi 8 février 2012 21:57:09 UTC+1, Kai Engert a écrit :
> My criticism:
>
> (a)
> I don't like it that the amount of CRLs will be a subset of all CRLs.
> What about all the revoked certificates that aren't included in the list?
>
> With a dynamic mechanism like OCSP (and in the future OCSP stapling) you
> don't have to make a selection.

OCSPStapling doesn't work. You can have only one OCSP response by the standard, while you need at least 2. It was defined that way in 2006 (RFC4366), and confirmed in 2011 (RFC6066).

> (b)
> I don't like it that the CRLs are supposed to be filtered. How can you
> ensure that no important revocation will be missed?

It's the job of CAs to provide good enough CRLs. If they can't do this, can they really be trusted?

[...]
> In my opinion we should rather get our homework done: finally get
> on-demand downloading of CRLs done (which depends on more helping hands
> to get the bugs in libPKIX fixed), get OCSP stapling deployed and find a
> way to require strict revocation checking. The latter will involve
> creating user interface that allows users to override a temporary OCSP
> outage, e.g. when using a captive portal in order to get the payment done.

That should have been done a long time ago, the revocation checking problem is not new, it only has become more visible with Comodo and DigiNotar events.

Mozilla is still the only one to send OCSP requests as POST, bypassing standard cache mechanisms, preventing the use of CDNs to avoid SPOF.

I don't share all Google ideas (for example the green bar for "DNSSEC" certificates), but this one could be promising, let's see.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

ianG-2
In reply to this post by Erwann ABALEA-3
On 10/02/12 21:40 PM, Erwann Abalea wrote:

> Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit :
> [...]
>> A quote from Lucky Green
>> (http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html):
>>
>>> Most (but not all) of the CAs that I worked with over the years did not
>>> have anybody on the operations side full time that would know how to
>>> place a revocation reason into the CRL.
>
> What kind of CA are these?

:-)

>>> Which is why the majority of CRL
>>> entries include an unspecified reason code or the ever popular reason
>>> code "NULL".
>
> Before Google announce, what was the revocation reason used for? Nothing.
> One can use it to distinguish certificateHold and removeFromCrl reasons, but its use is seldom. One could eventually perform CRL partitionning, but I've never seen it in practice (and it's not really useful).
>
> So even if the revocation reason is taken into account during the revocation action, and stored in the CA database, outputing this reason in a CRL parsed by a machine that doesn't care about why a certificate has been revoked is useless.
>
> Now, after some thought (thanks, Jean-Marc), if Google could come up with an efficient mechanism so that revocation is really checked, that's cool. The "less than 100k" is a challenge, I'd like to see how it will be solved, given the large CA base and unequal technical expertise of them.


What I surmised was happening was that Google were asking CAs to provide
a new CRL for their specifications alone with "really must stop these"
revocations in them.

So, any routine "compromise" or "replaced" or "not-sure" or NULL issues
aren't to be in there.  Which gets it down to numbers less than 1000 for
the entire industry -- ones where the CA knows there is trouble.

Or, as Alexandre says, 231:
http://www.foo.be/cgi-bin/wiki.pl/2011-12-17_Certificate_Revocation_Reasons_2011

That's what I think they are doing.  Partitioning at the legal/admin level.

I would do something different ;-)  So would we all I guess...



iang
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Rob Stradling
In reply to this post by Erwann ABALEA-3
On 10/02/12 11:02, Erwann Abalea wrote:

> Le mercredi 8 février 2012 21:57:09 UTC+1, Kai Engert a écrit :
>> My criticism:
>>
>> (a)
>> I don't like it that the amount of CRLs will be a subset of all CRLs.
>> What about all the revoked certificates that aren't included in the list?
>>
>> With a dynamic mechanism like OCSP (and in the future OCSP stapling) you
>> don't have to make a selection.
>
> OCSPStapling doesn't work. You can have only one OCSP response by the standard, while you need at least 2. It was defined that way in 2006 (RFC4366), and confirmed in 2011 (RFC6066).

The fact that only 1 OCSP Response can be stapled is not a problem...if
we could just find a different way to improve revocation checking of the
intermediate CA certificate(s) in the chain.

Since there are probably very few revoked intermediate CA certificates
in the wild, why not use CRLSets just for intermediate revocation
checking?  (I'd expect the size of this data to be well under 100K !)

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Google about to fix the CRL download mechanism in Chrome

Ondrej Mikle-2
In reply to this post by Erwann ABALEA-3
On 02/10/2012 11:40 AM, Erwann Abalea wrote:

> Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit :
> [...]
>> A quote from Lucky Green
>> (http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html):
>>
>>> Most (but not all) of the CAs that I worked with over the years did not
>>> have anybody on the operations side full time that would know how to
>>> place a revocation reason into the CRL.
>
> What kind of CA are these?

Last time I tried to ask about specific CAs, I got an answer: "You must
joking, right?" (NDAs are prolific in this line of business.) That's why
I favor public disclosure of sub-CA certs that is currently being
discusses at mozilla.dev.security.policy.

>>> Which is why the majority of CRL
>>> entries include an unspecified reason code or the ever popular reason
>>> code "NULL".
>
> Before Google announce, what was the revocation reason used for? Nothing.

At the very least it was used by researchers (EFF, crlwatch just to name
a few).

> So even if the revocation reason is taken into account during the revocation action, and stored in the CA database, outputing this reason in a CRL parsed by a machine that doesn't care about why a certificate has been revoked is useless.

UI of TLS clients could be different for specific revocation reasons.
It's really a corner case (just for the sole purpose of an example).

RFC 5280 says:

   CRL issuers are strongly
   encouraged to include meaningful reason codes in CRL entries;
   however, the reason code CRL entry extension SHOULD be absent instead
   of using the unspecified (0) reasonCode value.

Why not use it? Following the logic "no code I know of parses it anyway"
we could drop many kinds of fields from other protocols.

> Now, after some thought (thanks, Jean-Marc), if Google could come up with an efficient mechanism so that revocation is really checked, that's cool. The "less than 100k" is a challenge, I'd like to see how it will be solved, given the large CA base and unequal technical expertise of them.

I'm glad that Google came up with the proposal. Despite being
incomplete/controversial, this time the discussion actually may end up
in something being changed for the better (instead of the usual "oh
well" ending).

Ondrej
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
12