Stefan,
I don't think that we have any gaps in the technical understanding of this
proposal. Based on the discussions over the last few months, I can
confidently say that the difference of opinion is around the benefits of
adoptions and the costs associated with it.
Here are the possible goals that had been discussed
1) Address CA compromise issue
2) Provide certificate white list/black list information to the clients
3) Allow CAs to return revoked for non-issued. Some clients in some
situation benefit by not falling back to CRL validation.
I understand that according to you, 3 is the only goal for this update. So I
am basing the following on that goal
Benefits
~~~~~~~
- In some situations, It allows clients to reject some (not all)
fraudulently issued certificates that are and not detected by the CA.
- It allows buggy clients sending incorrect serial number to detect the bug.
(This is based on your last post, but I don't think that you seriously
consider this a benefit :))
Limitations
~~~~~~~~
- Works only if attacker fraudulently issued a certificate with a serial
that is not associated with a good certificate.
- Works only if attacker did not fraudulently issued a responder
certificate.
- Works only if client is configured to use OCSP as primary validation
option
- Works only if responder is not a CRL based responder.
- Works only if responder is producing live responses.
Cons (this is where we have the disagreement)
~~~~
- Stated goal leaves it to the imagination of readers to figure out the
problem that is being tackled.
- Provides false sense of security. Readers may believe that it addresses CA
compromise issue.
- Challenges the fundamental assumption behind x.509 processing that
certificate signature and certificate issuance are equivalent.
- Leaves the clients to deal with the paradox of responder trust if they
choose to interpret the response as meaning non-issued as opposed to revoked
- It's a change in the main document, so every implementer will have to go
through it even though the benefit is very limited to specific scenarios.
- The unintended consequence is that people will incorrectly start believing
that CRLs are less secure that OCSP.
- The draft exceeds the stated goal in the abstract (protocol useful in
determining the current status of a digital certificate without requiring
CRLs)
I understand that you don't see the cons listed above as major problem.
Your position is that it does not affect any other deployments except the
CAs who want to support it. That is technically correct, but the side effect
of this explicit endorsement from pkix is that the proponents start touting
this as the secure solution that needs to be adopted by everyone. They don't
have the luxury/motivation to look at pkix discussions to understand the
limitations of this approach.
As an example, there was a proposal in CAB forum to move away from CRL based
responders. Thankfully, a few vendors who have heavily invested in
pre-signed OCSP infrastructure voted against it.
On a final note, I understand there are facts and there are opinions and
this particular instance there are opinions galore (including mine:) ).
I suggest we move on, and let the IETF decide. I don't think our opinions
will converge with any more discussion. We'll have lot more data in a few
years to evaluate the diverse opinions that were presented in this WG. There
is always the option of coming out with another update if things don't go as
planned :).
-Piyush
-----Original Message-----
From: Stefan Santesson [mailto:stefan(_at_)aaa-sec(_dot_)com]
Sent: Saturday, April 13, 2013 4:24 PM
To: Piyush Jain; 'Henry B. Hotz'
Cc: pkix(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509
Internet Public Key Infrastructure Online Certificate Status Protocol -
OCSP)
to Proposed Standard
On 4/13/13 8:56 PM, "Piyush Jain" <piyush(_at_)ditenity(_dot_)com> wrote:
[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?
Because of your lack of fantasy :)
Shift your focus from the client to the server.
A client have control over never asking for a non-issued certificate,
unless
the CA is broken.
The server have not.
A bad, broken or malicious client may for what ever reason it may have,
send
a request for a non-issued certificate.
If that happens, the protocol should allows ways to handle that.
Just imagine a such benign situation of a client with a bug, that sends
the
wrong serial number if the most significant bit is set.
For half of it's requests it sends requests for completely non existent
certs.
Perhaps not likely, but possible.
The chance of discovering this error increase significantly if the
non-issued
serial number requests returns "revoked" instead of "good".
This just on top of the case of a broken CA.
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 :).
Feel free. But saying a million times that a black stone is white, does
not
change its colour.
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?
No, to take it to that level, you need a new white list extension.
You see this from the wrong angle.
This change is not intended to provide the client indisputable knowledge
about whether a certificate is non-issued or not.
It is intended to give the responder a means of causing the client to
reject
rather than accept something that is known not to be good.
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.
It makes your statement totally irrelevant until the point where you can
demonstrate its relevance.
/Stefan