[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] the "NotOnOrAfter" issue
On Tue, 22 Jan 2002, Stephen Farrell wrote:
- NotOnOrAfter. This is different from most end-date types specified
elsewhere, in particular the notAfter field in many ASN.1 structures.
There is no justification given for this semantic change which will
cause new boundary conditions and hence new (probably broken) code. For
example, if an issuer has an X.509 certificate with a notAfter of
20021231235959Z then what is the latest NotOnOrAfter value that should
result in a valid assertion? What is the first NotOnOrAfter value that
should result in an assertion being invalidated for this reason? I don't
know the answers. Gratuitous changes are bad things. This is one such.
I agree that in this case consistency with X.509 Validity field:
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
makes good sense, and support changing the NotOnOrAfter Condition
attribute to "NotAfter". Is there some good argument as to why it should
be NotOnOrAfter?
- RL "Bob"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC