OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[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