1009110 - (mozilla::pkix-CAs) For intermediate certs, don't accept OCSP responses that are more than 10 days old

Status: NEW

(Core :: Security: PSM, defect, P3)

Description

[Kathleen Wilson]

For compatibility reasons, bug #991815 was resolved by allowing OCSP responses in intermediate certs to be longer than 10 days old. This bug is to undo that.

https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
"6. OCSP responses must have a maximum expiration time of ten days. This applies to OCSP responses for intermediate certificates as well as end-entity certificates"

After a reasonable amount of time for CAs to update their intermediate OCSP responses, we should update mozilla::pkix to enforce that intermediate OCSP responses also be limited to 10 days old.

Comment 1

[Gervase Markham [:gerv]]

Kathleen: I thought that we decided in bug 991815 that, because once we have CRLsets, Firefox will not be checking OCSP for intermediates at all, we would not put a requirement on CAs to provide information we are not planning to use?

If we didn't agree that, I suggest that we should :-) Short OCSP timeouts are a good thing for the ecosystem, but I am concerned about the principle of us using our program requirements to require things from CAs on behalf of unnamed others rather than ourselves.

Gerv

Comment 2

[Kathleen Wilson]

I think it'll depend on when CRLsets actually get implemented.

Comment 3

[Kathleen Wilson]

Some good points were raised in the mozilla.dev.security.policy discussion forum...

https://groups.google.com/d/msg/mozilla.dev.security.policy/aAEI3IkE3aI/vtyst2TmoxcJ
"<=12 months are permitted so that CAs don't have to access their offline root keys frequently, so I think you should expect a backlash from CAs that would consider it onerous to have to access their offline root keys every <=10 days."
and
"This is especially true in the federal space where some intermediates
are stored offline most of the time.  Per Section 4.9.7 of the FBCA CP,
these CAs use a 31-day interval for status information.  Bringing the CA
online to generate responses every 10 days will actually make those CAs less
secure."

So, we should wait on this bug until the Baseline Requirements have been updated to take this under consideration. 

If the BRs are updated to incorporate a related change (and corresponding effective date), then we can add code to enforce it (if we are still checking intermediate OCSP responses at that time).

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I thought the practice was to pre-generate a year's worth of responses once a year, and then use whatever response corresponds to the current date as the year progresses? Making this change wouldn't require that the root key be accessed more frequently - there would just need to be more responses generated at a time.

Comment 5

[Rob Stradling]

(In reply to David Keeler (:keeler) from comment #4)
> I thought the practice was to pre-generate a year's worth of responses once
> a year, and then use whatever response corresponds to the current date as
> the year progresses?

Some CAs already do this, but it could be a fairly large implementation task for those CAs that don't already do it.  (Disclaimer: I wrote the code that Comodo uses to do exactly this).

Comment 6

[Kathleen Wilson]

Removing from the dependency list for Bug #1009102 -- "(mozilla::pkix-CAs) CA compatibility issues that affect mozilla::pkix"
I would like to use the dependency list in that Bug to identify the things that we want to actively get CAs to fix, and then take out the work-arounds in the code.

Because to require this would require either changing BR #3.2.2, or adding a new requirement to Mozilla policy.

Also, now that we have OneCRL, perhaps this bug isn't relevant anymore, and should be close.