[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC