Re: [xcbf] SignedData Attributes - DigitalSignature Attributes

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

Alessandro,

I detest attributes myself, and welcome John's
suggested solution. When I see groups trying to
come up with hard and fast rules and conventions
for attribute versus element use I have to shake
my head and smile. Little value that I can see
in attributes in general, and an incredible
amount of flux associated with their use.

Phil




Alessandro Triglia wrote:

> 
>>-----Original Message-----
>>From: Phil Griffin [mailto:phil.griffin@asn-1.com] 
>>Sent: Monday, August 12, 2002 19:34
>>To: Alessandro Triglia
>>Cc: j.larmouth@salford.ac.uk; 'xcbf'
>>Subject: Re: [xcbf] SignedData Attributes - DigitalSignature 
>>Attributes
>>
>>
>>
>>
>>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.
>>
> 
> 
> Phil, this was exactly my point.  Using an attribute for describing some
> property of the element content is indeed reasonable and is common
> practice, I agree.  Your example of "xml:lang" shows that.  In this
> case, the *application* receives the data (the text string in some
> natural language), and can process it according to the language
> indicated in the attribute.
> 
> Using an attribute to tell the *decoder* how to decode a data item is an
> entirely different thing. If a "format" attribute were used to carry
> encoding information, the "format" attribute itself would not be part of
> the abstract value, and the relationship between the XML document and
> its infoset, and between the infoset and the abstract value, would
> become less clean.  
> 
> The situation becomes still more complex and confused in your last
> example, where you use two attributes, one carrying information about
> the *encoding* of the other.  There is no formal mechanism in XML 1.0
> and in any schema language that can link two attributes in this way.
> Please notice that the order of attributes is arbitrary and not
> significant in XML, so your consideration about left-to-right processing
> does not apply to this case.  But again, linking two attributes in this
> manner is perfectly legal and I understand it may be common practice *if
> the link is defined at the application level* rather than at the
> encoding/decoding level.
> 
> Alessandro
> 
> 
> 
>>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>
>>>
>>
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>