Re: [security-services] the "NotOnOrAfter" issue

I'm very much in sympathy with Rich's mails on this topic. An area 
like this where there's a history of problems is one where SAML 
really should be conservative - which is what I tried to be in 
suggesting one-second and UTC-only restrictions.

A few more things, then I'll shut up about this:-

- Adopting NotAfter vs. NotOnOrAfter for me is simply the issue
of programmers and the "=" sign in code. I don't claim X.509
validity is wonderful - I just don't see any reason why we need
something different, especially not something subtly different.

- Folks have argued that some XML processing substrate will handle
all this, so SAML is ok to just use dateTime. I recall the same 
arguments about ASN.1 compiler runtime libraries offering support 
for things like UTCTime way back in ASN.1-land, but they never really 
got it right (e.g. one ASN.1 compiler/code-generator I recall had 
correctly implemented 1988 DER which unfortunately had an error in
how UTCTime was handled, so when DER got fixed about '93, programs 
using that compiler's code were suddenly broken). Don't even ask 
what happened when compilers tried to handle the various ASN.1 
string formats!

- I checked, and the *DEFINITION* (sorry, couldn't resist:-) of 
dateTime basically says: "its whatever values are allowed in ISO 8601",
then goes on to limit that. I don't have that ISO document myself; I 
don't see any mention of leap seconds, and I do see that dateTime 
has (in general) only a partial ordering defined. That last, is IMO, 
not sufficient for SAML.

- This isn't academic in the way that it might be with X.509
public key certificates which tend to last for about a year. I 
expect SAML assertions with lifetimes in the minutes to be fairly
common, so that many more edge value cases are likely to occur.

Regards,
Stephen.

PS: dateTime seems to be defined at: 
            http://www.w3.org/TR/xmlschema-2/#dateTime 


Rich Salz wrote:
> 
> The x509 notBefore/notAfter fields are second resolution, Stephen(?)
> said. If SAML is going to follow those fields, as opposed to creating
> new "pure and clean" ones, then it should subtype dateTime to enforce that.
> 
> As for timezones, "here be dragons", so mandating everyone convert to a
> canonical format -- UTC -- seems to make sense to me, but it was others
> who were advocating, I was just suggesting how to achieve that.
> 
> > I agree with you about the subtleties and complexities existing, but I
> > stand by my statement that this processing should (and more-and-more
> > often will as XML in general and schema in particular continue to gather
> > momentum) happen in a layer that the SAML-processor is built on.
> 
> My experience on the sopabuilders mailing list is that almost EVERYONE
> got it wrong initially, and I betcha almost everyone has leapseconds
> still wrong.
> 
>         /r$
> --
> Zolera Systems, http://www.zolera.com
> Information Integrity, XML Security
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:
Ireland                             http://www.baltimore.com