497184 - Add default OCSP responder for trustwave

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Johnathan Nightingale [:johnath]]

Brian Trzupek from trustwave says that they will soon be ready to enable a default OCSP responder for us, using the mechanism introduced in bug 485052.

The data structure that controls this is here:

http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSCallbacks.cpp#1058

So we just need that information (issuer name, issuer key ID, ocsp url) for each cert (including intermediates) that trustwave wants to have OCSP checking for using this mechanism.

Comment 1

[Eddy Nigg (StartCom)]

Is this the preferred way these days? How about implementing revocation checking correctly by including the OCSP URI in the certificate(s)?

Comment 2

[Paul Kehrer]

Hi Eddy,

This is definitely not the preferred method, but as of Firefox 3.5 all EV certificates require OCSP responders or else they are downgraded in the UI to OV/DV presentation.  You can see within the link provided by Johnathan that several CAs are providing hardcoded default OCSP responders for their roots/subroots.  This ensures that their existing end entity certificates (that do not have OCSP URIs embedded) will be unaffected by the changed behavior.

Comment 3

[Eddy Nigg (StartCom)]

Yes I know. Incidentally Nelson is trying to get CRLs working, since FF 3.5 has been somewhat delayed, maybe it's still possible. The lack of OCSP should then have no effect I believe.

Comment 4

[Paul Kehrer]

Here is the information requested:

KeyID: 42 32 b6 16 fa 04 fd fe 5d 4b 7a c3 fd f7 4c 40 1d 5a 43 af 
Issuer Name: SecureTrust CA
OCSP URL: ocsp.trustwave.com

I would be happy to produce the patch if someone can explain the format of the KeyIDs.  They appear to be base64 encoded binary blobs?

Comment 5

[Johnathan Nightingale [:johnath]]

Paul - that's right - base64 encoded blobs.  Will you require a second entry to validate any intermediate certs, or do they have their own OCSP responders specified in the cert?

Comment 6

[Paul Kehrer]

We shouldn't require any additional entries.  For the blob, could you elaborate on the method of generation?  I apologize if this is self-evident but I don't want to provide an incorrect encoding of the keyid.

Comment 7

[Johnathan Nightingale [:johnath]]

Kai will correct me if I'm wrong, but I believe that feeding the binary key id (perhaps by cat'ng a 20-byte file containing it) to a base64 encoder should do the trick.  It should be the binary Key ID that's encoded, not a string containing the characters '4', '2', '3', '2', etc.

Comment 8

[Paul Kehrer]

Attachment: Trustwave OCSP Default Responder

Comment 9

[Johnathan Nightingale [:johnath]]

Great, Paul. Is there a test page we should use to verify the patch works?

Comment 10

[Paul Kehrer]

Unfortunately I don't know the exact date that we'll have the responder publicly available, although we're working hard to have it within the next week.

Comment 11

[Paul Kehrer]

As of this time we have our OCSP responder available publicly at ocsp.trustwave.com.  I have also successfully built the branch using the submitted patch.  Due to the low impact nature of the change is there any chance of it making in before 3.5?  If Trustwave can assist in any way, please let me know.

Comment 12

[Paul Kehrer]

Some test sites: https://www.trustwave.com or https://ssl.trustwave.com

Comment 13

[Brian Trzupek]

Seeing as FF 3.0 currently supports the EV UI for our certificates, we feel it would benefit the Mozilla customer base if this treatment continues in 3.5. The patch has been tested and is of very minimal impact and we would enjoy your consideration of this patch prior to final release.

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

Hi Brian, sadly we've already done what we expect to be the final build for Firefox 3.5's final release, and the time required to rebuild with this patch included would require us to slip the schedule.

We'll consider and likely take the patch for the first stability update, Firefox 3.5.1.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Johnath: who's right to review this patch?

Comment 16

[Johnathan Nightingale [:johnath]]

Comment on attachment 383338 [details] [diff] [review]
Trustwave OCSP Default Responder

(In reply to comment #15)
> Johnath: who's right to review this patch?

kaie or rrelyea are the right reviewers for this component, but it's barely a code change - the most scathing review comment would be that it didn't fix the problem, but trustwave says this patch works for their test sites. 

I'll flag kaie for it.

Comment 17

[Johnathan Nightingale [:johnath]]

Comment on attachment 383338 [details] [diff] [review]
Trustwave OCSP Default Responder

I've tested this, confirm that it fixes the behaviour for trustwave. Since there is no real "code" change here, just an added piece of metadata, I'm going to give it my r+, but still check with kaie or rrelyea to make sure they're okay with me doing that, before landing.

I'd like to land this on 1.9.1.1 too - near-zero risk, enables EV for another CA who was being downgraded by our lack of CRLDP support.

Comment 18

[Johnathan Nightingale [:johnath]]

Comment on attachment 383338 [details] [diff] [review]
Trustwave OCSP Default Responder

Clearing approval request since this already blocks 1.9.1.1 - thanks Mike.

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

We need to firedrill a 3.5.1, moving this to 3.5.2 which will likely be first week of August.

Comment 20

[Paul Kehrer]

With such a trivial change (as Johnathan says in #17, near-zero risk), is there any chance this could make it into the firedrill release?  After missing 3.5 so narrowly it'd be a shame to miss the next release as well.

If that's not possible I do still appreciate the information regarding timeframe Mike!

Comment 21

[Johnathan Nightingale [:johnath]]

Landed on mozilla-central for baking, even if the baking is mostly academic for a metadata change like this.

http://hg.mozilla.org/mozilla-central/rev/69ebef6ff887

Will request approval to land on the 1.9.1 branch as soon as it reope

Comment 22

[Johnathan Nightingale [:johnath]]

Comment on attachment 383338 [details] [diff] [review]
Trustwave OCSP Default Responder

Requesting approval to land this on 1.9.1.2. There is
negligible risk here, and the upside is that we fix validation of certificates
for this CA.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 383338 [details] [diff] [review]
Trustwave OCSP Default Responder

a1912=beltzner

Comment 24

[Johnathan Nightingale [:johnath]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/bd3674407488

This has landed on the 1.9.1 stream, should be testable in tomorrow's nightly 1.9.1 builds, and should appear in Firefox 3.5.2 when it is released.

Comment 25

[juan becerra [:juanb]]

Paul, can you help us verify this in the 3.5.2 (build1) candidates?

Comment 26

[Paul Kehrer]

(In reply to comment #25)
> Paul, can you help us verify this in the 3.5.2 (build1) candidates?

I downloaded the build and can confirm that it is working as expected.

Comment 27

[Paul Kehrer]

If you'd like to test it directly you can visit https://sealserver.trustwave.com/seal.php

Comment 28

[juan becerra [:juanb]]

Thanks, Paul. Adding verified1.9.1 keyword, per comment #26.

For reference, I wanted to see the difference in behavior between 3.5 and 3.5.2, which is not apparent by visiting the sites mentioned here.