RE: RE: PKIX Part 2 - Revised Draft

["Paul Turner"<turnerp@xxxxxxxxxx>]

Since the relying party is going to be interested in knowing what the
revocation status of a certificate status was at a given time, based on
when the document that they are verifying was signed with the private key,
OCSP requests should include a "DateToCheckRevocationStatus" parameter.
This will allow a relying party who is verifying the signature on a
document that may have been signed months or years ago to determine whether
the private key used to sign the document was valid at the time the
signature was applied.  This capability is crucial from a legal and
business perspective since old digitally signed documents are undoubtedly
going to need to be relied upon, and individuals/organizations will
probably not want to go around hunting for an old CRL.

True, some OCSP service providers will not want to archive all of the old
CRLs to provide this level of service but they can simply respond with
"SERVICE UNAVAILABLE".

In addition, OCSP responses should probably include a
"DateCheckedForRevocationStatus" so that the relying party has a signed
response from the OCSP service provider attesting the revocation status and
the date that the status was checked.

Paul Turner
CertCo LLC - www.certco.com

turnerp@certco.com
801.553.7709
FAX 801.553.1764





sharon.boeyen@entrust.com on 08/07/97 06:00:37 AM

To:   dpkemp@missi.ncsc.mil, ietf-pkix@tandem.com, mfsmith@zionsbank.com
cc:   S814FSB@zionsbank.com, S814JZF@zionsbank.com (bcc: Paul
      Turner/CERTCO/US)
Subject:  RE: RE: PKIX Part 2 - Revised Draft




I agree that leaving revocation entries on a revocation list past the
expiry date doesn't achieve non-repudiation, nor is it intended to.
Notary and timestamping services are required in non-repudiation and the
new parts of PKIX are addressing this. It is worth looking at the use of
these new parts in the context of part 2 however.

Enabling revocation entries to remain on revocation lists beyond their
expiry date is a useful feature in many current environments where
timestamping and notary services are not deployed. As indicated by Peter
in his earlier message, this requires no additional standardization and
can be achieved within the existing set. There is no intention that this
any substitute for notary services though and on that I believe we are
all agreed.
------------------
Sharon Boeyen
Entrust Technologies

mailto:boeyen@entrust.com       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security


>----------
>From:    Mike Smith[SMTP:mfsmith@zionsbank.com]
>Sent:    August 6, 1997 3:10 PM
>To:      dpkemp@missi.ncsc.mil; ietf-pkix@tandem.com
>Cc:      S814FSB@zionsbank.com; S814JZF@zionsbank.com
>Subject:      Re: RE: PKIX Part 2 - Revised Draft
>
>Note:  the time and date (notarization in previous message) would also
need
>to be attached securely to
>
>>>> David P. Kemp <dpkemp@missi.ncsc.mil> 08/06/97 10:04AM >>>
>> From: Sharon Boeyen <sharon.boeyen@entrust.com>
>>
>> Peter, there's another to handle it as well without any standardization.
>> Using distribution points, once all the certs pointing to a certain
>> distribution point have passed their expiry date, you can consider that
>> distribution point an "old" crl.
>
>Am I missing something?  Isn't there more to non-repudiation than
>just archiving old CRLs?
>
>There must be some evidence that the certificates and CRLs were valid
>as of the signature date - notarizing them is one method of achieving
>this.  But if you have a notarized copy of the old CRL, why do you need
>an archived (unprotected) copy?
>
>(A CRL archive might be necessary with a "publish-the-hash-tree-in-a-
>newspaper" type scheme, but is that what is being discussed here?)
>
>
>
>
>
>
>
>
>
>
>
>
>                                                     !
>
>
>
>
>
>