Re: [xcbf] SignedData Attributes - DigitalSignature Attributes

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

Alessandro Triglia wrote:

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


This may be a problem with the design of some
tools, but using attributes on markup tags to
describe the characteristics of the content
that the tags encapsulate is common practice.

Given

    Examp ::= SEQUENCE {
      this  BOOLEAN,
      that  BIT STRING
    }

It is easy enough to specify an instance of type
Example using XML markup as

   <Examp format='base64'> D234592FF0F </Examp>

This encoding is processed from left to right, so
the attribute indicating the formatting of the
value of type Examp is seen by a tool when the
tool examines the 'Tag', the character string
"<Examp format='base64'>", which is before it
encounters the actual value.

Whether this is desirable or not, this is common
practice for XML markup when using such as the
language attribute, xml:lang='it', for example.

It is not even unreasonable to expect the likes
in XML of

   <Examp format='base64' value='D234592FF0F'/>

Phil


 
> 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>
>>
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>