[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xcbf] X9.84 question - Representation of dates/times
Bancroft Scott wrote: > > On Fri, 12 Apr 2002, Phil Griffin wrote: > > > > > > > Bancroft Scott wrote: > > > > > > On Fri, 12 Apr 2002, Phil Griffin wrote: > > > > > > > As I stated in this thread, if the receiver preserves the > > > > encoding used in the signature process as sent, it does > > > > not even matter if the encoding is not canonical or that > > > > it is encoded correctly. > > > > > > > > But an LDAP thread recently reveals that the receiver often > > > > does not preserve the original encoding of DER objects, which > > > > can mask encoding errors that become apparent only when > > > > the receiver tries to encode again and the signature > > > > check fails. > > > > > > I think that this is a bit different, Phil. Given that RELAIVE-OID > > > is in use, any change to it between decoding and re-encoding would > > > be fundamental. It would be exactly as if we had the likes of > > > "name UTF8String,". Although "Bancroft Scott" and "Bancroft Scott " > > > are the same abstract values in a sense, we don't make rules for > > > applications to follow about what to do about trailing blanks. Along > > > > Actually Bancroft, you're totally wrong here. You're > > thinking only about the sorts of rules you commonly > > make in the ASN.1 standards. This is an application > > standard, and it would be perfectly within scope to > > assert that trailing blanks should not be used by a > > message sender. The two strings you provide in fact > > would fail an exact match test, yet they would appear > > when displayed to a human user exactly the same. > > I *think* I follow what you are saying - what we are specifying here is at > the application level, so it is appropriate to impose such rules. No > argument. > > So, do you wish to forbid trailing 0's in RELATIVE-OID's when they are > used for date-time? What about UTF8String values in particular uses, > do we restrict trailing blanks? Anything else that we should be > considering? Let's just look at DateTime first. Just as I started to write this it dawned on me, and after noticing X9.68 throughout this thread, that type DomainCertificate is referenced in X9.84 in the second ASN.1 schema module that I have not yet reviewed and posted to our web site as: CertificateChoices ::= CHOICE { certificate Certificate, attrCert [1] AttributeCertificate, domainCert [2] DomainCertificate, -- X9.68:2 otherCert [3] OtherCertificate } So we do use DateTime in this context, and not just in the biometric object. With this too slow to come revelation, I am now leaning towards text that warns the user that there is more than one way to represent the same date and time since trailing zeros are allowed, and to recommend that senders always strip trailing zeros (except as noted) to achieve the smallest possible encodings, and that receivers be prepared to accept whatever comes. Phil > ------------------------------------------------------------------------- > Bancroft Scott Toll Free :1-888-OSS-ASN1 > OSS Nokalva International:1-732-302-0750 > baos@oss.com Tech Support :1-732-302-9669 x-1 > 1-732-302-9669 x-200 Fax :1-732-302-0023 > http://www.oss.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC