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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[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