Hi all,
I have missed to comment before
the end of the last call however
I'll rather comment to the draft.
1) Archive Timestamp attribute type OID issue
(Section 6.4.1 Archive time-stamp attribute definition)
The archive hash calculation method was entirely changed
between RFC 3126 and CAdES I-D. As for archive timestamp attribute
itself we can't find which method was used.
So I think it would be better if other
OID is assigned to the attribute.
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27}
2) Archive Hash Target Issue (6.4.1 Archive time-stamp attribute definition)
I think the archive hash method definition in this I-D and
ETSI TS 101 733 v1.5.1 or later is ambiguous than RFC 3126.
2-1) encapContentInfo as archive hash target
the I-D definition is below:
The value of messageImprint field within TimeStampToken shall be a hash
of the concatenation of:
- The encapContentInfo element of the SignedData sequence;
As for CMS SignedData, a document to be signed may be included
in the 'attached signature' form or excluded in the 'detached signature'
form.
There is no description about those differences in the I-D.
I think a signing document should be add to archive hash targets
in order to archive long term integrity however
to encode attached format encapContentInfo for huge data
will be hard work. Also eContent of encapContentInfo may represented
indefinite length data of ASN.1 BER encoding.
(See `5.2. EncapsulatedContentInfo Type' of RFC 3852)
It may better to add only signing data itself.
2-2) normalization of ASN.1 BER encoded data
A signedAttrs field of CMS SignedData should be
DER encoded as described in the CMS definition:
RFC 3852 CMS '5.3. SignerInfo Type'
signedAttrs is a collection of attributes that are signed. The
field is optional, but it MUST be present if the content type of
the EncapsulatedContentInfo value being signed is not id-data.
SignedAttributes MUST be DER encoded, even if the rest of the
structure is BER encoded. Useful attribute types, such as signing
time, are defined in Section 11. If the field is present, it MUST
contain, at a minimum, the following two attributes:
I think other fields which are added to archive hash target should be
normalized to DER encoding since hash value results may vary for
its encoding. I think the way of normalization for archive hash target
should
be described in the I-D.
3) Version 3 SignedData issue (5.4 SignedData type)
The syntax of the SignedData of the ES is as defined in CMS (RFC 3852
[4]).
The fields of type SignedData have the meanings as defined in CMS (RFC
3852 [4]) except that:
- the syntax version number value shall be 3.
I'm afraid that a certificate without subjectKeyIdentifier extension
can not be used for CAdES in many cases.
Since if any attribute certificates will not included in the SignedData and
the signer's certificate has no subjectKeyIdentifier
X.509.v3 extension then it will be version 1 SignedData.
(See the definitions in RFC 3852 section 5.1 and 5.3)
What do you think?
Kenji
--
Kenji URUSHIMA | Entrust Japan | http://japan.entrust.com/