Interesting test case

This is an interesting S/MIME test case.  Since our GroupWise S/MIME beta 
software had some difficulty handling it, I'll describe it.

The attachment (yes, there is an attachment to this signed message, just in 
case there doesn't appear to be), is a result of a signed message in cleartext 
form that I originally sent to the PKIX list.  Tom Gundin replied, but his 
reply included my entire original message, including my .vcf file, my 
certificates, and the associated signature, and hence it appears that the 
message was signed by me.  However, since he had modified it when replying, the 
signature doesn't verify.

If signature checking gets carried away, it may reject this outer message as 
invalid, when in fact it should be valid (I think). The fact that the 
apparently signed attachment is invalid should not cause the outer signed 
message to be invalidated -- only the attachment.

I'd be curious to know how different software packages handle this case, both 
S/MIME V2 and V3.

Bob



Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
bjueneman(_at_)novell(_dot_)com
1-801-861-7387

--- Begin Message ---

BJUENEMAN(_at_)novell(_dot_)com on 08/20/99 04:54:00 PM

To:   "tgindin(_at_)us(_dot_)ibm(_dot_)com"@e1.ny.us.ibm.com, 
ietf-pkix(_at_)imc(_dot_)org
cc:
Subject:  Re: NR and Private Key Usage Period





Tom,

Unless I read your message too quickly, to my way of thinking
you have this exactly backwards.  The Private Key Usage
period was supposed to be shorter than, not longer than the
certificate validity.

[Tom Gindin]   You did read it too quickly, because I didn't say which of the
two periods was longer - I thought everybody understood that.  The idea was that
a certificate which was created with a private key usage period shorter than the
certificate validity would be usable for NR signatures only until the PKUP
expired, but that those signatures could be checked against CRL's until the
certificate itself expired.  It is true that X.509 section 11.2 has a note which
might require archiving of expired CRL's, but they wouldn't be available online
and the note's wording is fairly unhelpful: "If a non-repudiation of data
service is dependent on keys provided by the CA, the service should ensure that
all relevant keys of the CA (revoked or expired) and the timestamped revocation
lists are archived and certified by a current authority."  The emphasis on
CA-provided (not CA-certified) keys here might make this note inapplicable to
the case where the NR keys are generated by end-user clients.  This wording is
from the June 1997 version, and perhaps it has been replaced by something which
more obviously binds CA's which certify externally generated keys as NR ones.
If it hasn't been replaced, it should be.

If the current definition of NR means anything at all (which
isn't clear), then I would submit that it PROBABLY means that
that the signature is intended to endure and still be considered
valid long AFTER the certificate has been expired, or even
been revoked, so long as it can be established that it was valid
at the time of signing, e.g., with OCSP, CRLs plus notarized timestamps,
Papal archives, or whatever.

There is virtually no reason I can think of why the Private Key Usage
should extend beyond the expiration date of the certificate --
that just increases the risk of compromise with no concomitant
benefit.

What the Private Key Validity period should do, and the reason why
I am still opposed to deprecating it, is to set a time after which a signature
which was apparently created using a key that was supposedly zeroized
should be looked at with considerable scepticism, to say the least.

(For those who may have tuned in late -- the fact that a certificate has
expired or even been revoked does NOT ipso facto mean that the
signature is not legally binding -- it just means that it may be
more difficult to prove.)

Assuming that keys and certificates are relatively inexpensive, but that
validation of a signature once the certificate has expired is considerably
more expensive than during the validity period (because of the
additional archiving, etc., required), then from the user's perspective
what he would like to do is use short-lived keys and long-lived certificates.

Ignoring cryptanalytic attacks, zeroizing a key is the surest possible
way of protecting against a key compromise. So if a key management
system provides a way to automatically schedule a key for destruction
(or at least to remind the user to destroy it), that would be a Good Thing.

Once the key has been zeroized, from the user's perspective, and especially
from the Relying Party's perspective, the longer the certificate lifetime, the
better, since during the validity period it isn't necessary to have all of the
time stamped archives -- you can just query the CA to see whether
the key is still valid..  But from the CA's perspective, of course, this
isn't too good, because it increases the size of the CRL's.

[Tom Gindin]   This argument only applies to signing certificates, especially
NR, right?

Regards,

Bob

(P.S. -- this is a beta version of GroupWise 5.5 with S/MIME support.
If anyone notices anything wrong with the format, etc., please let
me know so we can fix it.)


Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
bjueneman(_at_)novell(_dot_)com
1-801-861-7387

<tgindin(_at_)us(_dot_)ibm(_dot_)com> 08/20/99 10:12AM >>>

     Today, Private Key Usage Period is recommended against by RFC 2459 (section
4.2.1.4).  Given that most of the scenarios for NR require that certificates be
valid at the time when a signature is to be checked by a third party, which may
be long after the object is signed, shouldn't Private Key Usage Period be used
with NR certificates?

     A possible new wording would be:
     The Private Key Usage Period extension should only be present in
certificates which possess a keyUsage extension with the nonRepudiation bit of
that extension set.

     Similar, but weaker, arguments would apply to permitting this extension
when the keyCertSign bit is set as well, since certificates may also be valid
for a long time.

          Tom Gindin

Bob Jueneman.vcf
Description: Binary data

smime.p7s
Description: Binary data

--- End Message ---

Bob Jueneman.vcf
Description: Vcard

smime.p7s
Description: S/MIME Cryptographic Signature