Re: [xcbf] SignedData Attributes - DigitalSignature Attributes

[John Larmouth <j.larmouth@salford.ac.uk>]

Phil Griffin wrote:
> 
> Then it appears that XER is not sufficient here.
> 
> It should be possible to send meta data in the
> communication, as how would both sides know if
> '011000' were a three octet string or a six bit
> binary value.

No.  Both sides know because they have the same schema and encoding
instructions.

> This is what attributes are used
> for in XML.

There is much disagreement on what attributes are or should be used for
in XML.  
Originally (in your time with ASN.1) we did indeed use an attribute to
identify the form of an encoding, and made the choice an encoder's
option.  We backed off that for very good reasons.

I suppose if you really wanted to (with VXER) you could have a CHOICE
{hex OCTET STRING, base64 [BASE64] OCTET STRING}.  But that would be
very dirty.
 
> 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, 

XCBF is a major user of XER and CXER and VXER, and we want to try to
meet your needs.  But please also recognise that if we are to approve an
XCBF document, we will be expecting it to be conformant to one of these
encoding rules.  You cannot just invent random XML instances
(encodings).

I for one will not be able to support an XML instance example in an XCBF
document that is not one of the XER encodings of the ASN.1 schema.

On the other-hand, as a major user of XER, if you make your real needs
clear, we will see what we can do to accommodate them.

John L

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

-- 
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Development Services)
   1 Blueberry Road                     
   Bowdon                               j.larmouth@salford.ac.uk
   Cheshire WA14 3LS                    Tel: +44 161 928 1605
   England				Fax: +44 161 928 8069