I have a few comments about draft-schaad-smime-algorithm-attribute-03.txt:
1) The key question is what should contain the field signatureAlgorithm ?
SignatureAlgorithmIdentifier is defined in section 10.1.2 from RFC 5652:
10.1.2. SignatureAlgorithmIdentifier
The SignatureAlgorithmIdentifier type identifies a signature
algorithm, and it can also identify a message digest algorithm.
Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with
SHA-256. A signature algorithm supports signature generation and
verification operations. The signature generation operation uses the
message digest and the signer's private key to generate a signature
value. The signature verification operation uses the message digest
and the signer's public key to determine whether or not a signature
value is valid. Context determines which operation is intended.
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
Some examples are questionable: is RSA really a "signature algorithm" ?
sha-1withRSA is really a signature mechanism, since it cannot be used for
encryption.
If "real signature algorithms" were being used in the OID, then half of the
problems mentioned in the draft would disappear.
This case should be mentioned in the draft.
The draft should also recommend the use of signature algorithms using both a
hash function and an asymetric algorithm.
2) We come from a point where, 20 years ago, the same certificate was used for
three purposes:
authentication, non repudiation and encipherment. RSA was the single algorithm
used in practice.
Since then, there are many situations where different certificates are used for
each purpose.
We now should recommend to use "real signature algorithms", which mean an OID
specifying
a combination of a hash function and an asymetric cryptographic algorithm.
If a certificate is being used, then an OID specifying the algorithm in the
certificate should be OID
specifying a combination of a hash function and an asymetric cryptographic
algorithm.
When certificates are being used, when the ESSCertID is being used, and when
"real signature algorithms" are being used
then the new proposed protection attribute is not needed.
The current draft does not mention this possibility.
3) There is another draft under discussion in the PKIX WG called:
draft-ietf-pkix-ocspagility-09.
Although the field "certIdentifier" below is misnamed, the idea is to say that
for Elliptic Curves we need two parameters
instead of one. This is what the proposed draft is attempting to say:
PreferredSignatureAlgorithm ::= SEQUENCE { sigIdentifier
AlgorithmIdentifier, certIdentifier AlgorithmIdentifier OPTIONAL
}
The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of RFC
5280 [RFC5280]
sigIdentifier specifies the signature algorithm the client prefers, e.g.
algorithm=ecdsa-with-sha256. Parameters are absent for most common signature
algorithms.
certIdentifier specifies the subject public key algorithm identifier the
client prefers in the server's certificate used to validate the OCSP
response. e.g. algorithm=id-ecPublicKey and parameters= secp256r1.
certIdentifier is OPTIONAL and provides means to specify parameters
necessary to distinguish among different usages of a particular algorithm,
e.g. it may be used by the client to specify what curve it supports for a
given elliptic curve algorithm.
Note the this draft provides a correct example for a signature algorithm
identifier: ecdsa-with-sha256
The draft proposed by Jim should consider the case of OIDs for Elliptic Curves
4) The draft is missing a risk analysis or examples for real possibilities of
substitution.
For the above reasons, I believe that a new draft should be issued.
Denis
----------
From : smime-bounces
To : smime
Date : 2010-12-06, 23:43:50
Subject : [smime] Fwd: Last Call: (SignerInfo Algorithm Protection Attribute)
to Proposed Standard
-------- Original Message --------
Subject: Last Call: <draft-schaad-smime-algorithm-attribute-03.txt>
(Signer Info Algorithm Protection Attribute) to Proposed Standard
Date: Mon, 06 Dec 2010 14:35:04 -0800
From: The IESG <iesg-secretary(_at_)ietf(_dot_)org>
To: IETF-Announce <ietf-announce(_at_)ietf(_dot_)org>
The IESG has received a request from an individual submitter to consider
the following document:
- 'Signer Info Algorithm Protection Attribute'
<draft-schaad-smime-algorithm-attribute-03.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-01-03. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attribute/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attribute/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime