[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETF-PKIX] OCSP Status Information on a Certificate
- To: IETF-PKIX@xxxxxxxxxxxxxxxx
- Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
- From: Marc Branchaud <marcnarc@xxxxxxxxx>
- Date: Fri, 17 Apr 1998 09:52:47 -0700
- Approved-by: Marc Branchaud <marcnarc@XCERT.COM>
- In-reply-to: Your message of "Fri, 17 Apr 1998 08:48:15 PDT." <>
- Reply-to: "IETF X.509-based public key infrastructure mailing list" <IETF-PKIX@xxxxxxxxxxxxxxxx>
- Sender: "IETF X.509-based public key infrastructure mailing list" <IETF-PKIX@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
Michael Myers <mmyers@VERISIGN.COM> scrawled:
>
> And in the event a client receives {is revoked, not issued}, which
I think you mean {is revoked, issued} here...
> dominates? Similarly, {not revoked, not issued}. I remain unconvinced this
> is no problem. As soon as OCSP clients are out there in any volume, there
> are those who will seek to determine the client's behavior in fringe cases.
>
I agree that the implications are not trivial. For one thing, as I've said,
a responder working solely with CRL information can not determine a
certificate's existance if the cert has not been revoked. One bit is not
enough to capture the semantics.
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marcnarc@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNTeI3lrdFXNdDxPlAQFnJQL8Cnti/rIncZp1o3IFfy2XeZPHQXluc8FO
8+KNr2FzAJQPeXWGovrZpp+6LoMRSJ1b+TWqLMdNSqlGin/CJtx2iHg6RkWgik40
b5gADHFKTv1BratoNpS4ZB07C9rp8/3d
=Rxae
-----END PGP SIGNATURE-----