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

From: Torsten Hentschel <[email-masked]>
Date: Fri, 07 Feb 2003 11:49:46 +0100

Hi Simon,

Simon Tardell wrote:
> 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.
> 
> 
> 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.

Thanks for this aspect. I already catched it from your earlier postings
and it made me think the direction you outline here. So you already
made me aware of the fact, that key and certificate can be considered
independent. I think it really is nice.

When I read your earlier lines, it became aware, that SigG may have
gone a step too far when it demands that certificates may not
become invalid just by a CA cert revocation. For the intent the writers
had in mind (as I suspect it), it would have been sufficient to demand
the following things:
   a) The key may not become useless by a CA cert revocation.
      (Somebody has to issue and distribute new certs for these keys.
      A cert on a smart card can be replaced easily.)
   b) Signatures intended for long term non repudiation must have been
      completed with validation information (RFC 3116 style;
      "ES-X long" wraped by "ES-A") shortly after creation.
Indeed, b) is demanded by SigG in a relaxed way already.

A different point using current practice: When you create RFC 3116
style ES-X containers, then PKIX signatures can become the same
weight as the signatures required by SigG. But it is obvious that long
term non repudiation signatures become more expensive and complicated
to create. The question is, what is more economic. Compatibilty with
the rest of the world must be respected in the calculations of the
German government for the answer as well. Perhaps there is the root of
the problem.

Kind regards,

   Torsten

-- 
Torsten Hentschel

[The poisitions described by me above are not neccessarily
those of my employer.]

---

From: [email-masked]
Date: Fri, 7 Feb 2003 07:40:13 -0700

not only the key and the certificate independent .... but the certificate
is actually just some representation of a process of RA and certification.
in that sense ... anologous to other certificates &/or license ... aka say
a  driver's license .... representing the test you took to drive. if your
driver's license goes thru the wash (and/or some other process and is
destroyed) ... that doesn't mean that you need to retake the driver's test
to get a new license. your ability to drive is independent of the
certification process ... and the certification/license issue to represent
the test of your ability to drive. typically if some license/certificate is
lost/destroyed ... it is just re-issued.

in the aads model ... it is even taken further. it isn't even necessary to
have a certificate to sign something with a key. it allows for some online
facility that can make a real-time representation to the RA and
certification process.  this is somewhat taken from financial transaction
model .... where something is used for authentication .... but there is a
real-time access to representation  .... especially in a business model
where the business process transaction contains the complete real-time
representation that is something specific to the business process at hand
with higher quality information (aka rather than providing the lower
quality information that a certificate might represent about individual
having a bank account .... the real-time transaction says that there is
actual funds available for the transactions and the movement of money has
actually occured). In that case, the key can be sufficient for the bank to
know that it is one of their customers .... and the merchant doesn't care
particularly any details about you ... they just care whether they get
their money.

http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/index.html#aads

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

[email-masked] on 12/7/2003 3:49 am wrote:

Hi Simon,

Simon Tardell wrote:

.. snip ..