OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC