Re: [smime] [pkix] Fwd: Last Call: <draft-schaad-smime-algorithm-attribute-03.txt> (SignerInfo Algorithm Protection Attribute) to Proposed Standard
"Jim Schaad" <ietf@augustcellars.com> Wed, 22 December 2010 03:50 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: smime@core3.amsl.com
Delivered-To: smime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B27C3A6977; Tue, 21 Dec 2010 19:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBbNGiuw2yPv; Tue, 21 Dec 2010 19:49:57 -0800 (PST)
Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 12EA23A693E; Tue, 21 Dec 2010 19:49:57 -0800 (PST)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id E05F52CA09; Tue, 21 Dec 2010 19:51:51 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: denis.pinkas@bull.net, 'ietf' <ietf@ietf.org>, 'smime' <smime@ietf.org>, 'pkix' <pkix@ietf.org>
References: <4CFD6726.8040100@ieca.com> <DreamMail__092311_70675148164@msga-001.frcl.bull.fr>
In-Reply-To: <DreamMail__092311_70675148164@msga-001.frcl.bull.fr>
Date: Tue, 21 Dec 2010 20:07:12 -0800
Message-ID: <005201cba18d$b6a97290$23fc57b0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CBA14A.A88DACA0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHosiQhqvL9r6pWYq4QUfBZDCsggQF9xKGJk2W8DfA=
Content-Language: en-us
Subject: Re: [smime] [pkix] Fwd: Last Call: <draft-schaad-smime-algorithm-attribute-03.txt> (SignerInfo Algorithm Protection Attribute) to Proposed Standard
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smime>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Dec 2010 03:50:08 -0000
Comments are inline. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Pinkas Sent: Friday, December 17, 2010 12:23 AM To: ietf; smime; pkix Subject: Re: [pkix] [smime] Fwd: Last Call: <draft-schaad-smime-algorithm-attribute-03.txt> (SignerInfo Algorithm Protection Attribute) to Proposed Standard 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. [JLS] While I agree that perhaps draft should recommend the use a signature algorithms (which are fully defined), I don't understand how this can actually protect against the problems that are outlined. If an attacker can successfully substitute the signature identifier of ECDSA with SHA-256 for ECDSA with SHA-1, and come up with a case where the signature actually validates then there is no protection in the current specification. Actually the case of using rsaEncryption does provide additional protection since the internals of the v1.5 signature validation process checks that the digest algorithm encoded inside of the signature value matches the digest algorithm used to create the digest so in this case the fact that a full signature algorithm identifier is not used there is additional protection. In looking at the text from RFC5652 I believe that there is an errata that could be issued. The text "DSA with SHA-1" should have been "DSA with SHA-256". It is generally accepted that DSA, when not qualified requires the SHA-1 algorithm and thus is a fully specified signature algorithm. I would argue that the same is true for ECDSA. Thus of the listed set, only RSA can be considered not to be a fully specified signature algorithm, but it has internal specification of the hash algorithm. If new signature algorithms are created with random values as part of the input, then there would be no protection as the random value would not be protected. A number of changes to hash functions has been suggested where this might be the case. 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. [JLS] The view you are espousing here, that certificates should be restricted in the algorithm that they can be used for, is not one that is broadly accepted in either the S/MIME or PKIX communities. Since that is the case I don't think that this would address the problems outlined. I do however agree that this can be mentioned as one way of addressing part of the problem statement. 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 [JLS] I need more guidance from you on what you think you need. The curve would be protected by the certificate itself. The signature algorithm would be protected by the proposed attribute. 4) The draft is missing a risk analysis or examples for real possibilities of substitution. [JLS] I am currently looking at this in more detail. Jim 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@ietf.org <mailto:%20iesg-secretary@ietf.org> > To: IETF-Announce <ietf-announce@ietf.org <mailto:%20ietf-announce@ietf.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@ietf.org <mailto:%20ietf@ietf.org> mailing lists by 2011-01-03. Exceptionally, comments may be sent to iesg@ietf.org <mailto:%20iesg@ietf.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@ietf.org <mailto:%20IETF-Announce@ietf.org> https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ smime mailing list smime@ietf.org <mailto:%20smime@ietf.org> https://www.ietf.org/mailman/listinfo/smime
- [smime] Fwd: Last Call: <draft-schaad-smime-algor… Sean Turner
- [smime] Fwd: Last Call: <draft-schaad-smime-algor… Paul Hoffman
- Re: [smime] Fwd: Last Call: <draft-schaad-smime-a… Denis Pinkas
- Re: [smime] [pkix] Fwd: Last Call: <draft-schaad-… Jim Schaad
- Re: [smime] Fwd: Last Call: Martin Rex