[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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. 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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC