Re: Fw: [xcbf] XCBF CS Ballot

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

Thanks Ed. I copied Paul on this note just as a reminder that this
issue is related to homework from Baltimore. NOTE: I understand
from Paul that he is still working this issue and will respond just as
soon as a solution is available.

But Ed, while I would agree with you that the XER required by XCBF
in this one case is not "schema-valid", I would remark that the resulting
XML markup is well-formed. And it is possible to use tools to generate
encodings that conform to the XCBF requirements. 

This case for using tools to cope with schema imperfections is not so
different from that required to use the LDAP standards, which defines
several object identifiers that do not conform to the ASN.1 standards. 

Likewise, nearly all of the IETF PKIX and S/MIME works are based 
on ASN.1 that when written did not conform to any version of the ASN.1
standards. With the recent withdrawal of X.208 and X.209 as standards,
these security protocols could be considered to no longer be based on any
existing ASN.1 standards at all.

So, the real issue here I think is that either the referenced amendment must
be available to the public before we can progress XCBF beyond CS, or
the required encoding control statements needed to allow a valid OCTET 
STRING type to carry Base64 armored binary data must be added to the 
XCBF schema. 

I fully agree with you that we must fix this in the document before we can
try to make our work an OASIS Standard. And again, I very much appreciate
your pointing this glitch out and supporting the ballot.

Phil


Ed Day wrote:
> > Objective Systems votes to approve with a reservation.  The values
> > 'CertificateSet' and 'CertificateReservationLists' are shown to be OCTET
> > STRING's in the ASN.1 schema.  Yet in the text, the comment is made that
> > these shall be encoded in the markup using base64 encoding.  This is not a
> > valid way to encode OCTET STRING's under the X.693 XML encoding rules.  A
> > document is referenced - X.693 Amendment 1 (VXER) - which proclaims to fix
> > this defect.  But this document is not available for public review at this
> > time.  It is therefore not possible to produce an implementation that
> > conforms to the schema as stated.
> >
> > Ed Day
> > Objective Systems, Inc.
> > REAL WORLD ASN.1 AND XML SOLUTIONS
> > Tel: +1 (484) 875-3020
> > Fax: +1 (484) 875-2913
> > Toll-free: (877) 307-6855 (USA only)
> > mailto:eday@obj-sys.com
> > http://www.obj-sys.com
> >
> >
> > ----- Original Message -----
> > From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
> > To: "[OASIS XCBF]" <xcbf@lists.oasis-open.org>
> > Sent: Monday, January 06, 2003 9:58 PM
> > Subject: [xcbf] XCBF CS Ballot
> >
> >
> > > I have updated the documents for the CS Ballot starting
> > > tomorrow and ending in two weeks. Please review the
> > > files and send any comments to the list. And please vote
> > > on the approval of the work as an OASIS Committee
> > > Specification before January 21, 2003.
> > >
> > > Phil
> > >
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >     
> >   
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>