[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xcbf] SignedData Attributes - DigitalSignature Attributes
> -----Original Message----- > From: Phil Griffin [mailto:phil.griffin@asn-1.com] > Sent: Monday, August 12, 2002 16:12 > To: Ed Day > Cc: xcbf > Subject: Re: [xcbf] SignedData Attributes - DigitalSignature > Attributes > > > Not at all. Only the inputs to cryptographic > processing need to be in canonical form. The > suggested attributes will exist in the wrapper > that carries this information. > > Note that in IETF SMIME CMS (and X9.73 CMS), > which defines SignedData, the encoding is BER > for everything but the DER payload that is > signed. > > This is the same technique I wish to apply > here. Phil, what is the ASN.1 type of "certificates" and "crls"? Unless the type is OCTET STRING, according to the current text of XER/VXER, the content of these elements cannot be a base-64 string. If it is OCTET STRING, there is no need of a "format" attribute, as the base-64 encoding would be specified in the schema via a VXER encoding instruction. Alessandro > > Phil > > > > 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> > > > > > > ---------------------------------------------------------------- > 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