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

From: [email-masked]
Date: Wed, 5 Feb 2003 12:54:41 +0100

Olaf,

>><SNIP>
>>
>>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.

>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.

To withhold the certificate from the directory is exactly the solution that
is applied by existing service providers currently. But that means that RPs
are forced to check the existance of a given certificate in the directory
to examine validity of a signature, i.e. a white-list check. This is in
compliance with the law (great) but not with PKIX (uups).

Currently OCSP (the german style) is used to perform that check. And I
agree that RFC OCSP  has not been built for that. We (i.e. those people
that discussed which specifications to go for to implement law-compliant
PKIs) adopted OCSP as a solution to this problem while it was in draft. And
we totally missed the basic idea that OCSP should be a responder capable of
working on CRLs alone. We interpreted it as a white-list service from the
very beginning. When the draft was finished and promoted to an RFC we had
to realize that we created something different.  Peters RTCS in its current
shape  would deliver the needed functionality as well.

I understand your suggestion as setting up an LDAP-directory that allows
queries for matches for a given certificate. That would be an alternative
and simple way to implement a white-list, but it would still be a
white-list. (Issues like obtaining trust into the response of the directory
and obtaining information on the point in time the certificate was inserted
into the directory have still to be resolved.) And white-list checks are
IMHO not in compliance with PKIX path validation. 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.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 Feb 2003 09:49:37 +0100

See comments at the end.

> IMHO not in compliance with PKIX path validation. 

This is correct.

> We would love to see

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

---

From: Torsten Hentschel <[email-masked]>
Date: Thu, 06 Feb 2003 13:08:53 +0100

Hi Denis, Olaf, et al.,

> the German Law: a few sentences from the German Law should be changed.

Please do not take the following as an offence, I am really asking
open minded and with the fact in mind, that I may not have read
the German law thouroughly enough:
Where do you think the German law does mandate a technical solution?
(Olaf seems to state this and Denis even shrinks it to a few sentences.)

 From my point of view the most important difference between certificate
handling conformant to German Electronic Siganture Act (SigG in short)
and PKIX (even X.509) is the requirement that an EE cert may not be
affected by the  revocation of a CA cert. This is not even
formulated literally within the law's text. It is a conclusion from
such a formulation. To make this clear, I would like to cite it
(§ 19, (5) SigG): "Die Gültigkeit der von einem
Zertifizierungsdiensteanbieter ausgestellten
qualifizierten Zertifikate bleibt von der Untersagung des Betriebes
und der Einstellung der Tätigkeit sowie der Rücknahme und dem Widerruf
einer Akkreditierung unberührt." I try my best to translate it
(without adding or dropping anything): "The validity of those
qualified certificates issued by a certificate authority
is not affected by the interdiction of the business of this
certificate authority nor by the closing of it nor by the
revocation of its accreditation."
This sentence resides within the context of §19, which
defines the power of the national root authority (RegTP) over
local certification authorities. This paragraph is intended
to give RegTP the power (among other empowerments mentioned
there) to close a CA if good reasons justify this.
It also describes the consequences from this.

Is it this, what you are referencing (Denis?, Olaf?).

 From my point of view there is no technical requirement in there.
But yes, some can be concluded from this. For instance,
§19, (5) SigG indirectly means: the CA certs will be revoked
by the RegTP when (for instance) there exists strong evidence
that a CA did not perform their operations trustworthy enough,
but the EE certs will not be revoked. This obviously creates
the need for the ability to validate EE certificates
after CA certificates have been revoked.

BUT: Neither SigG nor any ordinance related to it (as far
as I know them -- I am no lawyer!) mandate
any technical implementation how to achieve this.

The currently deployed technical implementation is the validity
model called "chain model", which fulfills the above requirement
by demanding a white list check for certificates as well.
SigG requires the CA to archive a lot of documentation
securely whenever they issue a certificate. These can be used
to reconstruct the white list (and put it on line protected by
another CA key) when a CA key gets revoked.

BUT: It could have been deployed differently (and perhaps it
will at some point in time). I am convinced that other models
like EE certs signed by two independent CAs could fit as well.

Kind regards,

   Torsten

P.S.: As far as I understand it, §19 (5) SigG was written this way
       under the vision to ease the creation of non repudation style
       signatures for end entities by the cost of making life a little
       harder for CAs and validation software providers: When EEs use
       qualified certifiactes, they are asured, they have the control,
       at what time their certificate becomes invalid (either because
       they lost their smart card or because they revoke it). This way
       they can digitally sign contracts without the fear, that their
       signature becomes invalid by an accident they did not cause
       (key compromise of a CA). I suspect, this way the need should
       be eleminated, that with PKIX digitally signed contracts need to
       be archived by an entrusted third party, which guarantees to
       bring the non repudiateable proof at any point in the future,
       that the signature has been valid at a special point in time.

-- 
Torsten Hentschel

[The positions described above are not neccessarily those
of my employer.]

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 Feb 2003 13:19:07 +0100

Torsten,

> the German law thouroughly enough:

This is fine.

> (Olaf seems to state this and Denis even shrinks it to a few sentences.)

I have already spent (too) much time on this issue. This list is to discuss 
PKIX issues, not to fix the German Law which is currently based on a model 
which is incompatible both with PKIX and X.509.

Let us leave the bandwith of this list for other topics.

Denis

---

From: Torsten Hentschel <[email-masked]>
Date: Thu, 06 Feb 2003 15:12:29 +0100

Hi Denis,

> I have already spent (too) much time on this issue.

Wouldn't have expected that. 8-/

 > This list is to
> discuss PKIX issues, not to fix the German Law which is currently based 
> on a model which is incompatible both with PKIX and X.509.

Here I disagree. Again: it is not the law, it may be an
implementation that is not in all points compatible.
(Sometimes the implementation used by RegTP
(Germany's root CA) is mixed with "requirements
enforced by law".)

As this is the PKIX list: Why shouldn't it be discussed here, how the
current implementations in Germany do use and profile PKIX to be
compatible to PKIX to the extent they can and where they are not.
"Looking over the border" sometimes helps improving, doesn't it?

Regards,

   Torsten

-- 
Torsten Hentschel

[Positions outlined by me above are not neccessarily
those of my employer.]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Feb 2003 12:21:01 -0500

>maybe implemented one way or the other in compliance with PKIX.

My suggestion is not at all what you suggest. Two issues were cited 
as the rationale for using a white list for verifying cert validity:
	- dealing with activation for postal delivery of smart cards
	- dealing with CA key compromise, again with emphasis on 
smart cards, where the costs of cert reissuance are very significant

I said was that using any white list scheme to validate a cert, e.g., 
directory presence, is just one approach to solving concerns re CA 
key compromise or smart card activation. As such it probably does not 
merit standardization, since other schemes for addressing this 
concern are invisible from a standards perspective.

Steve

---

From: "Simon Tardell" <[email-masked]>
Date: Fri, 7 Feb 2003 09:32:48 +0100

Torsten,

>        that the signature has been valid at a special point in time.

Sometimes I think people attribute too much to certificates. You sign
with the keys, not with the certificates. The binding between the key
and identity can in principal be established after the signature has
been made. Having the certs before the point of signature *verification*
does indeed the hassle for the verifier, but until then they don't
matter too much.

Simon

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