Re: [xcbf] SignedData Attributes - DigitalSignature Attributes

[Phil Griffin <phil.griffin@asn-1.com>]

John,

You must not have read my reply to Ed. Only
cryptographic processing inputs need to be
canonical. The rest of the message need only
be XML markup.

CMS uses BER for everything in SignedData but
the encoding of the cryptographic payload. And
X.509 certificates are formed from a BER wrapper
around a DER encoded signed content.

This is common practice as it allows for use of
indefinite length encoding of those components
whose processing (say using pipes) can benefit
from not knowing the length of the data before
starting to transmit the data.

Phil


John Larmouth wrote:

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