Firefox behavior with CDPs and AIAs

[r.an...@computer.org]

I know that FF allows you to choose a CRL and it will check status against that CRL when it finds a cert issued by the CRL issuer. Does anyone know if FF uses the CDP in the cert or the cert's issuer name as a key to find the CRL?

The reason I ask is in regards to partitioned CRLs, where a CA could, for example, have one CRL for odd serial numbers and one for even. The CA would put the appropriate CDP in each cert, but would that confuse FF?

Same question about OCSP responses and AIA.

Does anyone know the answers for IE?

[Ian Melven]

you might also try asking this on mozilla.dev.tech.crypto :)

thanks,
ian

_______________________________________________
dev-security mailing list
dev-se...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

[Rick Andrews]

Sid Stamm suggested dev.security...

> -----Original Message-----
> From: Ian Melven [mailto:ime...@mozilla.com]
> Sent: Thursday, April 11, 2013 1:22 PM
> To: r andrews
> Cc: dev-se...@lists.mozilla.org
> Subject: Re: Firefox behavior with CDPs and AIAs
>
>
> you might also try asking this on mozilla.dev.tech.crypto :)
>
> thanks,
> ian
>
>
> ----- Original Message -----
> From: "r andrews" <r.an...@computer.org>
> To: dev-se...@lists.mozilla.org
> Sent: Thursday, April 11, 2013 12:25:17 PM
> Subject: Firefox behavior with CDPs and AIAs
>

[Daniel Veditz]

On 4/11/2013 1:26 PM, Rick Andrews wrote:
> Sid Stamm suggested dev.security...
>
>> -----Original Message-----
>> From: Ian Melven [mailto:ime...@mozilla.com]
>>

>> you might also try asking this on mozilla.dev.tech.crypto :)

Sid was wrong :-) The guys who know the technical guts of our crypto
implementation are over in m.d.tech.crypto

AFAIK we do not download CRLs based on certs, but will update CRLs the
user has manually specified. We've talked about improving CRL handling
as part of a comprehensive reform of revocation checking but have yet to
solve the performance and space requirements of CRLs.

We do support OCSP and are in the process of adding support for OCSP
stapling to improve performance, security, and privacy. Lack of an OCSP
response is not fatal however, because in general OCSP has not been
reliable enough for that. However, cautious users can change the mozilla
pref security.OCSP.require to true if they wish the lack of an OCSP
reponse to be fatal.

For anything more detailed (timelines, bug numbers) you'll need to go
bug the .tech.crypto folks.

-Dan Veditz

[Camilo Viecco]

It is possible (but not supported) to use have FF download the CRLs specified
by the certificate.

There are (of course) many caveats:

1. This is enabled by changing several hidden prefs (which mean we might change
them at any time without notifying our users).
2. Downloading is not the same as requiring fresh revocation information for all
connections.
3. If you require fresh revocation info you will have issues with certificates without
revocation information (such as self signed and business CAs) since they will be treated
as revoked and no override will be possible.
4. You will find some bugs on the certificate UI.
5. The code is not as tested as the rest of the FF and this is potentially more buggy.
6. There will be a non-trivial performance hit (specially network bases) as some CRLs
are >500k and these entries are not cached across sessions (no peristent cache). This
might not be an issue if you have good network connections (no mobile).

Without more due, here are the invocations to be added to your about:config.
(not recomented for defaults for the reasons listed above.)

bool pref: security.use_libpkix_verification: true //enables alt verification lib
bool pref: security.CRL_download.enabled: true //enables crl download in libpkix only!
bool pref: security.fresh_revocation_info.require : true // revocation info mandatory in libpkix only

Hope this helps

Camilo

----- Original Message -----
From: "Daniel Veditz" <dve...@mozilla.com>
To: dev-se...@lists.mozilla.org
Sent: Thursday, April 11, 2013 3:31:03 PM
Subject: Re: Firefox behavior with CDPs and AIAs

[r.an...@computer.org]

Thanks; I had already posted this to dev.tech.crypto...

[Daniel Veditz]

On 4/11/2013 5:16 PM, r.an...@computer.org wrote:
> Thanks; I had already posted this to dev.tech.crypto...

Oh, sorry then. I looked before replying and didn't see it, guess it's
an unreliable feed.

-Dan Veditz

[Daniel Veditz]

On 4/11/2013 5:12 PM, Camilo Viecco wrote:
> It is possible (but not supported) to use have FF download the CRLs specified
> by the certificate.
>
> There are (of course) many caveats:

Which is why we don't support it.

> 6. There will be a non-trivial performance hit (specially network bases) as some CRLs
> are >500k and these entries are not cached across sessions (no peristent cache). This
> might not be an issue if you have good network connections (no mobile).

yes, the biggie: even though CRLs are valid for a quite a while we don't
cache them across restarts. Maybe not so bad if you never shut down your
browser

> bool pref: security.use_libpkix_verification: true //enables alt verification lib

Yes, note that CRL download support is only available as part of the
not-yet-supported libpkix verification path. It's quite a bit bigger
than just CRL downloads, this uses a completely different library to
verify certificates. Libpkix is not entirely untested: Firefox uses it
for EV certs, and Chrome uses it for everything. But last time I looked
into it (months ago) there were bugs that were deemed bad enough that we
weren't ready to turn it on in Firefox.

> bool pref: security.fresh_revocation_info.require : true // revocation info mandatory in libpkix only

How does this interact with the security.ocsp.require pref? Do they
conflict? Play well together? Or simply unrelated, one applying to the
old path and one to libpkix?

-Dan Veditz

[r.an...@computer.org]