Subject: Re: Signing what you don't understand

From: [email-masked]
Date: Thu, 20 Jul 2000 10:58:08 -0400

Steve,

>>What other mechanisms would cover that case of my issuing CA going out of
>>business?  If a CA's assets (including its keys) are sold as part of a
>>bankruptcy process, I would think that trust in those keys would be
fairly
>>quickly revoked by other CAs that might have cross-certified it.  In this
>>case, invalidityDate on those revocations would probably be set so that
no
>>certificate that had been issued by the former CA's key would be trusted
>>(to prevent the keys' new owners from issuing new backdated
certificates).
>>However, as a subscriber to the former CA, I don't see why my signatures
>>should suddenly become less trustworthy, if my key can be verified via
>>another path.
>
>A RP can be responsible for acquiring all the requisite evidence for
>later support of signed document validity, including time stamping
>this evidence. I think this addresses the scenario you described
>above.

That addresses the case where the document is processed by the RP prior to
my CA going out of business, but it doesn't help if trust in the CA has
already been revoked at the time the RP tries to verify the signature.
Note I'm not talking about NR here - In the scenario I'm concerned with,
the RP will itself not trust my signature, even though it should be valid.
In an e-mail environment, this may not matter too much, as the RP could
simply ask the signer to re-send a freshly signed copy of the e-mail, but
in a work-flow or EDI environment, where documents move through a system
acquiring multiple counter-signatures over portions of the documents, it
may be impractical to simply re-start the process.

It is possible for the signer to timestamp his signature, along with a
complete certification path from some root CA, along with CRL- or
OCSP-based liveness evidence for every certificate on that path.  This is,
I think, what ESS terms a signer-generated ES-X.  But that doesn't help
unless the RP directly trusts the signer's root CA.  If the RP doesn't
trust the root that the signer chooses, then the timestamped chain is of
little use to him, since it won't say anything about the certificates in
the chain the RP constructs (although if a chain from one of the RP's
trusted roots happens to "join up" with some fraction of the signer's
timestamped chain, then the timestamp can be used as evidence of validity
at signing time of the fraction of the chain below the intersection point).

Even if the RP does trust the signer's root, though, it's not clear why the
RP's software should believe a signature based on a certificate chain that
contains revoked certificates (with invalidity dates that precede the
signature date), even if it includes evidence that at the time of signature
creation, those certificates had not yet been revoked.  Even if not
rejected outright, such a signature should be treated as at best
suspicious.

John

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 20 Jul 2000 18:16:27 +0200

John,

Let me jump in this discussion (and hopefully go out very quickly).

> (...)

> already been revoked at the time the RP tries to verify the signature.

Don't you think that if a RP receives a siganture it has better to
make sure that what it gets is "fine" ? So he should validate the
signature as soon as possible and in order to cover the case of a
possible (volontary) revocation of the signer certificate, he should
time stamp the signature as soon as possible. So the case you are
considering is not a practical case.

> Note I'm not talking about NR here - 

So what are you talking about ???

> In the scenario I'm concerned with,
> I think, what ESS terms a signer-generated ES-X.  

Yes. This is one of the formats that may be used.

> But that doesn't help
> unless the RP directly trusts the signer's root CA.  

There is no concept of root CA. There is a concept of a Signature
Policy that may involve one or more root CAs but involves many other
conditions.

> If the RP doesn't
> trust the root that the signer chooses, 

 ... you mean : If the RP thinks that the Signature Policy is not
adequate for his context of use, then this is the end of the story.

> then the timestamped chain is of
> creation, those certificates had not yet been revoked.  

This is contradictory. "if it includes evidence that at the time of
signature creation, those certificates had not yet been revoked"
means that you must provide a proof that the certificates whre not
revoked at the time of the signature, so you cannot say at the same
time "certificate chain that contains revoked certificates".   

Denis

> Even if not

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Jul 2000 18:38:28 -0400

John,

>may be impractical to simply re-start the process.

I agree that in a more slowly moving processes you describe above the 
window for the CA vanishing is greater, but in practice I think it 
would be quite rare.  If it's quite rare, it's feasible to restart 
the process.

>at signing time of the fraction of the chain below the intersection point).

In practice today (and maybe the right way in the long run anyway) 
there are not multiple choices for a root relative to a specific 
signer.  For example, if I operate in an organization context, my 
cert is issued by my org, period.  My org may not choose to be 
certified by any TTPs, or it may choose only one.  In such cases, an 
RP has a take it or leave it option.  In the physical world we often 
have this sort of credential situation.  If you don't trust the bank 
from which I got a letter of credit, we don't do business. If you 
don't trust D&B for a background check on a U.S. business, your 
options are severely limited.

>rejected outright, such a signature should be treated as at best

When we check a signature for NR, and significant time has elapsed 
since the signature was applied, then different rules must be 
employed.  After all, the certs may have expired and, unless we make 
use of the private key validity interval extension (which is not too 
common), we still consider the signature to be potentially valid. One 
might define this as an "archival signature validation" process, with 
different rules and additional inputs (e.g., TSA signed data ...).

Steve

---

From: Aram Perez <[email-masked]>
Date: Thu, 20 Jul 2000 18:38:08 -0700

Hi Steve K.,

> employed.

How do you know how much "time has elapsed since the signature was applied"?
I am not aware of any standard that mandates the time of the signature.
S/MIME/PKCS#7 has provision for the signature time, but they don't mandate
it.

Regards,
Aram Perez

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 21 Jul 2000 09:23:38 +0200

Aram,

ETSI Standard ES 201733 mandates the signature time as a signed
attribute of the CMS structure. An informational draft RFC based on
that standard is available from:

http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-01.txt

Denis

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jul 2000 09:34:34 -0400

Aram,

>S/MIME/PKCS#7 has provision for the signature time, but they don't mandate

If one is looking to effect NR, one has to do a number of things 
beyond simple signature checking of the sort required for typical 
authentication for input to an access control process.  For example, 
one often needs to time stamp the signature on the data, collect the 
certs and CRLs and have them time stamped, etc.  This creates a 
context that allows NR signature verification for the longer term 
than the validity of the signer's cert, or the signer's CAs' cert, 
etc.

Steve

---

From: Aram Perez <[email-masked]>
Date: Fri, 21 Jul 2000 08:38:36 -0700

Hi Denis P.,

> attribute of the CMS structure.

How widely implemented/used is this standard? Who determines the signature
time? Is the signature time "certified"?

> An informational draft RFC based on

How long before this "informational draft RFC" becomes a standard?

Regards,
Aram Perez

---

From: Aram Perez <[email-masked]>
Date: Fri, 21 Jul 2000 08:45:16 -0700

Hi Steve K.,

> than the validity of the signer's cert, or the signer's CAs' cert,

Without regurgitating the previous discussions on the validity of the NR
bit, where would someone know that if you are trying "to effect NR, one has
to do a number of things beyond simple signature checking"? Denis P. pointed
out ETSI Standard ES 201733, but how many implementers of digital signatures
that effect NR have read that standard and implemented it?

Regards,
Aram Perez

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jul 2000 12:42:51 -0400

Aram,

>to do a number of things beyond simple signature checking"?

 From my perspective most of the NR burden usually is on the RP, and 
an RP knows when it is interested in NR vs. simple authentication.

>Denis P. pointed

I doubt that this is widely used yet, but then I see very little if 
any use of digital signatures for high value, long term NR anyway.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 24 Jul 2000 11:39:02 +0200

Aram,

> How widely implemented/used is this standard? 

This standard has been published in April 2000. It will take some
time before it gets implemented. 

> Who determines the signature

Look at the details. Everything is explained within the document.

> How long before this "informational draft RFC" becomes a standard?

Since the basic document (i.e. ES 201733) is copyrighted by ETSI,
but the IETF has been given the right to publish the document, but
not to modify it. Hence the reason why it will stay has
INFORMATIONAL. The basic document is available for free from the
ETSI site. (http://www.etsi.org)

Denis