OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [xcbf] XCN in XCBF SignedData

I want to propose that we use XCN and code a few
formatting attributes in our XER representations
of ASN.1 values. The needs here will be simple, and
will in no way affect the signature or encryption
processing. But I suppose this means that we will
need an XCN module to be written (or in line XCN
definitions if this is better) by someone involved
in that work and included in our XCBF document.
Here's what I propose.

The SignedData type used in the integrity block
need not be encoded using cXER. Only the content to
be digested for signing needs to be in cXER form. The
message that carries the signature can be ordinary

SignedData has what I've always called two saddle bags,
one for digital certificates and another for certificate
revocation lists (CRLs). These are not central to the
actual payloads carried by the PKCS#7 message types. In
practice, these two components are encoded using the ASN.1
Distinguished Encoding Rules (DER), and so are commonly
treated by current applications as hex blobs. Usually,
they are handed off by applications to tools built for
this purpose for processing.

I'd like these two fields in XCBF to be base64 armored
when they appear as XML markup, so that they can be handed
off easily to tools that process DER encodings, and so that
their XML details need not be understood or displayed. At
the end of the day, these are signed DER objects, and their
signatures must be validated by using applications in that

So I suggest the following solution:

SignedData ::= SEQUENCE {
    version           CMSVersion (v84, ...),
    digestAlgorithms  DigestAlgorithmIdentifiers,
    encapContentInfo  EncapsulatedContentInfo,
    certificates      [0] CertificateSet  OPTIONAL,
    crls              [1] CertificateRevocationLists  OPTIONAL,
    signerInfos       SignerInfos

should be represented as

    <version> ........................ </version>
    <digestAlgorithms> ............... </digestAlgorithms>
    <encapContentInfo> ............... </encapContentInfo>
    <certificates format='base64'> ... </certificates>
    <crls format='base64'> ........... </crls>
    <signerInfos> .................... </signerInfos>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC