Re: QUESTIONS ?

Hi Apvrille,

There are two possible ASN.1/XML based solutions
here. One, as you describe, would use DER for the
input to the message digest and signature processes.
That solution would only give you a standard way to
express the ASN.1 abstract values using XML markup.
You could use this technique now with CMS to give
any ASN.1 encoded binary values an XML representation.

But there is another solution, and it only involves
using XML markup. Here, all inputs to the message
digest and subsequent signature processes are encoded
using the canonical variant of XER instead of DER. In
this solution, no binary encodings are used.

For the sake of clarity, consider the current description
of the message digest process for SignedData from XCBF,
noting that this is a simplified use of SignedData as
there are no signed attributes present:

    "A message digest is used to create the digital
    signature carried in the SignerInfo component of
    SignedData. The message digest is calculated using
    the algorithm and parameters specified in the
    digestAlgorithm component of SignerInfo, and the
    value of the eContent component of
    EncapsulatedContentInfo. The eContentType component
    of EncapsulatedContentInfo identifies the type of
    value being signed. This is always the object
    identifer id-data in XCBF.

    When a value of type SignedData is represented as
    XML markup, the starting and ending eContent tags
    are excluded from the message digest process. Only
    the "value" portion of the  complete canonical XER
    encoding of eContent is digested. The  <eContent>
    and </eContent> tags are excluded from the message
    digest process.

    The result of the message digest process is then
    digitally signed using the signers private key and
    the signature algorithm and parameters specified in
    the signatureAlgorithm component of SignerInfo. The
    result of the signature process becomes the value
    of the signature component of the SignerInfo component
    of SignedData.

The more general digest/signature process for SignedData
that includes signed attributes will be defined in X9.96
and can be applied to the X9.95 version of the time stamp
protocol. But the idea is the same. It is canonical XER
encodings that are digested, not DER encodings.

While it is still true that the results of the message
digest process is a binary value, and that this must be
expressed in a human readable format such as hexadecimal
or base64 characters, the input to the digest process is
pure XML markup.

So there is never the need for hexadecimal representations
of binary input values, as all of the values throughout
the protocol can be expressed using XML markup.

Phil


Apvrille, Axelle wrote:

> Hi Phil,
> Your answer is very interesting. Actually, I do not think XER can 
> completely help solve the problem for time stamps -- but maybe I'm wrong.
> 
> I'll try to explain why (but do give me your opinion about that):
> 
> the problem is that for time stamping, the time stamp token is first DER 
> encoded and then included as a signed attribute in a CMS structure.
> 
> Now, suppose you XER encode the time stamp. Okay, then, you're going to 
> get something "nice" for the CMS wrapping, but inside, when you get down 
> to the signed attribute for time stamping, you'll get an OCTET STRING... 
> which is the DER encoding of the time stamp token. No way XER can 
> produce something nice out of that, except if we XER recursively that 
> field...
> 
> So, for a time stamp, we'd get something like:
> <CMS>
>  <Version> 1 </Version>
>  <ContentInfo>
>         <Type> id-SignedData </Type>
>         <Content> <EncapsulatedContentInfo> ...
>         <SignedAttributes>
>                 <Attr>
>                         <type> id-timestamping </type>
>                         <value> 3082104150454 ... </value>
>                 </Attr>
>         </SignedAttributes>
>         ...    
>  </ContentInfo>
> </CMS>
> (This is roughly what it would show -- I'm writing this by memory, it's 
> maybe not the exact names).
> 
> The problem is that our goal was to read the time stamp token (included 
> in 3082...): we've got an XML output for the CMS message (that's nice, 
> but is it really useful ?) but nothing for the real payload information...
> 
> Unless we can recursively XER encode fields, I do not see how we can get 
> XER to "output" something really useful -- in the case of time stamps 
> (I'm not saying XER is not useful at all !).
> 
> Is this clear ? Am I wrong about XER ?
> Thanks again for your mail,
> 
> Axelle Apvrille.
>

Received on Wednesday, 17 July 2002 12:22:56 UTC