Subject: Re: Signing what you don't understand

From: [email-masked]
Date: Thu, 20 Jul 2000 14:09:56 -0400

Denis,

>> Note I'm not talking about NR here -
>
>So what are you talking about ???

The case where an RP receives a document and is trying to verify a
signature.  The significance of the NR bit in a certificate was the
starting point for this discussion, but for now I'm simply concerned with
the initial signature verification (if the RP doesn't believe my signature,
he certainly can't expect to hold me to it :).  Note I'm not restricting
this to simple E-mail, where because of the one-to-one, low-latency nature
of the communications involved, there is unlikely to be a significant time
between signing and verifying (and if there is, the RP can simply ask the
sender for a freshly-signed copy).  Rather, I'm talking about high-latency
or one-to-many environments.  An extreme example of this might be signing a
document and placing it on a web-site or in a directory - here I am signing
the document without any knowledge of the identity of the RPs, and with the
possibility of significant delay before an RP will try to verify the
signature.

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

In the situation I'm discussing, one of the CAs that the signer chose to
embed in his signature has already gone out of business by the time the RP
sees the signature.

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

Yes, that's a concise statement of the problem.  By requiring that the
signer choose a specific Signature Policy (including, in the context of
this discussion, the certificate chain), rather than leaving it to the RP
to construct the chain, there is a possibility of a signature being
incorrectly determined as invalid.  By omitting the signer's certificate
chain, and leaving it up to the RP to construct an appropriate chain, then
if my CA goes out of business, it wouldn't necessarily invalidate my prior
signatures (providing my key can be certified by another CA).

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

It's not contradictory:  Evidence that a certificate had not been revoked
at time T could include a CRL that was valid at T, and that did not list
the certificate.  However, if later a CRL were published (and were
available to the RP) that included the certificate, along with an
invalidityDate before time T, then the RP can conclude that the certificate
has been revoked, and should not be trusted to verify a signature made at
T.

John

---

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

John,

If you attend the next meeting in Pittsburgh, I propose that we
continue this discussion in the corridors. I will nevertheless
answer your questions.

> possibility of significant delay before an RP will try to verify the

Your are talking NR without knowing it. :-)

In your example, the signed data does not have NR properties but the
RP would like to get the the NR properties. So unless the signer
places signed data that have NR properties, the case CANNOT be
solved, i.e. disputes cannot be solved, just because there is not
enough information available to solve the dispute.  So unless
"sufficient" information is orginally placed, the signed message
does not have long term properties.

> incorrectly determined as invalid.  

This is incorrect. If in this specific case, all the chain is built
by the signer (including proof that every certificate from the chain
was not revoked at the time of the signature) then there is only ONE
determination possible. This means the chain must be constructed
while all the CAs are still in business, ... and this solves the
case.

> By omitting the signer's certificate

(snip) 

> has been revoked, and should not be trusted to verify a signature made at

You should talk a closer look at <draft-ietf-smime-esformats-01.txt>
section 4.1.1  Signature Timestamp Attribute Definition  

The Signature Validation Policy specifies, in the
signatureTimestampDelay field of TimestampTrustConditions, a maximum
acceptable time difference which is allowed between the time
indicated in the signing time attribute and the time indicated by
the Signature Timestamp attribute. If this delay is exceeded then
the electronic signature *must* be considered as invalid.

This means that the signed data *must* include a signing time (as a
signed attribute from the CMS construct). This allows to solve
unambiguously the case.

Denis