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