W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2002

RE: QUESTIONS ?

From: Apvrille, Axelle <ApvriA@europe.stortek.com>
Date: Wed, 17 Jul 2002 16:46:49 +0100
Message-ID: <182AA61AC50CD4118E8400805F0DF6290261ED10@tou-msg01.europe.stortek.com>
To: Phil Griffin <phil.griffin@asn-1.com>
Cc: w3c-ietf-xmldsig@w3.org
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 11:47:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:10 UTC