Subject: Timestamp: 03: extensions

From: "Manger, James" <[email-masked]>
Date: Mon, 27 Sep 1999 14:26:00 +1000

Use Attribute, instead of Extension, to offer extensibility in the timestamp
token.
334c334
<      extensions                   [4] EXPLICIT Extensions OPTIONAL
---
>      attributes                   [4] SEQUENCE OF Attribute OPTIONAL

The PKIX community are familiar with the Extension type from dealing with
Certificate & CertificateList values, but are even more familiar with
Attribute from dealing with Name & CertificationRequest (PKCS#10) values,
the [un]authenticatedAttributes field of PKCS#7 [CMS] signed values and
other items.

A certificate can be quite a sophisticated trust statement.  It also deals
with complex issues such as naming & identity.  Consequently, an extension
can change the meaning of another field and the criticality feature is
required to indicate when this occurs.  A timestamp, on the other hand, has
one simple meaning - "this token was created at this time".  I doubt this
meaning can be altered by an extension so a critical flag per extension is
not required.  Note: a semantics identifier provides functionality like a
critical bit (& more) [See earlier e-mail titled "Timestamp: 03: semantic id
instead of version number"].

If Extension is retained, there needs to a description of what to do when an
unrecognized extension is marked critical.  A certificate with such a value
must be rejected.  A CRL with such a value is still useful but may be
incomplete (a certificate on the list should still be treated as revoked).
A timestamp with such a value ???.  Presumably the time field still
indicates when the token was created so the token still has some value (i.e.
"reject on unrecognized critical extension" is too harsh).