Subject: A challenge

From: [email-masked]
Date: Fri, 7 Feb 2003 15:59:23 +0100

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 7 Feb 2003 17:25:15 +0100

Olaf,

To have redundant certificates in case the CA goes haywire
seems like a very peculiar solution and will force
users to select the proper certificate.  Which is?

There is really only one reasonable cure: To manage CA keys and
compromises the way most other CAs would.

If a CA has a key compromise it may not even be aware of it...

BTW, I don't see that CA key protection can be that hard.
Proper procedures (TONS of such have been written)
and HW crypto should do the trick.

Identity impersonation and its consequences is something
that you should really bother about.  And liabilities in
case of such.

Regarding cards: make them upgradable over the net.
You must anyway be prepared for distributing certificates
over net in order to address the  "Mobile Internet".

Anders

----- Original Message -----
From: <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>; "Stephen Kent" <[email-masked]>
Sent: Friday, February 07, 2003 15:59
Subject: A challenge

                      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.

Denis

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 08 Feb 2003 23:05:45 +0100

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:

>put those specs to a challenge and want to see how they respond
>
>RTCS
>maintaining the ability of end users to sign after a CA key compromise
>several million smartcards in the field are relying on this key security
>
>requirements
>in case of emergency
>that
>I think PKIX is interested to provide specifications that solve problems
>law has not been given by God. It would be helpful to know which words
>
>
>
> 
>
>                       Denis 
> Pinkas 
>
>                       <Denis.Pinkas@bu         An: 
>                                                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
> > maybe implemented one way or the other in compliance with PKIX
>
>to accommodate national level laws that may be ill advised"
>
>the German Law: a few sentences from the German Law should be changed
>
>Denis

---

From: "Hans Nilsson" <[email-masked]>
Date: Sun, 9 Feb 2003 22:22:04 +0100

Olaf,

You are explaining the German chain model witht the example of handling
CA key compromise. Although allowing signing after CA key comprise is a
case "handled" by the German law, I think a more important, and
certainly more likely case, is the case of the CA just loosing their
status as licensed/accredited CA from RegTP. In this case RegTP will
revoke the CA certificate, but the user certificate should remain valid.
In this very likely scenario, the users should be able of continuing
using their key/certificate/smart card. And thus the chain model was
invented.

Incidentally, I guess that all commercial CA hierarchies face the same
problem, but most ignore that. Have we ever seen an intermediate CA in
the Micrsoft tree or other browser-installed tree having its CA
certificate revoked because they no longer fulfill the Root CAs
requirements in some way or another? I do not think so, because you
would get a lot of angry peopole out there, who signatures suddenly
would start become invalid. Once a CA is in there, it stays there :-)
But the Germans draw the right conclusion, saying that if you issue a
license, you must also have a method of withdrawing it.

I have always argued that the Germans correctly identified the problem,
but took the wrong solution to the solving it. Instead of revoking the
CA certificate and declaring the EE certificates to still be valid, they
*should not revoke* the CA certificates. By using the CA certificate not
only as a statement of the fact that a certain CA holds a certain key,
but also as a "certificate of license" that can be revoked at any time,
they have "made their bed" in this ugly fashion. 

It is really a question of what semantics a CA certificate carries. I
think it should only state the binding of identity/key (just like an EE
certificate), nothing more. The status of the CA
(licensed/accredited/supervised...) should be distributed in some other
fashion (which is the subject of a European project within ETSI).

Hans Nilsson

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, February 07, 2003 3:59 PM
> To: Denis Pinkas
> Cc: [email-masked]; Stephen Kent
> Subject: A challenge
> 
> 
> 
> 
> 
> 
> 
> 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.
> 
> - 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:      
>                       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
> 
> 
> 
> 
> 
>

---

From: Juergen Brauckmann <[email-masked]>
Date: Mon, 10 Feb 2003 11:30:31 +0100

> certificates and thus would not be a subject for PKIX.

I found an english translation here:

http://www.kuner.com/data/sig/sig_august_16.html

Interesting paragraph: §19(6)

Here you can find an unofficial translation of the accompanying
ordinance, which is also important:

http://www.sng.it/acrobat/it%20security/Leggi/Signaturverordnung%20neu%20(English%20unofficial%20version).pdf

§15(3) says:
"The information according to sentence 1 must include whether the
checked qualified certificates were present at the given time in the
directory of qualified certificates, and not locked."   (locked =>
revoked)

Regards,
  Juergen

---

From: "Simon Tardell" <[email-masked]>
Date: Mon, 10 Feb 2003 16:35:04 +0100

Anders,

> seems like a very peculiar solution and will force users to 
> select the proper certificate.  Which is?

Not at all. A signature is made with a key, not a certificate. As long
as the identity of the certificate is not signed into the message, any
certificate that corresponds to the right key can be used to validate
the signature. The certificate may  be sent with the signed message or
obtained from somewhere else. It is largely the headache of the
verifier. 

The certificate that is used to verify the signature may even be issued
after the signature is made. (And in fact, this would be a reasonable
possible consequence of having CA redundancy -- after some time it could
happen that both CAs that certify a certain key-identity-binding are
replacement CAs deployed after the first signatures were made with the
card)

For some reason the common paradigm is to let users chose a certificate
associated with a key to imply the key. This practice requires the
certificate to be present at the client. Or rather, *a* certificate. The
certificate could be e.g. a self-signed cert (issued by the smart card
itself at production time just to supply a GUI handle to applications
looking for, and to supply a subject name for the end entity to claim,
if the application needs one). This would remove the need to ever update
the smart card. Or, as Sun would say, the network is the computer.

Simon

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 11 Feb 2003 17:19:18 +0100

Simon,
Aaah.   So the cards would contain "redundant" certificates using
the same keys.

You also claim that one should not put certificates in signed
messages as it is only the key that matters.
That of course works from a cryptographic point of view.

But RPs must have a way to associate they key with
a name.  A certificate does this function.  "Something" must
(or is usually assumed to) be asserted in signatures to notify
where the issuer is to be found.

Anyway, in Sweden this would *not* work as the 24h government
uses the TTP-issued certificates to vouch for citizenship and
citizen registration code.  By doing that all authorities do not
necessarily need to have the citizen-register on-line as the
certificates themselves form sort of a "distributed citizen database".

I also wonder if competing CAs actually "like" the idea to share
EE-keys, be it an irrational consideration or not.

============================================
But frankly I see no future in smart cards of the type Germany
is investing in.  A mobile phone is such a tremendously
more powerful "container" that allows users to do things
that smart card owners cannot even _dream_ about.  Since
mobile phones are on-line by definition, static key and
certificate schemes then become rather irrelevant.
============================================

Anders

----- Original Message ----- 
From: "Simon Tardell" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>; "'Denis Pinkas'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "'Stephen Kent'" <[email-masked]>
Sent: Monday, February 10, 2003 16:35
Subject: RE: A challenge

Anders,

Simon

---

From: "Simon Tardell" <[email-masked]>
Date: Tue, 11 Feb 2003 18:00:37 +0100

Anders,

> messages as it is only the key that matters. That of course 
> works from a cryptographic point of view.

It works from an application point of view as well, I'd say.

> (or is usually assumed to) be asserted in signatures to 
> notify where the issuer is to be found.

Generally assumed to, yes. Must, no. The relying party only has to know
what identity is claimed. That identity is used to look up certificates
from whatever issuer the relying party trusts. It doesn't matter which
issuer the client trusts, although it perhaps doesn't seem probable that
there would be a certificate associated with the clients key that the
client doesn't somehow trust the issuer of (but it is certainly
possible). The clients' claimed identity can be encoded in a self-signed
certificate, since not all signed formats have a separate field for
"claimed identity".
 
> citizen registration code.  By doing that all authorities do 
> not necessarily need to have the citizen-register on-line as 
> the certificates themselves form sort of a "distributed 
> citizen database".

That is of course utterly stupid. The authority pushes some of its
processing complexity onto the client. On not onto the client machine,
but the client human. 

Interestingly enough, in the physical world things are moving the other
way. I renewed my passport recently and nowadays you don't have to bring
a "personbevis" (a paper stating that there exists a person with my name
and number). The police is online, they already know!

> I also wonder if competing CAs actually "like" the idea to 
> share EE-keys, be it an irrational consideration or not.

In the German case the idea was to force it on them by law. 

In a more general situation I can see that they would, issuing smart
cards is a lot more expensive than issuing certs to a smart card issued
by someone else.

Simon.

---

From: Torsten Hentschel <[email-masked]>
Date: Wed, 12 Feb 2003 09:31:56 +0100

Hi Anders,

as of my knowledge some of your assumptions about "German way" /
"German law" are wrong.

> EE-keys, be it an irrational consideration or not.

Perhaps you did not mean to refer to Germany with the statement above.
But I answer it as if:

EE-keys may not be shared. By law they are enforced to exist
exactly once: in the control of its holder; nobody else may
have enough information to reconstruct this key.
As a consequence in practice the key resides on a mobile secure
device: the smart card.

Even if you wanted to talk about EE-certs (instead of EE-Keys):
There is no requirement for CA Andrew to distribute the EE-certs
issued by CA Berta within the directory of Andrew as well, unless
the regulation authority explicitly tells to do so (this may
only happen if Berta is closed due to misbehaviour or insolvency).

Well, mobile phones contain smart cards, don't they?
I do absolutely not see the dead end here.

Kind regards,

   Torsten

-- 
Torsten Hentschel
[The positions of mine as outlined above are not neccessarily

---

From: "Olle Mulmo" <[email-masked]>
Date: Wed, 12 Feb 2003 15:54:49 +0100

What whitelist protocol did the police use? RTCS? :-)

/Olle

-----Original Message-----
From: Simon Tardell
Sent: den 11 februari 2003 18:01

[snip]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Feb 2003 16:26:28 -0500

Hans,

The message clarifying what seems to be the major focus of the German 
CA law is quite illuminating. I can understand the motivation behind 
the law in this form, but it is also very much different from what 
many have said, where the focus was on CA key compromise, vs. 
cessation of operation of a CA. The requirement stated here could be 
met in many ways through procedural means of "shutting down" a CA, 
without revoking its cert.

For example, one might mandate that a TTP CA be required to use a 
separate key for CRL and/or OCSP response signing, and that this key 
be escrowed. Then one could destroy the cert signing key as a means 
of shutting down the CA, but still retain the ability to sign 
revocation status data structures for the lifetime of any certs 
issued by the CA. That would provide the separation that seems to be 
the crux of the law, completely within the scope of current PKIX 
standards, right?

Steve