Hello Jim,
I am new to the smime list. A discussion is currently taking place on
the pkix mailing list (Multiple certificates for the same key ?) and as
the solution lies in the CMS document, I subscribed to the smime mailing
list only this week, to follow both discussions. So, please apologize,
if I do not have all the history on the smime list.
I am using your proposal related to the addition of a new section 11.5
to the CMS document.
11.5 Signing Certificate Attribute
The signing-certificate attribute type specifies the exact certificate used
to sign the signed-data. This provides for an authenticated method of
linking the certificate used to create the signed-data object and the
signed-data object itself.
This is a good start, but this is not sufficient to handle all the
cases. If one trust point (ie. root CA) of the verifier is also the CA
that is identified in that attribute, this is fine and sufficient. If a
certificate chain is needed to end up to the trust point of the
verifier, then a SEQUENCE OF IssuerAndSerialNumber *may* be needed. The
reason is the following : CA names are not necessarily unique. One CA is
only mandated to issue a name that is unique to it, but does not need to
check that the name is not used by another CA. However if you take a
given CA as a trust point, the SEQUENCE OF IssuerAndSerialNumber is
unique. The side advantage is that this works without using
Distinguished Names (ie X.521 names).
If this attribute is not used and two different
certificates are used for the same keys, it is possible to substitute the
certificates without breaking the signature.
True.
It is suggested that the
signing-certificate attribute be present if there are any authenticated
attributes present.
What do you mean exactly by this ?
The signing-certificate attribute MAY be critical. The signing-certificate
attribute MUST be authenticated. Only one instance of the
signing-certificate attribute may appear in an attribute set.
The following object identifier identifies the signing-certificate
attribute:
id-signingCert OBJECT IDENTIFIER ::= <TBD>
Signing-certificate attribute value has the ASN.1 type IssuerAndSerialNumber.
--- END ---
As a summary, my proposal would be to consider a Signing Chain Attribute
instead, that can be reduced to a single Signing Certificate Attribute.
The attribute then becomes a SEQUENCE OF IssuerAndSerialNumber.
Re-using your text, we would then have :
--- BEGINNING OF TEXT PROPOSAL ---
11.5 Signing Chain Attribute
The signing-Chain attribute type specifies the exact certification path
that is acknowledged by the signer to sign the signed-data. This
provides a method of linking the certification path accepted by the
signer to create the signed-data object with the signed-data object
itself. This certification path may be reduced to one leg, ie. a
identifier of the certificate of the signer. If this attribute is not
used and two different certificates are used for the same keys, it is
possible to substitute the certificates without breaking the signature.
The signing-chain attribute MAY be critical. The signing-chain
attribute MUST be authenticated. Only one instance of the signing-chain
attribute may appear in an attribute set.
The following object identifier identifies the signing-chain attribute:
id-signingChain OBJECT IDENTIFIER ::= <TBD>
Signing-chain attribute value has the ASN.1 type SigningChain.
SigningChain :: = SEQUENCE OF IssuerAndSerialNumber.
The first certificate identifier of the chain is the one from the
signer, optionally followed by certificate identifiers from CAs.
--- END OF TEXT PROPOSAL ---
This solves one concern, but not another one. For the case where this
attribute is used, with the actual CMS text, the signature process
involves one hash function only. Thus the signature of the authenticated
attribute is done by computing a hash over a message data (e.g. a 1 Mo
message) to which the authenticated attribute is happened. There may be
some advantages to be able to pre-compute the hash of the message
independently and so that the overall signature applies to the imprint
of the message (ie. the hash result together with the hash OID)
concatenated with the authenticated attributes.
We could thus consider to sign the hash of the message, instead of the
message itself. What is nice is that the imprint of a message is a
characteristic of the message that can be computed independently of the
context of the signature. It can be generated or checked in advance or
in parallel.
I do not see this as a replacement to what exists today, but as a new
format "to be used where necessary".
Any comments ?
Denis
--
Denis Pinkas Bull S.A.
mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21