Subject: AW: OCSP concept question

From: [email-masked]
Date: Wed, 7 Aug 2002 11:03:06 +0200

I am not an OCSP expert as well but fortunately yesterday I read something
about the structure of OCSP responses.
I cross checked it with RFC 2560.
There a sequence containing the revocationTime is defined.
Having in mind, that an OCSP responder does in general nothing else but
checking a CRL and forwarding the requested information I cannot see a
difference between the usage of CRLs and OCSP but the neccessity of retrieve
actual CRLs.

Regards

Thomas Beckmann
 -------------------------------------
 Thomas Beckmann
 Fachgruppenleiter PKI und Trustcenter
 SchlumbergerSema -
 Competence Center Informatik GmbH 
 Lohberg 10 - 49716 Meppen - Germany
 tel: +49 5931-805-242
 mobil: +49 170 2802 343  
 fax: +49 5931-842-242
 mail: [email-masked]

> -----Ursprüngliche Nachricht-----
> Von: Haaino Beljaars [mailto:[email-masked]]
> Gesendet: Sonntag, 4. August 2002 15:48
> An: [email-masked]
> Betreff: OCSP concept question
> 
> 
> 
> Hi,
> 
> Hopefully somebody can help me with the follwoing questions 
> and remarks:
> 
> I send a signed message to person A, person A checks the 
> status of my certificate on time T by an OCSP request, and 
> the status of my certificate is 'good' according to the OCSP 
> response. At time T+1 my certificate is revoked. Person A 
> checks my message again at time T+2.
> 
> Question: what does the OCSP responder give back as status at T+2 ?
> 
> * If the OCSP responder gives back 'revoked' at time T+2, 
> then that is correct at that moment in time, but it is wrong 
> when you look at the time(T) when the message was signed, 
> because the message was signed when the certificate status 
> was still good.
> 
> * If the OCSP responder gives back 'good': this indicates 
> that an OCSP has as a 'history' function. As far as I can 
> read this is not the case in the OCSP RFC.
> 
> If person A check the message against a CRL it would indicate 
> at time T+2 that the certificate was good at the moment of 
> signing, this is because a CRL contains time and date when a 
> certificate was revoked, but an OCSP response does not 
> contian that information.
> 
> According to this 'analysis' I get different answers 
> concerning the status of a certificate when I concult a CRL or OCSP?
> 
> Why doesn't an OCSP response contain date and time when a 
> certificate was revoked? 
> 
> And why doesn't an OCSP response contain a signed time? How 
> can I check that the time the OCSP responder gives back is correct?
> 
> Best regards,
> Haaino
>

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 08 Aug 2002 11:01:50 +0200

Gene Hilborn a dit :

>While both CRLs and OCSP have a defined syntax for conveying the
>information of WHEN a certificate was revoked, neither is required to
>indefinitely maintain this information as an historical record.
>
>RFC 2459 does not require or recommend archiving revocation after expiry:
>"An entry may be removed from the CRL after appearing on one regularly
>scheduled CRL issued beyond the revoked certificate's validity period."
>
>RFC 2560 makes such archival information optional for OCSP:  'An OCSP
>responder MAY choose to retain revocation information beyond a
>certificate's expiration. The date obtained by subtracting this retention
>interval value from the producedAt time in a response is defined as the
>certificate's "archive cutoff" date.'
>
>Thus, since CRLs and OCSP responders are not normally set up as historical
>archives, they do not facilitate determining if and when a certificate was
>revoked when they are consulted long after the expiry date on the
>certificate.
>
Which is why in my first answer, I said that the responder should better 
check the information as soon as it receives the signature and save the 
response it received.

But still taking care of how he handles the case where the certificate 
was just on hold.

---

From: Peter Williams <[email-masked]>
Date: Sun, 11 Aug 2002 05:23:14 -0700

Peter dice que:

(a) We need to differentiate between the OCSP (P for protocol)
and services supported by the protocol. IETF never
standardized any OCSP services, note, though some OCSP service
semantics are implicit in some of our standard protocols
and profiles. 

(b) We can specify an archival service whenever we get together, note.
It doesnt have to be pure-OCSP, either. I'm far more interested in
real working systems, than well-architected abstract protocols,
personally. I think we can get a lot more milage from
the Internet's current support for CRL syntaxes, by innovating
with the commodity components.

(c) on the matter of MUST, SHOULD etc, structured CRL archival has 
never been mandatory in IETF, but has always been a part of the 
Internet model. See 1422:

"In the absence of ubiquitous X.500 directory services, the IPRA will
require 
each PCA to provide, for its users, robust database access to CRLs for the 
Internet hierarchy, i.e., the IPRA CRL, PCA CRLs, and CRLs from all CAs. 
The means by which this database is implemented is to be coordinated 
between the IPRA and PCAs. This database will be accessible via email 
as specified in RFC 1424, both for retrieval of (current) CRLs by any user, 
and for submission of new CRLs by CAs, PCAs and the IPRA. Individual 
PCAs also may elect to maintain CRL archives for their CAs, but this is 
not required by this policy."
 
Peter.

----------

SIDE BAR: for folks interested possibly in new work
in OCSP-archival matters:

(1) S/MIME archival

An OCSP responder supporting digital signatures in
a TNI-TCSEC evaluated network can support the original TNI definition of
non-repudiation by maintain an email-style archive record.
To support the proof semantics of ProofOfOriginWithNR, the
OCSP responder originates for local storage a signed S/MIME msg 
whose contents are: validated signatures/on-source-CRLs, and whatever
supporting certs and other (recursive) data were used to 
determine revocation status of the cert on the certification path 
that  supported the possibly-indirect CRL. 

The OCSP responder is responsible for records mgt - that is, 
resigning the "repository document" (a legal term) to maintain its
currency as an easily verifiable authenticated record.
There is nothing new in any of this, of course. 

Lets recall that S/MIME is both a writer-to-reader
email standard and a set of reusable, nestable security 
procedures. (See some recent IETF work on harmonizing
Allied X.400 EITs with the underlying CMSyntaxes)

For example, I specified non writer-to-reader use of PKCS7 for
Cisco's SCEP, back with Alex in 1996. That certificate
management standard (de facto) is probably now the most 
widely-used, open, remote automated router key management mechanism
in the Internet, and is a credit to our collective product
design judgements about PKCS7/CMS! Alex's getCRL facility
addition is probably the most widely used IPSEC revocation-mechanism 
in the world! Microsoft's support for it works v nicely,
and was easy to modify so that a CRL partition of just
the requested cert status is dynamically generated 
interactively! This gets OCSP-like behaviour via CMS syntaxes
support into legacy IPSEC router stacks that only supports CRL
syntaxes.

But back to the main point and conclusion:

An OCSP response can communicate the S/MIME signed
NR-repository msg mentioned above, bearing its NR-relevant archive
information, in the OCSP response. Dont forget, OCSP is a
framework: profiles and future standards can add message types 
to the protocol. The better implementations are built to plug in support
for such protocol extensions, in fielded systems, providing
their services according to detection of a cert policy value
in the requestor's user cert.

(2)R&D Specification Offer

On a slightly different but related tack, I have some 
profiling  templates for specifying OCSP protocols and validation
services, for fully-modelled OSI application processes, if any 
LARGE, fun projects would like to take part in an academic 
specification experiment with me (at cs.ucl.ac.uk, not valicert) 
on this type of advanced OCSP  usage. You'd need really to need 
to be familiar with the full  nomenclature of the OSI application 
layer model, however, to use the results for certification purposes.

Peter.