RE: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >[Piyush]  From an RP's perspective finding status of serial numbers
> >serves no purpose unless they can associate that serial number with a
> >certificate.
> 
> Absolutely, that is the client's perspective of this.

Great. We agree
> 
> >When an OCSP client extracts the serial number from a certificate and
> >sends it the responder to determine the status, it is acting under a
> >very important assumption - the CA has issued that certificate and that
> >it has issued only one certificate with that serial.
> 
> Absolutely
Great. We agree.  
Let me reiterate -OCSP client extracts the serial number assuming that the
CA issued the certificate and issued only one certificate with that serial
number. So why do we need the responder to return non-issued for the same
certificate?

> 
> >If you say that this assumption is invalid, your trichotomy of serial
> >status is not mutually exclusive any more. Same serial can now be
> >associated with a good, revoked and non-issued status.
> 
> I didn't say that. I said it can "only be good, revoked or non-issued"
> Notice the difference? My sentence contains the word "or", yours the word
> "and".

I stand by my words :).

> These are the three possible states of a serial number. It must always be
in
> ONE of these states.
As long as you assume that a certificate signed by the CA cannot be
non-issued i.e. CA knows what certificates it issued.
If you break that assumption, you have to deal with the possibility of
different certificates with same serial numbers (after all certificates are
getting issued without CA's knowledge). This implies that the same serial
number can be associated with a good certificate and a non-issued
certificate.

Let me frame it in a different way. If you get a "good" response from a
responder that issues "revoked" for "non-issued", can you be sure that the
certificate you are checking is not a non-issued certificate? 


> 
> >And also the client cannot be sure if
> >the CA delegated responder's certificate is good or non-issued. This
> >renders OCSP completely useless.
> 
> I did not talk about responder certificates.

You did not. But that does not make my statement any less relevant or
incorrect and strengthens Henry's point about this spec achieving what it is
trying to do.








[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]