Re: [IETF-PKIX] OCSP Status Information on a Certificate

[Marc Branchaud <marcnarc@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


"Alexei V. Vopilov" <alx@elnet.msk.ru> scrawled:
>
> =======Marc Branchaud posted:
> [. . .]
> :
> :One thing this exercise has showed me is that "unknown cert" is really a
> :useless response value, since it is either bogus or subsumed by other values
> :(like "unknown CA").
>
> Should "unknown" statuses be read as followed?
>
> Revocation =  "NotAvailable" // cannot access to CRL information
>               "UnknownCA"    // cannot access to unknown CA database

Well, setting aside the issue of whether multi-valued responses are a good
idea or not, I would argue that the above two cases are equivalent.

If the responder can't access the proper CRL information, it's because it
hasn't collected the CRLs from the CA and so it basically doesn't recognize
the CA.  The same argument applies to responders with direct access to a
CA's database.

Come to think of it, there could be a situation where a responder holds an
expired CRL for which it has yet to receive a replacement.  One might argue
that a "NotAvailable" response would be OK, but I think it would be better
to provide a response based on the expired CRL, perhaps accompanied by some
kind of warning.

> Expiration =  "NotAvailable" // cannot access to known CA database _contents_
>               "UnknownCA"    // cannot access to unknown CA database

Expiration is independent of the contents of a CA's database or even the
recognition of the CA by the responder.  The only time the responder would
reply with an "unknown" expiration value is if it doesn't actually perform
the expiration calculation.  This calculation can be performed for _any_
certificate, so whether an unknown response is made is really just a matter
of how the responder is configured.

So, once again, I think a single kind of "unknown" response is adequate
here.

> Issued     =  "NotAvailable" // cannot access to known CA database _directory_
>               "UnknownCA"    // cannot access to unknown CA database
>

This is where complexity is justified, because a responder using only CRLs
can not know if an unrevoked certificate has ever been issued (revoked
certs, on the other hand, are known to have been issued).  So I agree that
these two kinds of "unknown" responses are a good thing.  The "NotAvailable"
response would be given by responders that only have CRL information (for
the given CA).  A responder with direct access to the CA's database shouldn't
normally use the "NotAvailable" response.

> Having this a Responder implementation can support only part of
> specification without interoperability problems.
> Note there is the difference between "NotAvailable" semantic for
> Expiration and Issued statuses.
>
> Note also that nothing (according to spec design)
> prevents implementing an OCSP Responder by extending CRLs
> issued by a CA (or by just ignoring them at all).
>

I'm not sure what you mean by this.  Could you elaborate?

As for the bigger picture, I'm still not convinced either way about whether
or not OCSP should have multi-valued responses.  I think the extra
complexity is manageable, but I also see the appeal of a simpler protocol.
It really depends on what people want to do with OCSP.  Are the issued/
unissued and expired/unexpired values needed?

I do think they're more marginal.  If the cert's signature verifies, then
it's a good bet that the cert was issued.  As for expiration, a client would
have to be pretty thin to not have a clock.

                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

iQB1AwUBNTY4yVrdFXNdDxPlAQGOkQMAlU1Xs3Sil/119qBXASuMUtv27pMDoJr8
ZZit37F7BsZZPITyEB9/NZ1/gJ6VC+zU4tM5Nygf8WqnGX9BkCxGvjVFJTP5K+/F
6+1zmjhz6Yqij5UcTm2Aqbsuay6PIT1W
=Ly0I
-----END PGP SIGNATURE-----