From nobody Wed May 20 10:49:19 2015 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870D61A89C5 for ; Wed, 20 May 2015 10:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdUk1EU6WAHl for ; Wed, 20 May 2015 10:49:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E14C1A89A8 for ; Wed, 20 May 2015 10:49:16 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:47557) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Yv87G-0006rB-LW for smime@ietf.org; Wed, 20 May 2015 13:49:14 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 627B13FFD8 Message-ID: <555CC91A.8040006@bbn.com> Date: Wed, 20 May 2015 13:49:14 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: smime@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [smime] CMS signed object algorithm selection question X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:49:17 -0000 Hi all, Is this the right place to ask a question about the Cryptographic Message Syntax signed object spec (RFC5652 Section 5)? (I'm interested in understanding the RFC author's intentions, not what implementations currently do.) I am reviewing draft-ietf-sidr-rfc6485bis for the sidr working group and am confused about SignerInfo algorithm selection, specifically the relationship between the digestAlgorithm and signatureAlgorithm fields. RFC3370 defines the digest algorithm OIDs sha-1 and md5. It also defines the signature algorithm OIDs rsaEncryption, sha1WithRSAEncryption, and md5WithRSAEncryption. This leads me to wonder: * Suppose digestAlgorithm contains sha-1. Is there any functional difference between choosing rsaEncryption vs. sha1WithRSAEncryption for the signatureAlgorithm field? * What happens if I put sha-1 in digestAlgorithm but choose md5WithRSAEncryption for signatureAlgorithm? * In general, what is the relationship between the digest algorithm associated with the chosen signatureAlgorithm and the chosen digestAlgorithm? Thanks, Richard From nobody Wed May 20 11:08:16 2015 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC1F1A8A23 for ; Wed, 20 May 2015 11:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVyMUa5VKJ_3 for ; Wed, 20 May 2015 11:08:13 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0D81A871B for ; Wed, 20 May 2015 11:08:13 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E01489A4040; Wed, 20 May 2015 14:08:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id yHLIN5fERIDp; Wed, 20 May 2015 14:07:10 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 130809A4021; Wed, 20 May 2015 14:07:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <555CC91A.8040006@bbn.com> Date: Wed, 20 May 2015 14:07:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <65F19AD8-0B34-4264-AD0A-080F6B4C9E3E@vigilsec.com> References: <555CC91A.8040006@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.1085) Archived-At: Cc: smime@ietf.org Subject: Re: [smime] CMS signed object algorithm selection question X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:08:15 -0000 Richard: See below. > Is this the right place to ask a question about the Cryptographic > Message Syntax signed object spec (RFC5652 Section 5)? (I'm = interested > in understanding the RFC author's intentions, not what implementations > currently do.) >=20 > I am reviewing draft-ietf-sidr-rfc6485bis for the sidr working group = and > am confused about SignerInfo algorithm selection, specifically the > relationship between the digestAlgorithm and signatureAlgorithm = fields. >=20 > RFC3370 defines the digest algorithm OIDs sha-1 and md5. It also > defines the signature algorithm OIDs rsaEncryption, > sha1WithRSAEncryption, and md5WithRSAEncryption. This leads me to = wonder: >=20 > * Suppose digestAlgorithm contains sha-1. Is there any functional > difference between choosing rsaEncryption vs. sha1WithRSAEncryption > for the signatureAlgorithm field? These are equivalent. However, the practice is to use the hash function = identifier in digestAlgorithm and the the identifier that includes the = hash function and the signature algorithm in signatureAlgorithm. > * What happens if I put sha-1 in digestAlgorithm but choose > md5WithRSAEncryption for signatureAlgorithm? At minimum, this is rude. The I would expect an error. The complete answer requires looking at SignedData: SignedData ::=3D SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } The digestAlgorithms list comes before the content. This allows an = implementation to calculate the hash values as it buffers or processes = the content, depending on the circumstance. To encounter a signature = that uses a hash function that is not in this list should cause an = error. > * In general, what is the relationship between the digest algorithm > associated with the chosen signatureAlgorithm and the chosen > digestAlgorithm? I think this is answered above, Russ From nobody Wed May 20 11:43:04 2015 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C791A8A82 for ; Wed, 20 May 2015 11:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrsv3WuQ8o9I for ; Wed, 20 May 2015 11:43:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D2A1A8990 for ; Wed, 20 May 2015 11:43:01 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:47744) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Yv8xI-0009qO-3d; Wed, 20 May 2015 14:43:00 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id D88083FFB6 Message-ID: <555CD5B3.1080805@bbn.com> Date: Wed, 20 May 2015 14:42:59 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Russ Housley References: <555CC91A.8040006@bbn.com> <65F19AD8-0B34-4264-AD0A-080F6B4C9E3E@vigilsec.com> In-Reply-To: <65F19AD8-0B34-4264-AD0A-080F6B4C9E3E@vigilsec.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: smime@ietf.org Subject: Re: [smime] CMS signed object algorithm selection question X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:43:03 -0000 Thank you for your prompt reply. Comments below. On 2015-05-20 14:07, Russ Housley wrote: >> * Suppose digestAlgorithm contains sha-1. Is there any functional >> difference between choosing rsaEncryption vs. sha1WithRSAEncryption >> for the signatureAlgorithm field? > > These are equivalent. Good to know, thanks. I was worried that sha1WithRSAEncryption might mean to use SHA1 to hash whatever hash was produced by the chosen digestAlgorithm before applying RSA, as silly as that would be. :) > However, the practice is to use the hash function identifier in > digestAlgorithm and the the identifier that includes the hash > function and the signature algorithm in signatureAlgorithm. Intriguing! The reason draft-ietf-sidr-rfc6485bis exists is to go in the opposite direction -- to change the requirement from sha256WithRSAEncryption to just rsaEncryption. All of the existing RPKI CA implementations use rsaEncryption, apparently because the 3rd party crypto libraries don't support sha256WithRSAEncryption. It was decided that it would be easier/better to change the RFC than to force implementations to change. See for details. >> * What happens if I put sha-1 in digestAlgorithm but choose >> md5WithRSAEncryption for signatureAlgorithm? > > At minimum, this is rude. The I would expect an error. OK. Shouldn't RFC3370 and/or RFC5652 prohibit mismatches? If the signatureAlgorithm's named digest algorithm should always match the chosen digestAlgorithm, why do the xxxWithRSAEncryption variants even exist? Why not just have rsaEncryption? > The complete answer requires looking at SignedData: > > SignedData ::= SEQUENCE { > version CMSVersion, > digestAlgorithms DigestAlgorithmIdentifiers, > encapContentInfo EncapsulatedContentInfo, > certificates [0] IMPLICIT CertificateSet OPTIONAL, > crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, > signerInfos SignerInfos } > > The digestAlgorithms list comes before the content. This allows an > implementation to calculate the hash values as it buffers or > processes the content, depending on the circumstance. To encounter a > signature that uses a hash function that is not in this list should > cause an error. I did see the discussion about how SignedData's digestAlgorithms field is meant to enable one-pass processing in RFC5652 Section 5.1. However, if sha1WithRSAEncryption had meant to hash the hash before RSA, then one-pass processing would still be possible even if SHA1 wasn't mentioned in digestAlgorithms. >> * In general, what is the relationship between the digest algorithm >> associated with the chosen signatureAlgorithm and the chosen >> digestAlgorithm? > > I think this is answered above. Indeed, thanks! -Richard From nobody Wed May 20 13:01:10 2015 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94C11A903A for ; Wed, 20 May 2015 13:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1yu2LFDbnpP for ; Wed, 20 May 2015 13:01:07 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB12C1A9008 for ; Wed, 20 May 2015 13:01:05 -0700 (PDT) Received: from Odysseus.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id t4KK13eB031919 for ; Wed, 20 May 2015 16:01:03 -0400 (EDT) Received: from PINTO.missi.ncsc.mil ([fe80::60c7:cec6:b35c:deed]) by Odysseus.missi.ncsc.mil ([fe80::a8ee:8532:895b:b420%14]) with mapi id 14.03.0210.002; Wed, 20 May 2015 16:01:02 -0400 From: "Kemp, David P." To: "smime@ietf.org" Thread-Topic: [smime] CMS signed object algorithm selection question Thread-Index: AQHQkyVPLYXIEVkSUE2DInnYHjR4ep2FbGKAgAAJ94D//8UUkA== Date: Wed, 20 May 2015 20:01:01 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8D9C5E597@PINTO.missi.ncsc.mil> References: <555CC91A.8040006@bbn.com> <65F19AD8-0B34-4264-AD0A-080F6B4C9E3E@vigilsec.com> <555CD5B3.1080805@bbn.com> In-Reply-To: <555CD5B3.1080805@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.60.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [smime] CMS signed object algorithm selection question X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 20:01:09 -0000 -----Original Message----- Richard Hansen wrote: > On 2015-05-20 14:07, Russ Housley wrote: >>> * Suppose digestAlgorithm contains sha-1. Is there any functional >>> difference between choosing rsaEncryption vs. sha1WithRSAEncryption >>> for the signatureAlgorithm field? >>=20 >> These are equivalent. >> >> However, the practice is to use the hash function identifier in=20 >> digestAlgorithm and the the identifier that includes the hash function=20 >> and the signature algorithm in signatureAlgorithm. > > Intriguing! The reason draft-ietf-sidr-rfc6485bis exists is to go in > the opposite direction -- to change the requirement from sha256WithRSAEnc= ryption > to just rsaEncryption. All of the existing RPKI CA implementations use r= saEncryption, > apparently because the 3rd party crypto libraries don't support sha256Wit= hRSAEncryption. > It was decided that it would be easier/better to change the RFC than to f= orce > implementations to change. A case could be made that rsaEncryption and sha1WithRSAEncryption are not e= quivalent. The former should be used exclusively to identify a type of pub= lic key (in a certificate's subjectPublicKeyInfo "algorithm" field) and the= latter should be used exclusively to identify a signature algorithm (in a = SignerInfo's or Certificate's "signatureAlgorithm" field). If the ASN.1 sp= ecification were more strongly typed it would be an easy-to-detect syntax e= rror to use an OID of one type in a field of a different type, instead of b= eing just a logical error that could lead to latent issues. Failure to identify the signature algorithm (by using rsaEncryption in sign= erInfo) could cause problems if digestAlgorithms contains more than one Dig= estAlgorithmIdentifier (e.g. MD5, SHA-1, and SHA-256). In that case all th= ree hashes are computed over the content, but there is nothing to indicate = which hash value should be used in a particular signerInfo. From nobody Wed May 20 13:39:24 2015 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CEF1A90C4 for ; Wed, 20 May 2015 13:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00mf6-c8MkYn for ; Wed, 20 May 2015 13:39:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C19B1A90C2 for ; Wed, 20 May 2015 13:39:21 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:47623) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YvAlq-0008mP-2v for smime@ietf.org; Wed, 20 May 2015 16:39:18 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id D82E33FFD8 Message-ID: <555CF0F5.3060500@bbn.com> Date: Wed, 20 May 2015 16:39:17 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: smime@ietf.org References: <555CC91A.8040006@bbn.com> <65F19AD8-0B34-4264-AD0A-080F6B4C9E3E@vigilsec.com> <555CD5B3.1080805@bbn.com> <5B1D7E570380A64989D4C069F7D14BC8D9C5E597@PINTO.missi.ncsc.mil> In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC8D9C5E597@PINTO.missi.ncsc.mil> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [smime] CMS signed object algorithm selection question X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 20:39:22 -0000 On 2015-05-20 16:01, Kemp, David P. wrote: > Richard Hansen wrote: >> On 2015-05-20 14:07, Russ Housley wrote: >>>> * Suppose digestAlgorithm contains sha-1. Is there any functional >>>> difference between choosing rsaEncryption vs. sha1WithRSAEncryption >>>> for the signatureAlgorithm field? >>> >>> These are equivalent. >>> >>> However, the practice is to use the hash function identifier in >>> digestAlgorithm and the the identifier that includes the hash function >>> and the signature algorithm in signatureAlgorithm. >> >> Intriguing! The reason draft-ietf-sidr-rfc6485bis exists is to go in >> the opposite direction -- to change the requirement from sha256WithRSAEncryption >> to just rsaEncryption. All of the existing RPKI CA implementations use rsaEncryption, >> apparently because the 3rd party crypto libraries don't support sha256WithRSAEncryption. >> It was decided that it would be easier/better to change the RFC than to force >> implementations to change. > > A case could be made that rsaEncryption and sha1WithRSAEncryption are > not equivalent. The former should be used exclusively to identify a > type of public key (in a certificate's subjectPublicKeyInfo > "algorithm" field) and the latter should be used exclusively to > identify a signature algorithm (in a SignerInfo's or Certificate's > "signatureAlgorithm" field). You make an interesting point. RFC3370 Section 3.2 says: The algorithm identifier for RSA subject public keys in certificates is: rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } Notice the phrase "for RSA subject public keys in certificates". However, later in that same section: The rsaEncryption algorithm identifier is used to identify RSA (PKCS #1 v1.5) signature values regardless of the message digest algorithm employed. which sounds to me like it can *also* be used for a SignerInfo's signatureAlgorithm field. > If the ASN.1 specification were more > strongly typed it would be an easy-to-detect syntax error to use an > OID of one type in a field of a different type, instead of being just > a logical error that could lead to latent issues. > > Failure to identify the signature algorithm (by using rsaEncryption > in signerInfo) could cause problems if digestAlgorithms contains more > than one DigestAlgorithmIdentifier (e.g. MD5, SHA-1, and SHA-256). > In that case all three hashes are computed over the content, but > there is nothing to indicate which hash value should be used in a > particular signerInfo. What about a particular SignerInfo's digestAlgorithm field? -Richard From nobody Thu May 21 00:17:30 2015 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863971A1B9C for ; Thu, 21 May 2015 00:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pe1eLcG3HP5Z for ; Thu, 21 May 2015 00:17:25 -0700 (PDT) Received: from mail.ascertia.com (ds9380.dedicated.turbodns.co.uk [94.136.51.136]) by ietfa.amsl.com (Postfix) with ESMTP id 351CA1A1B6D for ; Thu, 21 May 2015 00:17:23 -0700 (PDT) Received: from [192.168.0.85] ([202.141.240.170]) by ascertia.com with MailEnable ESMTP; Thu, 21 May 2015 08:16:45 +0100 Message-ID: <555D85F5.4070207@ascertia.com> Date: Thu, 21 May 2015 12:15:01 +0500 From: Bilal Ashraf User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Hansen , smime@ietf.org References: <555CC91A.8040006@bbn.com> In-Reply-To: <555CC91A.8040006@bbn.com> Content-Type: multipart/alternative; boundary="------------040702060902050800040705" X-MXScan-Scan: Scanned by MxScan 2.7.501.0 for DS9380 X-MXScan-Msgid: 687D8D48460D4E4C861F2D9E1AF35C0D_ X-MXScan-Country-Sequence: PAKISTAN->Private Network->Destination X-MXScan-AntiVirus: ClamAV devel-clamav-0.97-408-ge11f7cc/20487/Tue May 19 23:38:36 2015 [Clean] X-MXScan-AntiSpam: CLAM_SANE [Pass], KEYWORD [Pass], RDNSBL [NA], URLBL [Pass], SPAMASSASSIN [1.6 (BAYES_50, HTML_MESSAGE, RDNS_NONE)], DCC_CHECK [Pass], BACKSCATTER [Pass] X-MXScan-SpamScore: 1.6 X-MXScan-ProcessingTime: 1.31 sec(s) X-ME-Bayesian: 0.000000 Archived-At: Subject: Re: [smime] CMS signed object algorithm selection question X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:17:27 -0000 This is a multi-part message in MIME format. --------------040702060902050800040705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Please see my responses inline. Regards, Bilal. On 5/20/2015 10:49 PM, Richard Hansen wrote: > Hi all, > > Is this the right place to ask a question about the Cryptographic > Message Syntax signed object spec (RFC5652 Section 5)? (I'm interested= > in understanding the RFC author's intentions, not what implementations > currently do.) > > I am reviewing draft-ietf-sidr-rfc6485bis for the sidr working group an= d > am confused about SignerInfo algorithm selection, specifically the > relationship between the digestAlgorithm and signatureAlgorithm fields.= > > RFC3370 defines the digest algorithm OIDs sha-1 and md5. It also > defines the signature algorithm OIDs rsaEncryption, > sha1WithRSAEncryption, and md5WithRSAEncryption. This leads me to wond= er: > > * Suppose digestAlgorithm contains sha-1. Is there any functional > difference between choosing rsaEncryption vs. sha1WithRSAEncryptio= n > for the signatureAlgorithm field? [Bilal] : If you look at RFC 2315 (PKCS#7) , the ASN.1 structure of=20 signerInfo is : SignerInfo ::=3D SEQUENCE { version Version, issuerAndSerialNumber IssuerAndSerialNumber, digestAlgorithm DigestAlgorithmIdentifier, authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL, digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier, encryptedDigest EncryptedDigest, unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL } Here it is mentioned the "digestEncryptionAlgorithm" and it should be=20 e.g. "rsaEncryption" while the "digestAlgorithm" should be like "sha-1". In RFC 3852 (CMS) which maintains backward compatibility with PKCS#7,=20 the ASN.1 structure of signerInfo is : SignerInfo ::=3D SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } Here it is mentioned the "signatureAlgorithm" and it should be e.g.=20 "sha1withrsaEncryption" while the "digestAlgorithm" should be like=20 "sha-1". Here "signatureAlgorithm" alone can be be used to pick the=20 digest algorithm but IMHO, "digestAlgorithm" remains there for backward=20 compatibility with PKCS#7. "digestAlgorithm" must be compatible with the = "signatureAlgorithm" otherwise tool kits that processes this structure=20 will give an error. CMS tool kits must be able to process both types of structures and tool = kits that generates CMS should create as per new structure i.e. use=20 "signatureAlgorithm" instead of "digestEncryptionAlgorithm" and=20 "digestAlgorithm" remains as it is. > * What happens if I put sha-1 in digestAlgorithm but choose > md5WithRSAEncryption for signatureAlgorithm? [Bilal] : See above. > > * In general, what is the relationship between the digest algorithm > associated with the chosen signatureAlgorithm and the chosen > digestAlgorithm? [Bilal] : See above. > > Thanks, > Richard > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime > > --------------040702060902050800040705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi,

Please see my responses inline.

Regards,
Bilal.

On 5/20/2015 10:49 PM, Richard Hansen wrote:
Hi all,

Is this the right place to ask a question about the Cryptographic
Message Syntax signed object spec (RFC5652 Section 5)?  (I'm interested
in understanding the RFC author's intentions, not what implementations
currently do.)

I am reviewing draft-ietf-sidr-rfc6485bis for the sidr working group and
am confused about SignerInfo algorithm selection, specifically the
relationship between the digestAlgorithm and signatureAlgorithm fields.

RFC3370 defines the digest algorithm OIDs sha-1 and md5.  It also
defines the signature algorithm OIDs rsaEncryption,
sha1WithRSAEncryption, and md5WithRSAEncryption.  This leads me to wonder:

  * Suppose digestAlgorithm contains sha-1. Is there any functional
    difference between choosing rsaEncryption vs. sha1WithRSAEncryption
    for the signatureAlgorithm field?
[Bilal] : If you look at RFC 2315 (PKCS#7) , the ASN.1 structure of signerInfo is :

SignerInfo ::= SEQUENCE {
     version Version,
     issuerAndSerialNumber IssuerAndSerialNumber,
     digestAlgorithm DigestAlgorithmIdentifier,
     authenticatedAttributes
       [0] IMPLICIT Attributes OPTIONAL,
     digestEncryptionAlgorithm
       DigestEncryptionAlgorithmIdentifier,
     encryptedDigest EncryptedDigest,
     unauthenticatedAttributes
       [1] IMPLICIT Attributes OPTIONAL }

Here it is mentioned the "digestEncryptionAlgorithm" and it should be e.g. "rsaEncryption" while the "digestAlgorithm" should be like "sha-1".

In RFC 3852 (CMS) which maintains backward compatibility with PKCS#7, the ASN.1 structure of signerInfo is :

SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

Here it is mentioned the "signatureAlgorithm" and it should be e.g. "sha1withrsaEncryption" while the "digestAlgorithm" should be like "sha-1".  Here "signatureAlgorithm" alone can be be used to pick the digest algorithm but IMHO, "digestAlgorithm" remains there for backward compatibility with PKCS#7. "digestAlgorithm" must be compatible with the "signatureAlgorithm" otherwise tool kits that processes this structure will give an error.

CMS tool kits must be able to process both types of structures and  tool kits that generates CMS should create as per new structure i.e. use "signatureAlgorithm" instead of "digestEncryptionAlgorithm" and "digestAlgorithm" remains as it is.

  * What happens if I put sha-1 in digestAlgorithm but choose
    md5WithRSAEncryption for signatureAlgorithm?
[Bilal] : See above.
 

  * In general, what is the relationship between the digest algorithm
    associated with the chosen signatureAlgorithm and the chosen
    digestAlgorithm?
[Bilal] : See above. 

Thanks,
Richard

_______________________________________________
smime mailing list
smime@ietf.org
https://www.ietf.org/mailman/listinfo/smime

--------------040702060902050800040705-- From nobody Thu May 21 11:37:00 2015 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F561A6F03 for ; Thu, 21 May 2015 11:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yffN6D0-hLLt for ; Thu, 21 May 2015 11:36:57 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04FE1A1EF5 for ; Thu, 21 May 2015 11:36:57 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:48022) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YvVKx-000Hun-H3; Thu, 21 May 2015 14:36:55 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 403D33FFFD Message-ID: <555E25C6.9070104@bbn.com> Date: Thu, 21 May 2015 14:36:54 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bilal Ashraf , smime@ietf.org References: <555CC91A.8040006@bbn.com> <555D85F5.4070207@ascertia.com> In-Reply-To: <555D85F5.4070207@ascertia.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [smime] CMS signed object algorithm selection question X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:36:59 -0000 On 2015-05-21 03:15, Bilal Ashraf wrote: > On 5/20/2015 10:49 PM, Richard Hansen wrote: >> * Suppose digestAlgorithm contains sha-1. Is there any functional >> difference between choosing rsaEncryption vs. sha1WithRSAEncryption >> for the signatureAlgorithm field? > > [Bilal] : If you look at RFC 2315 (PKCS#7) , the ASN.1 structure of > signerInfo is : > > SignerInfo ::= SEQUENCE { > version Version, > issuerAndSerialNumber IssuerAndSerialNumber, > digestAlgorithm DigestAlgorithmIdentifier, > authenticatedAttributes > [0] IMPLICIT Attributes OPTIONAL, > digestEncryptionAlgorithm > DigestEncryptionAlgorithmIdentifier, > encryptedDigest EncryptedDigest, > unauthenticatedAttributes > [1] IMPLICIT Attributes OPTIONAL } > > Here it is mentioned the "digestEncryptionAlgorithm" and it should be > e.g. "rsaEncryption" while the "digestAlgorithm" should be like "sha-1". > > In RFC 3852 (CMS) which maintains backward compatibility with PKCS#7, > the ASN.1 structure of signerInfo is : > > SignerInfo ::= SEQUENCE { > version CMSVersion, > sid SignerIdentifier, > digestAlgorithm DigestAlgorithmIdentifier, > signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, > signatureAlgorithm SignatureAlgorithmIdentifier, > signature SignatureValue, > unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } > > Here it is mentioned the "signatureAlgorithm" and it should be e.g. > "sha1withrsaEncryption" while the "digestAlgorithm" should be like > "sha-1". I'd like to get some historical context: Do you know why the semantics of digestEncryptionAlgorithm (rsaEncryption) was changed to signatureAlgorithm (sha1WithRSAEncryption)? > Here "signatureAlgorithm" alone can be be used to pick the > digest algorithm So an implementation conforming to RFC5652 is allowed to ignore digestAlgorithm when validating a signature? I couldn't find anywhere in RFC5652 or RFC3370 that suggests this. If so, this means that it is not OK to put rsaEncryption in the signatureAlgorithm field, as that doesn't specify which digest algorithm to use. > but IMHO, "digestAlgorithm" remains there for backward > compatibility with PKCS#7. OK, backward compatibility makes sense. > "digestAlgorithm" must be compatible with the > "signatureAlgorithm" otherwise tool kits that processes this structure > will give an error. Where does RFC5652 or RFC3370 state this requirement? I couldn't find anything. Are digestAlgorithm and signatureAlgorithm required to be compatible for PKCS#7 compatibility? Is PKCS#7 compatibility required by RFC5652? Thanks, Richard > > CMS tool kits must be able to process both types of structures and tool > kits that generates CMS should create as per new structure i.e. use > "signatureAlgorithm" instead of "digestEncryptionAlgorithm" and > "digestAlgorithm" remains as it is. > >> * What happens if I put sha-1 in digestAlgorithm but choose >> md5WithRSAEncryption for signatureAlgorithm? > > [Bilal] : See above. > >> >> * In general, what is the relationship between the digest algorithm >> associated with the chosen signatureAlgorithm and the chosen >> digestAlgorithm? > > [Bilal] : See above. > >> >> Thanks, >> Richard From nobody Thu May 21 11:39:06 2015 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CA31A854D for ; Thu, 21 May 2015 11:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlyrlGQMPK6X for ; Thu, 21 May 2015 11:39:03 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 82FA51A6FF5 for ; Thu, 21 May 2015 11:39:03 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 0D3B09A4061; Thu, 21 May 2015 14:38:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id OwHjl1eEk3jZ; Thu, 21 May 2015 14:38:08 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id ADA579A4069; Thu, 21 May 2015 14:38:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-555-807251498 From: Russ Housley In-Reply-To: <555D85F5.4070207@ascertia.com> Date: Thu, 21 May 2015 14:38:21 -0400 Message-Id: <5FEC47C9-683E-41E5-915D-DA1C2A9F7F7B@vigilsec.com> References: <555CC91A.8040006@bbn.com> <555D85F5.4070207@ascertia.com> To: Bilal Ashraf X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SMIME Subject: Re: [smime] CMS signed object algorithm selection question X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:39:06 -0000 --Apple-Mail-555-807251498 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bilal: The original PKCS#7 specification only supported RSA signatures. That = is, a message digest or hash value was computed, and then it was = encrypted with the RSA private key. The standards-track RFC supports = RSA as well as many other signature schemes. The terminology was = changed to reflect this situation. Russ On May 21, 2015, at 3:15 AM, Bilal Ashraf wrote: > Hi, >=20 > Please see my responses inline. >=20 > Regards, > Bilal. >=20 > On 5/20/2015 10:49 PM, Richard Hansen wrote: >> Hi all, >>=20 >> Is this the right place to ask a question about the Cryptographic >> Message Syntax signed object spec (RFC5652 Section 5)? (I'm = interested >> in understanding the RFC author's intentions, not what = implementations >> currently do.) >>=20 >> I am reviewing draft-ietf-sidr-rfc6485bis for the sidr working group = and >> am confused about SignerInfo algorithm selection, specifically the >> relationship between the digestAlgorithm and signatureAlgorithm = fields. >>=20 >> RFC3370 defines the digest algorithm OIDs sha-1 and md5. It also >> defines the signature algorithm OIDs rsaEncryption, >> sha1WithRSAEncryption, and md5WithRSAEncryption. This leads me to = wonder: >>=20 >> * Suppose digestAlgorithm contains sha-1. Is there any functional >> difference between choosing rsaEncryption vs. = sha1WithRSAEncryption >> for the signatureAlgorithm field? > [Bilal] : If you look at RFC 2315 (PKCS#7) , the ASN.1 structure of = signerInfo is : >=20 > SignerInfo ::=3D SEQUENCE { > version Version, > issuerAndSerialNumber IssuerAndSerialNumber, > digestAlgorithm DigestAlgorithmIdentifier, > authenticatedAttributes > [0] IMPLICIT Attributes OPTIONAL, > digestEncryptionAlgorithm > DigestEncryptionAlgorithmIdentifier, > encryptedDigest EncryptedDigest, > unauthenticatedAttributes > [1] IMPLICIT Attributes OPTIONAL } >=20 > Here it is mentioned the "digestEncryptionAlgorithm" and it should be = e.g. "rsaEncryption" while the "digestAlgorithm" should be like "sha-1". >=20 > In RFC 3852 (CMS) which maintains backward compatibility with PKCS#7, = the ASN.1 structure of signerInfo is : >=20 > SignerInfo ::=3D SEQUENCE { > version CMSVersion, > sid SignerIdentifier, > digestAlgorithm DigestAlgorithmIdentifier, > signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, > signatureAlgorithm SignatureAlgorithmIdentifier, > signature SignatureValue, > unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } >=20 > Here it is mentioned the "signatureAlgorithm" and it should be e.g. = "sha1withrsaEncryption" while the "digestAlgorithm" should be like = "sha-1". Here "signatureAlgorithm" alone can be be used to pick the = digest algorithm but IMHO, "digestAlgorithm" remains there for backward = compatibility with PKCS#7. "digestAlgorithm" must be compatible with the = "signatureAlgorithm" otherwise tool kits that processes this structure = will give an error. >=20 > CMS tool kits must be able to process both types of structures and = tool kits that generates CMS should create as per new structure i.e. use = "signatureAlgorithm" instead of "digestEncryptionAlgorithm" and = "digestAlgorithm" remains as it is. >=20 >> * What happens if I put sha-1 in digestAlgorithm but choose >> md5WithRSAEncryption for signatureAlgorithm? > [Bilal] : See above. >>=20 >> * In general, what is the relationship between the digest algorithm >> associated with the chosen signatureAlgorithm and the chosen >> digestAlgorithm? > [Bilal] : See above. >>=20 >>=20 >> Thanks, >> Richard >>=20 >> _______________________________________________ >> smime mailing list >> smime@ietf.org >> https://www.ietf.org/mailman/listinfo/smime >>=20 >>=20 >=20 > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime --Apple-Mail-555-807251498 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Bilal:

The original PKCS#7 specification only supported RSA signatures.  That is, a message digest or hash value was computed, and then it was encrypted with the RSA private key.  The standards-track RFC supports RSA as well as many other signature schemes.  The terminology was changed to reflect this situation.

Russ


On May 21, 2015, at 3:15 AM, Bilal Ashraf wrote:

Hi,

Please see my responses inline.

Regards,
Bilal.

On 5/20/2015 10:49 PM, Richard Hansen wrote:
Hi all,

Is this the right place to ask a question about the Cryptographic
Message Syntax signed object spec (RFC5652 Section 5)?  (I'm interested
in understanding the RFC author's intentions, not what implementations
currently do.)

I am reviewing draft-ietf-sidr-rfc6485bis for the sidr working group and
am confused about SignerInfo algorithm selection, specifically the
relationship between the digestAlgorithm and signatureAlgorithm fields.

RFC3370 defines the digest algorithm OIDs sha-1 and md5.  It also
defines the signature algorithm OIDs rsaEncryption,
sha1WithRSAEncryption, and md5WithRSAEncryption.  This leads me to wonder:

  * Suppose digestAlgorithm contains sha-1. Is there any functional
    difference between choosing rsaEncryption vs. sha1WithRSAEncryption
    for the signatureAlgorithm field?
[Bilal] : If you look at RFC 2315 (PKCS#7) , the ASN.1 structure of signerInfo is :

SignerInfo ::= SEQUENCE {
     version Version,
     issuerAndSerialNumber IssuerAndSerialNumber,
     digestAlgorithm DigestAlgorithmIdentifier,
     authenticatedAttributes
       [0] IMPLICIT Attributes OPTIONAL,
     digestEncryptionAlgorithm
       DigestEncryptionAlgorithmIdentifier,
     encryptedDigest EncryptedDigest,
     unauthenticatedAttributes
       [1] IMPLICIT Attributes OPTIONAL }

Here it is mentioned the "digestEncryptionAlgorithm" and it should be e.g. "rsaEncryption" while the "digestAlgorithm" should be like "sha-1".

In RFC 3852 (CMS) which maintains backward compatibility with PKCS#7, the ASN.1 structure of signerInfo is :

SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

Here it is mentioned the "signatureAlgorithm" and it should be e.g. "sha1withrsaEncryption" while the "digestAlgorithm" should be like "sha-1".  Here "signatureAlgorithm" alone can be be used to pick the digest algorithm but IMHO, "digestAlgorithm" remains there for backward compatibility with PKCS#7. "digestAlgorithm" must be compatible with the "signatureAlgorithm" otherwise tool kits that processes this structure will give an error.

CMS tool kits must be able to process both types of structures and  tool kits that generates CMS should create as per new structure i.e. use "signatureAlgorithm" instead of "digestEncryptionAlgorithm" and "digestAlgorithm" remains as it is.

  * What happens if I put sha-1 in digestAlgorithm but choose
    md5WithRSAEncryption for signatureAlgorithm?
[Bilal] : See above.
 
  * In general, what is the relationship between the digest algorithm
    associated with the chosen signatureAlgorithm and the chosen
    digestAlgorithm?
[Bilal] : See above. 
Thanks,
Richard

_______________________________________________
smime mailing list
smime@ietf.org
https://www.ietf.org/mailman/listinfo/smime

_______________________________________________
smime mailing list
smime@ietf.org
https://www.ietf.org/mailman/listinfo/smime

--Apple-Mail-555-807251498--