Re: [Ejbca-develop] Include Archive Cutoff OCSP extension in all responses

[Tomas G. <to...@pr...>]

Hi Jaime,

The change makes sense to me. It must be optional however. Any behavior
change that changes behavior like this need to be optional.

We are in fact in the pipe-line of adding configuration of archive
cutoff to GUI configuration for the OCPS Key Binding. Value can be
different for differn4t key bindings, and needs to be more easily
configurable than in the properties file. I see then three options:
- never use archive cutoff
- always use archive cutoff
- use archive cutoff for expired certificates

As such, the patch, good it may be, does not make sens at this moment as
it needs to change soon.

Any possibility that you would work on your patch with this in mind?

Regards,
Tomas

On 2019-06-09 17:42, Jaime Hablutzel wrote:
> Hi, I think that always including the Archive Cutoff OCSP extension (if
> enabled) in responses would be really helpful. Now, some illustrative
> examples:
> 
> Status for a given certificate might not be available anymore (e.g.
> CertificateStatus.NOT_AVAILABLE), but it could have been good or revoked
> in the past, for example, for an expired certificate deleted after the
> retention interval got surpassed, so including the archive cutoff date
> warns clients of this possibility, which is specially important when
> "Non existing is good" is enabled, because the server could be
> responding good now for a deleted certificate previously revoked.
> 
> If certificate status is still available
> (CertificateStatus.REVOKED or CertificateStatus.OK), to provide the
> archive cutoff would help clients to learn the server retention
> interval, so they can realize until when the OCSP server guarantees to
> keep certificate status after expiration, e.g. a client might be
> planning to demonstrate in a trial (in a given date in the future) that
> a signature generated in the past was generated with a valid certificate
> and knowing the archive cutoff would be helpful for him to know until
> when that information will be available.
> 
> Now, quoting from RFC 6960, "4.4.4. Archive Cutoff":
> 
>     OCSP servers that provide support for such a historical reference
>     *SHOULD include an archive cutoff date extension in responses*.
> 
> 
> It doesn't say that the extension should be included only for
> certificates under a given criteria (e.g. only expired ones), it just
> say that if a server support historical reference (e.g. a regular EJBCA
> setup), the archive cutoff should be included in responses, where
> "responses" could be interpreted as "all responses" for the sake of
> always providing clients with this helpful information.
> 
> Finally, I’m attaching a proposed patch over r32508. Just note that
> introducing this patch would require changes in
> https://www.ejbca.org/docs/Archive_Cutoff.html, for example, the
> following wouldn't be true anymore:
> 
>     Archive Cutoff is only returned in the OCSP responses for expired
>     certificates.
> 
> 
> Jaime Hablutzel -  +51 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>