[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] the "NotOnOrAfter" issue
Agreed, this usage of "NotOnOrAfter" is quite puzzling. I had been agitating for its removal some time ago, but I guess we have never worked thru it on the list. I would propose that if there is no good reason given by Tuesday, Jan 29, we should switch to NotAfter. - prateek >>-----Original Message----- >>From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu] >>Sent: Wednesday, January 23, 2002 7:34 PM >>To: OASIS Security Services TC >>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" >> >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC