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.
781 245 6996 x227
> -----Original Message-----
> From: Irving Reid [mailto:]
> Sent: Thursday, January 24, 2002 1:14 PM
> To: OASIS Security Services TC; ''; 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:]
> > Sent: Thursday, January 24, 2002 12:49 PM
> > To: 'RL 'Bob' Morgan'; OASIS Security Services TC;
> > ''
> > 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.
>
