[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xcbf] SignedData Attributes - DigitalSignature Attributes
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC