Re: [xcbf] SignedData Attributes - DigitalSignature Attributes

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

No problems with making them binary opaque objects.  The issue is how
the base64 encoding is handled.

If you don't need to be canonical, then VXER allows you to specify
base64 transfers of octet strings.  That is all you need.  There is no
need for a "format=" attribute.  That would only be needed if the format
was an encoder's option, and that is NOT planned for VXER.

John L


Phil Griffin wrote:
> 
> Alessandro,
> 
> The type for certificates is certificates, a CHOICE
> of either X.509 identity certificates, X.509 attribute
> certificates as defined in the free ITU-T module database:
> (http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/index.html)
> or, the X9.68 compressed domain digital certificate (see
> http://asn-1.com/x968.htm), an open type that allows for
> other flavors of certificates to be used as they evolve or
> become prevalent.
> 
> Generally, certificates are a SEQUENCE type. They are signed
> objects, so they can be carried in the clear in SignedData,
> as they are already protected. Certificate signatures are
> computed over a DER encoding of their content. To be useful,
> and generally to be handed off to a validation and verification
> tool, they must be in binary.
> 
> For the purposes of XCBF, they are peripheral to our work and
> need not be decoded into XML markup in order to use the XCBF
> specification. Note that the certificates and crls components
> of SignedData are optional, and that even when present in a
> message, these components may carry more or less certificates
> and crls needed to verify a signature.
> 
> So it is best to simply make them opaque objects, as their
> structural details are of no consequence in XCBF.
> 
> Phil
> 
> Alessandro Triglia wrote:
> 
> >
> >>-----Original Message-----
> >>From: Phil Griffin [mailto:phil.griffin@asn-1.com]
> >>Sent: Monday, August 12, 2002 16:12
> >>To: Ed Day
> >>Cc: xcbf
> >>Subject: Re: [xcbf] SignedData Attributes - DigitalSignature
> >>Attributes
> >>
> >>
> >>Not at all. Only the inputs to cryptographic
> >>processing need to be in canonical form. The
> >>suggested attributes will exist in the wrapper
> >>that carries this information.
> >>
> >>Note that in IETF SMIME CMS (and X9.73 CMS),
> >>which defines SignedData, the encoding is BER
> >>for everything but the DER payload that is
> >>signed.
> >>
> >>This is the same technique I wish to apply
> >>here.
> >>
> >
> >
> > Phil, what is the ASN.1 type of "certificates" and "crls"?  Unless the
> > type is OCTET STRING, according to the current text of XER/VXER, the
> > content of these elements cannot be a base-64 string.  If it is OCTET
> > STRING, there is no need of a "format" attribute, as the base-64
> > encoding would be specified in the schema via a VXER encoding
> > instruction.
> >
> > Alessandro
> >
> >
> >
> >>Phil
> >>
> >>
> >>
> >>Ed Day wrote:
> >>
> >>
> >>>I thought in a canonical XER encoding things could be done
> >>>
> >>one way and only
> >>
> >>>one way.  Doesn't introducing these attributes violate the
> >>>
> >>canonical rules?
> >>
> >>>Regards,
> >>>
> >>>Ed Day
> >>>Principal Engineer
> >>>Objective Systems, Inc.
> >>>Tel: +1 (484) 875-3020
> >>>Fax: +1 (484) 875-2913
> >>>Toll-free: (877) 307-6855 (USA only)
> >>>mailto:eday@obj-sys.com
> >>>http://www.obj-sys.com
> >>>
> >>>
> >>>----- Original Message -----
> >>>From: "Phil Griffin" <phil.griffin@asn-1.com>
> >>>To: "xcbf" <xcbf@lists.oasis-open.org>
> >>>Sent: Monday, August 12, 2002 9:02 AM
> >>>Subject: [xcbf] SignedData Attributes - DigitalSignature Attributes
> >>>
> >>>
> >>>
> >>>
> >>>>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>

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