RE: OCSP concept question

[Peter Williams <peterw@xxxxxxxxxxxx>]

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.


-----Original Message-----
From: Jean-Marc Desperrier
To: Gene Hilborn; ietf-pkix
Sent: 8/8/02 2:01 AM
Subject: Re: OCSP concept question


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.