[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] the "NotOnOrAfter" issue
The problem with the X.509 approach is that it leads to a complex ambiguity in interpretation. To put it another way, Steve has a problem because X.509 is confused and broken. The problem with the X.509 approach is that it requires a very peculiar interpretation of the NotAfter time. Say we have 23:59:59, we have to consider the cert valid on 23:59:59.00 which is expected but also 23:59:59.01 which is not. The mapping from X.509 to notOnOrAfter is actually straightforward, you just have to add on the resolution of the time value which is almost always a second. The alternative is that every SAML implementation has to do the same thing every time a time is measured. What is easier to code SAML if ( NotBefore <= time AND time < NotOnOrAfter) X.509 if ( NotBefore <= time AND trunc (time, NotAfter.resolution) < NotAfter ) Where NotAfter.resolution gives the resolution to which NotAfter is specified. The reason I want to make the change is that practically every X.509 implementation handles time in a subtly different way. I believe that having a clearer set of semantics will make it easier to get interoperability. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Irving Reid [mailto:Irving.Reid@baltimore.com] > Sent: Thursday, January 24, 2002 1:14 PM > To: OASIS Security Services TC; 'pbaker@verisign.com'; Stephen Farrell > Subject: RE: [security-services] the "NotOnOrAfter" issue > > > If I remember correctly, the "NotOnOrAfter" semantics were chosen to > specifically address a problem with the X.509 way of doing > validity time > intervals. I think it was Phill Hallam-Baker that proposed > it, but I could > be wrong. > > The problem with the X.509 restrictions is that you can't create two > non-overlapping certificates without leaving a time gap > between them. For > example: > > cert 1: notBefore 5:00 > notAfter 6:00 > cert 2: notBefore 6:00 > notAfter 7:00 > > Both cert 1 and cert 2 are valid at exactly 6:00. You could > try to make them > non-overlapping by making cert 2 notBefore 6:01, but now > there might be a > time interval where neither cert is valid, depending on how fine the > granularity is on your clock. > > By using notBefore/notOnOrAfter semantics, you can create two > assertions > that don't overlap and don't have a gap between them no > matter what the > clock granularity is. > > > That's the reasoning. I don't have a strong opinion either > way about whether > it is better to maintain compatibility with existing systems, > or correct > this particular "flaw" in the existing systems. > > - irving - > > > -----Original Message----- > > From: Mishra, Prateek [mailto:pmishra@netegrity.com] > > Sent: Thursday, January 24, 2002 12:49 PM > > To: 'RL 'Bob' Morgan'; OASIS Security Services TC; > > 'pbaker@verisign.com' > > 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 > > >>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. > > > -------------------------------------------------------------- > --------------------------------------------------- > The information contained in this message is confidential and > is intended > for the addressee(s) only. If you have received this message > in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this > message is > strictly forbidden. Baltimore Technologies plc will not be > liable for direct, > special, indirect or consequential damages arising from > alteration of the > contents of this message by a third party or as a result of > any virus being > passed on. > > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. >
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC