Subject: Antwort: Re: A challenge

From: [email-masked]
Date: Tue, 11 Feb 2003 14:31:49 +0100

Stefan,

first, to avoid confusion: RTCS is Peter's idea and he invented it for a
different purpose.

Second, you are right,  a white list check if applied every time is
obsoleting the signature on the certificate.

The signature in the certificate allows you to decide whether to rely on
the certificate integrity and correct issuance. Normally.

But if the CA's public key is no longer trustworthy you are in trouble, you
have to reject all certificates of that CA then as you no longer can
distinguish correct certificates from forged certificates.

In that case a white list check (and that is how it is applied in some
systems in Germany today) provides a second resort. The (German)OCSP
response you get is protected by another still trustworthy key with
independent security.

A signed (German)OCSP response with status for a specific certificate is a
"kind of" certificate on its own. Once you have obtained it you can reuse
it later on for checking as long as the OCSP responder's signing key
remains trustworthy (at least to check signatures that have been created
before the point in time the OCSP response has been created), To check
later signatures you can use a PKIX-compliant OCSP responder, as the fact
that a certificate is on a white list will never change (but revocation
state may do).

As far as I understand RTCS in its current shape could be used the same
way.

I do not really favour introducing white list checking into PKI systems.The
introduction of white list checking into PKIX would be an alteration of the
PKIX model. It would cause confusion as with white list checking in PKIX
you would have two different ways to verify a certificate: one way based on
local trusted key repositories and CRLs, another way extended by a white
list. This is probably the reason why most people on this list are
rejecting the idea. I just want to illustrate that the idea of a white list
is not as senseless and paradox as it looks on first sight.

And unfortunately the real German system is not exactly behaving the way as
described above. At the root-level the independent key security is not
given, or more exactly, most law-aware applications do not treat the root
directory key as an independent trusted key. They ask for a certificate of
this key signed by the root key.

                      Stefan Santesson                                                                                                  
                      <stefan.retrospek         An:      [email-masked], Denis Pinkas <[email-masked]>              
                      [email-masked]>               Kopie:   [email-masked], Stephen Kent <[email-masked]>                                 
                                                Thema:   Re: A challenge                                                                
                      08.02.2003 23:05                                                                                                  

Olaf,

The moment you introduce RTCS you have obsoleted the whole concept of using

X.509 certificates.

The function of a certificate is to provide proof over time, during which,
status service is provided.

OCSP can relay the information of a CRL and has therefore a place in this
structure as a service that can be provided by someone other than the CA.
It seams that RTCS must be provided by the CA. If the CA is compromised,
you can't trust the RTCS either (unless complex key structure is used), so
no benefits there.

If the CA is not compromised, the certificate is actually made obsolete
since you don't use the certificate for any trust decission you don't
require on-line from the CA at time of verificatrion. The whole concept of
using certificates can thus be replaced with an on-line request for the
subject public key, attributes and parameters from the CA at time of
validation.

It would be interesting to know the wording of the German Law requiring
RTCS. It seams that it requires som other technology than X.509
certificates and thus would not be a subject for PKIX.

/Stefan

At 15:59 2003-02-07 +0100, [email-masked] wrote:

>Introductory note (hello, stephen, please read): I am not asking for
>updates, changes to or extensions of existing specs and standards. I just
>put those specs to a challenge and want to see how they respond
>
>And I changed the topic, as we are now far away enough from discussing
>RTCS
>
>The german law does not really mandate a white list check. It mandates
>maintaining the ability of end users to sign after a CA key compromise
>Thomas has explained the law in detail. The intention of the law is to
keep
>the user unharmed by CA key compromise.  It would be fine to have at least
>a solution that satisfies the intention. And large-scale card issuers have
>as well an interest in a scheme that does not force them to replace huge
>volumes of smartcards in a very short period of time. And unlikely as it
>may be one needs a persuading emergency plan for CA key compromise if
>several million smartcards in the field are relying on this key security
>
>The "chain model" that is currently in use in Germany and has the
>white-list mechanism in it is satisfying the requirements, but it is not
>compliant with PKIX and has some other problems as well (the need for
>online-transactions for signature validation is increased, not law-aware
>applications produce deviating (wrong in the sense of the law) validity
>statements).  We are looking for alternate solutions to satisfy the
>requirements
>
>The optimal solution would be the one
>
>- that will cause PKIX-compliant applications to produce the validity
>statements on signatures as required by the law
>- without requiring private or proprietary extended validation mechanisms
>in the client applications
>- and would not require end user certificate and token updates in the
field
>in case of emergency
>
>Simon Tardell is suggesting a scheme with redundant user certificates
>issued by independently secured CA keys. We will have a closer look at
>that
>
>I think PKIX is interested to provide specifications that solve problems
>Here is one. Hopefully it is now clear enough explained. Can it be solved
>within the framework of  existing PKIX specifications ?
>
>Denis response indicates there is one solution. A pointer to it would be
>fine. If it really requires just changing a few words in the law, well the
>law has not been given by God. It would be helpful to know which words
>
>
>
>
>
>                       Denis
> Pinkas
>
>                       <Denis.Pinkas@bu         An:
> [email-masked]
>                       ll.net>                  Kopie:   Stephen Kent
> <[email-masked]>, [email-masked]
>                                                Thema:   Re: Antwort: Re:
> Antwort: Re: Real-time Certificate Status Facility for OCSP -
>                       06.02.2003
> 09:49         (RTCS)
>
>
>
>
>
>
>
>
>
>
>See comments at the end
>
>
> > We would love to see
> > someone demonstrating to us that the legal obligations already
explained
> > maybe implemented one way or the other in compliance with PKIX
>
>As Steve already mentioned, "PKIX is not in the habit of setting standards
>to accommodate national level laws that may be ill advised"
>
>There is indeed a real technical problem in case of a CA key compromise,
>but the German Law mandates a solution whereas it should have stated
>requirements only, instead of a technical solution. There exists a
solution
>to the problem, but of course it cannot fit with the current text from
>the German Law: a few sentences from the German Law should be changed
>
>Denis