From blaker@gmail.com Thu Apr 1 01:07:44 2010 Return-Path: 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 C6A623A67A6 for ; Thu, 1 Apr 2010 01:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 2TRJEG5KzbJs for ; Thu, 1 Apr 2010 01:07:42 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D96AD3A672E for ; Thu, 1 Apr 2010 01:07:41 -0700 (PDT) Received: from mail-pw0-f43.google.com (mail-pw0-f43.google.com [209.85.160.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o3188Djw049897 for ; Thu, 1 Apr 2010 01:08:13 -0700 (MST) (envelope-from blaker@gmail.com) Received: by pwj6 with SMTP id 6so774817pwj.16 for ; Thu, 01 Apr 2010 01:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8vfgYpu3y8noWMuAdZyeN2HG9aMRNbeJMVrKtLcS2Pg=; b=T4+eC7YfTwSWp9KPrF6TQoNpVsrUvKnNi7ALwz3M11LKuzCO0YCj3f01DYl0Yd2XXl iwNRUKLnA6QFmXkkk1tMOwcRiSYeqOtahaiLwW42b0rhqTt5Zy08E46Xr84lgbKcHcD3 cdaN7leNjjzUEEdx4MeVQ4LAW/1+aXFJmDfwg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wlEuqbSZcJRcfGquHVOOzvBvHLYgSrFopKXNtKjGaR4PLBRLPzQYKlgxNcIux2gI+B TsJsGfRpX1jwDkyRRemrww3tdY63yKXJa4bTj6WL536bIRHn8xBh2fd/cYttgW/5L5ec MZp9PRK7KS4N+QgNLgUrXEYgckI0xhwnETDuw= MIME-Version: 1.0 Received: by 10.142.161.21 with HTTP; Thu, 1 Apr 2010 01:08:12 -0700 (PDT) In-Reply-To: <4BB431FC.1040109@stroeder.com> References: <4BB431FC.1040109@stroeder.com> Date: Thu, 1 Apr 2010 01:08:12 -0700 Received: by 10.142.66.5 with SMTP id o5mr74108wfa.159.1270109292533; Thu, 01 Apr 2010 01:08:12 -0700 (PDT) Message-ID: From: Blake Ramsdell To: =?ISO-8859-1?Q?Michael_Str=F6der?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf-smime@imc.org Subject: Re: [smime] Use of subjectKeyIdentifier X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 08:07:45 -0000 2010/3/31 Michael Str=F6der : > Peter Gutmann wrote: >> =3D?ISO-8859-1?Q?Michael_Str=3DF6der?=3D writes: >> >>> If an S/MIME cert does not contain a subjectKeyIdentifier extension is = a >>> sending S/MIME MUA allowed to generate RecipientInfos referencing the >>> receiver's cert by (self-calculated) subjectKeyIdentifier (instead of i= ssuer >>> name and serial number)? >> >> I think there's a diference here between "can it" and "if it does, will = it >> work". =A0I can't see why an MUA can't do whatever it pleases (within th= e spec), >> but then since the sKID is an implicit identifier (i.e. it's "whatever b= inary >> blob is stored within the cert") rather than an explicit one ("you can >> generate an unambiguous sKID by doing ..."), it's more or less pot luck = as to >> whether the recipient will end up with the same sKID. And I agree with this. The short answer is that even though none of the specs say that generating your own sKID and trying to match that up to a certificate that doesn't have a sKID in it is a bad idea, the implied use is that you identify a certificate by sKID when you grabbed that sKID out of the certificate extension. The second that you might think that it's a good idea to generate an sKID on the fly, in the hopes of matching it back up with the certificate from which it is derived (that does not have the extension), you might read section 4.2.1.2 of RFC 5280 and see that there are multiple uses of the word SHOULD as well as multiple alternatives for computation, which should then give you pause that "Hm. Maybe I shouldn't go down this path. Something is not right." But indeed, it never says the words "don't generate a sKID in the hopes of matching it back up with a certificate that doesn't have that extension." But the terrible smells in the area surrounding how sKIDs can be generated (which includes "Other methods of generating unique numbers are also acceptable") should be enough to make you want to pick another direction ;). As Peter points out, it's a binary blob that (if you're lucky) was generated in a deterministic way based on the public key and (if you're not) it's a counter or random value or hash or MPEG of a cat. > This is a problem with Outlook 2010 beta sending subjectKeyIdentifier in > RecipientInfos although my e-mail cert does not contain the > subjectKeyIdentifier extension. Seamonkey is not able to find my accompan= ying > e-mail cert and private key based on that and thus is not able to decrypt= the > S/MIME message. That's bad. If Outlook 2010 is doing this, it's bad, for the reasons that Russ, Peter and I are pointing out. Generating an sKID for a certificate that doesn't have one is the wrong path, you must use issuerAndSerialNumber to identify the certificate in this case, and then make a very frowny face at the CA that generated the certificate for ignoring the SHOULD in section 4.2.1.2 of RFC 5280 "To assist applications in identifying the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates" which is why we're here now. > In theory one could even determine one of the commonly used algorithms by > looking at the key id size. But I'd prefer to have a good argument that > Outlook 2010 violates a standard. I don't think we're going to find a "MUST NOT try to guess an sKID if a certificate does not have one" anywhere, but I think there's one and a half implementors that are chiming in right now and saying "OMG, that is totally creepy and isn't really going to work". Now, I can see from an implementation point of view that you might think "dangit, I really don't want to support both subjectKeyIdentifier and issuerAndSerialNumber in SignerIdentifier and RecipientIdentifier" and then try to do something like, I dunno, generate an sKID for a certificate that doesn't have that attribute, and then use the sKID CHOICE in those structures. I think we've discussed that's bad (now the receiver has to jump through the same hoops and hopefully generates the same sKID that you did, which exactly zero implementations do right now). So if that's what Outlook 2010 beta is doing, I think I'd want to hear a medium length explanation about why this is the case. Because any other implementation is going to see an sKID and then try to look up a certificate that matches that sKID and fail (since there's no certificate that contains that extension). They won't attempt to use every known sKID generation algorithm currently known to try and synthesize one, they'll just give up. I don't blame 'em, and I think it's not a good idea to attempt. > > RFC 5652, section 6.2.1 says: > > =A0 =A0 =A0[..] the subjectKeyIdentifier identifies the > =A0 =A0 =A0recipient's certificate by a key identifier. =A0When an X.509 > =A0 =A0 =A0certificate is referenced, the key identifier matches the X.50= 9 > =A0 =A0 =A0subjectKeyIdentifier extension value. =A0When other certificat= e > =A0 =A0 =A0formats are referenced, the documents that specify the certifi= cate > =A0 =A0 =A0format and their use with the CMS must include details on matc= hing > =A0 =A0 =A0the key identifier to the appropriate certificate field. =A0Fo= r > =A0 =A0 =A0recipient processing, implementations MUST support both of the= se > =A0 =A0 =A0alternatives for specifying the recipient's certificate. =A0Fo= r > =A0 =A0 =A0sender processing, implementations MUST support at least one o= f > =A0 =A0 =A0these alternatives. > > But still that's IMO not really clear for the case the e-mail certs does = not > contain the subjectKeyIdentifier extension. This is a great section to quote. Sure it is -- it says "matches the X.509 subjectKeyIdentifier extension value". The value that's in the extension. If the extension isn't present, it doesn't say "if it's not present, synthesize one". If Outlook 2010 is really generating an sKID for a certificate that doesn't have one, I think that we can find a large number of implementors who will disagree with that strategy. Bottom line -- if there's no subjectKeyIdentifier, you use issuerAndSerialNumber, don't try and generate your own subjectKeyIdentifier. Blake From ietf@augustcellars.com Thu Apr 1 09:45:14 2010 Return-Path: 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 CCC983A6A3E for ; Thu, 1 Apr 2010 09:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.616 X-Spam-Level: X-Spam-Status: No, score=-4.616 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 DRo0xmkWMFQJ for ; Thu, 1 Apr 2010 09:45:13 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 70B0A3A6A47 for ; Thu, 1 Apr 2010 09:45:13 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o31GjiDM083889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Apr 2010 09:45:45 -0700 (MST) (envelope-from ietf@augustcellars.com) 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 smtp2.pacifier.net (Postfix) with ESMTP id CD2106A444; Thu, 1 Apr 2010 09:45:42 -0700 (PDT) From: "Jim Schaad" To: "'Blake Ramsdell'" , "=?iso-8859-1?Q?'Michael_Str=F6der'?=" References: <4BB431FC.1040109@stroeder.com> In-Reply-To: Date: Thu, 1 Apr 2010 09:45:38 -0700 Message-ID: <049201cad1ba$c3009d00$4901d700$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrRcuC2FC0IMTCYQNmmbXN7p5gRQAAR9rpA Content-Language: en-us Cc: ietf-smime@imc.org Subject: Re: [smime] Use of subjectKeyIdentifier X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 16:45:14 -0000 AMEN. Jim > -----Original Message----- > From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf > Of Blake Ramsdell > Sent: Thursday, April 01, 2010 1:08 AM > To: Michael Str=F6der > Cc: ietf-smime@imc.org > Subject: Re: [smime] Use of subjectKeyIdentifier >=20 > 2010/3/31 Michael Str=F6der : > > Peter Gutmann wrote: > >> =3D?ISO-8859-1?Q?Michael_Str=3DF6der?=3D = writes: > >> > >>> If an S/MIME cert does not contain a subjectKeyIdentifier = extension > is a > >>> sending S/MIME MUA allowed to generate RecipientInfos referencing > the > >>> receiver's cert by (self-calculated) subjectKeyIdentifier (instead > of issuer > >>> name and serial number)? > >> > >> I think there's a diference here between "can it" and "if it does, > will it > >> work". =A0I can't see why an MUA can't do whatever it pleases = (within > the spec), > >> but then since the sKID is an implicit identifier (i.e. it's > "whatever binary > >> blob is stored within the cert") rather than an explicit one ("you > can > >> generate an unambiguous sKID by doing ..."), it's more or less pot > luck as to > >> whether the recipient will end up with the same sKID. >=20 > And I agree with this. The short answer is that even though none of > the specs say that generating your own sKID and trying to match that > up to a certificate that doesn't have a sKID in it is a bad idea, the > implied use is that you identify a certificate by sKID when you > grabbed that sKID out of the certificate extension. >=20 > The second that you might think that it's a good idea to generate an > sKID on the fly, in the hopes of matching it back up with the > certificate from which it is derived (that does not have the > extension), you might read section 4.2.1.2 of RFC 5280 and see that > there are multiple uses of the word SHOULD as well as multiple > alternatives for computation, which should then give you pause that > "Hm. Maybe I shouldn't go down this path. Something is not right." >=20 > But indeed, it never says the words "don't generate a sKID in the > hopes of matching it back up with a certificate that doesn't have that > extension." But the terrible smells in the area surrounding how sKIDs > can be generated (which includes "Other methods of generating unique > numbers are also acceptable") should be enough to make you want to > pick another direction ;). As Peter points out, it's a binary blob > that (if you're lucky) was generated in a deterministic way based on > the public key and (if you're not) it's a counter or random value or > hash or MPEG of a cat. >=20 > > This is a problem with Outlook 2010 beta sending = subjectKeyIdentifier > in > > RecipientInfos although my e-mail cert does not contain the > > subjectKeyIdentifier extension. Seamonkey is not able to find my > accompanying > > e-mail cert and private key based on that and thus is not able to > decrypt the > > S/MIME message. >=20 > That's bad. If Outlook 2010 is doing this, it's bad, for the reasons > that Russ, Peter and I are pointing out. Generating an sKID for a > certificate that doesn't have one is the wrong path, you must use > issuerAndSerialNumber to identify the certificate in this case, and > then make a very frowny face at the CA that generated the certificate > for ignoring the SHOULD in section 4.2.1.2 of RFC 5280 "To assist > applications in identifying the appropriate end entity certificate, > this extension SHOULD be included in all end entity certificates" > which is why we're here now. >=20 > > In theory one could even determine one of the commonly used > algorithms by > > looking at the key id size. But I'd prefer to have a good argument > that > > Outlook 2010 violates a standard. >=20 > I don't think we're going to find a "MUST NOT try to guess an sKID if > a certificate does not have one" anywhere, but I think there's one and > a half implementors that are chiming in right now and saying "OMG, > that is totally creepy and isn't really going to work". >=20 > Now, I can see from an implementation point of view that you might > think "dangit, I really don't want to support both > subjectKeyIdentifier and issuerAndSerialNumber in SignerIdentifier and > RecipientIdentifier" and then try to do something like, I dunno, > generate an sKID for a certificate that doesn't have that attribute, > and then use the sKID CHOICE in those structures. I think we've > discussed that's bad (now the receiver has to jump through the same > hoops and hopefully generates the same sKID that you did, which > exactly zero implementations do right now). >=20 > So if that's what Outlook 2010 beta is doing, I think I'd want to hear > a medium length explanation about why this is the case. Because any > other implementation is going to see an sKID and then try to look up a > certificate that matches that sKID and fail (since there's no > certificate that contains that extension). They won't attempt to use > every known sKID generation algorithm currently known to try and > synthesize one, they'll just give up. I don't blame 'em, and I think > it's not a good idea to attempt. >=20 > > > > RFC 5652, section 6.2.1 says: > > > > =A0 =A0 =A0[..] the subjectKeyIdentifier identifies the > > =A0 =A0 =A0recipient's certificate by a key identifier. =A0When an = X.509 > > =A0 =A0 =A0certificate is referenced, the key identifier matches the = X.509 > > =A0 =A0 =A0subjectKeyIdentifier extension value. =A0When other = certificate > > =A0 =A0 =A0formats are referenced, the documents that specify the > certificate > > =A0 =A0 =A0format and their use with the CMS must include details on > matching > > =A0 =A0 =A0the key identifier to the appropriate certificate field. = =A0For > > =A0 =A0 =A0recipient processing, implementations MUST support both = of these > > =A0 =A0 =A0alternatives for specifying the recipient's certificate. = =A0For > > =A0 =A0 =A0sender processing, implementations MUST support at least = one of > > =A0 =A0 =A0these alternatives. > > > > But still that's IMO not really clear for the case the e-mail certs > does not > > contain the subjectKeyIdentifier extension. >=20 > This is a great section to quote. Sure it is -- it says "matches the > X.509 subjectKeyIdentifier extension value". The value that's in the > extension. If the extension isn't present, it doesn't say "if it's not > present, synthesize one". >=20 > If Outlook 2010 is really generating an sKID for a certificate that > doesn't have one, I think that we can find a large number of > implementors who will disagree with that strategy. >=20 > Bottom line -- if there's no subjectKeyIdentifier, you use > issuerAndSerialNumber, don't try and generate your own > subjectKeyIdentifier. >=20 > Blake > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime From prvs=1708833c28=jherzog@ll.mit.edu Fri Apr 2 11:35:23 2010 Return-Path: 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 86A8D3A68EA for ; Fri, 2 Apr 2010 11:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] 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 5itFZk5y9Ku5 for ; Fri, 2 Apr 2010 11:35:22 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by core3.amsl.com (Postfix) with ESMTP id 242DC3A6ADB for ; Fri, 2 Apr 2010 11:13:28 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o32IDwRC002226 for ; Fri, 2 Apr 2010 14:14:01 -0400 From: "Herzog, Jonathan - 0668 - MITLL" To: "smime@ietf.org" Date: Fri, 2 Apr 2010 14:13:55 -0400 Thread-Topic: New ID of potential interest Thread-Index: AcrSkEGHX2HP1ZYY5k6iqcDwbR9Z9Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3353062435_6206965" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_13:2010-02-06, 2010-04-02, 2010-04-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004020159 Cc: "Khazan, Roger - 0668 - MITLL" Subject: [smime] New ID of potential interest X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 18:35:23 -0000 --B_3353062435_6206965 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I would like to inform the SMIME working group of a newly-submitted Internet Draft that may be of interest: A set-key attribute for symmetric-key packages draft-herzog-setkey-00 Abstract A set-key is a symmetric key (or set of keys) associated with an immutable set of participants. This document defines a set-key attribute for use in the CMS-based symmetric-key package structure defined in in RFC XXXX. {{{ RFC Editor, please replace XXXX with the number assigned to draft-ietf-keyprov-symmetrickeyformat when it is published. }}} https://datatracker.ietf.org/doc/draft-herzog-setkey/ We welcome all comments and reviews. Thank you. -- Jonathan Herzog Technical Staff, MIT Lincoln Laboratory jherzog@ll.mit.edu --B_3353062435_6206965 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUGQYJKoZIhvcNAQcCoIIUCjCCFAYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EfwwggTGMIIDrqADAgECAgp6ybP8AAAAAANrMA0GCSqGSIb3DQEBBQUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTEwHhcNMDkwNjEyMTM0OTI3WhcNMTAwNjEyMTM0OTI3WjBkMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSMwIQYDVQQDExpIZXJ6b2cuSm9uYXRoYW4uQy41MDAxMTMwNTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOXkwtV9hBZEu8VfUkwVKE/T1YdbBVZVo7oJ23LKmsuo 7uSpluhOhyuQ3mTOcuOHLRMpO7IIG++2SeUU/xdkakbb4KmFQmgEYh8AcQEt6p0fgwqHAxpc cnMNpQtlMfnaU++iCdqzhAk5HWKWTr1iUdn3k/Q/GRearSAFtbnjk1U61/Z8n91xq8EnInvD wN0lAbqE+OXIATrr3yLL0bo7g0R1/gc8EaTR7pzzZoZpL2S6oKs57mGqo8fBgF82OIgSi58B G4XYY2MfktO7L1+Ok4nrGfMkHAn9jdDanwhFmPDzK+R91ls+f/EfkeYD4hcN+vn0hCkvUju1 aw7VhQ3fEbMCAwEAAaOCAYswggGHMA4GA1UdDwEB/wQEAwIGwDAdBgNVHQ4EFgQUfw9fyO/t gD1OIfPOjPji0oD8Ey4wHwYDVR0jBBgwFoAUlFrGWMm2JpugCXuoL2SQw4kCbiowMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTENBMTA9BggrBgEF BQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTENB MTAMBgNVHRMBAf8EAjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2H FYPq8EWFtqEfHYXL3jKH/4pzAgFkAgEDMCwGA1UdJQEB/wQiMCAGCCsGAQUFBwMEBgorBgEE AYI3CgMMBggrBgEFBQcDAjAnBgNVHSAEIDAeMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIB AwEIMB0GA1UdEQQWMBSBEmpoZXJ6b2dAbGwubWl0LmVkdTANBgkqhkiG9w0BAQUFAAOCAQEA VC+80q9zXOSzAHKzZNbzymlx6rm7lcRJz7FPiT/JHPzXOlimLZhsjv85Xhi9qmTaMdaMsMXO r1ZY4PrAVmV5GWQXu0TNc6dgiOujE1qd3SKr67ErWgxPRjPKeHzVjuDgAzWxGHsmuuNx4/k1 HS6mpNQtKoM0/fKtlBwTp/6IgitpbTjqKSH9id2/bzoMPh4ia1sLTjXhoG3/ZbbEHcKrmeyY GZuzJYFKFLGLqVOwSDyQwo8rnmKsZsZg/mf6J6J9bOwBQkAbS4rzRu8qgUntJbb6CgnXDkDZ eLL5iXPTUMrrL4JQ+fjk1F6YZ3nc8VAdMels0hi6qiVaV/1UkIBcyzCCBCcwggMPoAMCAQIC AQMwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0w ODEwMTUxMjAwMDBaFw0xNDEwMTUyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENB LTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR6ztRCggSJl8DROVlA6fjEplj a+BpV0dCgFg5xmYf465vFglkYEd1Zf4o0Smssrl9k1iwyKLN6nBNL1v/WzOfaluDR+BzF/NQ bi56xA29miegrCXCwj1/FNmtvwwc0ys/+cy7ODT2GMF0TM2c074dkBgll73l0MiquuZnS5TM 57NLOrtSKNP8VsrGP5jrTdL82taOIzbERQlSNe5KXr38jTzOAp3HyLbm0UG3TQTB0U/bxF8u pQjQ7ZOACqAKAlJm50EzowQi95XCaa2jCPfooDP6Q8CJLkytcv3j3UxXM7NQY9fc2xLvJS0j w/5Kxq166l2Vm7h9L0o9mYb0Jt9ZAgMBAAGjggEFMIIBATASBgNVHRMBAf8ECDAGAQH/AgEA MB0GA1UdDgQWBBSUWsZYybYmm6AJe6gvZJDDiQJuKjAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1 iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTAnBgNVHSAEIDAeMA0GCyqGSIb3 EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCSqGSIb3DQEBBQUAA4IBAQBWemGmX0dh9Hk0VAbd Yg4eE4WYGEHNEop0NPQTxe6KMztJ3assGoj8ulU0Q9ZqVYZac/iQGdFZMdZQcbJRTo7TYYdn GMuchPBfgJzRG+IRaSyprulB4MNk+gvdh6CFaewy55wbuP9WP6zbGKK2UPTFSrvL/8US/y0d zQEYO2uks4tgagNZVoK68fX3nbbQ7Nj7tXGKkoEcj0YvGRk11VZ8bU7sNuPkElLH6xNBpEgN IY5Tb3pKIRsCbH1VtylMjk+bvr6g1mN6ckZvPA1FrBGQiC+QKWNCDiO2o9J1g2BsgaRBMjqc snCgorUccE8UGzFIGOhmYPukvkCdwDM6A2GIMIIEQDCCAyigAwIBAgIEPsRfVjANBgkqhkiG 9w0BAQUFADA9MQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTENMAsGA1UECxMEbGxjYTAeFw0wODEwMDkxODQ3NDVaFw0xMTExMDMwNDAwMDBaMFQxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWw ArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012ECHadQ4I7XQAy lSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4YqSevrCP2baxUZ rChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02RXDPUjl9H+8Jr GItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqDAgMBAAGjggEv MIIBKzAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjA8BggrBgEFBQcBAQQwMC4w LAYIKwYBBQUHMAKGIGh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTENBMIGJBgNVHR8E gYEwfzBUoFKgUKROMEwxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQ0wCwYDVQQLEwRsbGNhMQ0wCwYDVQQDEwRDUkwxMCegJaAjhiFodHRwOi8vY3Js LmxsLm1pdC5lZHUvY3JsL2NybC5jcmwwHwYDVR0jBBgwFoAUQojpumqd0mMlazmqCugCj2cN A3EwHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMA0GCSqGSIb3DQEBBQUAA4IBAQA6 BPTctusZX6KcStYDrvAVmjjl+QlgsZWSJ6cIdwFRM8xAQMRJSDFfMvuXWNdu+7M9Mksfea+G Bs/E7jWohsj5GavJQeMFydsnDD+s4N0aB5MPnHrPcbmm4HiM1bQHhUJN9/+i9yQRUN+VapdK pXqzj77yM1B8xG4TL52m2wgavQ6It9gSAVVVqDkucZyrzd1x97ueqxLQd7KPTD+bvlVhUanJ xurkUQ+QskqSazW0y3vJ01FdsNxEFoxOD/AMijYXoBISd/Y5hyiPVK2vV463CRF1b4+wytJP 0K3Cv3fNSrkp5DZXXMFBBh64WaU9CbedZXOXzjZcXV0RwTp63rRvMIIEvzCCA6egAwIBAgIK essGTQAAAAADbTANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0x MB4XDTA5MDYxMjEzNTA1NVoXDTEwMDYxMjEzNTA1NVowZDELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMa SGVyem9nLkpvbmF0aGFuLkMuNTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCb+shjR8NpanI6X6RMl/ifaO7TxvGAK1SpXhtmUc8G/cnp6nrZlmzqWbsgJOVq8jd0 KSsWmieFhFoIzS3plF3C8o3eQVbK5N46pwZtP8NEy1Lm3q751xxPp6walr8zulwJHj9VsOjF SudcB1veSMmDCkQ1kWmGZbTFwk75GJz9bsnj9IWA6fXVEU/UfLbVqYNn9buuOTfFP4XaEE/e KPM54+wkZEWhLHRNhpH5Hjpj6rbgg5Ohbi1HYCxahyDDnUk36rlIJuA7uJXVE8AIqHGnS3+w IXH8vCcvllpcMZ0Qpq8/EnWEsV9Qx3hTb15wQiwvA9jhcmoH5H4MQhGdjxZhAgMBAAGjggGE MIIBgDAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFDTBbBLD29FyICm6ye6ly1fQO0E0MB8G A1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXRjcmw/TExDQTEwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUF BzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExDQTEwDAYDVR0TAQH/BAIwADA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vt IAIBZAIBAzAlBgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAnBgNVHSAE IDAeMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMB0GA1UdEQQWMBSBEmpoZXJ6b2dA bGwubWl0LmVkdTANBgkqhkiG9w0BAQUFAAOCAQEAT4JsxVDivSIw3JYqIBCYJxahy85qACjv bkES4utlpPyG8B06Fn+Pvhl0DFMG8WSKrAUHb0oRre7AVurJAsZK9wvy2UGqhJWIJjb1F1v+ cDiynU34EY86n9sm/3Z1RjRMvoRuu8HRkO3F4ew/3XgSvY5P68lY5r58fRl99TOnKEcfiisV 7F9oykUX2D9dcdXDm5NcDe1RibCAUSe2VYyN1s3FUZAHRQ7XohvDLJUY7jRRKph8GQkRqD0K 6ywzSJJZkWmWDMbOo4CjhUuwstAg6v1iRqYo9cbkC2RTxyTs3Wa4y1rR6e3oOR47YNBfgE/G nb9a3bwda3XkIzfhbkNsAzGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoT Fk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMQIKesmz/AAAAAADazAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFNZII25x8hBj cpCjGvV7BMzTiIKWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEwMDQwMjE4MTM1NVowDQYJKoZIhvcNAQEBBQAEggEAmWdWkCP9lwZQqWBxpH/A9dhZ7wLV TeiUXXDoTEDTVezxRpu7R93MPy8Ht7O9IJhdc9gskRRpVjwBYBxsKSliXU/oPKRP0T1cdt3F b1Xc0T7lxm8Bqmg5Z2GkhQmJP3MdI/XMwgz59aRnBwdDHGjiXio9eBC9Q7RcfDnx89D5DoMq yb+RYndwex5z6OM3vc0tOchL2duX29/goh8kmGRCJ3nhVkbu+MHTOD/2MXu4fpT5R8WO8oar Y1VLA0C3oRsVKK4+SPVLfCmEYp59Wqrla0m6ecVxt7t020i42XBunYsIM+N2Dh+lq2nKvQW8 wpTjKQ/W99tcFlrsMFMgUnAb6w== --B_3353062435_6206965-- From prvs=1708833c28=jherzog@ll.mit.edu Fri Apr 2 11:37:38 2010 Return-Path: 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 92F533A6CE9 for ; Fri, 2 Apr 2010 11:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] 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 9+RCSaKm1EOc for ; Fri, 2 Apr 2010 11:37:37 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by core3.amsl.com (Postfix) with ESMTP id 5685D3A6AFB for ; Fri, 2 Apr 2010 11:15:01 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o32IFXUR006451 for ; Fri, 2 Apr 2010 14:15:33 -0400 From: "Herzog, Jonathan - 0668 - MITLL" To: "smime@ietf.org" Date: Fri, 2 Apr 2010 14:15:30 -0400 Thread-Topic: (Another) new ID of potential interest Thread-Index: AcrSkHonBI3G/TM0VE6boE5LuwIaTA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3353062531_6193452" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_13:2010-02-06, 2010-04-02, 2010-04-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004020161 Cc: "Khazan, Roger - 0668 - MITLL" Subject: [smime] (Another) new ID of potential interest X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 18:37:38 -0000 --B_3353062531_6193452 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I would like to inform the SMIME working group of a newly-submitted Internet Draft that may be of interest: Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax draft-herzog-static-ecdh-00 Abstract This document describes how to use 'static-static' Elliptic Curve Diffie-Hellman key-agreement with the Cryptographic Message Syntax. In this form of key-agreement, the Diffie-Hellman values of both sender and receiver are long-term values contained in certificates. Thus, this form of key-agreement provides authentication of sender as well as receiver. https://datatracker.ietf.org/doc/draft-herzog-static-ecdh/ We welcome all comments and reviews. Thank you. -- Jonathan Herzog Technical Staff, MIT Lincoln Laboratory jherzog@ll.mit.edu --B_3353062531_6193452 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUGQYJKoZIhvcNAQcCoIIUCjCCFAYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EfwwggTGMIIDrqADAgECAgp6ybP8AAAAAANrMA0GCSqGSIb3DQEBBQUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTEwHhcNMDkwNjEyMTM0OTI3WhcNMTAwNjEyMTM0OTI3WjBkMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSMwIQYDVQQDExpIZXJ6b2cuSm9uYXRoYW4uQy41MDAxMTMwNTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOXkwtV9hBZEu8VfUkwVKE/T1YdbBVZVo7oJ23LKmsuo 7uSpluhOhyuQ3mTOcuOHLRMpO7IIG++2SeUU/xdkakbb4KmFQmgEYh8AcQEt6p0fgwqHAxpc cnMNpQtlMfnaU++iCdqzhAk5HWKWTr1iUdn3k/Q/GRearSAFtbnjk1U61/Z8n91xq8EnInvD wN0lAbqE+OXIATrr3yLL0bo7g0R1/gc8EaTR7pzzZoZpL2S6oKs57mGqo8fBgF82OIgSi58B G4XYY2MfktO7L1+Ok4nrGfMkHAn9jdDanwhFmPDzK+R91ls+f/EfkeYD4hcN+vn0hCkvUju1 aw7VhQ3fEbMCAwEAAaOCAYswggGHMA4GA1UdDwEB/wQEAwIGwDAdBgNVHQ4EFgQUfw9fyO/t gD1OIfPOjPji0oD8Ey4wHwYDVR0jBBgwFoAUlFrGWMm2JpugCXuoL2SQw4kCbiowMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTENBMTA9BggrBgEF BQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTENB MTAMBgNVHRMBAf8EAjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2H FYPq8EWFtqEfHYXL3jKH/4pzAgFkAgEDMCwGA1UdJQEB/wQiMCAGCCsGAQUFBwMEBgorBgEE AYI3CgMMBggrBgEFBQcDAjAnBgNVHSAEIDAeMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIB AwEIMB0GA1UdEQQWMBSBEmpoZXJ6b2dAbGwubWl0LmVkdTANBgkqhkiG9w0BAQUFAAOCAQEA VC+80q9zXOSzAHKzZNbzymlx6rm7lcRJz7FPiT/JHPzXOlimLZhsjv85Xhi9qmTaMdaMsMXO r1ZY4PrAVmV5GWQXu0TNc6dgiOujE1qd3SKr67ErWgxPRjPKeHzVjuDgAzWxGHsmuuNx4/k1 HS6mpNQtKoM0/fKtlBwTp/6IgitpbTjqKSH9id2/bzoMPh4ia1sLTjXhoG3/ZbbEHcKrmeyY GZuzJYFKFLGLqVOwSDyQwo8rnmKsZsZg/mf6J6J9bOwBQkAbS4rzRu8qgUntJbb6CgnXDkDZ eLL5iXPTUMrrL4JQ+fjk1F6YZ3nc8VAdMels0hi6qiVaV/1UkIBcyzCCBCcwggMPoAMCAQIC AQMwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAeFw0w ODEwMTUxMjAwMDBaFw0xNDEwMTUyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENB LTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDR6ztRCggSJl8DROVlA6fjEplj a+BpV0dCgFg5xmYf465vFglkYEd1Zf4o0Smssrl9k1iwyKLN6nBNL1v/WzOfaluDR+BzF/NQ bi56xA29miegrCXCwj1/FNmtvwwc0ys/+cy7ODT2GMF0TM2c074dkBgll73l0MiquuZnS5TM 57NLOrtSKNP8VsrGP5jrTdL82taOIzbERQlSNe5KXr38jTzOAp3HyLbm0UG3TQTB0U/bxF8u pQjQ7ZOACqAKAlJm50EzowQi95XCaa2jCPfooDP6Q8CJLkytcv3j3UxXM7NQY9fc2xLvJS0j w/5Kxq166l2Vm7h9L0o9mYb0Jt9ZAgMBAAGjggEFMIIBATASBgNVHRMBAf8ECDAGAQH/AgEA MB0GA1UdDgQWBBSUWsZYybYmm6AJe6gvZJDDiQJuKjAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1 iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTAnBgNVHSAEIDAeMA0GCyqGSIb3 EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCSqGSIb3DQEBBQUAA4IBAQBWemGmX0dh9Hk0VAbd Yg4eE4WYGEHNEop0NPQTxe6KMztJ3assGoj8ulU0Q9ZqVYZac/iQGdFZMdZQcbJRTo7TYYdn GMuchPBfgJzRG+IRaSyprulB4MNk+gvdh6CFaewy55wbuP9WP6zbGKK2UPTFSrvL/8US/y0d zQEYO2uks4tgagNZVoK68fX3nbbQ7Nj7tXGKkoEcj0YvGRk11VZ8bU7sNuPkElLH6xNBpEgN IY5Tb3pKIRsCbH1VtylMjk+bvr6g1mN6ckZvPA1FrBGQiC+QKWNCDiO2o9J1g2BsgaRBMjqc snCgorUccE8UGzFIGOhmYPukvkCdwDM6A2GIMIIEQDCCAyigAwIBAgIEPsRfVjANBgkqhkiG 9w0BAQUFADA9MQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTENMAsGA1UECxMEbGxjYTAeFw0wODEwMDkxODQ3NDVaFw0xMTExMDMwNDAwMDBaMFQxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWw ArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012ECHadQ4I7XQAy lSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4YqSevrCP2baxUZ rChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02RXDPUjl9H+8Jr GItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqDAgMBAAGjggEv MIIBKzAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjA8BggrBgEFBQcBAQQwMC4w LAYIKwYBBQUHMAKGIGh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTENBMIGJBgNVHR8E gYEwfzBUoFKgUKROMEwxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQ0wCwYDVQQLEwRsbGNhMQ0wCwYDVQQDEwRDUkwxMCegJaAjhiFodHRwOi8vY3Js LmxsLm1pdC5lZHUvY3JsL2NybC5jcmwwHwYDVR0jBBgwFoAUQojpumqd0mMlazmqCugCj2cN A3EwHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMA0GCSqGSIb3DQEBBQUAA4IBAQA6 BPTctusZX6KcStYDrvAVmjjl+QlgsZWSJ6cIdwFRM8xAQMRJSDFfMvuXWNdu+7M9Mksfea+G Bs/E7jWohsj5GavJQeMFydsnDD+s4N0aB5MPnHrPcbmm4HiM1bQHhUJN9/+i9yQRUN+VapdK pXqzj77yM1B8xG4TL52m2wgavQ6It9gSAVVVqDkucZyrzd1x97ueqxLQd7KPTD+bvlVhUanJ xurkUQ+QskqSazW0y3vJ01FdsNxEFoxOD/AMijYXoBISd/Y5hyiPVK2vV463CRF1b4+wytJP 0K3Cv3fNSrkp5DZXXMFBBh64WaU9CbedZXOXzjZcXV0RwTp63rRvMIIEvzCCA6egAwIBAgIK essGTQAAAAADbTANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0x MB4XDTA5MDYxMjEzNTA1NVoXDTEwMDYxMjEzNTA1NVowZDELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMa SGVyem9nLkpvbmF0aGFuLkMuNTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCb+shjR8NpanI6X6RMl/ifaO7TxvGAK1SpXhtmUc8G/cnp6nrZlmzqWbsgJOVq8jd0 KSsWmieFhFoIzS3plF3C8o3eQVbK5N46pwZtP8NEy1Lm3q751xxPp6walr8zulwJHj9VsOjF SudcB1veSMmDCkQ1kWmGZbTFwk75GJz9bsnj9IWA6fXVEU/UfLbVqYNn9buuOTfFP4XaEE/e KPM54+wkZEWhLHRNhpH5Hjpj6rbgg5Ohbi1HYCxahyDDnUk36rlIJuA7uJXVE8AIqHGnS3+w IXH8vCcvllpcMZ0Qpq8/EnWEsV9Qx3hTb15wQiwvA9jhcmoH5H4MQhGdjxZhAgMBAAGjggGE MIIBgDAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFDTBbBLD29FyICm6ye6ly1fQO0E0MB8G A1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXRjcmw/TExDQTEwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUF BzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExDQTEwDAYDVR0TAQH/BAIwADA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vt IAIBZAIBAzAlBgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAnBgNVHSAE IDAeMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMB0GA1UdEQQWMBSBEmpoZXJ6b2dA bGwubWl0LmVkdTANBgkqhkiG9w0BAQUFAAOCAQEAT4JsxVDivSIw3JYqIBCYJxahy85qACjv bkES4utlpPyG8B06Fn+Pvhl0DFMG8WSKrAUHb0oRre7AVurJAsZK9wvy2UGqhJWIJjb1F1v+ cDiynU34EY86n9sm/3Z1RjRMvoRuu8HRkO3F4ew/3XgSvY5P68lY5r58fRl99TOnKEcfiisV 7F9oykUX2D9dcdXDm5NcDe1RibCAUSe2VYyN1s3FUZAHRQ7XohvDLJUY7jRRKph8GQkRqD0K 6ywzSJJZkWmWDMbOo4CjhUuwstAg6v1iRqYo9cbkC2RTxyTs3Wa4y1rR6e3oOR47YNBfgE/G nb9a3bwda3XkIzfhbkNsAzGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoT Fk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMQIKesmz/AAAAAADazAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFK6gvd8q4Pjq hVIm8gi6hFgHh9YDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEwMDQwMjE4MTUzMVowDQYJKoZIhvcNAQEBBQAEggEAm/a5ytJrJ4Sb1+uBciB6tAulTf48 i6Tgkh3zw0GFTaFqCkogoW449SjR4YNU4PlylWEHRLEp2xhby9gLqM9RVOfRGayQrlvPFwO+ n6p0ldShYZNEOHJGEppCsGXF7c2F2Q11p2+qdSqeLkqg2rnley2+bqlF71mM5GwrZXI2G5ut Qt7mN0lP8M+XQYBhe5oEwhFbpNU1vdsOrr1K0e2XNzgHI2kLODDYylfQSyaAoG+IDtBDFNij auUu0AdoE5RfU5PEpG7jqWRO/mNE8VMNNFIlSNYaku24SWCCSBPlwkyr/VWMmkhQk7WHAmAx ZxtUtc0GpyI3nxQ6Lpt+GDb9pQ== --B_3353062531_6193452-- From wwwrun@rfc-editor.org Thu Apr 8 18:03:58 2010 Return-Path: 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 74EF13A67E1 for ; Thu, 8 Apr 2010 18:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 JkNvpsbGYoQH for ; Thu, 8 Apr 2010 18:03:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 9D6AA3A67B1 for ; Thu, 8 Apr 2010 18:03:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 26A30E06A9; Thu, 8 Apr 2010 18:03:54 -0700 (PDT) To: blaker@gmail.com, turners@ieca.com, turners@ieca.com, tim.polk@nist.gov, paul.hoffman@vpnc.org, blaker@gmail.com From: RFC Errata System Message-Id: <20100409010354.26A30E06A9@rfc-editor.org> Date: Thu, 8 Apr 2010 18:03:54 -0700 (PDT) Cc: rfc-editor@rfc-editor.org, smime@ietf.org Subject: [smime] [Technical Errata Reported] RFC5751 (2143) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 01:03:58 -0000 The following errata report has been submitted for RFC5751, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5751&eid=2143 -------------------------------------- Type: Technical Reported by: Jim Schaad Section: 3.2.2 Original Text ------------- Name CMS Type Inner Content enveloped-data EnvelopedData id-data signed-data SignedData id-data certs-only SignedData none compressed-data CompressedData id-data Corrected Text -------------- Name CMS Type Inner Content enveloped-data EnvelopedData id-data signed-data SignedData id-data certs-only SignedData id-data compressed-data CompressedData id-data Notes ----- The inner content type is not an optional field. Some inner content type MUST be included, id-data is the correct inner content type to be specified. The balance of the required information is in section 3.7. It is possible that the fact that id-data is used as the encapsulated content type should be added to the section Step 1 in 3.7 Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5751 (draft-ietf-smime-3851bis-11) -------------------------------------- Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Publication Date : January 2010 Author(s) : B. Ramsdell, S. Turner Category : PROPOSED STANDARD Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG From ietf@augustcellars.com Sat Apr 10 17:31:16 2010 Return-Path: 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 5A9573A6810 for ; Sat, 10 Apr 2010 17:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.752 X-Spam-Level: X-Spam-Status: No, score=0.752 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_OBFU_ALL=0.751] 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 FUps4UaCJXFl for ; Sat, 10 Apr 2010 17:31:15 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 1E9E23A680D for ; Sat, 10 Apr 2010 17:31:11 -0700 (PDT) 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 smtp1.pacifier.net (Postfix) with ESMTP id 6A9806EF09; Sat, 10 Apr 2010 17:31:05 -0700 (PDT) From: "Jim Schaad" To: "'Herzog, Jonathan - 0668 - MITLL'" , "'Khazan, Roger - 0668 - MITLL'" References: In-Reply-To: Date: Sat, 10 Apr 2010 17:31:01 -0700 Message-ID: <03ae01cad90e$43a13b90$cae3b2b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrSkHonBI3G/TM0VE6boE5LuwIaTAGa/VvA Content-Language: en-us Cc: smime@ietf.org Subject: Re: [smime] (Another) new ID of potential interest X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 00:31:16 -0000 Gentlemen, I have been reviewing this document I would like to suggest that it is either overgenerous in the set of cryptographic services that are provided or missing some pre-conditions that are necessary in order to obtain those services. In section 1 states that one of the services that is available is sender-authentication, however no restrictions are placed on when this service is available anyplace in the document that I can find. I would like to suggest that is this not actually either a very strong service or one that is always available. Please consider the following sequence of actions: 1. Alice sends a static-static Authenticated message to both Bob and Mallory. Alice will use a static-static DH method to transport the key to Bob, it does not really matter what technique is use to transport the key to Mallory. The important thing is just that this is one message and thus one authentication key. 2. Mallory intercepts the message and prevents Bob from receiving it. 3. Mallory creates a new message using the same authentication key that Alice generated to authenticate a new message. Mallory may or may not include himself as a recipient of the message. 4. Mallory sends the new message to Bob. 5. Bob receives the message, validates the static-static DH works and authenticates the message. Bob now believes that Alice was the original sender of the message. There is a difference in services one gets between an online protocol and a store-and-forward protocol. For on-line you only ever get a pair-wise operation and you have the immediate check that the negotiation was successful. This is lacking for the store-and-forward versions. This difference is only relevant if you are looking for sender-authentication of the messages that are sent. Thus there are never an issue for an ephemeral-static version of the protocols. Mallory could run the same sequence as above, but since there is no reason for Bob to believe that Alice sent the message, there is not a strong attack. In order to get a sender-authentication of a message one needs to do the following: 1. Mandate in any protocol using this that only a single Recipient Info can ever occur in a message. 2. Mandate that the ukm be present in the message and, 3. Mandate that a timeliness element be included in the ukm. In any event, the sender-authentication can never be taking to a third party for verification since either party could have constructed the message. Bob in fact could construct a message despite the fact that Alice has never sent a message to Bob. Other comments: 1. As written the ukm descriptions are incorrect. For section 2.1 - the correct order is. If ukm is present, it contains the ECC-CMS-SharedInfo structure. If the user wants to add a random value, it is placed in the entityUInfo field of this structure. 2. The bullet list in section 2.2. lists the ukm twice. (The first bullet here is vastly confusing - perhaps a error in doing updates?) 3. Note 3278bis appears to have been published in January of this year, so saying that the update is a work in progress appears to be significantly out of date. 4. Several references to section 5 appear to be out of date. 5. You need to supply an ASN.1 module. I have a personal preference to one that uses the new ASN.1 but could live with an 88 module if necessary. Doing so might expose some deficiencies in the document. 6. You need to look at the document before it is published. Having the document tin twice is somewhat crazy. Jim > -----Original Message----- > From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf > Of Herzog, Jonathan - 0668 - MITLL > Sent: Friday, April 02, 2010 11:16 AM > To: smime@ietf.org > Cc: Khazan, Roger - 0668 - MITLL > Subject: [smime] (Another) new ID of potential interest > > I would like to inform the SMIME working group of a newly-submitted > Internet Draft that may be of interest: > > Use of static-static Elliptic-Curve Diffie-Hellman key agreement in > Cryptographic Message Syntax > > draft-herzog-static-ecdh-00 > > Abstract > > This document describes how to use 'static-static' Elliptic Curve > Diffie-Hellman key-agreement with the Cryptographic Message Syntax. > In this form of key-agreement, the Diffie-Hellman values of both > sender and receiver are long-term values contained in certificates. > Thus, this form of key-agreement provides authentication of sender as > well as receiver. > > https://datatracker.ietf.org/doc/draft-herzog-static-ecdh/ > > We welcome all comments and reviews. > > Thank you. > > > -- > Jonathan Herzog > Technical Staff, MIT Lincoln Laboratory > jherzog@ll.mit.edu From ietf@augustcellars.com Sat Apr 10 18:07:33 2010 Return-Path: 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 5375E3A687C for ; Sat, 10 Apr 2010 18:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.752 X-Spam-Level: X-Spam-Status: No, score=0.752 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_OBFU_ALL=0.751] 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 YQlM11KJ+nPa for ; Sat, 10 Apr 2010 18:07:32 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by core3.amsl.com (Postfix) with ESMTP id 8772F3A6811 for ; Sat, 10 Apr 2010 18:07:32 -0700 (PDT) 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 smtp3.pacifier.net (Postfix) with ESMTP id BC7017E41; Sat, 10 Apr 2010 18:07:27 -0700 (PDT) From: "Jim Schaad" To: "'Herzog, Jonathan - 0668 - MITLL'" , "'Khazan, Roger - 0668 - MITLL'" References: In-Reply-To: Date: Sat, 10 Apr 2010 18:07:23 -0700 Message-ID: <03ba01cad913$585f0a30$091d1e90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrSkEGHX2HP1ZYY5k6iqcDwbR9Z9QGgXGpA Content-Language: en-us Cc: smime@ietf.org Subject: Re: [smime] New ID of potential interest X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 01:07:33 -0000 A couple of questions and comments on this document 1. Is there a reason not to make the sequence require at least two elements for a union and an intersection? 2. For 'union' and 'intersection' I would prefer "This sequence MUST be non-empty." To be rendered as "The sequence of SetKeyParticipentSet values MUST be non-empty." The first time I read this I mixed up the ASN.1 sequence with the contents of the result of the union. 3. Given that we are discussion SETs. Are there any reasons not to impose some restrictions on those who create SetKetParticipentSet values so that they are not every empty? Thus an intersection SHOULD NOT result in an empty result. 4. Are there any locations (such as SetMember) where you one should explicitly state that this field may be expanded at a later date with additional values that may need to be recognized as being present, even if they are not evaluated. 5. When doing an intersection, does none need to understand the value of SetMember, or can the evaluation be done on the ASN.1 encoding of the SetMember. Specifically would one need to understand that a certificate containing a specific public key be identified EITHER by the pub key info or by the issuer/serial? Jim > -----Original Message----- > From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf > Of Herzog, Jonathan - 0668 - MITLL > Sent: Friday, April 02, 2010 11:14 AM > To: smime@ietf.org > Cc: Khazan, Roger - 0668 - MITLL > Subject: [smime] New ID of potential interest > > > I would like to inform the SMIME working group of a newly-submitted > Internet Draft that may be of interest: > > A set-key attribute for symmetric-key packages draft-herzog-setkey-00 > > Abstract > > A set-key is a symmetric key (or set of keys) associated with an > immutable set of participants. This document defines a set-key > attribute for use in the CMS-based symmetric-key package structure > defined in in RFC XXXX. {{{ RFC Editor, please replace XXXX with the > number assigned to draft-ietf-keyprov-symmetrickeyformat when it is > published. }}} > > https://datatracker.ietf.org/doc/draft-herzog-setkey/ > > We welcome all comments and reviews. > > Thank you. > > -- > Jonathan Herzog > Technical Staff, MIT Lincoln Laboratory > jherzog@ll.mit.edu From turners@ieca.com Mon Apr 19 15:43:29 2010 Return-Path: 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 8DECE3A67AF for ; Mon, 19 Apr 2010 15:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.748 X-Spam-Level: X-Spam-Status: No, score=0.748 tagged_above=-999 required=5 tests=[AWL=-2.604, BAYES_50=0.001, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, UNPARSEABLE_RELAY=0.001] 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 XdvIMVk2yXfn for ; Mon, 19 Apr 2010 15:43:28 -0700 (PDT) Received: from smtp113.biz.mail.re2.yahoo.com (smtp113.biz.mail.re2.yahoo.com [66.196.116.98]) by core3.amsl.com (Postfix) with SMTP id 861993A68E1 for ; Mon, 19 Apr 2010 15:43:27 -0700 (PDT) Received: (qmail 80875 invoked from network); 19 Apr 2010 22:43:16 -0000 Received: from thunderfish.local (turners@71.191.11.39 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 19 Apr 2010 15:43:15 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: AW.Vn_wVM1lc.jbANO8qerXlexEoJgRl_9FzRE8x1jpabjJkxyr51lV4xFlDNbmDN9GANfWlWeuUTCVDhb7a1iaVuYb05dY7bm34vLRATkk6Im9MStAh3eAnHh78wc2P3A2bdJNGovL9UbD1jesvaixEPtC48VAwBzovaMDR0Gmn0tqAq_jCAPEIvK3eZThmtbRyppjT2CqFLbu0ON7qu1S91kUS1NM9fXn86NGtjpSaZw6zVRLZmekS41Btl7XRbMz1AK8DqP2y.D5O3tzS8mGhCECP9s3F50FcRxDp3fxcPkfmXus9YBr1vl4GPdePsZfnQ5c6P8AKUZAiG85MMXlTQ19eD1ypzL47DW3ytAqQNFYdMHkkZSV4kIJwSlwMAqcAOLG406IHtgqgUilZgZfnzm48ZhvdnL_c3ECY76JeTA0_UyZ9CPf4cJci46T53TVvxtIA5TpANQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BCCDC83.6040401@ieca.com> Date: Mon, 19 Apr 2010 18:43:15 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: =?KOI8-R?Q?=EC=C5=CF=CE=D4=D8=C5=D7_=F3=C5=D2=C7=C5=CA_=E5=C6=C9=CD?= =?KOI8-R?Q?=CF=D7=C9=DE?= References: <200909170925.n8H9PpXx009782@boreas.isi.edu> <4717c1330909230756j5b7d2391y9285006a1ae43947@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: ah@tr-sys.de, smime@ietf.org Subject: Re: [smime] [Technical Errata Reported] RFC4490 (1884) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:43:29 -0000 What are your recommendations for the other errata: http://www.rfc-editor.org/verify_errata_select.php?eid=1885 Should it also be rejected? spt Леонтьев Сергей Ефимович wrote: > Hi, > > REJECT > > This is a request (Errata Note for RFC 4490, EID=1884) to change the protocol, not an errata. Changes like this need to go through a new RFC. > > > -- > Sorry for my bests English. > Serguei E. Leontiev w:+7(495)780-4820 USSR,Moscow,127018,Sushchevskij val 16-5 > Crypto-Pro, Ltd. m:+7(916)686-1081 SMS: > > > > > -----Original Message----- > From: Gregory Chudov [mailto:gchudov@gmail.com] > Sent: Wednesday, September 23, 2009 6:57 PM > To: RFC Errata System > Cc: Леонтьев Сергей Ефимович; tim.polk@nist.gov; pasi.eronen@nokia.com; turners@ieca.com; blaker@gmail.com; ah@tr-sys.de; smime@ietf.org > Subject: Re: [Technical Errata Reported] RFC4490 (1884) > > Greetings. > > 1) The Message Digest within the context of CMS is treated not as an > integer, but as a sequence of bytes. Ideally, we shouldn't have > mentioned any byte order here at all. > 2) Unfortunately, GOST R 34.11-94 doesn't specify the byte order for > the resulting digest, so we did have to specify it here. > 3) The samples from GOST R 34.11-94 > (http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost341194-02#section-7.3.1) > use little-endian byte order for the source messages, so little-endian > representation was a de-facto standard for applications using GOST R > 34.11-94 digest, long before RFC4490 was published. > 4) Reversing the byte order for Message Digest would require at least > a new digest OID, otherwise it would break numerous existing > implementations, and would be inconsistent with the samples provided > in RFC4490. > 5) As an alternative errata, the following sample can be added, > clarifying the byte order for Message Digest, using example from GOST > R 34.11-94: > > Message from [GOSTR341194] Appendix 3.1 > ([draft-dolmatov-cryptocom-gost341194-02], section 7.3.1): > M = "This is message, length=32 bytes" > MessageDigest: > 0 32: OCTET STRING > : b1 c4 66 d3 75 19 b8 2e 83 19 81 9f f3 25 95 e0 > : 47 a2 8c b6 f8 3e ff 1c 69 16 a8 15 a6 37 ff fa > > > Regards, > Gregory Chudov & Serguei Leontiev > > 2009/9/17 RFC Errata System : >> The following errata report has been submitted for RFC4490, >> "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4490&eid=1884 >> >> -------------------------------------- >> Type: Technical >> Reported by: Alfred Hoenes >> >> Section: 2.1, pg. 4 >> >> Original Text >> ------------- >> When the Message Digest authenticated attribute is present, the >> | DigestedData digest contains a 32-byte digest in little-endian >> representation: >> >> >> Corrected Text >> -------------- >> When the Message Digest authenticated attribute is present, the >> | DigestedData digest contains a 32-byte digest in big-endian >> representation: >> >> >> Notes >> ----- >> Rationale: >> - Contradiction to other parts of the document, >> which use "big-endian" == 'network byte order' >> as established in the Internet architecture. >> - Please also note that the ASN.1 BER/DER encoding is >> based on the 'natural' byte order for left-to-right >> scripts -- otherwise the intrinsically variable-length >> representation used would be very complicated to deal >> with in processing. >> - Intrduction of varying endian-ness is a likely source >> of implementation issues and, consequentially, >> interoperability problems. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4490 (draft-ietf-smime-gost-07) >> -------------------------------------- >> Title : Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS) >> Publication Date : May 2006 >> Author(s) : S. Leontiev, Ed., G. Chudov, Ed. >> Category : PROPOSED STANDARD >> Source : S/MIME Mail Security >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> > > From turners@ieca.com Mon Apr 19 16:15:45 2010 Return-Path: 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 EF07E3A67F7 for ; Mon, 19 Apr 2010 16:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.832 X-Spam-Level: X-Spam-Status: No, score=0.832 tagged_above=-999 required=5 tests=[AWL=-2.520, BAYES_50=0.001, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, UNPARSEABLE_RELAY=0.001] 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 Sz6fGHZ5TQ7w for ; Mon, 19 Apr 2010 16:15:43 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id 7AE5B3A67AF for ; Mon, 19 Apr 2010 16:15:43 -0700 (PDT) Received: (qmail 47721 invoked from network); 19 Apr 2010 23:15:32 -0000 Received: from thunderfish.local (turners@71.191.11.39 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 19 Apr 2010 16:15:31 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 4El6qkcVM1nzclbKkeLkxZFoAAUlQh8hRfd97QRnfPfiXQoxDv5Q9oUJWvp2Q5aYuF0Cc0bREGJNxIeWyrI35S_.30b9PjHWq.hW8GHMzxsD738O5g21mvBv3rBtg_xczRUdyA16T4MJ.iDi_5.0XcP_5p0hXlmD6b8k5jH9F.JzvMl_bILW56J5Yi3HuqgG8b7IPvkHq9A60EX.bEh6qVa53ACMjP9eyqFQ9Wmw_7fKwUag7AKKGyrZQPTgCmruERJHEcOjd926yb80YBBOUE._9cCnouw3MDha_mc9f4BNjYFhbcZyU7kdqpXGcvb6h.NTr1A.3L2SCVkjONGeaj5crgCS87ij_IIpf_373lVKh84_sfvqKIR8CgkN_fcKvfNI95h_gVq7tg_mfyeZbFddjnPkeETJlyz1Ed4IeURX97vI9bt7C8S_TM59SLJQokAo08GrFsi6rA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BCCE413.8040600@ieca.com> Date: Mon, 19 Apr 2010 19:15:31 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: =?KOI8-R?Q?=EC=C5=CF=CE=D4=D8=C5=D7_=F3=C5=D2=C7=C5=CA_=E5=C6=C9=CD?= =?KOI8-R?Q?=CF=D7=C9=DE?= , =?KOI8-R?Q?=E4=CF=CD=C1_?= =?KOI8-R?Q?=E7=D2=C9=C7=CF=D2=C9=CA_=FE=D5=C4=CF=D7?= References: <200909170925.n8H9PpXx009782@boreas.isi.edu> <4717c1330909230756j5b7d2391y9285006a1ae43947@mail.gmail.com> <4BCCDC83.6040401@ieca.com> In-Reply-To: <4BCCDC83.6040401@ieca.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: smime@ietf.org Subject: Re: [smime] [Technical Errata Reported] RFC4490 (1884) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 23:15:45 -0000 Sorry wrong link: http://www.rfc-editor.org/errata_search.php?eid=1885 Sean Turner wrote: > What are your recommendations for the other errata: > > http://www.rfc-editor.org/verify_errata_select.php?eid=1885 > > Should it also be rejected? > > spt > > Леонтьев Сергей Ефимович wrote: >> Hi, >> >> REJECT >> >> This is a request (Errata Note for RFC 4490, EID=1884) to change the >> protocol, not an errata. Changes like this need to go through a new RFC. >> >> >> -- >> Sorry for my bests English. >> Serguei E. Leontiev w:+7(495)780-4820 USSR,Moscow,127018,Sushchevskij >> val 16-5 >> Crypto-Pro, Ltd. m:+7(916)686-1081 SMS: >> >> >> >> >> -----Original Message----- >> From: Gregory Chudov [mailto:gchudov@gmail.com] Sent: Wednesday, >> September 23, 2009 6:57 PM >> To: RFC Errata System >> Cc: Леонтьев Сергей Ефимович; tim.polk@nist.gov; >> pasi.eronen@nokia.com; turners@ieca.com; blaker@gmail.com; >> ah@tr-sys.de; smime@ietf.org >> Subject: Re: [Technical Errata Reported] RFC4490 (1884) >> >> Greetings. >> >> 1) The Message Digest within the context of CMS is treated not as an >> integer, but as a sequence of bytes. Ideally, we shouldn't have >> mentioned any byte order here at all. >> 2) Unfortunately, GOST R 34.11-94 doesn't specify the byte order for >> the resulting digest, so we did have to specify it here. >> 3) The samples from GOST R 34.11-94 >> (http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost341194-02#section-7.3.1) >> >> use little-endian byte order for the source messages, so little-endian >> representation was a de-facto standard for applications using GOST R >> 34.11-94 digest, long before RFC4490 was published. >> 4) Reversing the byte order for Message Digest would require at least >> a new digest OID, otherwise it would break numerous existing >> implementations, and would be inconsistent with the samples provided >> in RFC4490. >> 5) As an alternative errata, the following sample can be added, >> clarifying the byte order for Message Digest, using example from GOST >> R 34.11-94: >> >> Message from [GOSTR341194] Appendix 3.1 >> ([draft-dolmatov-cryptocom-gost341194-02], section 7.3.1): >> M = "This is message, length=32 bytes" >> MessageDigest: >> 0 32: OCTET STRING >> : b1 c4 66 d3 75 19 b8 2e 83 19 81 9f f3 25 95 e0 >> : 47 a2 8c b6 f8 3e ff 1c 69 16 a8 15 a6 37 ff fa >> >> >> Regards, >> Gregory Chudov & Serguei Leontiev >> >> 2009/9/17 RFC Errata System : >>> The following errata report has been submitted for RFC4490, >>> "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST >>> R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=4490&eid=1884 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Alfred Hoenes >>> >>> Section: 2.1, pg. 4 >>> >>> Original Text >>> ------------- >>> When the Message Digest authenticated attribute is present, the >>> | DigestedData digest contains a 32-byte digest in little-endian >>> representation: >>> >>> >>> Corrected Text >>> -------------- >>> When the Message Digest authenticated attribute is present, the >>> | DigestedData digest contains a 32-byte digest in big-endian >>> representation: >>> >>> >>> Notes >>> ----- >>> Rationale: >>> - Contradiction to other parts of the document, >>> which use "big-endian" == 'network byte order' >>> as established in the Internet architecture. >>> - Please also note that the ASN.1 BER/DER encoding is >>> based on the 'natural' byte order for left-to-right >>> scripts -- otherwise the intrinsically variable-length >>> representation used would be very complicated to deal >>> with in processing. >>> - Intrduction of varying endian-ness is a likely source >>> of implementation issues and, consequentially, >>> interoperability problems. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4490 (draft-ietf-smime-gost-07) >>> -------------------------------------- >>> Title : Using the GOST 28147-89, GOST R 34.11-94, GOST >>> R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic >>> Message Syntax (CMS) >>> Publication Date : May 2006 >>> Author(s) : S. Leontiev, Ed., G. Chudov, Ed. >>> Category : PROPOSED STANDARD >>> Source : S/MIME Mail Security >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >>> >> >> > From paul.hoffman@vpnc.org Fri Apr 30 10:56:58 2010 Return-Path: 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 2E96C28C146 for ; Fri, 30 Apr 2010 10:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[AWL=-1.776, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] 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 Umltlo36LmlO for ; Fri, 30 Apr 2010 10:56:57 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id ADCE03A6B89 for ; Fri, 30 Apr 2010 10:56:56 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o3UHufYL005205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Apr 2010 10:56:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 30 Apr 2010 10:56:39 -0700 To: smime@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [smime] Fwd: Last Call: rfc4049 (BinaryTime: An alternate format for representing date and time in ASN.1) to Proposed Standard X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 17:56:58 -0000 Of interest to the WG... >To: IETF-Announce >From: The IESG >Subject: Last Call: rfc4049 (BinaryTime: An alternate format for representing > date and time in ASN.1) to Proposed Standard >Date: Thu, 29 Apr 2010 12:46:15 -0700 (PDT) >Reply-To: ietf@ietf.org >Sender: ietf-announce-bounces@ietf.org > >The IESG has received a request from an individual submitter to consider >the following document: > >- 'BinaryTime: An alternate format for representing date and time in > ASN.1 ' > RFC 4049 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 mailing lists by 2010-05-27. Exceptionally, >comments may be sent to iesg@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://www.ietf.org/rfc/rfc4049.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=4049&rfc_flag=1