[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