Subject: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)

From: [email-masked]
Date: Mon, 3 Feb 2003 19:03:39 +0100

While reading the introduction of Peters draft I got the feeling that OCSP
is flawed as it is only able to assure the presence of a revocation but not
the opposite. I looked up the OCSP specification and found that it delivers
three different reponses, with "good" indicating that the certificate is
definitely not revoked. Which has to be interpreted as "I have enough
information to perform the revocation check, and the check returned not
revoked." I understand that "unknown" is indicating that information
avaliable is insufficient to decide the question. This, of course, can mean
anything. I think that "yes", "no", or "don't know" is a perfect choice of
answers for an agent answering the question "is this certificate revoked?.
OCSP is not flawed (at least not here). I suggest Peter to review the
introduction on this topic to avoid misunderstandings.

The main difference between RTCS and standard OCSP is that RTCS is
answering a different question and thus is providing different information.
It is a white list check and a black list check. It answers the question
"Is this certificate issued correctly AND not revoked ?"

The most specific answer here is "yes"  which means that the certificate is
known in the cert repository and there is no revocation indication present.
In the short form of the response "no" is ambigous. It can mean

1. that the cert is not in the repository (but should be there, indication
of a CA key compromise, cert invalid),
2. the cert is in the repository and marked as revoked (cert invalid), or
3. the repository to look at is not available to the responder (cert state
unknown, maybe valid, ask someone else).

Looking at the available list of responses in the extended RTCS Response, I
cannot map the response codes given there directly to the listed cases. The
first and third case map to StatusUnknown, the second case to
StatusRevoked. I suggest to provide more response codes to have a
one-on-one mapping of the different cases to codes.

The debate will probably continue on the topic "Do we really need a white
list check?". In the common PKIX (and X.509) paradigm "CA key security is
perfect"  the answer probably is "no".  A certificate carrying a signature
of a trusted CA is valid, no need to ask the CA again.

In Germany the german signature law is identifying a fourth case:

4. the cert is in the repository, but not active yet (cert invalid, maybe
valid in the future)

This case is required (by law) if a CA issues not only certificates but
private keys as well to the end user. Think of a bank producing and
delivering a smartcard with keys and certificates on it to you. As long as
you did not confirm the receipt of the card to the CA the CA must protect
you by having the certificate "on hold" so during transport no valid
signatures can be created. This may be handled by an "onHold" status on a
CRL but is currently deployed in Germany using white list technology.

The second reason why german electronic signature technology is requiring a
white list check is another obligation by law, namely that it is not
allowed to render correctly issued user certificates invalid due to a CA
key compromise (or any other kind of CA ceases operation). This is again
achieved with white list technology and status information signed by a key
with independent security. RTCS would fit well in here.

                      [email-masked]                                                                                                 
                      nd.ac.nz (Peter           An:      [email-masked], [email-masked]                               
                      Gutmann)                  Kopie:   [email-masked], [email-masked], [email-masked]                     
                      Gesendet von:             Thema:   Re: Real-time Certificate Status Facility for OCSP - (RTCS)                    
                      owner-ietf-pkix@m                                                                                                 
                      ail.imc.org                                                                                                       

                      31.01.2003 10:51                                                                                                  

[A bit of a flame, sorry folks]

Denis Pinkas <[email-masked]> writes:

>"invalid without being revoked" does not mean anything.

So you're saying the only way a certificate can ever be regarded as invalid
is
if it's formally revoked by a CA?

>>and can be valid but OCSP can't tell you that because it can only say
"not
>>revoked", which doesn't mean "valid" - see the endless debate on this
over the
>>years).
>
>There is no such an endless debate, except from your side.

Anyone who bothers to search the PKIX archives can see how accurate Denis'
claims are.

(It's amazing you can even make such a claim, when anyone who's been on the
 PKIX list for more than a few months has seen the OCSP-status debate crop
up
 at least once.  You've even taken part in them yourself... a 30-second
search
 of the archives dug up:

 Subject: Re: German Law and OCSP
 From: Denis Pinkas <Denis.Pinkas@xxxxxxxx>
 Date: Thu, 10 Feb 2000 16:59:24 +0100

 as one example (I don't have the '01 archives becuase they're too big,
that
 was the last one from '00)).

>[Blah blah blah, lots more bogus whining and moaning] for example:

  Because the hash of a certificate is not included in the CRL, so using
CRLs
  only would not be possible.

and then right after it you quote the very text which refutes your claim:

>   memcpy( response.certHash, request.certHash, 20 );

and so on and so on.  Look, I'm sorry, but you're grasping at any available
(or imaginary) straw here in an attempt to criticse RTCS.  It's obvious
from
your messages (and others have commented on this as well) that you've
barely
read the RTCS draft (if at all), and even then only to pick out bits to
complain about.  The posting of obviously incorrect claims such as the ones
cited above aren't helping your credibility much either.  It's simply a
waste
of time me even responding to stuff like this - the excerpt above shows
that
not only have you barely read RTCS, you're not reading the replies either,
except to pick out bits to criticise.

In the meantime I welcome intelligent debate with anyone else (the
cert-HTTP
draft has been considerably improved by recent user feedback).

Peter.

---

From: "Simon Tardell" <[email-masked]>
Date: Tue, 4 Feb 2003 10:50:12 +0100

> The second reason why german electronic signature technology 
> is requiring a white list check is another obligation by law, 
> namely that it is not allowed to render correctly issued user 
> certificates invalid due to a CA key compromise (or any other 
> kind of CA ceases operation). This is again achieved with 
> white list technology and status information signed by a key 

Ah, yes, the German OCSP-turned-into-a-certificate-notary. Too late to
change, but if you back up a bit isn't the problem that you don't want
the EE *keys* rendered useless by a CA key compromise? That is perfectly
valid concern: The EE keys are not compromised themselves, just the
binding to the identity (through the CA key compromise). Reissuing smart
cards, especially loads of them, is painfull and takes time, not to say
costs a lot of money. 

A simple solution that would not have mandated inventing a new protocol
("German OCSP") that is uninteroperable with just anything else would
have been to mandate that each EE key be certified with at least two
independent CAs.

Simon

Simon Tardell, cell +46 70 3198319, [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Feb 2003 21:02:31 -0500

Olaf,

><SNIP>

This seems an unnecessary complication. The CA could simply wait to 
post the cert to a directory until the user acknowledges receipt. 
I'm not in favor of adding complexity when there are other, simpler 
solutions to a problem.

>with independent security. RTCS would fit well in here.

My response to Simon addresses this issue, i.e., German law seems to 
have mandated a solution to a problem that is not technically 
justified, given the alternatives. PKIX is not in the habit of 
setting standards to accommodate national level laws that may be ill 
advised.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Feb 2003 21:01:35 -0500

>have been to mandate that each EE key be certified with at least two

There are many ways to address the concerns raised by CA key 
compromise. Relying on a secure directory to confirm the validity of 
an EE cert (not keys) is one approach, but too often it seems to be 
based on a very questionable assumption, i.e., that by using two 
authorities (the CA and the directory operator) and two keys to 
verify cert status, that this is necessarily more secure that relying 
on the CA only.  Thios overlooks the possibility that the CA uses 
multi-party controls for its keys, e.g., analogous to the way that 
SetCo did for the SET root CA.

Mandating use of a secure directory is only one possible way of 
addressing a valid concern, and to codify this approach as THE 
solution is unjustifiable.

Steve

---

From: Juergen Brauckmann <[email-masked]>
Date: Wed, 05 Feb 2003 09:29:39 +0100

> In Germany the german signature law is identifying a fourth case:

Just a short note: All these issues with the German Signature Law "only"
relate to qualified certificates. 

> delivering a smartcard with keys and certificates on it to you.
[...]
> This may be handled by an "onHold" status on a

Or by simply not publishing it. Otherwise you will get a somewhat
oversized CRL if your bank decides to issue 2 million new banking cards,
all with "on hold" certificates. Makes validation a little bit slower
than normal :-)

Juergen

---

From: "Simon Tardell" <[email-masked]>
Date: Thu, 6 Feb 2003 12:37:24 +0100

> 4. the cert is in the repository, but not active yet (cert 
> invalid, maybe valid in the future)

My interpretation that the problem that you try to cover for here is if
the card AND the PIN code envelope both gets lost en route from the
issuer to the intended end issuer, the card should not be usable.

Well, why not issue the certs after the card has been (in a trusted
manner) been delivered to the intended recipient?

Again, it obviates the need for a custom design protocol.

Simon