Subject: Comment on RFC 3161

From: "hermes3.si.c-s.fr" <[email-masked]>
Date: Thu, 04 Apr 2002 07:39:57 +0200

Hi!

I wonder something about the first security considerations of RFC 3161 (§4.1).

It says that if the TSA private key shall not be used any more and
is not compromised ,
the corresponding certificate shall be revoked with a reason code.
Thus any token signed with the corresponding key before the revocation time
will remain valid.

However we could imagine that the key becomes compromised after the
revocation, allowing
the "hacker" to generate time-stamp tokens with a date previous to
the revocation time.
Thus false tokens will be consider as valid...

The point is how to get the crucial "before" in " ... before the
revocation time" .

If someone can help ...

Antoine Bourrouilh

---

From: "José A. Mañas" <[email-masked]>
Date: Thu, 04 Apr 2002 12:53:26 +0200

I think you are right,
and I think it is a problem with any signature:
the status of the cert must be ok when the verification is run.

For the case of time-stamping,
there is renewal procedure such that an old time-stamp token
is enveloped within a new token thus extending the value
of the first token from the original instant to the
end of the validity of the enveloping token.
If renewal is applied regularly
(always before the outmost key is compromised)
the value may be extended indefinitely.

Hope it helps,
jam

-- 
-----------------------------------------------------------
Prof. Jose A. Manas                mailto:[email-masked]
Dpt. Telematica                http://www.dit.upm.es/~pepe/
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid                      gsm: [+34] 609 62 70 98
SPAIN                               fax: [+34] 91.336 73 33

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Apr 2002 09:32:51 +0200

Good catch !

Here is a proposal to fix it and replace the whole 4.1 :

      When the reason code extension indicates keyCompromise then all 
      the tokens that have been signed with the corresponding private 
      key SHALL be considered as invalid.

      When the reason code extension indicates other reasons like 
      affiliationChanged (3) or cessationOfOperation (5), then this 
      reason code is definitive. However, should a key compromise 
      happen later on, it will not be reported by the CA. A good 
      practice will be for the TSA to warn its subscribers in advance 
      for a future revocation, so that they can apply another 
      time-stamp token over the previous one and capture the CRL from 
      the CA that has issued the certificate to the previous time-
      stamping unit.

Denis

Note: ISO is working on an extension that will allow to announce in advance
the revocation of one certificate or a set of certificates. Once this is
done we could consider to support this extension in PKIX.