[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xcbf] SignedData Attributes - DigitalSignature Attributes
> -----Original Message-----
> From: Ed Day [mailto:eday@obj-sys.com]
> Sent: Monday, August 12, 2002 19:04
> To: j.larmouth@salford.ac.uk
> Cc: xcbf
> Subject: Re: [xcbf] SignedData Attributes - DigitalSignature
> Attributes
>
>
> > VXER - Variant XER - *will* provide a BASE64 transfer, but
> VXER is not
> > canonical
>
> What is this? There is no mention of it anywhere I can find
> on the web
> (this is also true of the XCN acronym used in some prior XCBF
> e-mails). It
> seems that if you are going to be using these standards to
> define new specs,
> they should at least be published somewhere..
The "VXER" acronym is less than a week old. It designates the variant
of the XML Encoding Rules that takes account of "encoding instructions"
(such as ATTRIBUTE, NAME, NAMESPACE, LIST, UNTAGGED, etc.). There has
been a recent change in the relationships between XER, CXER, and
encoding instructions.
The initial version of XER (as defined in X.680 and X.693) has been
known as "vanilla XER" and has a canonical variant, CXER.
Much work has been done in the last 12 months to define a comprehensive
set of "encoding instructions" that modify the basic XER encodings to
enhance the power of ASN.1 as a schema language for XML. The "XCN"
acronym (XER control notation) has been used to designate a special
notation that allows to write encoding instructions and assign them to
types and components defined in ASN.1 modules. More recently, the ASN.1
module structure has been extended to allow the specification of
encoding instructions (potentially for any encoding rules) within the
ASN.1 module itself; as a result, the term "XCN" is being used less
frequently.
Now we call (basic) "XER" the basic variant of the XML Encoding Rules
(the old "vanilla XER"). CXER is the canonical variant of XER. Basic
XER and CXER ignore all the encoding instructions that may be present in
an ASN.1 module. "VXER" ("Variant XER") takes encoding instructions
into account. No canonical variant of VXER is (currently) defined.
XER is simple and easy to understand. It is sufficient for many
applications that want an XML encoding of ASN.1 values but are happy
with the most basic forms of XML encoding. VXER is more powerful and
more complex, and enables ASN.1 to compete with other well-known schema
languages (such as XML Schema). VXER allows data interchange between an
ASN.1-based system and a system built with XML Schema.
Alessandro
>
> Regards,
>
> Ed
>
> ----- Original Message -----
> From: "John Larmouth" <j.larmouth@salford.ac.uk>
> To: "Ed Day" <eday@obj-sys.com>
> Cc: "Phil Griffin" <phil.griffin@asn-1.com>; "xcbf"
> <xcbf@lists.oasis-open.org>
> Sent: Monday, August 12, 2002 11:36 AM
> Subject: Re: [xcbf] SignedData Attributes - DigitalSignature
> Attributes
>
>
> > CXER does not support encoding instructions. So an octet
> string value
> > in CXER can only be transferred using hex.
> >
> > VXER - Variant XER - *will* provide a BASE64 transfer, but
> VXER is not
> > canonical.
> >
> > (We have discussed providing a CVXER - Canonical Variant XER, but we
> > have almost agreed not to, at least at present, for some very good
> > reasons: it is very difficult, and it will delay the progression of
> > VXER, which we know is needed.)
> >
> > As Ed rightly says, there is no way you can have canonical encodings
> > that allow both hex and base64 for an OCTET STRING, even if
> you have a
> > "format=" attribute. For canonical encodings, there is
> just one, and
> > only one, way of encoding an octet string. For CXER, that is hex.
> >
> > John L
> >
> >
> > Ed Day wrote:
> > >
> > > I thought in a canonical XER encoding things could be
> done one way and
> only
> > > one way. Doesn't introducing these attributes violate
> the canonical
> rules?
> > >
> > > Regards,
> > >
> > > Ed Day
> > > Principal Engineer
> > > Objective Systems, Inc.
> > > 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: "Phil Griffin" <phil.griffin@asn-1.com>
> > > To: "xcbf" <xcbf@lists.oasis-open.org>
> > > Sent: Monday, August 12, 2002 9:02 AM
> > > Subject: [xcbf] SignedData Attributes - DigitalSignature
> Attributes
> > >
> > > > I proposed on 8/6 that the following XML markup be used
> > > > in XCBF.
> > > >
> > > > <version> ........................ </version>
> > > > <digestAlgorithms> ............... </digestAlgorithms>
> > > > <encapContentInfo> ............... </encapContentInfo>
> > > > <certificates format='base64'> ... </certificates>
> > > > <crls format='base64'> ........... </crls>
> > > > <signerInfos> .................... </signerInfos>
> > > >
> > > > The signature component of the SIGNATURE parameterized
> > > > type identifies a value of type BIT STRING. These bits
> > > > are not used as bit flags, and signatures tend to be in
> > > > the thousands of bits in length and can more easily and
> > > > compactly be represented as OCTET STRINGs. I propose that
> > > > the following XML markup be used for these values:
> > > >
> > > > <signature format='hex'> ... </signature>
> > > >
> > > > So far, I have received no comments. Unless I hear comments
> > > > that use of these attributes is unacceptable, I will include
> > > > them in the next release of the XCBF document.
> > > >
> > > > 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>
> >
> > --
> > Prof John Larmouth
> > Larmouth T&PDS Ltd
> > (Training and Protocol Development Services)
> > 1 Blueberry Road
> > Bowdon j.larmouth@salford.ac.uk
> > Cheshire WA14 3LS Tel: +44 161 928 1605
> > England Fax: +44 161 928 8069
> >
> > ----------------------------------------------------------------
> > 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>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC