Subject: RE: German Law and OCSP

From: Ambarish Malpani <[email-masked]>
Date: Thu, 3 Feb 2000 11:05:17 -0800

Hi Andreas,
    Does it really make sense calling this OCSP any more? You will
most probably not work with most of the servers/clients.

    Also, you do have the requirement that the client verifies the
public key hash that it receives in the response...

    There are ways of profiling the spec that work within the
parameters defined by OCSP. In other ways, you break the design
of the basic protocol. In my opinion, this is the latter, not
the former.

Regards,
Ambarish

P.S. If you can get the German standard changed to follow the
spec, that might not be a very bad idea.

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: Andreas Berger [mailto:[email-masked]]
> Sent: Monday, January 31, 2000 5:19 AM
> To: Ambarish Malpani
> Cc: [email-masked]'
> Subject: Re: German Law and OCSP
> 
> 
> Ambarish Malpani wrote:
> > 
> > Hi Guys,
> >     I recently read a document that seemed to indicate that
> > the German Digital Signature Law or some related documents
> > specified that you can use OCSP to check the revocation status
> > of a cert, but they allowed you to send over all 0's as the
> > hash of the CA's public key.
> 
> This is true. We introduced this option to enable the 
> end-system to make
> queries about certificates when the CA certificate is not (at least at
> the point of this check) known. Therefore, we allowed to "omit" the CA
> public key (resp. the hash) in the query. The hash is, of course,
> required in the reply.
> 
> >     Does anybody know more about whether the statement above
> > is true or not? If it is, I am concened that they might not be
> > using OCSP correctly.
> 
> We had to extend the functionality (it was mid 1998 if I remember
> correctly). OCSP supports (supported) only the CRL-like "CRL on-line"
> design. We needed (as Hans has written)
> 
> 1. Certificate was created, is in the service since T, and is not
> revoked
> 2. Certificate was created, is in the service since T, and is revoked
> 3. Certificate is unknown
> 
> which was not possible with then the OCSP.
> 
> Andreas Berger
> GMD Darmstadt
> -- 
> Keine Zeit haben wir genug!
>

---

From: Simon Tardell <[email-masked]>
Date: Tue, 8 Feb 2000 11:26:28 +0100

> of the basic protocol. In my opinion, this is the latter, not

The German requirements raise the question what would be the "canonical" way
of extending OCSP. This is not quite clear to me from reading the RFC. In my
mind the scope of OCSP is to answer binary status queries on certificates
(good, bad and possibly "don't know"). The natural question to ask is that
of revocation. The Germans need to answer that of issuance. Still more can
be imagined.

In RFC2560 CertificateStatus can be set to "good", "revoked" or "unknown".
The wording is a bit unclear here: Does "unknown" mean that "I don't know
whether this certificate is revoked" or "I know this certificate does not
exist"? The Germans seem to have opted for the latter interpretation. Now,
assuming the former interpretation we have three answers to the revocation
question (good, bad, don't know). How do we extend OCSP to assert the answer
to other questions? I see two possible approaches:

1)
CertificateStatus is generalized so that it contains the logical sum of all
properties that the client wants to have asserted (or that the responder
wants to assert in response to a query). E.g. assume two properties A and B
that both have to be "good" for a certificate to be valid for use, then
CertificateStatus is "good" if both of them are "good", "bad" if (at least)
one of them is "bad" unless one of them is "unknown" in which case
CertificateStatus is "unknown". Extensions to the respective statuses can be
used to qualify the answer (e.g. to tell _what_ properties were bad), if the
client really cares.

2)
CertificateStatus is defined to only provide good, bad and unknown answers
to the revocation question. SingleExtensions are defined for each property
(except for revocation status) and each such SingleExtension can take the
value "good", "bad" and "unknown". The problem then arises that the client
can perhaps not be expected to understand new properties (extensions) as
they are implemented on the server. To solve that, these extensions should
be marked critical if they are "bad" or "unknown", but not if they are
"good".  

Now, this is not quite what it says in the RFC (for example, the answer
"good" allows to be qualified with other types of goodness, but there is
seemingly no way to answer "not revoked, but bad in some other sense"). The
former method seems more attractive from the perspective that it allows
making the clients simpler, but it would require some changes to the current
protocol. The latter solution would work with current clients (how widely
deployed are they anyway?) but is less appealing (an error in the client
would have the meaning "no, you can't do that"...).

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], http://www.iD2tech.com/
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

---

From: Ambarish Malpani <[email-masked]>
Date: Tue, 8 Feb 2000 09:39:03 -0800

Hi Simon,
    You describe the situation very well. If I were trying to provide
additional semantics, I would do them through extensions. For example,
if a client wanted to know whether a cert was issued or not, in
addition to its revocation status, I would recommend putting that
additional status information in singleExtensions, rather than
trying to overload the meaning of good.

We went through a long discussion on how best to do this when OCSP
was being defined and figured that the best way of keeping the spec
clean, was to have a very specific meaning for status, which is just
revocation status.

The issue of whether a cert was ever issued or not, did come up, but
the group concensus was that a client either had the cert in hand and
could verify the signature on the cert and so know whether it was
issued or not.

If the CA's cert signing key was compromised and you wanted to deal
with that case, you need to either directly trust the OCSP responder
and ask it about the CA's self signed cert, or check the CA's cert
if it is part of a larger hierarchy, or try to deal with the issue in
an out of band way.

Hope this helps,
Regards,
Ambarish 

> From: Simon Tardell [mailto:[email-masked]]
> Sent: Tuesday, February 08, 2000 2:26 AM
> To: 'Ambarish Malpani'; 'Andreas Berger'
> Cc: [email-masked]'
> Subject: RE: German Law and OCSP
> 
> 
> Ambarish wrote:
>

---

From: "Hesse, Johan" <[email-masked]>
Date: Thu, 24 Feb 2000 14:37:23 +0100

Hello out there!

It seems that there are a lot of confusions regarding some terms in the
German Law.
As considered there are two distinct entities. One for issuing certificates
and one for revoking certificates. The revocation is maintained by the
directory service (DIR, Andreas Berger described it with "information
service"). In the moment the issuing entity signs a certificate you may be
attempted to say its valid, but in the sense of German Law a valid
certificate has to be published. Published in this coherence means that the
certificate is either *checkable* (you can only get status information) or
*retrievable* (you can get status information and the whole certificate).
Both status have to be maintained by the DIR.

I think the confusion springs from legal terms. In the above mentioned
example the technical term of *valid* for a certificate would be the moment
of the signing with the signing key. The legal term assumes the publishing
of the certificate.

Another misunderstanding seems to be the role of the CRL in German Law. 

Antonio Lioy wrote (28.01.2000) "... the only legally binding way to prove
that a cert was not valid at a certain date is to provide a CRL (or a
CSL!!!) that includes it." The German Law requires only the *checkability*
of the status of a certificate for anybody to any time (§4 SigG). The
interoperability schemes (SigI A5) propose OCSP. The status *suspension*
isn't allowed according to the German Law, in comparision with Italian law
which requires a CRL (Art. 29 par. 3) and the possibility of suspension
(Art. 33).

   Best regards,   
                        Johan Hesse

> **************************************
> Johan Hesse
> secunet 
> Security Networks AG     
> Osterbekstraße 90b
> 22083 Hamburg
>  
> Tel   : +49 (0)40/696599-12
> Fax   : +49 (0)40/696599-29
> mailto:[email-masked]
> **************************************
> 
>

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 24 Feb 2000 07:44:03 -0800

Hi Guys,
    As I understand it, the requirements for a certificate to
be considered valid according to the German Digital Signature
Act are:

1. The certificate has been created and signed by the CA
2. It is publicly available (if the certificate holder allows).

There was another benefit desired, where a client be able to
query the status of a certificate, where, while querying, it
might not have the CA's public key.

This was translated into an OCSP request where:
a. The request may be made with the hash of the CA's public key
set to 0/all 0's
b. The response would contain the real hash of the CA's public key
c. The responder (VA) verify that the cert was contained in "the"
directory.

Comments
--------
- I believe the requirement to force the VA to check that the
cert is in the directory was to prevent the VA from issuing
incorrect responses (where a cert has been signed, but not
added in the directory)

Issues
------
I. IMPORTANT: If a client be allowed to make a query for a
certificate where it hasn't checked the signature, it could
be making a query for a certificate that doesn't exist (because
the signature on it is bad). The responder might still say the
certificate is good, because, ANOTHER CERTIFICATE WITH THE SAME
SERIAL NUMBER WAS ISSUED AND IS IN THE DIRECTORY!

II. The "publicly available" clause needs to be carefully
interpreted. I don't think it makes sense to force the VA
to try and retrieve the certificate in question from a
directory, because you *will* hit the situation where a
certificate was, in fact correctly issued, but because of
some transient network/machine problem, the VA can't get to
the repository for an instant in time. In that case, should
the VA return a status of bad/revoked/unknown/good? Which of
the responses is "correct"?

Recommendations
---------------
i) Require clients to verify the signature on the certificate
and its validity (ie. in the notBefore and notAfter period)
when the make the query [caveat: the cert might have expired,
in which case you need to check the ArchiveCutoff in the response].
This job needs to be done by the client to ensure that the
query is a reasonable one.

ii) Enforce the publicly available requirement by policy and
procedure. Don't try to enforce that with software.

Does this make sense?

Regards,
Ambarish

> From: Stefan Kelm [mailto:[email-masked]]
> Sent: Thursday, February 24, 2000 5:48 AM
> To: [email-masked]
> Cc: [email-masked]
> Denis,
> > > Once such a division is made technically, it was extended 
> to the idea
> > > that a certificate should only be valid once it is inserted in the
> > > information service database.
> >
> > I do not understand. To be "valid" a certificate does not (even)
> > have to be published. It may be given back to the user who may
> > decide to send it to whatever entity he wishes.
> 
> you're certainly right. However, the German Digital Signature 
> Act states:
> [from http://www.iid.de/rahmen/iukdgebt.html#a3]
> 
> § 5: Issue of Certificates
> 
> (1) The certification authority shall reliably establish the 
> identity of persons applying for a
> certificate. It shall confirm the assignment of a public 
> signature key to an identified person
> by a signature key certificate which, together with any 
> attribute certificates, shall be kept
> available for verification and, with the consent of the owner 
> of the signature key, for
> retrieval at all times and for everyone over publicly 
> available telecommunication links.
> 
> The magic statement here is "...shall be kept available for 
> verification...
> at all times...". Therefore, a certificate implicitly is 
> valid once it is
> made available (from the CA's repository) for verification. Like it or
> not (I don't) - that's the way the validity model was chosen 
> to be. E.g., I've
> been issued one of the very few certificates issued according 
> to the law
> but since it has not been published yet it is not valid in the sense
> of the law...
> 
> The law currently is under evaluation and will be revised later this
> year. It's highly unlikely that they're going to change this validity
> model, though.
> 
> Cheers,
> 
>         Stefan.
> 
> ______________________________________________________________
> ________________
> Stefan Kelm            PGP key: "finger [email-masked]" 
> or via key server
> DFN-PCA                                                      
> <[email-masked]>
> Vogt-Koelln-Str. 30                               
> http://www.pca.dfn.de/~kelm/
> 22527 Hamburg (Germany)                   Tel: +49 40 428 
> 83-2262 / Fax: -2241
>

---

From: Paul Halliden <[email-masked]>
Date: Thu, 24 Feb 2000 16:52:50 -0000

> It seems that there are a lot of confusions regarding some terms 
> in the German Law.  
Agreed ;)

[snip]

> I think the confusion springs from legal terms. In the above 
> mentioned example the technical term of *valid* for a certificate 
> would be the moment of the signing with the signing key. 
Technically a certificate is valid from the date and time contained in the
ASN.1 element "notBefore" in the "Validity" sequence of the X.509 structure.
This may or may not be the time of signing by the CA.  Indeed, it may be
delayed with respect to time of signing to cope with the scenario you
describe in your later mail.  This is the same as the process known as "Thro
dating" used by credit card companies to protect against the risks you
mention.

> The legal term assumes the publishing of the certificate.
>
> Antonio Lioy wrote (28.01.2000) "... the only legally binding way
> to prove that a cert was not valid at a certain date is to provide
> a CRL (or a CSL!!!) that includes it." The German Law requires
> only the *checkability* of the status of a certificate for anybody 
> to any time (§4 SigG). 
This is §5(1) in my (English) copy dated 1 August 1997.  Is there a later
version?  More importantly, it was explained to me that the German model
needed to know if a certificate was valid at the time that the corresponding
signature key was originally used and not at the time the request for
validation is performed.  This is because one might be checking a legal
document that is tens of years old.  Is that what you mean by "to any time"?

> The interoperability schemes (SigI A5) propose OCSP. 
As I understand it, OCSP is designed to tell you status now not status at
some previous date.  If so, is this another issue with German Law and OCSP?

> The status *suspension* isn't allowed according to the German Law, 
> in comparison with Italian law which requires a CRL (Art. 29 par. 3)
> and the possibility of suspension (Art. 33).
Do you have a reasonable English translation of the Italian law - or a link
to a translation?

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 24 Feb 2000 19:52:59 -0800

Hi Alistair,
    Didn't you want to scrap OCSP entirely, anyway? :-)

How a VA gets and keeps access to its revocation data doesn't
need to involve access to the CAs repository. It could keep the
data locally/in memory.

Yes, I agree, you could return tryLater, the main thing I would
question is the value of making that a requirement on the
VA.

Regards,
Ambarish

> From: Grant, Alistair [mailto:[email-masked]]
> Sent: Thursday, February 24, 2000 3:54 PM
> To: Ambarish Malpani; [email-masked]'
> If we take this reasoning one step further, the responder 
> can't get the CRL
> because of some transient network/machine problem, what 
> should be done?
> Taking this to the (ridiculous) extreme, does that mean we 
> shouldn't force
> the responder to try and retrieve the CRL?
> 
> I think the common answer will be that the responder returns 
> unknown or
> tryLater until the CRL becomes available.
> 
> I don't believe that this particular argument holds against 
> requiring the
> responder to retrieve the certificate as part of the status check.
> 
> 
> Cheers,
> 
> 
> Alistair Grant
> Project Manager - Development
> Computer Associates, OpenDirectory Lab
> Melbourne, Victoria, Australia
> Phone:	+61 3 9727 8912
> Mobile:	+61 408 565 080
> Fax:	+61 3 9727 3491
> E-Mail:	[email-masked]
>

---

From: "Hesse, Johan" <[email-masked]>
Date: Fri, 25 Feb 2000 12:23:36 +0100

> -----Ursprüngliche Nachricht-----
> Von:	Paul Halliden [SMTP:[email-masked]]
> Gesendet am:	Donnerstag, 24. Februar 2000 17:53
> An:	'Hesse, Johan'; [email-masked]; [email-masked];
> [email-masked]
> Cc:	[email-masked]
> Betreff:	RE: German Law and OCSP
> 
	[Hesse, Johan]  O.k. But the element "notBefore" doesn't help in
this scenario. If you don't know how long it exactly takes that the PSE is
handed out to the intended end user. May be 2 minutes and the user wants to
sign immediately (personal handing out), or 2 weeks (the user is absent and
sends the acknowledgement later).

> document that is tens of years old.  Is that what you mean by "to any
	[Hesse, Johan]  You are right, §5. I have to learn the Law by heart
again ;-)
> Do you have a reasonable English translation of the Italian law - or a
	[Hesse, Johan]  Sorry, I have the law only in italian. The details
concerning suspension and CRL as mentioned above can be find in the "Decreto
del Presidente del Consiglio dei Ministri, 8 febbraio 1999" under
http://www.aipa.it/servizi[3/normativa[4/leggi[1/regfin.asp  .      

	Ciao, Johan

---

From: Michael Herfert <[email-masked]>
Date: Fri, 25 Feb 2000 16:10:56 +0100

Hello,

Hans Nilsson wrote:
> (For non-German speakers: "Good" means that the certificate is issued by the
> CA, known in the Directory and not revoked)
> 
> This is quite a different interpretation of "good" from RFC 2560, where
> "good" not necessarily means that the certificate has been issued!!!

there are two important differences between standard OCSP and SigG OCSP:

1. The meaning of "good":
   I think Hans is right in this point.

2. The single request extension certHash:
   The german law requires that user certificates must 
   be valid, even if the CA key has been corrupted.
   The extensions certHash contains the hash value of the certificate 
   being asked. It is a MUST in every request. 
   Without this value the service would not work 
   according to the law because the identification of a certificate by 
   (issuerNameHash, issuerKeyHash, serialNumber)
   is only a valid reference if the CA cert signing key is okay.
   Assume Alice has the serial number 5.
   In a desaster case where the CA cert signing key has been broken,
   an attacker may generate a certificate for Bob which has the 
   serial number 5, too. 
   In the same matter he may generate many faked certificates 
   that share a serial number with a correct certificate.

Michael 

---

Michael Herfert
GMD - German National Research Center for Information Technology
Darmstadt
Germany

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 25 Feb 2000 07:31:50 -0800

Hi Michael,
    - The requirements you have specified could be met by using
standard OCSP and requiring the VA to send over the full cert
hash in the response.
    - If a CA cert signing key has been compromised, I would
treat everything issued by the CA as suspect - you would open
yourself up to too many attacks - it isn't worth it to try and
save the certificates that were legitimately issued.

Regards,
Ambarish

> From: Michael Herfert [mailto:[email-masked]]
> Sent: Friday, February 25, 2000 7:14 AM
> To: Denis Pinkas; [email-masked]
> Hello Denis and all,
> Denis Pinkas wrote:
> > Besides the wording, the question was to understand the rational of
> > the model. The question is still pending ...
> 
> The standard X.509 model does not satisfy the requierements 
> of the german 
> law. So there was a need for a new model. The important 
> paragraphs are:
> 
> 
> §13(5):	"The validity of the certificates issued by a 
> certification 
>          authority shall remain unaffected by the withdrawal or 
> 	 revocation of a licence. The competent authority may order the
>      	 invalidation of certificates when facts warrant the assumption 
> 	 that certificates have been forged or are not adequately 
> 	 protected against forgery or when technical components
>      	 used for the signature keys reveal security flaws enabling 
> 	 digital signatures to be forged or signed data to be 
> 	 manipulated without detection." 
> 
> §8(3):	"The competent authority shall invalidate 
> certificates which it has 
>   	 issued according to §4(5) when a certification authority 
>       	 ceases operation or its licence is withdrawn 
> or revoked."
> 
> 
> Assume a CA looses its license, for example because it has 
> lost its money.
> According to §8(3) the competent authority (= the german root CA) 
> must revoke the certificate. 
> 
> By §13(5) user certificates must remain valid if a CA looses 
> the license.
> 
> So we have a revoked CA certificate and valid user certificates.
> This case can not be handled by the standard X.509 model.
> 
> ---
> 
> The SigG model is an easy and effective model.
> Assume a two level hierarchy:  
> 	root CA
> 	CA
> 	users
> 
> 1. Now Alice wants to verify 10000 digital signatures 
>    with respect to the standard model.
>    She decides that she needs online verification of certificates.
>    For the first signature she must ask her online service 
> three times:
>      to verify the user certificate
>      to verify the CA certificate
>      to verify the root certificate
>    So for 10000 verifications she needs 30000 requests.
> 
> 2. On the other side, Bob verifies the same amount of signatures
>    by the SigG model.
>    He first verifies the CA and the root CA certificates.
>    He can store the results and reuse them in the future.
>    So for 10000 verifications Bob needs 10002 requests.
> 
> ---
> 
> A standard X.509 directory service may be joined with the 
> german signature law.
> Alice ask this service for the certificate of Bob.
> The service answers by sending Bob's certificate 
> (if Bob has allowed this).
> The certificate is signed by the CA, like always,
> but it has no extra signature.
> The meaning of the answer is: 
>   Alice, this is Bob's certificate. It may be valid
>   or not. If you want to know the exact status,
>   ask the validation service.
> 
> If we replace the words "validation service" by "OCSP" 
> then this is exact the meaning we have in the standard model.
> 
> Greetings,
> Michael
> 
> ---
> 
> Michael Herfert

---

From: [email-masked]
Date: Fri, 25 Feb 2000 16:48:10 -0500

There is also a set of technical rules associated with that
presidential decree at the link
http://www.aipa.it/attivita[2/protocollo[13/normprot[1/regole428.asp.
Please note that the link contains left square brackets in file names, not
parentheses.

          Tom Gindin

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Feb 2000 17:02:34 -0500

directory.

Is VA now a generic term for OCSP responder?  I thought you guys trademarked
it. Be careful, you don't want to go the way of kleenex... :)

>ANOTHER CERTIFICATE WITH THE SAME

How so?  Since the certID includes the issuerNameHash, it identifies the
issuer, and since the issuer doesn't re-use serial#'s,...  There are
performance impliciations -- it might require a directory to index by
HASH(issuer_dn) -- but that seems surmountable.  There are other approaches,
such as having an OCSP responder which gets both certs and crl's, not just
revocation data.  (Modesty prevents me from naming names :)

It also puts the directory into part of the trusted base.  In general
directories aren't put there, but if that's what the lawyers wrote, then
we techies can only comply.