RE: [xcbf] SignedData Attributes - DigitalSignature Attributes

[Alessandro Triglia <sandro@oss.com>]

> -----Original Message-----
> From: Phil Griffin [mailto:phil.griffin@asn-1.com] 
> Sent: Monday, August 12, 2002 17:37
> To: j.larmouth@salford.ac.uk
> Cc: xcbf
> Subject: Re: [xcbf] SignedData Attributes - DigitalSignature 
> Attributes
> 
> 
> Then it appears that XER is not sufficient here.
> 
> It should be possible to send meta data in the
> communication, 


Is is certainly possible to send metadata in the communication.  

However, relying on the value of a data item (an attribute) to determine
the XER encoding of another data item of the same data structure is a
different thing, and was avoided.  If you think about it, this would
require a decoder to examine the value of an attribute before it was
able to complete the decoding of another data item.  Such a dependence
is not desirable.

Attributes in XER are just components of a SEQUENCE that happen to be
encoded as XML attributes rather than as child elements.  In (vanilla)
XER and in CXER, the same components are always encoded as child
elements, never as attributes.


> as how would both sides know if
> '011000' were a three octet string or a six bit
> binary value. This is what attributes are used
> for in XML.


I disagree. There is no such capability in RELAX NG and XML Schema **at
the encoding/decoding level**.

You can clearly include metadata in an ASN.1 schema, but that would be
information about the data, not information about how the data is to be
encoded/decoded by the XER encoder/decoder.  You can do what you
describe above by defining the component as a UTF8String and having the
application deal with the value.  The question is why?

Alessandro



> 
> I did not seek to disallow a BIT STRING signature
> from being carried or displayed as bits when I
> proposed that it also be allowed to carry this
> information as octets.
> 
> And I would not wish to prohibit an application
> from carrying a certificate signed as an XML
> encoding as XML instead of as a base64 encoding.
> 
> Phil
> 
> 
> 
> 
> John Larmouth wrote:
> 
> > The "format=" is not current XER.
> > 
> > This needs thinking through a bit more, Phil.
> > 
> > We certainly intend to allow BASE64 encodings, but currently the
> > specification that it is BASE64 will be part  of the encoding
> > instructions (known to both sides), and not something which 
> is carried
> > in an instance of communication.
> > 
> > So I guess I oppose your "format=" parameter.
> > 
> > Why do you need to have that transmitted in the XML?
> > 
> > John L
> >  
> > 
> > Phil Griffin wrote:
> > 
> >>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>
>