Revocation Checking via Browser CRL/Cache Flushing

[Kirk Hall]

The recent fake certs incident has led to of discussion about the
current CRL/OCSP revocation process, and many suggestions on how to
improve revocation. Some suggestions seem pretty complicated and
unlikely to work.

I want to suggest two alternatives that are pretty simple and would
involve cooperation from the browsers. If adopted, we could move to a
secure, always responsive revocation system very quickly.

FIRST PROPOSAL – COMPREHENSIVE CRLs IN THE BROWSER ITSELF

The basic concept is to move the CRL to inside the browser itself (so
clients using the browsers won’t have to search the internet for a CRL
or OCSP response) – but the CRL would only certs that were revoked for
major security breaches or where revocation has been specifically
requested. That way the CRL would be small in size and easily
manageable. Here are more details.

Under this proposal, each browser would gather certificate revocation
information from each CAs with a trusted root in the browser and put
the responses from all CAs in one place – a new, comprehensive
“Browser CRL” – and then include the Browser CRL in their browser
software to be pushed out to clients. This Browser CRL would be
updated daily for routine revocation, or immediately for issues like
the recent bad cert problem.

When a client tries to go to a site with a cert listed in the Browser
CRL, they would be blocked. No reference to an outside CRLs or OCSPs
would be required, so issues like OCSP non-response, OCSP stapling,
backup OCSP addresses, soft default or hard default, etc. wouldn’t be
relevant. All the necessary information on revocation would be in the
browser itself.

How would the Browser CRL be created? The browsers could instruct the
CAs exactly how they have to post revocation information to the
browsers (including appropriate security requirements) so the CAs
would make it easy for the browsers to collect the updates. Browsers
would be required to send an update message to all clients every 24
hours (the “Daily Update”) even if there have been no additional
certificate revocations – so the Daily Update that the clients would
expect would either say “No Changes” or “Please add/delete these certs
to your existing Browser CRL”.

If the client does not receive its Daily Update, the browser software
would give the client a warning each time the client goes to an https
site, e.g., “Warning – your browser software has not been updated
since [date]. You may not know if the certificate securing this site
has been revoked. Click here to update your browser.”

If a CA fails to provide the browser with a “CA” Daily Update that the
browser can use to push out its own Daily Update to the clients, the
client browser can give the client a warning each time the client goes
to an https site secured by that CA only, e.g., “Warning – the
Certification Authority [name of CA] that issued the certificate
securing this site has not updated its revocation list with this
browser since [date]. You may not know if the certificate securing
this site has been revoked.” That warning would show up on all sited
secured by that CA – so CAs would work hard to make sure each browser
received a CA Daily Update every day.

While connectivity problems could create limited problems (e.g., a
client might not be able to receive its Daily Update from the browser
for some reason – but in that case, how would the client browser be
surfing the internet to https sites?), it’s actually a good thing that
the client will get a warning if its operating without an updated
Browser CRL (or operating with an incomplete Browser CRL if one CA’s
Daily Update is missing). This would be a huge improvement over the
situation today, where every client’s visit to an https site results
in a search across the internet for a CRL or OCSP response, and where
numerous connectivity issues mean that browsers won’t use a “hard
fail” for lack of CRL/OCSP response and the client is potentially
insecure.

The usual first objection to a comprehensive Browser CRL is “It will
be too large to work.” But will it? Suppose the browsers require CAs
to use reasonCodes in their CRLs as defined in RFC 5280 , Section
5.3.1

5.3.1. Reason Code
The reasonCode is a non-critical CRL entry extension that identifies
the reason for the certificate revocation. 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. The removeFromCRL (8)
reasonCode value may only appear in delta CRLs and indicates that a
certificate is to be removed from a CRL because either the certificate
expired or was removed from hold. All other reason codes may appear
in any CRL and indicate that the specified certificate should be
considered revoked.

id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }

-- reasonCode ::= { CRLReason }

CRLReason ::= ENUMERATED {
Unspecified (0)
keyCompromise (1)
cACompromise (2)
affiliationChanged (3)
superseded (4)
cessationOfOperation (5)
certificateHold (6)
-- value 7 is not used
removeFromCRL (8)
privilegeWithdrawn (9)
aACompromise (10) }

We could all agree to use one of these reasonCodes to notify the
browsers of a high value/major security breach like the recent fake
cert incident.

Going further, we could map each of the following main categories for
revoking certificates to one of the predefined RFC 5280 reasonCodes
according to the following breakdown:

Category 1 – Cert was revoked because of major security breach
(like the recent fake cert incident)

Category 2 – Cert was revoked because revocation was requested
(which represents a potential security issue)

Category 3 – Everything else (e.g., customer didn’t pay, the
expiring cert was replaced by the CA with a new
cert, etc.)

For example, Category 1 could be mapped to reasonCode,
“privilegeWithdrawn” which is defined as reason code Nine (9). All
CAs would use the same mapping.

As I understand it, there have been almost no “major security breach”
certificate revocations - Category 1 above – for many years (the
recent fake certs are the only ones in Category 1 I can think of), and
there are very few Category 2 revoked certs. Most certs on a CRL
belong in Category 3 – and would NOT have to be included in a
comprehensive Browser CRL because they don’t represent a security
risk.

It's my guess that the cumulative number of Category 1 and 2
revocations from all CAs is actually very small, and that the number
of new Category 1 and 2 revocations is very small. Because revoked
certs cycle off a CRL once they have expired, the comprehensive
Browser CRL would be “self-pruning” over time.

Some CAs follow their own practices for adding Category 3 revocations
to their CRLs (e.g., they revoke all expiring certs upon reissuance,
even if there is nothing wrong with the expiring cert), so their CRL
is MB in size -- but the browsers can ignore the Category 3
revocations when compiling the comprehensive Browser CRL. If the CA
wants to leave the Category 3 revocations on its CRL and/or OCSP
responder (so clients get a warning sign the traditional way – via CA
CRL/OSCP response), they can continue to do that – but the browsers
will be under no pressure to “hard fail” a lack of response from a
traditional CRL/OCSP query, as the most important revocations (Class 1
and 2) will already be inside the browser software, and will be
certain to warn the client even if there are connectivity problems to
the CA’s CRL/OCSP responder.

How big would a comprehensive Browser CRL be? I’m guessing, but I
suspect no more than 500 KB if limited only to Class 1 and Class 2
revocations (and assuming revoked certs on the Browser CRL cycle off
once they expire). The initial Browser CRL (the whole thing) could be
downloaded initially to clients at the same time the browsers send out
a comprehensive browser software update – in many cases, those browser
updates are 10 MB to 80 MB in size, so an additional 0.5 MB – one time
only – wouldn’t be a noticeable additional burden.

Users would not have to download the entire Browser CRL every day, but
would download only changes to the Browser CRL since the last download
in the Daily Update, again keeping the burden on the browser small – I
suspect that the Daily Update would be less than one kilobyte. I
think most browsers do small daily updates already for new phishing
sites, etc., so the Daily Updates technology wouldn’t be new. The
Daily Updates from the browsers could be staggered and managed through
the day to further limit the burden.

There could be a concern that this solution would not work in a mobile
environment, either because the Browser CRL would be too large for the
mobile device’s available storage, or because mobile users are charged
for download time. On the first point, it seems many new phones have
GB of memory, so 0.5 MB wouldn’t be a burden. On the second point, if
the initial Browser CRL is downloaded with the initial mobile device
software it will only be a small additional burden, and the Daily
Updates would consume an insignificant download time. Also, if the
mobile device only had to check its own preloaded Browser CRL each
time it goes to an https site, and doesn’t have to search for an OCSP
response, that will cut down on the mobile device’s usage of air time.

One other point – for the extremely rare situation in which a new
Class 1 revocation occurs (Major security breach), the CA involved
could report that immediately to each browser through a secure
channel, and the browser could immediately push out that small update
to the Browser CRL on all the clients. That’s essentially what
happened recently with the fake certs issue (I saw the patches being
installed on my client browser software), so this wouldn’t be new.
Again, there will probably only be a Class 1 revocation event every
few years, so the burden on the browsers isn’t great compared with the
security risk – and the solution would be way more secure than just
relying on OCSP.

Finally, if this proposal were adopted, the browsers might work with
the CAs to create a single CRL Repository where the CAs initially post
their Class 1 and 2 revocations, as well as their individual CA Daily
Updates (all in secure mode), and the browsers can all access the
Repository to assemble their browser software’s initial Browser CRL as
well as later Daily Updates. In other words, there may be ways to
improve efficiency and security so both CAs and browsers only need to
go one place to keep the Browser CRLs up to date.

While the browsers may not want to take on the responsibility of
creating a browser CRL within their software, they may be forced to do
it if one browser is a first mover – implementing a Browser CRL as
outlined above and then advertising that its browser and related
applications are safer for consumers than all the other browsers, etc.

As a first step to determining the feasibility of creating a Browser
CRL and Daily Update system, it would be very useful for each CA to
provide the following data:

1. How many Category 1, 2, and 3 revoked certs (reported
separately) are on their current CRLs – in total?
2. How many new Category 1, 2, and 3 revoked certs (reported
separately) do they add to their CRLs each
day, on average?

If the combined numbers for the Category 1 and 2 revocations are as
small as I suspect they will be, a comprehensive Browser CRL would be
entirely feasible, and add considerable security for clients.

SECOND PROPOSAL – FLUSHING CRL AND OCSP CACHES

Here is a second proposal that puts less of a burden on the browsers.

In general, posting to a CRL with CRL caching is good enough for 99.99%
+ of revoked certs. For example, if a bad cert is issued in the name
of “portlandbicycles.com” or “amysbistro.com”, the danger to consumers
is small enough that posting to a CRL with CRL caching is good
enough. It’s only for high risk targets – maybe 0.01% of all certs –
like login.live.com or opera.com that immediate revocation via OCSP
may be required.

Based on this assumption, the second proposal for improving revocation
is to create a message service that is initialized by the CA that
sends a request to each web browser to have their users flush the
specified cached CRL or cached OCSP response from the CA. This
message would be sent by the CA to the browsers in the event of
revocation of a cert determined by the CA to represent a high risk to
users. The browsers, in turn, would send a tiny update or command to
users to flush their caches (similar to updates now sent by browsers
in response to new phishing risks, etc.).

This method would allow the CAs is determine if a high risk breach
should have immediate revocation, but also recognizes that low risk
sites don't need this functionality and can use the existing CRL/OCSP
infrastructure. The method would be used infrequently, but would be
very effective in an emergency.

This proposal assumes that browser software will actually block access
to a site if the site’s cert is listed on the CA’s CRL/OCSP. It also
assumes the browser software will block all sites potentially covered
by the specified CRL (i.e., all sites secured by certs from that CA)
if access to the CA’s CRL is non-functional after the cache flushing
request is sent.

As an added benefit from this proposal, CAs will pay more attention to
maintaining their CRL uptime if browsers essentially block access to
all sites secured by the CA if the CRL is down or non-responsive
following a cache flushing request. (It’s my understanding that most
established CAs don’t have a problem with maintaining CRL uptime, but
some marginal CAs do).

Another positive feature of this solution is that it effectively
leaves most of the revocation checking burden with the CAs – they are
the ones who will have to be prepared to refresh their CRL and OCSP
responses among all users once the browsers have told their users to
flush their caches. The browsers would only be “pushing out” the
cache flushing request to their users, and the CAs would then have to
respond.

One potential problem with this second proposal: it’s not clear how
this proposal would work in corporate environments, because the
browsers would have to give a command to everyone's desktop in a
corporate environment to clear a cache.

Any comments on either proposal?

[Gervase Markham]

Hi Kirk,

Thanks for joining the debate :-)

As decided at a meeting last week, Mozilla intends to add "certificate
issuer/serial pair blacklisting" to their existing mechanism for
blacklisting addons and graphics drivers. The file with such blacklists
in is downloaded daily. This would allow us to push out instructions to
disregard particular certs, with a 24-hour max lag time. We have no hard
ETA for this feature, but I would be disappointed not to see it in
Firefox 6.

This system has some features of your first proposal.

We could implement an additional system to aggregate revocation
information from public CA CRLs based on Reason Code (part of your first
idea).

On 12/04/11 00:29, Kirk Hall wrote:
> As a first step to determining the feasibility of creating a Browser
> CRL and Daily Update system, it would be very useful for each CA to
> provide the following data:
>
> 1. How many Category 1, 2, and 3 revoked certs (reported
> separately) are on their current CRLs – in total?
> 2. How many new Category 1, 2, and 3 revoked certs (reported
> separately) do they add to their CRLs each
> day, on average?

That would be very interesting data indeed.

> Based on this assumption, the second proposal for improving revocation
> is to create a message service that is initialized by the CA that
> sends a request to each web browser to have their users flush the
> specified cached CRL or cached OCSP response from the CA.

If we are sending requests to each browser, why not just tell the
browser to distrust the relevant cert(s), rather than getting them to
flush caches so they can download CRLs and OCSP which then tell them to
distrust the relevant cert(s)?

Gerv

[Ian G]

On 12/04/11 9:12 PM, Gervase Markham wrote:
> Hi Kirk,
>
> Thanks for joining the debate :-)
>
> As decided at a meeting last week, Mozilla intends to add "certificate
> issuer/serial pair blacklisting" to their existing mechanism for
> blacklisting addons and graphics drivers. The file with such blacklists
> in is downloaded daily. This would allow us to push out instructions to
> disregard particular certs, with a 24-hour max lag time. We have no hard
> ETA for this feature, but I would be disappointed not to see it in
> Firefox 6.

Would the semantics of inclusion in this list be exactly equivalent to
inclusion in a CRL? That is, is it equivalent to revocation, at a
semantic level?

iang

[Gervase Markham]

On 12/04/11 12:17, Ian G wrote:
> Would the semantics of inclusion in this list be exactly equivalent to
> inclusion in a CRL? That is, is it equivalent to revocation, at a
> semantic level?

I think that the details of implementation have not got very far! Do you
have reasons why the answer to the question above should particularly be
"yes" or "no; it should be different in way X"?

Gerv

[Kirk Hall]

One additional benefit to the First Proposal above I forgot to
mention.

In other discussions, people have raised privacy concerns about OCSP
checking by the client -- essentially a CA could accumulate a log of
the websites you were visiting based on your pings for an OCSP check,
and over time might use the data to try to sell you stuff, turn over
to law enforcement, etc.

With a Browser CRL under the First Proposal, clients would not have to
check OCSP (unless they want to ), and so the CA would not know which
websites you are visiting - less of a privacy concern.

[Eddy Nigg]

On 04/13/2011 02:10 AM, From Kirk Hall:

> With a Browser CRL under the First Proposal, clients would not have to
> check OCSP (unless they want to ), and so the CA would not know which
> websites you are visiting - less of a privacy concern.

Just a note on that one, if a CA would be really interested in that, it
could include unique CRL DPs on a per certificate basis. Not much more
difficult than an OCSP responder.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Ian G]

On 12/04/11 9:20 PM, Gervase Markham wrote:
> On 12/04/11 12:17, Ian G wrote:

>> Would the semantics of inclusion in this list be exactly equivalent to
>> inclusion in a CRL? That is, is it equivalent to revocation, at a
>> semantic level?
>

> I think that the details of implementation have not got very far!

Ah, implementation before semantics, this is one of those chicken & egg
questions :)

> Do you
> have reasons why the answer to the question above should particularly be
> "yes" or "no; it should be different in way X"?

A few years ago we had a debate about how to revoke the root, and
concluded that the way to do this was through vendor actions, now
documented in the wiki somewhere. A lot of the discussion also applies
to sub-roots. For various reasons, revoking a sub-root is difficult,
and it puts a lot of strain on the disaster plans of the CA.

If a CA could also count on a revocation of the sub-root as being
deliverable through multiple channels, then it would assist the planning
quite a lot. The problem is an artifact of the brittle design of PKI,
the "must never fail" structure becomes quite tough in industry because
resiliance practices insist that failure be dealt with.

However, for that to work, we'd want the semantics of all of the
channels to be compatible and complementary. Ideally, the same. Or, in
other words, revocation means the same thing no matter the
implementation details.

iang

[Kyle Hamilton]

On Tue, Apr 12, 2011 at 4:18 PM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 04/13/2011 02:10 AM, From Kirk Hall:
>>
>> With a Browser CRL under the First Proposal, clients would not have to
>> check OCSP (unless they want to ), and so the CA would not know which
>> websites you are visiting - less of a privacy concern.
>
> Just a note on that one, if a CA would be really interested in that, it
> could include unique CRL DPs on a per certificate basis. Not much more
> difficult than an OCSP responder.

This is why I want the DP specification moved from the EE cert into the intermediate CA cert.

This is why it's inappropriate to have it in the EE cert.

-Kyle H

[Gervase Markham]

On 13/04/11 03:36, Ian G wrote:
> However, for that to work, we'd want the semantics of all of the
> channels to be compatible and complementary. Ideally, the same. Or, in
> other words, revocation means the same thing no matter the
> implementation details.

You mean, "The answer should be 'Yes'"? :-)

Gerv

[Ian G]

On 13/04/11 8:40 PM, Gervase Markham wrote:
> On 13/04/11 03:36, Ian G wrote:

>> However, for that to work, we'd want the semantics of all of the
>> channels to be compatible and complementary. Ideally, the same. Or, in
>> other words, revocation means the same thing no matter the
>> implementation details.
>

> You mean, "The answer should be 'Yes'"? :-)

In terms of your original question; I have one reason that suggests
"Yes" ... Any browser "blacklist" should be equivalent to revocation by
other channels (OCSP, CRL), so that problems be eased for CAs (e.g., for
those CAs doing disaster planning).

There might be other reasons saying "No" and my arrogance has never
succeeded in stopping those... Especially, you started by saying that
implementation hadn't proceeded enough :) and as there is no solid
meaning to revocation, implementers could find other purposes and
benefits as they're going...

For delicious example, I just had a look at that recent CAB/Forum
baseline thing to see if revocation was defined (it wasn't) and found
this inside pandora's box 12.2.3:

"for example, a complaint from a law enforcement official that a Web
site is engaged in illegal activities should carry more weight than a
complaint from a consumer alleging that she didn‟t receive the goods she
ordered"

! so following that hint, revocation means that someone bigger than you
doesn't like your competitive practices.

iang

[Gervase Markham]

On 14/04/11 12:46, Ian G wrote:
> In terms of your original question; I have one reason that suggests
> "Yes" ... Any browser "blacklist" should be equivalent to revocation by
> other channels (OCSP, CRL), so that problems be eased for CAs (e.g., for
> those CAs doing disaster planning).

I think a default implementation would be Yes (subject to technical
constraints), so I was wondering if there were good reasons for it to be No.

> "for example, a complaint from a law enforcement official that a Web
> site is engaged in illegal activities should carry more weight than a
> complaint from a consumer alleging that she didn‟t receive the goods she
> ordered"
>
> ! so following that hint, revocation means that someone bigger than you
> doesn't like your competitive practices.

I don't think what's quoted leads to the conclusion you describe. I
presume the CA would want evidence that the acts were in fact illegal in
the jurisdiction of the CA, the site host, the owner or all three.

Gerv

[Ian G]

On 14/04/11 11:45 PM, Gervase Markham wrote:
> On 14/04/11 12:46, Ian G wrote:

>> In terms of your original question; I have one reason that suggests
>> "Yes" ... Any browser "blacklist" should be equivalent to revocation by
>> other channels (OCSP, CRL), so that problems be eased for CAs (e.g., for
>> those CAs doing disaster planning).
>

> I think a default implementation would be Yes (subject to technical
> constraints), so I was wondering if there were good reasons for it to be
> No.

Yes, hopefully, they are the same.

As we've seen empirically recently, revocation is a mess, it's a hopeful
design that met a need on paper only.

Having a new pathway with different semantics will just add more white
legs to the same old elephant.

>> "for example, a complaint from a law enforcement official that a Web
>> site is engaged in illegal activities should carry more weight than a
>> complaint from a consumer alleging that she didn‟t receive the goods she
>> ordered"
>>
>> ! so following that hint, revocation means that someone bigger than you
>> doesn't like your competitive practices.
>

> I don't think what's quoted leads to the conclusion you describe. I
> presume the CA would want evidence that the acts were in fact illegal in
> the jurisdiction of the CA, the site host, the owner or all three.

Ha! This is CABForum we are talking about ... they will ignore one
stakeholder and listen to the other.

iang

[Kyle Hamilton]

On Thu, Apr 14, 2011 at 6:45 AM, Gervase Markham <ge...@mozilla.org> wrote:
> I don't think what's quoted leads to the conclusion you describe. I presume
> the CA would want evidence that the acts were in fact illegal in the
> jurisdiction of the CA, the site host, the owner or all three.

Ah, see, right there the presumption that you/Mozilla (and by extension the CABF) know best how to manage things rears its ugly head. You ignore the jurisdiction of the purchaser. States don't look kindly on, for example, international fraud. States don't look kindly on, for example, selling title to radioactive materials across international borders. States don't look kindly on foreign states' subjects committing crimes against their own. (This is what extradition treaties are for.)

It is insane that Mozilla has a huge cash reservoir but hasn't figured out that it needs to hire a lawyer or three to figure out how its toy fits into the state of the real world, 15 years after the Wassennar Arrangement. If Mozilla wants to take responsibility for making sure its users are safe online, then it needs to ensure that it's following the rules in doing so. It currently is not.

-Kyle H

[Brian Smith]

Kirk Hall wrote:
> How would the Browser CRL be created?

As far as I understand your proposal, you would instead have one CRL that is signed by the browser maker. This requires that the browser trust its website to not omit revocations from the Browser CRL. That might be considered an acceptable tradeoff, but we should avoid requiring that extra trust of the browser's website if possible.

I have an idea very, very similar to yours. The difference is that, instead of a "Browser CRL" being a real CRL, it would instead be a series of CRLs or diffs of CRLs, so that we could reconstruct the CRL of each CA and verify the CRL's signature using the CA's public key.

If we could use the CAs' existing default CRLs, because they would be too large and/or there are too many of them, then we would require each included CA to create a new CRL with just a subset of the revocations as you so well explained. Possibly, we could use the default CRLs for CAs with small CRLs, so that it would require less industry buy-in. In this case, we would probably ask each CA to coalesce this subset of revocation information into one CRL that covers all their roots (even when the normal CRL for each root is distinct), to reduce the number of signatures that would bloat the size of the "Browser CRL".

> Category 3 – Everything else (e.g., customer didn’t pay, the
> expiring cert was replaced by the CA with a new
> cert, etc.)
>

> Most certs on a CRL belong in Category 3 – and would NOT have
> to be included in a comprehensive Browser CRL because they
> don’t represent a security risk.

Is this true?

> Users would not have to download the entire Browser CRL every day, but
> would download only changes to the Browser CRL since the last download
> in the Daily Update, again keeping the burden on the browser small – I
> suspect that the Daily Update would be less than one kilobyte.

In my variant, there would be ~256-512 bytes of data per CA just for signatures and identification, so it would add up to several KB per day. But, I think it could be acceptable.

> As a first step to determining the feasibility of creating a Browser
> CRL and Daily Update system, it would be very useful for each CA to
> provide the following data:
>
> 1. How many Category 1, 2, and 3 revoked certs (reported
> separately) are on their current CRLs – in total?
> 2. How many new Category 1, 2, and 3 revoked certs (reported
> separately) do they add to their CRLs each
> day, on average?

I agree, we need to get this data ASAP. I believe that we (Mozilla) have a mechanism in place to contact all CAs to get these technical details, and the CAs are required to give us this type of technical information to remain in our root program. I will work on getting this information.

- Brian

[Eddy Nigg]

On 04/21/2011 02:37 AM, From Brian Smith:

>> Most certs on a CRL belong in Category 3 – and would NOT have
>> to be included in a comprehensive Browser CRL because they
>> don’t represent a security risk.
> Is this true?

Yes, this is pretty much the case, most revocations are due to lost keys
and other non-critical reasons, which however still requires the CA
revoke it...it's good bookkeeping.

[Gervase Markham]

On 21/04/11 00:37, Brian Smith wrote:
>> Most certs on a CRL belong in Category 3 – and would NOT have to be
>> included in a comprehensive Browser CRL because they don’t
>> represent a security risk.
>
> Is this true?

I would be concerned about plans which suggest that we ignore some
revocations as "not important". a) what if we were wrong, and b) I can
see all sorts of bad incentives and behaviours this would lead to if it
were widely adopted.

Gerv

[Kirk Hall]

Gerv, what is “important” for revocation purposes is usually spelled
out in the CA’s CPS. It lists which certs will be revoked, and the
reasons. Most CAs list a fairly well defined set of criteria, and
most relate to “important” reasons relevant to a potential security
risk. See the portion of AffirmTrust’s CPS, Sec. III.I, relating to
reasons for revocation and procedures,
http://www.affirmtrust.com/images/AffirmTrust_CPS_v1.1_12-23-2010.pdf

Unfortunately, many CAs add certs to their CRL for other, non-security
reasons, e.g., the customer asked for a refund, the customer didn’t
pay for the cert, the customer renewed successfully and there are four
weeks life left under the old cert (so revoke the old cert for some
reason), etc.

At GeoTrust, we wanted to keep our CRL small, so we did not include a
cert on our CRL unless the customer specifically said “please revoke”
or we ourselves saw a security risk. Our CRLs were always very small.

I’d say the browsers should start by asking the CAs for the numbers of
revoked certs on their CRLs by category – perhaps start by accepting
the categories kept by the CAs themselves and try to merge them, or
give the CAs categories yourself and ask them to give you the numbers
for each category. Then you can make a judgment.

One other point – if a “Browser CRL” is created containing only the
most important revocations (which are sent to the Browsers daily or
more often by the CAs in a secure fashion according to agreed
criteria), there would be nothing to prevent the CAs THEMSELVES from
publishing their own FULL CRLs by their traditional methods (all the
other revoked certs) if they want. Meaning consumers would get a
double dose of revocation – the Browser CRL would always work to block
sites with “important” cert revocations, while the consumer’s client
can ALSO check the CA’s regular CRL and OCSP to look for ADDITIONAL
revocations that don’t represent an agreed-on security risk. If the
consumer gets no response to a regular OCSP inquiry, the browsers can
continue to treat this as a soft fail because they have already taken
care of the important revocations through the built-in Browser CRL.
But the skanky customer who failed to pay for a cert will still get
enough “revoked” responses from the CAs regular CRL/OCSP system that
he won’t be getting a free, usable cert.

Here is revocation language from AffirmTrust’s CPS for EV
certificates:

Certificate revocation is the process by which AffirmTrust prematurely
ends the Operational Period of a Certificate by posting the serial
number of the Certificate to a Certificate Revocation List and OCSP.
AffirmTrust will maintain a continuous 24x7 ability to accept and
respond to revocation requests and related inquiries.
A Subscriber shall cease using an EV Certificate and its associated
Private Key and shall inform AffirmTrust and promptly request
revocation of a Certificate in the event that:

• any information in the EV Certificate is or becomes incorrect or
inaccurate;
• there is any actual or suspected misuse or compromise of the
Subscriber’s Private Key associated with the Public Key listed in the
EV Certificate; or
• upon a change in the ownership of a Subscriber's web server.

The Subscriber shall state the reason(s) for requesting revocation
upon submitting the request.

AffirmTrust shall revoke an EV Certificate if:
• The Subscriber requests revocation of its EV Certificate;
• The Subscriber indicates that the original EV Certificate Request
was not authorized and does not retroactively grant authorization;
• AffirmTrust obtains reasonable evidence that the Subscriber’s
Private Key (corresponding to the Public Key in the EV Certificate)
has been compromised or is suspected of compromise (e.g. Debian known
weak keys), or that the EV Certificate has otherwise been misused;
• AffirmTrust receives notice or otherwise becomes aware that a
Subscriber has violated one or more of its material obligations under
the Subscriber Agreement and Terms of Use (if applicable);
• AffirmTrust receives notice or otherwise becomes aware that a court
or arbitrator has revoked a Subscriber's right to use the domain name
listed in the EV Certificate, or that the Subscriber has failed to
renew its domain name;
• AffirmTrust receives notice or otherwise becomes aware of a material
change in the information contained in the EV Certificate;
• A determination, in AffirmTrust's sole discretion, that the EV
Certificate was not issued in accordance with the terms and conditions
of the EV Guidelines or AffirmTrust's EV Policies;
• AffirmTrust determines that any of the information appearing in the
EV Certificate is not accurate.
• AffirmTrust ceases operations for any reason and has not arranged
for another EV Certificate Authority to provide revocation support for
the EV Certificate;
• AffirmTrust's right to issue EV Certificates under the EV Guidelines
expires or is revoked or terminated, unless AffirmTrust makes
arrangements to continue maintaining the CRL Repository;
• The Private Key of AffirmTrust's Root Certificate used for issuing
that EV Certificate is suspected to have been compromised;
• Such additional revocation events as AffirmTrust publishes in its EV
Policies; or
• AffirmTrust receives notice or otherwise becomes aware that a
Subscriber has been added as a denied party or prohibited person to a
blacklist, or is operating from a prohibited destination under the
laws of AffirmTrust's jurisdiction of operation as described in
Section 10.11.2 of the EV Guidelines.

If AffirmTrust initiates revocation of a Certificate, AffirmTrust will
notify the administrative and technical contact provided by Subscriber
by e-mail message of the revocation and the reasons why. In the event
that AffirmTrust ceases operations, all Certificates issued by
AffirmTrust shall be revoked prior to the date that AffirmTrust ceases
operations, and AffirmTrust will notify the administrative and
technical contact provided by Subscriber by e-mail message of the
revocation and the reasons why.

A refund and/or reissue request by a Subscriber pursuant to Section
II.B.5 will not be treated as a request for revocation of a
Certificate under this subsection unless the Subscriber specifically
requests revocation of the Certificate. ***

[Varga Viktor]

On ápr. 12, 01:29, Kirk Hall <kh...@affirmtrust.com> wrote:

> FIRST PROPOSAL – COMPREHENSIVE CRLs IN THEBROWSERITSELF

Dear Kirk,

Your proposal is very close to my proposal, which is already in the
MS, the trust list feature.
Mozilla should have a trust list, which can download updates to the
root store, and to the blacklist store too.

With this list you can switch on and of CAs, trust bits.

And of-course some courage is needed to put big CA on the black
list... :)

regards, Viktor Varga

[Michael Ströder]

Eddy Nigg wrote:
> On 04/13/2011 02:10 AM, From Kirk Hall:
>> With a Browser CRL under the First Proposal, clients would not have to
>> check OCSP (unless they want to ), and so the CA would not know which
>> websites you are visiting - less of a privacy concern.
>
> Just a note on that one, if a CA would be really interested in that, it
> could include unique CRL DPs on a per certificate basis. Not much more
> difficult than an OCSP responder.

Good point. But unique CRL DPs would also be an obvious privacy issue
recognizable by the interested public.

Ciao, Michael.

[Eddy Nigg]

On 04/24/2011 03:51 PM, From Michael Ströder:

> Good point. But unique CRL DPs would also be an obvious privacy issue
> recognizable by the interested public.

Probably, but you couldn't prevent it. And neither with OCSP...but which
really leads to the question if you trust CAs in this respect. For some
you probably will, for some others not - and I have my guesses to that ;-)

[Erwann Abalea]

On 13 avr, 01:18, Eddy Nigg <eddy_n...@startcom.org> wrote:
> On 04/13/2011 02:10 AM, From Kirk Hall:
>
> > With a Browser CRL under the First Proposal, clients would not have to
> > check OCSP (unless they want to ), and so the CA would not know which
> > websites you are visiting - less of a privacy concern.
>
> Just a note on that one, if a CA would be really interested in that, it
> could include unique CRL DPs on a per certificate basis. Not much more
> difficult than an OCSP responder.

How would you do that? Create CRL partitioned by serialNumber, one for
each S/N, use the correct extension for it, and hope clients will be
able to deal with it?
If you limit the scope of your CRLs, the client MUST be told so.

--
Erwann.

[Eddy Nigg]

On 04/26/2011 05:56 PM, From Erwann Abalea:

> How would you do that?

Very easy....

> Create CRL partitioned by serialNumber, one for
> each S/N, use the correct extension for it, and hope clients will be
> able to deal with it?

Just include a CRL DP URI like http://supertrusted.ca/1234567.crl in the
certificate, obviously every certificate has its own CRL DP.

> If you limit the scope of your CRLs, the client MUST be told so.

There is no limitation as far as I can see.

[Rob Stradling]

On Tuesday 26 Apr 2011 16:00:29 Eddy Nigg wrote:
> On 04/26/2011 05:56 PM, From Erwann Abalea:

> > How would you do that?
>

> Very easy....

>
> > Create CRL partitioned by serialNumber, one for
> >
> > each S/N, use the correct extension for it, and hope clients will be
> > able to deal with it?
>

> Just include a CRL DP URI like http://supertrusted.ca/1234567.crl in the
> certificate, obviously every certificate has its own CRL DP.

Yes and no. RFC5280 says...

From Section 5:
Each CRL has a particular scope. The CRL scope is the set of
certificates that could appear on a given CRL. For example, the
scope could be "all certificates issued by CA X", "all CA
certificates issued by CA X", "all certificates issued by CA X that
have been revoked for reasons of key compromise and CA compromise",
or a set of certificates based on arbitrary local information, such
as "all certificates issued to the NIST employees located in
Boulder".

Also from Section 5:
Conforming applications are not
required to support processing of delta CRLs, indirect CRLs, or CRLs
with a scope other than all certificates issued by one CA.

From Section 5.2.5:
The issuing distribution point is a critical CRL extension that
identifies the CRL distribution point and scope for a particular CRL,
and it indicates whether the CRL covers revocation for end entity
certificates only, CA certificates only, attribute certificates only,
or a limited set of reason codes. Although the extension is
critical, conforming implementations are not required to support this
extension. However, implementations that do not support this
extension MUST either treat the status of any certificate not listed
on this CRL as unknown or locate another CRL that does not contain
any unrecognized critical extensions.

So yes, each certificate can have it's own unique CRL DP URI, but only if each
corresponding CRL contains the same URI in a critical Issuing Distribution
Point (IDP) extension.

Last I heard, NSS doesn't support the IDP extension.
https://bugzilla.mozilla.org/show_bug.cgi?id=309585

So I'm afraid it's not "very easy" and there is certainly no "obviously". I
lost count of how many times I read the relevant parts of RFC5280 and X.509
before I dared to conclude that I'd grasped what it was trying to say. Wan-
Teh told me once that he found these parts of the specs to be "impenetrable".

> > If you limit the scope of your CRLs, the client MUST be told so.
>

> There is no limitation as far as I can see.

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.

[Erwann Abalea]

On 26 avr, 17:00, Eddy Nigg <eddy_n...@startcom.org> wrote:
> On 04/26/2011 05:56 PM, From Erwann Abalea:
>
> > How would you do that?
>
> Very easy....
>
> >   Create CRL partitioned by serialNumber, one for
> > each S/N, use the correct extension for it, and hope clients will be
> > able to deal with it?
>

> Just include a CRL DP URI likehttp://supertrusted.ca/1234567.crlin the

> certificate, obviously every certificate has its own CRL DP.

The CRL is the list of revoked certificates, it is issued by the CA,
so it's attached to the CA, not to that particular end-user
certificate.

The application's job is to get enough CRLs to cover a sufficient
scope to make a decision about the revocation status. A sufficient
scope might be:
- "all the issued certificates", that's the default case, when you
don't specify any scope in the CRL, or when the CRL segmentation is
done on revocation reason (in that case, you'll have to get the
different CRLs covering all the different revocation reasons)
- "all the user certificates", that's triggered when the
issuingDistributionPoint extension sets the onlyContainsUserCerts flag
- "all the CA certificates", that's triggered when the
issuingDistributionPoint extension sets the onlyContainsCACerts flag
- "all the certificates with serial number ranging from x to y
(modulo z)", that's triggered by the cRLScope extension (defined in
2005 edition of X.509, at least, but declared as deprecated, and not
defined on RFC5280)

If you've got a large CA, using the onlyContainsUserCerts flag won't
have any effect on CRL size, compared to a full one.

> > If you limit the scope of your CRLs, the client MUST be told so.
>
> There is no limitation as far as I can see.

If the verifier gets a CRL to verify one certificate, and this
certificate isn't declared as a "reduced scope" one, then it can store
it in cache (it's the revocation list of all the certificates issued
by the considered CA, not the revocation status of this exact end-user
certificate). The same application, verifying another certificate, can
legitimately look in its store, get the previously seen CRL, and try
to find the new certificate's serial number in this CRL. If you
haven't limited the scope of your CRL, that verification will fail.

--
Erwann.

[Erwann Abalea]

On 26 avr, 17:42, Rob Stradling <rob.stradl...@comodo.com> wrote:
> So yes, each certificate can have it's own unique CRL DP URI, but only if each
> corresponding CRL contains the same URI in a critical Issuing Distribution
> Point (IDP) extension.

I don't think that having a match between URIs in
issuingDistributionPoint and cRLDistributionPoints extension changes
the scope of the CRL.

--
Erwann.

[Eddy Nigg]

On 04/26/2011 06:42 PM, From Rob Stradling:

>> Just include a CRL DP URI like http://supertrusted.ca/1234567.crl in the
>> certificate, obviously every certificate has its own CRL DP.
> Yes and no. RFC5280 says...
>

However you turn it, my point was to illustrate that the privacy
concerns about OCSP are moot. A CA can include a different CRL DP for
every end user certificate, even it would serve always the same CRL. At
least I can't find anything that could prevent a CA from doing that, do you?

[Rob Stradling]

On Tuesday 26 Apr 2011 18:39:09 Erwann Abalea wrote:
> On 26 avr, 17:42, Rob Stradling <rob.stradl...@comodo.com> wrote:

> > So yes, each certificate can have it's own unique CRL DP URI, but only if
> > each corresponding CRL contains the same URI in a critical Issuing
> > Distribution Point (IDP) extension.
>

> I don't think that having a match between URIs in
> issuingDistributionPoint and cRLDistributionPoints extension changes
> the scope of the CRL.

I'm not sure what you mean by "changes the scope".

When a CRL contains the IDP extension and that IDP extension contains the
optional distributionPoint field, that distributionPoint defines an arbitrary
scope for the CRL.
Certs that contain the CDP extension with a matching distributionPoint URI are
in scope for that CRL.
Certs that contain the CDP extension without a matching distributionPoint URI,
or which don't contain the CDP extension at all, are out of scope for that
CRL.

If you're saying that I'm wrong, then how would you construct certs/CRLs such
that a CRL's scope is "all certificates issued to the NIST employees located
in Boulder" or some other "arbitrary local information"?

RFC5280 says:
Each CRL has a particular scope. The CRL scope is the set of
certificates that could appear on a given CRL. For example, the
scope could be "all certificates issued by CA X", "all CA
certificates issued by CA X", "all certificates issued by CA X that
have been revoked for reasons of key compromise and CA compromise",
or a set of certificates based on arbitrary local information, such
as "all certificates issued to the NIST employees located in
Boulder".

> --
> Erwann.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Erwann Abalea]

(testing the new Google Groups interface, don't blame me if message formatting is buggy, I'm sure it will be)

Oh, I see.
Your point was to set different CRLDP (one for each produced certificate), to get access to the exact same CRL (a full scope one), to easily see "who checks who". In that scenario, then you're right, nothing prevents a CA from doing this. Weird, but compliant with the standard.

[Erwann Abalea]

[Rob Stradling]

On Tuesday 26 Apr 2011 18:45:25 Eddy Nigg wrote:
> On 04/26/2011 06:42 PM, From Rob Stradling:

> >> Just include a CRL DP URI like http://supertrusted.ca/1234567.crl in the
> >> certificate, obviously every certificate has its own CRL DP.
> >
> > Yes and no. RFC5280 says...
>

> However you turn it, my point was to illustrate that the privacy
> concerns about OCSP are moot. A CA can include a different CRL DP for
> every end user certificate, even it would serve always the same CRL. At
> least I can't find anything that could prevent a CA from doing that, do
> you?

AFAIK, you are correct that nothing prohibits a CA from including a different
CRL DP URI in every end-entity cert, as long as all of those URIs point to
exactly the same (non-IDP) CRL file.

Do any CAs do this? (I imagine the EFF Observatory data could tell us). If
yes, then I agree that it's as much a privacy concern as OCSP. If no (as I
suspect), then it's only a theoretical privacy concern.

There's actually an incentive for CAs to *not* do this. The Windows CryptoAPI
cache treats identical CRL files that are downloaded from different URIs as
different objects. Using a different CRL DP URI in every cert would render
this caching decidedly ineffective, and would therefore increase the bandwidth
requirements and the cost to the CA for serving CRLs.

[Eddy Nigg]

On 04/27/2011 12:05 AM, From Rob Stradling:

> There's actually an incentive for CAs to *not* do this.

Oh, I can refine it if you want. Just read the http header and log the
access in your DB, then redirect 301 to the real CRL URI.

[Rob Stradling]

On Tuesday 26 Apr 2011 22:10:59 Eddy Nigg wrote:
> On 04/27/2011 12:05 AM, From Rob Stradling:

> > There's actually an incentive for CAs to *not* do this.
>

> Oh, I can refine it if you want. Just read the http header and log the
> access in your DB, then redirect 301 to the real CRL URI.

I don't think that would alter the caching behaviour, I'm afraid. IIRC, the
CryptoAPI CRL cache is keyed by the SHA-1 hash of the CRL DP URI listed inside
the certificate.

[Jean-Marc Desperrier]

Rob Stradling wrote:
> The Windows CryptoAPI
> cache treats identical CRL files that are downloaded from different URIs as
> different objects. Using a different CRL DP URI in every cert would render
> this caching decidedly ineffective, and would therefore increase the bandwidth
> requirements and the cost to the CA for serving CRLs.

> IIRC, the

> CryptoAPI CRL cache is keyed by the SHA-1 hash of the CRL DP URI listed inside
> the certificate.

So it would increase the bandwidth, but only when the entity is
verifying a number of different certificates issued from the same CA, so
maybe not that much.

OTOH it has the side effect of making the spying described by Eddy a lot
more effective, because if cert A has a CRLDP of
http://supertrusted.ca/1234567.crlin and cert B has a CRLDP
http://supertrusted.ca/1234568.crlin, pointing in fact to the same
binary CRL, it will be downloaded twice even though this should not be
necessary, even though cert B could perfectly have been validated using
the already downloaded CRL of cert A.