Dear Pope and ietf-smime members,
Last year, 15 companies of ECOM members carried out the plugtest of RFC 3126
and ETSI TS 101 733 Version 1.5.1.
http://www.ecom.or.jp/LongTermStrage/en/project.html
On behalf of ECOM members, I would like to comment on the draft CAdES 01 based
on
the result of this plugtest and issues examination.
#1 Protection of signer's document detached from the signature
In order to protect signer's document by Archive Timestamp in the case of
constituting external signatures, the following text should be added to 6.4.1.
"When the eContent within ecapContentInfo is absent in the case of constituting
external signatures, the ecapContentInfo should be calculated with DER as though
the eContent containing signer's document was present."
#2 Backward compatibility of Archive Timestamp
As for change of the hash calculation, a hash according to RFC3126 and that
according to draft CAdES 01 will be undistinguishable at the time of
verification. New notes 1) has been added to 6.4.1, but nothing is solved. So,
either of the following measures should be considered.
I recognize that (1) is the best and (3) is the last resort.
(1) Define another Archive Timestamp attribute
Although another OID, from which behavior such as hash calculation is different,
cannot be given to the current Archive Timestamp, another Archive Timestamp
attribute, for example, "Preservation Timestamp" attribute with new OID,
should be defined.
(2)Define a new "rfc3161 compatible" attribute as an unsigned attribute
This attribute is stored in the unsigned attribute of each Archive Timestamp
attribute. The attribute value is set to ASN.1 BOOLEAN, for example, and
"rfc3161 compatible" is defined as True (so, new hash calculation is defined as
false). When this attribute is omitted, it is regarded as True because of
backward compatibility.
(3)Define a boundary of time (for example, January 1, 2007)
If it is timestamped before the boundary of time, it is regarded as a hash
according to rfc3161. In consideration of a transition period, if verification
goes wrong, another hash calculation should be also tried.
#3 Evasion of misunderstanding about DER processing
It was specified to remove type and length before hash calculation in RFC3126,
but only concatenation is written and it is not written how it is made
(including doing nothing) in draft CAdES 01. So, some misunderstandings have
arisen. For example, does singed attribute need to perform the same DER
processing as the message digest calculation process of CMS?
Since unsigned attributes are also the target of hash calculation, is it
necessary to perform DER processing?
I would like to leave the exact expression in English to authors, but it seems
that a supplementary explanation which it wrote clearly "binary codes with type
and length are concatenated as it is, without DER processing" does not have
misunderstanding.
Best Regards,
Michihiro Kimura
NEC Corporation