Subject: Re: Signing what you don't understand

From: [email-masked]
Date: Fri, 21 Jul 2000 11:39:30 -0400

Denis,

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

You are missing what I'm trying to say.  I'm not disputing that the
signature was created at the time claimed.

The fact that CRLs include an invalidityDate field, which can indicate that
a certificate was invalid well before that CRL was published means that it
is possible for a certificate revocation to be "backdated" - i.e. even
though a perfectly valid CRL was referenced in the signature and indicated
that the certificate was valid at the time the signature was constructed,
another CRL can be published (possibly much) later that will say the
certificate was invalid at the signing time.

This renders signer-provided evidence of non-revocation of little use
(unless you are willing to let the signer-provided evidence of
non-revocation trump the more recent CRL that asserts that the certificate
was invalid, which would open up a lot of security holes).

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

I think you're agreeing with the point I was originally trying to make.
This conversation started because it was suggested that simply using the
correct certificate chain would obviate the need for putting anything
special into the signature in support of NR - my response was that binding
the cert chain into the signature has some disadvantages, notably that the
signature can be rendered unverifiable _by_the_RP_ by circumstances that
ought to have no bearing on the signer's trustworthiness.  You appear to be
countering this with a requirement that the signer put special evidence
designed in support of NR (but in this case used by the RP to perform an
initial signature verification) into the signature in addition to the cert
chain.  I pointed out above that, due to the possibility of backdated
revocations, this doesn't really work, but that's really beside the point,
since requiring putting NR evidence into the signature is itself an
addition to the signature.

John

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 21 Jul 2000 18:11:44 +0200

John,

(deleted text)
 
> certificate was invalid at the signing time.

OK. I now understand better ! The point you are raising is
interesting.

If the RP uses the current CRL then he is *sure* that he is missing
revocations that recently occured. In any case the time to wait for
fetching the revocation status of a certificate is "signature policy
dependent". But let us suppose that the time is set to a very short
period of time. In that case the RP thinks he holds a valid proof
(this is the case you mention) and the signer, in order to object
would have to ask for the CA to prove when his certificate was
revoked.

The case you mention also exists with OCSP server, even if it
provide "real time" information just because it is reasonable to
give time to the real signer to report a key compromise. 

The conclusion is that the signature policy must set a period which
is "big enough and reasonable". This is for this reason why when
validating an electronic signature you may get "incomplete
validation" which means that you have to try again later on.

For high value transactions, the time to wait might be counted in
days (to make sure that the real user noticed that his private key
has been compromised and to give him the time to report).

> was invalid, which would open up a lot of security holes).

(deleted text)

> I think you're agreeing with the point I was originally trying to make.

In that case that's fine !

Denis

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jul 2000 13:16:35 -0400

John,

<snip>

>was invalid, which would open up a lot of security holes).

The inclusion of the invalidity date in a CRL does not allow 
backdating, although it may appear that way.  The argument put forth 
to justify approval of this extension was to allow the CA to alert 
RPs to newly gained info re a revocation so that IF the RP had not 
acted upon a transaction (or the like) THEN the RP could elect to 
treat the signature as invalid.  However, if an RP has collected a 
CRL that covers the interval during which the transaction took place, 
then any later CRL with an invalidity date does not prevent the RP 
from using the CRL he acquired to support NR, i.e., the RP has 
exercised due diligence by obtaining the first CRL.

<snip>

Steve