[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xcbf] SignedData Attributes - DigitalSignature Attributes
> -----Original Message-----
> From: Phil Griffin [mailto:phil.griffin@asn-1.com]
> Sent: Monday, August 12, 2002 16:43
> To: Alessandro Triglia
> Cc: 'Ed Day'; 'xcbf'
> Subject: Re: [xcbf] SignedData Attributes - DigitalSignature
> Attributes
>
>
> Alessandro,
>
> The type for certificates is certificates, a CHOICE
(OK. I thought I might have missed a recent change in the spec.) If
these definitions haven't changed, "certificates" is a SET OF CHOICE, so
the XER encoding must identify the alternative of the CHOICE. For an
X.509 certificate, the encoding would be:
<certificates><certificate> ... </certificate></certificates>
> 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.
I understand. However, if I am looking at the right spec, the
CertificateChoices type has a component of type Certificate (which is a
SEQUENCE) plus others:
CertificateSet ::= SET SIZE(1..MAX) OF CertificateChoices
CertificateChoices ::= CHOICE {
certificate Certificate,
............
}
Certificate ::= SIGNED { SEQUENCE {
.............. } } which expands into a SEQUENCE.
According to these definitions, I don't understand how I can take a
DER-encoded certificate and insert it within the XER encoding of a
SignerInfo. In order to achieve what you describe, the "certificate"
alternative of CertificateChoices should be an OCTET STRING, rather than
a "Certificate".
Alessandro
> 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>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC