Re: [xcbf] SignedData Attributes - DigitalSignature Attributes

[John Larmouth <j.larmouth@salford.ac.uk>]

Hopefully all this stuff will be approved (at least by ITU-T) long
before any OASIS work using it is approved.  But I agree that part of
the problem here is that Phil is making assumptions about the form and
direction of work in progress.

John L


Ed Day wrote:
> 
> > 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..
> 
> 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>

-- 
   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