From nobody Sun May 14 09:37:21 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A090C129451 for ; Sun, 14 May 2017 09:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 X8QMMj6OBX5m for ; Sun, 14 May 2017 09:37:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11CE128854 for ; Sun, 14 May 2017 09:35:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3ECC2B80A6E; Sun, 14 May 2017 09:35:50 -0700 (PDT) To: Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, paul.hoffman@vpnc.org, blaker@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: jsoref@gmail.com, smime@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170514163550.3ECC2B80A6E@rfc-editor.org> Date: Sun, 14 May 2017 09:35:50 -0700 (PDT) Archived-At: Subject: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 16:37:20 -0000 The following errata report has been submitted for RFC2633, "S/MIME Version 3 Message Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5019 -------------------------------------- Type: Technical Reported by: Josh Soref Section: 5 Original Text ------------- id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} Corrected Text -------------- id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::= {id-aa 11} Notes ----- encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945) referer [sic] before it, this is now part of the API. This error should be highlighted (as rfc2068 does for referer [sic]) so that people are aware that the natural spelling doesn't apply. If it's possible for a revised RFC to be published suggesting the correct spelling w/ a way for clients/servers to handle the old spelling, that would be nice, but based on precedent, that seems unlikely. Instructions: ------------- This erratum 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 can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2633 (draft-ietf-smime-msg-08) -------------------------------------- Title : S/MIME Version 3 Message Specification Publication Date : June 1999 Author(s) : B. Ramsdell, Ed. Category : PROPOSED STANDARD Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG From nobody Sun May 14 10:17:47 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2552D129A8D for ; Sun, 14 May 2017 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rRC67Jlp27rf for ; Sun, 14 May 2017 10:17:44 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC7B129B16 for ; Sun, 14 May 2017 10:15:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DB74D300572 for ; Sun, 14 May 2017 13:15:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QRRvgokUp38Z for ; Sun, 14 May 2017 13:15:00 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BC63130029F; Sun, 14 May 2017 13:14:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <20170514163550.3ECC2B80A6E@rfc-editor.org> Date: Sun, 14 May 2017 13:14:59 -0400 Cc: Paul Hoffman , Blake Ramsdell , Josh Soref , IETF SMIME Content-Transfer-Encoding: quoted-printable Message-Id: <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> References: <20170514163550.3ECC2B80A6E@rfc-editor.org> To: Kathleen Moriarty , Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 17:17:46 -0000 I believe that this errata should be rejected. The author used an = abbreviation, and the same spelling is used in RFC 3851. Russ > On May 14, 2017, at 12:35 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC2633, > "S/MIME Version 3 Message Specification". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5019 >=20 > -------------------------------------- > Type: Technical > Reported by: Josh Soref >=20 > Section: 5 >=20 > Original Text > ------------- > id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11} >=20 >=20 > Corrected Text > -------------- > id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {id-aa 11} >=20 > Notes > ----- > encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945) = referer [sic] before it, this is now part of the API. >=20 > This error should be highlighted (as rfc2068 does for referer [sic]) = so that people are aware that the natural spelling doesn't apply. >=20 > If it's possible for a revised RFC to be published suggesting the = correct spelling w/ a way for clients/servers to handle the old = spelling, that would be nice, but based on precedent, that seems = unlikely. >=20 > Instructions: > ------------- > This erratum 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC2633 (draft-ietf-smime-msg-08) > -------------------------------------- > Title : S/MIME Version 3 Message Specification > Publication Date : June 1999 > Author(s) : B. Ramsdell, Ed. > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime From nobody Sun May 14 10:48:17 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A71B128CD5 for ; Sun, 14 May 2017 10:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Oj4rTe5m796Q for ; Sun, 14 May 2017 10:48:12 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBA5129B75 for ; Sun, 14 May 2017 10:44:38 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l18so109199220oig.2 for ; Sun, 14 May 2017 10:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GpX2YbDp+ig8KXHXyaEDFd5VnpHWviFmn1M5EIJFkPg=; b=J1sURIfVl+S6GLIu6jQcZrcTr3yWQILna6Z3GAaTw03KQ6AeTCETGXkj3jFsU23qAq RlNQoPwo29++lMBVC1QmppNoUjOj0Fxuxy1/tip/X07X6S+/WEc8Kjhu1FJ2+yJ2qLpZ xCEHHvVZ1/EOQeVGybCDKN7Gveg3urjBltVltcKof/cFycVagLZtKvAxasdSzerCXSjT 4UlFh+IReR7trwBrj+U/4ddzBYuavRN8nA4I0MymC2VWAqLaHpzAaR8cbh5xi5Noey+x mJpTLCwDgV43Db9MpLZTMvJgbuhFJRzyQqHMXSQg6wKLLfv+LTMnDZ1aswGNPm4gCAQM P2kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GpX2YbDp+ig8KXHXyaEDFd5VnpHWviFmn1M5EIJFkPg=; b=BELDuinSMPpYO2xHGiEH0t2WDn8cWugsWacVy+41vERo48qSpYXTtxSYmVBSPOSx5s N4JBPjW6gqmgQrrpt48orekxzoN/vpmKm7b+j2geVrLMsLrOccvzIj4l6fESn2yngjKo xUd0k2qpjviUV5OZOD2arer9OeM1i2R9hv0z3b+qSUc2WiUt2BxFzRa/Qi6OREKYcAdk x2huiBd+tnme4h6HllFyVhPiiRpOQrdxNLrcnazKzZ6X/ApZjHY7JVg9MpeGK7bGd+W/ 3WFF4AS+ouPNOhwN3eeDYPw+MhYOX8MJhZNJhh+Ogp2CIj0ngPPPHR9RTj7JAfvOX58I g/lg== X-Gm-Message-State: AODbwcBjYQpCGn8n7kh6Y17hcMgLgkAsSi6PhvmwwS8GOYY5dwew63Lo OTcpMoLGlQiu1L5OgMW8eLPLpQZ06Q== X-Received: by 10.202.105.75 with SMTP id e72mr884390oic.180.1494783877846; Sun, 14 May 2017 10:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.14 with HTTP; Sun, 14 May 2017 10:44:36 -0700 (PDT) Received: by 10.157.4.14 with HTTP; Sun, 14 May 2017 10:44:36 -0700 (PDT) In-Reply-To: <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> From: Josh Soref Date: Sun, 14 May 2017 13:44:36 -0400 Message-ID: To: Russ Housley Cc: Paul Hoffman , Blake Ramsdell , IETF SMIME , Kathleen Moriarty , Eric Rescorla Content-Type: multipart/alternative; boundary="001a11408d620e1c28054f7f7ed8" Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 17:48:16 -0000 --001a11408d620e1c28054f7f7ed8 Content-Type: text/plain; charset="UTF-8" It isn't an abbreviation, other tokens are clearly longer such as signingCertificate and smimeEncryptCerts. It's likely that the errata applies to multiple RFCs. On May 14, 2017 1:15 PM, "Russ Housley" wrote: > I believe that this errata should be rejected. The author used an > abbreviation, and the same spelling is used in RFC 3851. > > Russ > > > > On May 14, 2017, at 12:35 PM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC2633, > > "S/MIME Version 3 Message Specification". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5019 > > > > -------------------------------------- > > Type: Technical > > Reported by: Josh Soref > > > > Section: 5 > > > > Original Text > > ------------- > > id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} > > > > > > Corrected Text > > -------------- > > id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::= {id-aa 11} > > > > Notes > > ----- > > encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945) > referer [sic] before it, this is now part of the API. > > > > This error should be highlighted (as rfc2068 does for referer [sic]) so > that people are aware that the natural spelling doesn't apply. > > > > If it's possible for a revised RFC to be published suggesting the > correct spelling w/ a way for clients/servers to handle the old spelling, > that would be nice, but based on precedent, that seems unlikely. > > > > Instructions: > > ------------- > > This erratum 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 > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC2633 (draft-ietf-smime-msg-08) > > -------------------------------------- > > Title : S/MIME Version 3 Message Specification > > Publication Date : June 1999 > > Author(s) : B. Ramsdell, Ed. > > Category : PROPOSED STANDARD > > Source : S/MIME Mail Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > smime mailing list > > smime@ietf.org > > https://www.ietf.org/mailman/listinfo/smime > > --001a11408d620e1c28054f7f7ed8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It isn't an abbreviation, other tokens are clearly lo= nger such as signingCertificate and smimeEncryptCerts. It's likely that= the errata applies to multiple RFCs.

<= div class=3D"gmail_quote">On May 14, 2017 1:15 PM, "Russ Housley"= <housley@vigilsec.com> w= rote:
I believe that= this errata should be rejected.=C2=A0 The author used an abbreviation, and= the same spelling is used in RFC 3851.

Russ


> On May 14, 2017, at 12:35 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC2633,
> "S/MIME Version 3 Message Specification".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5019
>
> --------------------------------------
> Type: Technical
> Reported by: Josh Soref <jsoref= @gmail.com>
>
> Section: 5
>
> Original Text
> -------------
> id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11}
>
>
> Corrected Text
> --------------
> id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {id-aa 11}
>
> Notes
> -----
> encryp isn't a word, it's a typo. Unfortunately, like http'= ;s (rfc1945) referer [sic] before it, this is now part of the API.
>
> This error should be highlighted (as rfc2068 does for referer [sic]) s= o that people are aware that the natural spelling doesn't apply.
>
> If it's possible for a revised RFC to be published suggesting the = correct spelling w/ a way for clients/servers to handle the old spelling, t= hat would be nice, but based on precedent, that seems unlikely.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC2633 (draft-ietf-smime-msg-08)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: S/MIME V= ersion 3 Message Specification
> Publication Date=C2=A0 =C2=A0 : June 1999
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: B. Ramsdell, Ed. > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S/MIME Mail S= ecurity
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> smime mailing list
> smime@ietf.org
> https://www.ietf.org/mailman/listinfo/smime=

--001a11408d620e1c28054f7f7ed8-- From nobody Sun May 14 10:58:02 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C7A129B17 for ; Sun, 14 May 2017 10:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 HcwN84Pvfz0D for ; Sun, 14 May 2017 10:57:59 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF61129412 for ; Sun, 14 May 2017 10:54:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 81A82300540 for ; Sun, 14 May 2017 13:54:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Lfl4uc17Okjw for ; Sun, 14 May 2017 13:54:30 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 823A930029F; Sun, 14 May 2017 13:54:30 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DF232206-6854-49FC-89A0-3027B6DE65FC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 14 May 2017 13:54:30 -0400 In-Reply-To: Cc: Paul Hoffman , Blake Ramsdell , IETF SMIME , Kathleen Moriarty , Eric Rescorla To: Josh Soref References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 17:58:01 -0000 --Apple-Mail=_DF232206-6854-49FC-89A0-3027B6DE65FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It is the name that the author chose to use in the ASN.1. If it was a = typo, then it would have been changed in the subsequent update to the = RFC. Russ > On May 14, 2017, at 1:44 PM, Josh Soref wrote: >=20 > It isn't an abbreviation, other tokens are clearly longer such as = signingCertificate and smimeEncryptCerts. It's likely that the errata = applies to multiple RFCs. >=20 > On May 14, 2017 1:15 PM, "Russ Housley" > wrote: > I believe that this errata should be rejected. The author used an = abbreviation, and the same spelling is used in RFC 3851. >=20 > Russ >=20 >=20 > > On May 14, 2017, at 12:35 PM, RFC Errata System = > wrote: > > > > The following errata report has been submitted for RFC2633, > > "S/MIME Version 3 Message Specification". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5019 = > > > > -------------------------------------- > > Type: Technical > > Reported by: Josh Soref > > > > > Section: 5 > > > > Original Text > > ------------- > > id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11} > > > > > > Corrected Text > > -------------- > > id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {id-aa 11} > > > > Notes > > ----- > > encryp isn't a word, it's a typo. Unfortunately, like http's = (rfc1945) referer [sic] before it, this is now part of the API. > > > > This error should be highlighted (as rfc2068 does for referer [sic]) = so that people are aware that the natural spelling doesn't apply. > > > > If it's possible for a revised RFC to be published suggesting the = correct spelling w/ a way for clients/servers to handle the old = spelling, that would be nice, but based on precedent, that seems = unlikely. > > > > Instructions: > > ------------- > > This erratum 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 > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC2633 (draft-ietf-smime-msg-08) > > -------------------------------------- > > Title : S/MIME Version 3 Message Specification > > Publication Date : June 1999 > > Author(s) : B. Ramsdell, Ed. > > Category : PROPOSED STANDARD > > Source : S/MIME Mail Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > smime mailing list > > smime@ietf.org > > https://www.ietf.org/mailman/listinfo/smime = >=20 --Apple-Mail=_DF232206-6854-49FC-89A0-3027B6DE65FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It is the name that the author chose to use in the ASN.1. =  If it was a typo, then it would have been changed in the = subsequent update to the RFC.

Russ


On May 14, 2017, at 1:44 PM, Josh Soref <jsoref@gmail.com> = wrote:

It isn't an abbreviation, other tokens are = clearly longer such as signingCertificate and smimeEncryptCerts. It's = likely that the errata applies to multiple RFCs.

On May = 14, 2017 1:15 PM, "Russ Housley" <housley@vigilsec.com> wrote:
I believe that this = errata should be rejected.  The author used an abbreviation, and = the same spelling is used in RFC 3851.

Russ


> On May 14, 2017, at 12:35 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC2633,
> "S/MIME Version 3 Message Specification".
>
> --------------------------------------
= > You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5019 >
> --------------------------------------
= > Type: Technical
> Reported by: Josh Soref <jsoref@gmail.com>
>
> Section: 5
>
> Original Text
> -------------
> id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11}
= >
>
> Corrected Text
> --------------
> id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {id-aa 11}
>
> Notes
> -----
> encryp isn't a word, it's a typo. Unfortunately, like http's = (rfc1945) referer [sic] before it, this is now part of the API.
>
> This error should be highlighted (as rfc2068 does for referer = [sic]) so that people are aware that the natural spelling doesn't = apply.
>
> If it's possible for a revised RFC to be published suggesting the = correct spelling w/ a way for clients/servers to handle the old = spelling, that would be nice, but based on precedent, that seems = unlikely.
>
> Instructions:
> -------------
> This erratum 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
> can log in to change the status and edit the report, if = necessary.
>
> --------------------------------------
= > RFC2633 (draft-ietf-smime-msg-08)
> --------------------------------------
= > Title               : = S/MIME Version 3 Message Specification
> Publication Date    : June 1999
> Author(s)           : B. Ramsdell, = Ed.
> Category            : PROPOSED = STANDARD
> Source              : S/MIME = Mail Security
> Area                : = Security
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> smime mailing list
> smime@ietf.org
> https://www.ietf.org/mailman/listinfo/smime


= --Apple-Mail=_DF232206-6854-49FC-89A0-3027B6DE65FC-- From nobody Sun May 14 13:40:32 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A15126D85 for ; Sun, 14 May 2017 13:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com 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 nMBFdTbfJKpE for ; Sun, 14 May 2017 13:40:27 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABCD129BC4 for ; Sun, 14 May 2017 13:35:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01D2CCB5.716ECF40" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494794132; h=from:subject:to:date:message-id; bh=CqFsuSvBRl7BtagAurRsMIPOCVnTFLFZT8uKMwZgzUk=; b=h0YPVOcExzWuCb1Wve45WI3ljl0FQGAAV6hNq4CfIV1qsoBVPVGIh0GS3vAItUYd/HkY8F2Xexa d0MTghfL010S4Nl+5bJq06N9GodLiEbhHsz6aSJ3idT9TmW/ov+EiQX1q4YgKDzcjq/Ms5/GZZ0mA oacPATqOQobvxs9ZvGDdXxYd9QJ91PY9aZYKbUbAUh9BjPM9461s7+6TMMEnNqYWUnsBeDIgGU2pe sFcN4X9m2b8c3+k4b/he7rtNrtqTO/0f15/Tpr6lRT87tQ8HqAAZy1pwj6vpw9ceV49voJPIJ0hou INZVAZ53ChvshmgoqpMl8iJaQOx4DJxJqPYg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 14 May 2017 13:35:31 -0700 Received: from Hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 14 May 2017 13:35:23 -0700 From: Jim Schaad To: 'Russ Housley' , 'Josh Soref' CC: 'Kathleen Moriarty' , 'Paul Hoffman' , 'Eric Rescorla' , 'IETF SMIME' References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> In-Reply-To: Date: Sun, 14 May 2017 13:24:37 -0700 Message-ID: <000a01d2ccf0$1dc9fdc0$595df940$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI0BoUGR6L9DvGoPD7iHYv3bniZuALJ2VGWAVdCe5UC2/hnR6D56VjQ X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 20:40:30 -0000 ------=_NextPart_000_000B_01D2CCB5.716ECF40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The name chosen has absolutely no change of what is one the wire. That means that this is at best editorial and is definitely not technical. This is only going to affect those people who decide to use autogenerated constant names from the ASN.1 file. The suggested change would make for an invalid ASN.1 file so it not correct. Changing this name at this point would be a hassle for any one doing auto generation and highlighting that this is not, in some sense, a word does not affect the standard in any way. This should be rejected. Jim From: smime [mailto:smime-bounces@ietf.org] On Behalf Of Russ Housley Sent: Sunday, May 14, 2017 10:55 AM To: Josh Soref Cc: Kathleen Moriarty ; Paul Hoffman ; Eric Rescorla ; IETF SMIME Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) It is the name that the author chose to use in the ASN.1. If it was a typo, then it would have been changed in the subsequent update to the RFC. Russ On May 14, 2017, at 1:44 PM, Josh Soref > wrote: It isn't an abbreviation, other tokens are clearly longer such as signingCertificate and smimeEncryptCerts. It's likely that the errata applies to multiple RFCs. On May 14, 2017 1:15 PM, "Russ Housley" > wrote: I believe that this errata should be rejected. The author used an abbreviation, and the same spelling is used in RFC 3851. Russ > On May 14, 2017, at 12:35 PM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC2633, > "S/MIME Version 3 Message Specification". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5019 > > -------------------------------------- > Type: Technical > Reported by: Josh Soref > > > Section: 5 > > Original Text > ------------- > id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} > > > Corrected Text > -------------- > id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::= {id-aa 11} > > Notes > ----- > encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945) referer [sic] before it, this is now part of the API. > > This error should be highlighted (as rfc2068 does for referer [sic]) so that people are aware that the natural spelling doesn't apply. > > If it's possible for a revised RFC to be published suggesting the correct spelling w/ a way for clients/servers to handle the old spelling, that would be nice, but based on precedent, that seems unlikely. > > Instructions: > ------------- > This erratum 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 > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2633 (draft-ietf-smime-msg-08) > -------------------------------------- > Title : S/MIME Version 3 Message Specification > Publication Date : June 1999 > Author(s) : B. Ramsdell, Ed. > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime ------=_NextPart_000_000B_01D2CCB5.716ECF40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The name = chosen has absolutely no change of what is one the wire. =   That means that this is at best editorial and is definitely = not technical.

 

This is = only going to affect those people who decide to use autogenerated = constant names from the ASN.1 file.  The suggested change would = make for an invalid ASN.1 file so it not correct.  Changing this = name at this point would be a hassle for any one doing auto generation = and highlighting that this is not, in some sense, a word does not affect = the standard in any way.

 

This should = be rejected.

 

Jim

 

 

From: smime = [mailto:smime-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Sunday, May 14, 2017 10:55 AM
To: Josh = Soref <jsoref@gmail.com>
Cc: Kathleen Moriarty = <Kathleen.Moriarty.ietf@gmail.com>; Paul Hoffman = <paul.hoffman@vpnc.org>; Eric Rescorla <ekr@rtfm.com>; IETF = SMIME <smime@ietf.org>
Subject: Re: [smime] [Technical = Errata Reported] RFC2633 (5019)

 

It is the = name that the author chose to use in the ASN.1.  If it was a typo, = then it would have been changed in the subsequent update to the = RFC.

 

Russ

 

 

On May 14, 2017, at 1:44 PM, Josh Soref <jsoref@gmail.com> = wrote:

 

It = isn't an abbreviation, other tokens are clearly longer such as = signingCertificate and smimeEncryptCerts. It's likely that the errata = applies to multiple RFCs.

 

On May = 14, 2017 1:15 PM, "Russ Housley" <housley@vigilsec.com> = wrote:

I believe that this errata should be = rejected.  The author used an abbreviation, and the same spelling = is used in RFC 3851.

Russ


> On May 14, 2017, at = 12:35 PM, RFC Errata System <rfc-editor@rfc-editor.org&g= t; wrote:
>
> The following errata report has been submitted = for RFC2633,
> "S/MIME Version 3 Message = Specification".
>
> = --------------------------------------
> You may review the report = below and at:
> http://www.rfc-editor.org/errata/eid5019
>> --------------------------------------
> Type: = Technical
> Reported by: Josh Soref <jsoref@gmail.com>
>
>= Section: 5
>
> Original Text
> -------------
> = id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa = 11}
>
>
> Corrected Text
> = --------------
> id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D = {id-aa 11}
>
> Notes
> -----
> encryp isn't a = word, it's a typo. Unfortunately, like http's (rfc1945) referer [sic] = before it, this is now part of the API.
>
> This error = should be highlighted (as rfc2068 does for referer [sic]) so that people = are aware that the natural spelling doesn't apply.
>
> If = it's possible for a revised RFC to be published suggesting the correct = spelling w/ a way for clients/servers to handle the old spelling, that = would be nice, but based on precedent, that seems = unlikely.
>
> Instructions:
> -------------
> = This erratum 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
> can log in to change the status and edit the report, if = necessary.
>
> = --------------------------------------
> RFC2633 = (draft-ietf-smime-msg-08)
> = --------------------------------------
> Title      =          : S/MIME Version 3 Message = Specification
> Publication Date    : June 1999
> = Author(s)           : B. Ramsdell, = Ed.
> Category            : PROPOSED = STANDARD
> Source              = : S/MIME Mail Security
> Area          =       : Security
> Stream      =         : IETF
> Verifying Party    =  : IESG
>
> = _______________________________________________
> smime mailing = list
> smime@ietf.org
> https://www.ietf.org/mailman/listinfo/smime

 

------=_NextPart_000_000B_01D2CCB5.716ECF40-- From nobody Sun May 14 13:46:57 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482C5128B88 for ; Sun, 14 May 2017 13:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fIsY5c2GJzBm for ; Sun, 14 May 2017 13:46:53 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8E4129AA0 for ; Sun, 14 May 2017 13:42:39 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id b204so111303588oii.1 for ; Sun, 14 May 2017 13:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=utbgZQNU/j2rqdsVx26gT0pG2teM07b8VzfpMQTL/d8=; b=RXqEm+MDuFXFSgHHHHRGZu04UaLb2HKHsW9TgxQh/4LNB8WwNitZwoyyTvsVcIr7nT F70JLLjChpzO6NNyFnpPRb+Y9FWFLpTcfuJlpfPQk/AedQCYBd1NbnnCmtiWVp6foSSP qIjGWSNmDAAN9a0SYguc8beZEyD3j1UCfk08VpKdpEHEvVn4mUHbhWUmJT6QfPmrUCAs b7YGd07dft5xna/PjOkpePx3lJCfoLAkgbfZTGV7Itvx5TYAPl9TW27gRjUF44nJvycE OymeKV1jdZlmsHqh6kY2CUuJ6386o/whNWqcea0t5NogdLgF4tPJLGVJgAA18Cj2hI+q Biqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=utbgZQNU/j2rqdsVx26gT0pG2teM07b8VzfpMQTL/d8=; b=OK2+FJ9hPY1U3A9hvsXQozDnOYkuYFszcTLkyE9JrZldEbmnA04hb8eKu0UO56tDVe crD6Nz+mh0M7Bbu/k+U4umSSHdSaew9lAUEA/bRaALPpR8e0k7NiVj4FUXYh12WKdeFn 31bsI102qSOUk2VTFr68zVCaT4/O18gXa/+UtK1LEY7BcNngP6daCF56uNvVHS0tF6Ua M6Dl/OjwMq1QFMs1EAxKchTnEUqSaCjh5Cf8dCyJLYO1eIqOFEnM4rAzTUWALxp86x+s TXlabZ1d/f5Qyb8i0VjhyfmEj4oTIdpkYaXS1UVUFvmO5ppcCUOSdLcoLMbnK1D6hCp2 /AaQ== X-Gm-Message-State: AODbwcD0jgUhGSYvv6+8sx+vpfvG9X/EBQAc109rck8RKYZhMpWd5LMq 6uLFG2HpjOwC9OaZCLzrXvq4dI7rRA== X-Received: by 10.157.13.23 with SMTP id 23mr1126785oti.5.1494794558692; Sun, 14 May 2017 13:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.14 with HTTP; Sun, 14 May 2017 13:42:38 -0700 (PDT) Received: by 10.157.4.14 with HTTP; Sun, 14 May 2017 13:42:38 -0700 (PDT) In-Reply-To: <000a01d2ccf0$1dc9fdc0$595df940$@augustcellars.com> References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> <000a01d2ccf0$1dc9fdc0$595df940$@augustcellars.com> From: Josh Soref Date: Sun, 14 May 2017 16:42:38 -0400 Message-ID: To: Jim Schaad Cc: Paul Hoffman , IETF SMIME , Eric Rescorla , Russ Housley , Kathleen Moriarty Content-Type: multipart/alternative; boundary="001a113ee1f2aef3b0054f81faf6" Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 20:46:56 -0000 --001a113ee1f2aef3b0054f81faf6 Content-Type: text/plain; charset="UTF-8" Ok. Let's say that I'm new to IETF process. The feedback provided so far is offensive. Please suggest the proper way to annotate that there is an error in a number of the documents hosted by IETF. Clearly someone successfully ridiculed IETF once such that future standards appropriately included "[sic]" wherever "referer" is used. It shouldn't be hard to suggest to a submitter the correct way to do that today, decades later. On May 14, 2017 4:35 PM, "Jim Schaad" wrote: > The name chosen has absolutely no change of what is one the wire. That > means that this is at best editorial and is definitely not technical. > > > > This is only going to affect those people who decide to use autogenerated > constant names from the ASN.1 file. The suggested change would make for an > invalid ASN.1 file so it not correct. Changing this name at this point > would be a hassle for any one doing auto generation and highlighting that > this is not, in some sense, a word does not affect the standard in any way. > > > > This should be rejected. > > > > Jim > > > > > > *From:* smime [mailto:smime-bounces@ietf.org] *On Behalf Of *Russ Housley > *Sent:* Sunday, May 14, 2017 10:55 AM > *To:* Josh Soref > *Cc:* Kathleen Moriarty ; Paul Hoffman < > paul.hoffman@vpnc.org>; Eric Rescorla ; IETF SMIME < > smime@ietf.org> > *Subject:* Re: [smime] [Technical Errata Reported] RFC2633 (5019) > > > > It is the name that the author chose to use in the ASN.1. If it was a > typo, then it would have been changed in the subsequent update to the RFC. > > > > Russ > > > > > > On May 14, 2017, at 1:44 PM, Josh Soref wrote: > > > > It isn't an abbreviation, other tokens are clearly longer such as > signingCertificate and smimeEncryptCerts. It's likely that the errata > applies to multiple RFCs. > > > > On May 14, 2017 1:15 PM, "Russ Housley" wrote: > > I believe that this errata should be rejected. The author used an > abbreviation, and the same spelling is used in RFC 3851. > > Russ > > > > On May 14, 2017, at 12:35 PM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC2633, > > "S/MIME Version 3 Message Specification". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5019 > > > > -------------------------------------- > > Type: Technical > > Reported by: Josh Soref > > > > Section: 5 > > > > Original Text > > ------------- > > id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} > > > > > > Corrected Text > > -------------- > > id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::= {id-aa 11} > > > > Notes > > ----- > > encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945) > referer [sic] before it, this is now part of the API. > > > > This error should be highlighted (as rfc2068 does for referer [sic]) so > that people are aware that the natural spelling doesn't apply. > > > > If it's possible for a revised RFC to be published suggesting the > correct spelling w/ a way for clients/servers to handle the old spelling, > that would be nice, but based on precedent, that seems unlikely. > > > > Instructions: > > ------------- > > This erratum 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 > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC2633 (draft-ietf-smime-msg-08) > > -------------------------------------- > > Title : S/MIME Version 3 Message Specification > > Publication Date : June 1999 > > Author(s) : B. Ramsdell, Ed. > > Category : PROPOSED STANDARD > > Source : S/MIME Mail Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > smime mailing list > > smime@ietf.org > > https://www.ietf.org/mailman/listinfo/smime > > > --001a113ee1f2aef3b0054f81faf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok. Let's say that I'm new to IETF process. The f= eedback provided so far is offensive.

Please suggest the proper way to annotate that there is an error = in a number of the documents hosted by IETF.

Clearly someone successfully ridiculed IETF once such = that future standards appropriately included "[sic]" wherever &qu= ot;referer" is used. It shouldn't be hard to suggest to a submitte= r the correct way to do that today, decades later.

On May 14, 2017 4:35 PM, "= ;Jim Schaad" <ietf@august= cellars.com> wrote:

The name chosen has= absolutely no change of what is one the wire. =C2=A0=C2=A0That means that = this is at best editorial and is definitely not technical.

=C2=A0

Thi= s is only going to affect those people who decide to use autogenerated cons= tant names from the ASN.1 file.=C2=A0 The suggested change would make for a= n invalid ASN.1 file so it not correct.=C2=A0 Changing this name at this po= int would be a hassle for any one doing auto generation and highlighting th= at this is not, in some sense, a word does not affect the standard in any w= ay.

=C2=A0

This should be rejected.

=C2=A0

Jim

<= p class=3D"MsoNormal">=C2=A0

=C2=A0

From: smime [= mailto:smime-bo= unces@ietf.org] On Behalf Of Russ Housley
Sent: S= unday, May 14, 2017 10:55 AM
To: Josh Soref <jsoref@gmail.com>
Cc:= Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>; Paul Hoffm= an <paul.hoff= man@vpnc.org>; Eric Rescorla <ekr@rtfm.com>; IETF SMIME <smime@ietf.org>
Subject: Re: = [smime] [Technical Errata Reported] RFC2633 (5019)

<= /div>

=C2=A0

= It is the name that the author chose to use in the ASN.1.=C2=A0 If it was a= typo, then it would have been changed in the subsequent update to the RFC.=

=C2=A0

Russ

=C2=A0

= =C2=A0

On May 14, 2017, at 1:44 PM, Josh Soref &= lt;jsoref@gmail.com> wrote:

=C2=A0

=C2=A0

On May 14, 2017 1:15 PM, "Russ Housley" <housley@vigilsec.com> wrote:

I believe that= this errata should be rejected.=C2=A0 The author used an abbreviation, and= the same spelling is used in RFC 3851.

Russ


> On May = 14, 2017, at 12:35 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:>
> The following errata report has been submitted for RFC2633,<= br>> "S/MIME Version 3 Message Specification".
>
>= --------------------------------------
> You may review the rep= ort below and at:
> http://www.rfc-editor.org/errata/eid5019
= >
> --------------------------------------
> Type: Tech= nical
> Reported by: Josh Soref <jsoref@gmail.com>
>
> Section: 5>
> Original Text
> -------------
> id-aa-encrypKeyPr= ef OBJECT IDENTIFIER ::=3D {id-aa 11}
>
>
> Corrected Tex= t
> --------------
> id-aa-encrypKeyPref [sic] OBJECT IDENTIFIE= R ::=3D {id-aa 11}
>
> Notes
> -----
> encryp isn&#= 39;t a word, it's a typo. Unfortunately, like http's (rfc1945) refe= rer [sic] before it, this is now part of the API.
>
> This erro= r should be highlighted (as rfc2068 does for referer [sic]) so that people = are aware that the natural spelling doesn't apply.
>
> If i= t's possible for a revised RFC to be published suggesting the correct s= pelling w/ a way for clients/servers to handle the old spelling, that would= be nice, but based on precedent, that seems unlikely.
>
> Inst= ructions:
> -------------
> This erratum is currently posted as= "Reported". If necessary, please
> use "Reply All&quo= t; to discuss whether it should be verified or
> rejected. When a dec= ision is reached, the verifying party
> can log in to change the stat= us and edit the report, if necessary.
>
> ---------------------= -----------------
> RFC2633 (draft-ietf-smime-msg-08)
> --= ------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: S/MIME Version 3 Message Specification=
> Publication Date=C2=A0 =C2=A0 : June 1999
> Author(s)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: B. Ramsdell, Ed.
> Category=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
> Source=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S/MIME Mail Security
>= ; Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
>= Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> ________________= _______________________________
> smime mailing list
> smime@ietf.org
>= = https://www.ietf.org/mailman/listinfo/smime

= =C2=A0

--001a113ee1f2aef3b0054f81faf6-- From nobody Sun May 14 14:26:19 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7FE129B8B for ; Sun, 14 May 2017 14:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 9dNVTSIxMwSm for ; Sun, 14 May 2017 14:26:15 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78DBF129465 for ; Sun, 14 May 2017 14:22:28 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id b68so29748783ywe.3 for ; Sun, 14 May 2017 14:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4sBoc9jZ3XxVDDHnIW95VOnHbjT7EMQ1LQ+2XrljRYQ=; b=f+cLJ5bI9XbKEtj6PJ/s+iGTM7NLW2eLg68Ec4UKWdCGcuDR4ar29OmEJgFK43NUXH TDvEfGzrQZ+CuTAgP1VEnUZ6xVdVcfB3ivhbCq7dpKpS2cHw9l+2Vsg+tg80kZFxHZPh Pni1+39knnPkidx+fhWHAbKUVfNRflbBqSboXFLctj+hXedSdcd51I4H6qX3Nkvkohc4 n0IM2StpRIZ9Xr1OM/VR6hEoslVrkK7oankt4VGF7WX33A7r2FByx1Z9BuFTzdZcaQjE q3sfK0lfew8SBRdxDcIMq5CqLeF+YeV4BRKf0JlRuJkdcicPpUvAyiC336qZZNya/60i 8A0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4sBoc9jZ3XxVDDHnIW95VOnHbjT7EMQ1LQ+2XrljRYQ=; b=tjRvlhUxzHO6ytTwrlE+Zx4knO28naWQScZ21/thkAYjzfALu94bjyBL/hrv10WlLX PDJmkx25W6A5jUoCj5yHVciokg/avLUjRRAz4zKZ8w5RlOpskxIp9Ztp0zrRyjSM2lYy 6gD+u2QyO31pSZa6VnSZU948wV9GuocEJEo8yy3VgvqoyAMPiLpsgMYj3AXYLy3MkdDM hGjjitQYGoIKX0SMoF+CEUzs5Hw6wTxK9BnJx5hdeiiMgMcCv+Dd8IjH92guKKHri09O xXYsoKFGOO/dIkzQTibfAsThM2w2lFIGoJKvYLgQ17TwyQhVK0iyEzzuWAX2EBu1EhZi zyLw== X-Gm-Message-State: AODbwcDqsMbg6fcFVZWyTjAFDSL2lNVBXoWFpMFliGxeKdl2cq9rrA1e M28rXOp1DkNpunEWIaYdRhJsNl3Yxg== X-Received: by 10.13.212.1 with SMTP id w1mr2353004ywd.24.1494796947666; Sun, 14 May 2017 14:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Sun, 14 May 2017 14:21:47 -0700 (PDT) In-Reply-To: References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> <000a01d2ccf0$1dc9fdc0$595df940$@augustcellars.com> From: Eric Rescorla Date: Sun, 14 May 2017 14:21:47 -0700 Message-ID: To: Josh Soref Cc: Jim Schaad , Paul Hoffman , IETF SMIME , Russ Housley , Kathleen Moriarty Content-Type: multipart/alternative; boundary="001a114fb0f613de30054f8289c8" Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 21:26:18 -0000 --001a114fb0f613de30054f8289c8 Content-Type: text/plain; charset="UTF-8" Hi Josh, AD for the successor group here (and hence one of the two ADs jointly responsible for processing this errata). 1. I don't actually think that the responses to you have been offensive. 2. I agree that "encryp" is an odd abbreviation, but then so is "pref", which I think you'll agree is an abbreviation, not a typo. So, I don't think this is a clear error, and the argument Russ offers that it isn't seems persuasive. 3. As Jim says, this has no impact on the protocol, and the specific change you are suggesting would actually break the ASN.1 module. No doubt we could use a comment, but given the opinions expressed here, I don't believe that that's necessary. Finally, I would note that even if I agreed with you that this in fact was an error, the correct processing would be "hold for document update", as indicated in point 5 of the processing guidelines https://www.ietf.org/iesg/statement/errata-processing.html -Ekr On Sun, May 14, 2017 at 1:42 PM, Josh Soref wrote: > Ok. Let's say that I'm new to IETF process. The feedback provided so far > is offensive. > > Please suggest the proper way to annotate that there is an error in a > number of the documents hosted by IETF. > > Clearly someone successfully ridiculed IETF once such that future > standards appropriately included "[sic]" wherever "referer" is used. It > shouldn't be hard to suggest to a submitter the correct way to do that > today, decades later. > > On May 14, 2017 4:35 PM, "Jim Schaad" wrote: > >> The name chosen has absolutely no change of what is one the wire. That >> means that this is at best editorial and is definitely not technical. >> >> >> >> This is only going to affect those people who decide to use autogenerated >> constant names from the ASN.1 file. The suggested change would make for an >> invalid ASN.1 file so it not correct. Changing this name at this point >> would be a hassle for any one doing auto generation and highlighting that >> this is not, in some sense, a word does not affect the standard in any way. >> >> >> >> This should be rejected. >> >> >> >> Jim >> >> >> >> >> >> *From:* smime [mailto:smime-bounces@ietf.org] *On Behalf Of *Russ Housley >> *Sent:* Sunday, May 14, 2017 10:55 AM >> *To:* Josh Soref >> *Cc:* Kathleen Moriarty ; Paul Hoffman >> ; Eric Rescorla ; IETF SMIME < >> smime@ietf.org> >> *Subject:* Re: [smime] [Technical Errata Reported] RFC2633 (5019) >> >> >> >> It is the name that the author chose to use in the ASN.1. If it was a >> typo, then it would have been changed in the subsequent update to the RFC. >> >> >> >> Russ >> >> >> >> >> >> On May 14, 2017, at 1:44 PM, Josh Soref wrote: >> >> >> >> It isn't an abbreviation, other tokens are clearly longer such as >> signingCertificate and smimeEncryptCerts. It's likely that the errata >> applies to multiple RFCs. >> >> >> >> On May 14, 2017 1:15 PM, "Russ Housley" wrote: >> >> I believe that this errata should be rejected. The author used an >> abbreviation, and the same spelling is used in RFC 3851. >> >> Russ >> >> >> > On May 14, 2017, at 12:35 PM, RFC Errata System < >> rfc-editor@rfc-editor.org> wrote: >> > >> > The following errata report has been submitted for RFC2633, >> > "S/MIME Version 3 Message Specification". >> > >> > -------------------------------------- >> > You may review the report below and at: >> > http://www.rfc-editor.org/errata/eid5019 >> > >> > -------------------------------------- >> > Type: Technical >> > Reported by: Josh Soref >> > >> > Section: 5 >> > >> > Original Text >> > ------------- >> > id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} >> > >> > >> > Corrected Text >> > -------------- >> > id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::= {id-aa 11} >> > >> > Notes >> > ----- >> > encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945) >> referer [sic] before it, this is now part of the API. >> > >> > This error should be highlighted (as rfc2068 does for referer [sic]) so >> that people are aware that the natural spelling doesn't apply. >> > >> > If it's possible for a revised RFC to be published suggesting the >> correct spelling w/ a way for clients/servers to handle the old spelling, >> that would be nice, but based on precedent, that seems unlikely. >> > >> > Instructions: >> > ------------- >> > This erratum 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 >> > can log in to change the status and edit the report, if necessary. >> > >> > -------------------------------------- >> > RFC2633 (draft-ietf-smime-msg-08) >> > -------------------------------------- >> > Title : S/MIME Version 3 Message Specification >> > Publication Date : June 1999 >> > Author(s) : B. Ramsdell, Ed. >> > Category : PROPOSED STANDARD >> > Source : S/MIME Mail Security >> > Area : Security >> > Stream : IETF >> > Verifying Party : IESG >> > >> > _______________________________________________ >> > smime mailing list >> > smime@ietf.org >> > https://www.ietf.org/mailman/listinfo/smime >> >> >> > --001a114fb0f613de30054f8289c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Josh,

AD for the successor group h= ere (and hence one of the two ADs
jointly r= esponsible for processing this errata).
1. I don't actually think that the re= sponses to you have been offensive.

2. I agree that "encryp" is an odd = abbreviation, but then so is "pref", which
I think you'll agree is an abbreviation, not a typo. So, = I don't think this is
a clear error, an= d the argument Russ offers that it isn't seems persuasive.

3. As Jim says, th= is has no impact on the protocol, and the specific
change you are suggesting would actually break the ASN.1 module.
No doubt we could use a comment, but given th= e opinions expressed
here, I don't beli= eve that that's necessary.

Finally, I would note that even if I agreed with y= ou that this in fact was
an error, the corr= ect processing would be "hold for document update",
as indicated in point 5 of the processing guidelines
https://www.ietf.org/iesg/statement/errata-process= ing.html

-Ekr






On Sun, May 14, 2017 at 1:42 PM,= Josh Soref <jsoref@gmail.com> wrote:
Ok. Let's say that I= 9;m new to IETF process. The feedback provided so far is offensive.

Please suggest the proper way to anno= tate that there is an error in a number of the documents hosted by IETF.

Clearly someone successful= ly ridiculed IETF once such that future standards appropriately included &q= uot;[sic]" wherever "referer" is used. It shouldn't be h= ard to suggest to a submitter the correct way to do that today, decades lat= er.

On May 14, 2017 4:35 PM, = "Jim Schaad" <ietf@augustcellars.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

The name chosen has absolutely no change of what is one = the wire. =C2=A0=C2=A0That means that this is at best editorial and is defi= nitely not technical.

=C2=A0=

This is only going to affect those peopl= e who decide to use autogenerated constant names from the ASN.1 file.=C2=A0= The suggested change would make for an invalid ASN.1 file so it not correc= t.=C2=A0 Changing this name at this point would be a hassle for any one doi= ng auto generation and highlighting that this is not, in some sense, a word= does not affect the standard in any way.

=C2=A0

This should be reject= ed.

=C2=A0

Jim

=C2=A0

=C2=A0

From: s= mime [mailto:sm= ime-bounces@ietf.org] On Behalf Of Russ Housley
Sent:= Sunday, May 14, 2017 10:55 AM
To: Josh Soref <jsoref@gmail.com>
C= c: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>; Paul= Hoffman <pau= l.hoffman@vpnc.org>; Eric Rescorla <ekr@rtfm.com>; IETF SMIME <smime@ietf.org>
Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019)

<= /div>

=C2=A0

It is the name that the author chose to use in the ASN.1.=C2=A0 If it= was a typo, then it would have been changed in the subsequent update to th= e RFC.

=C2=A0

Russ

=C2=A0

<= u>=C2=A0

On May 14, 2017, at 1:44 PM, Josh Soref= <jsoref@gmail.com= > wrote:

=C2=A0=

It isn't an abbreviation, o= ther tokens are clearly longer such as signingCertificate and smimeEncryptC= erts. It's likely that the errata applies to multiple RFCs.

=C2=A0

On May 14, 2017 1:15 PM, "Russ Housley" <housley@vigilsec.com<= /a>> wrote:

I believe that this errata should be reject= ed.=C2=A0 The author used an abbreviation, and the same spelling is used in= RFC 3851.

Russ


> On May 14, 2017, at 12:35 PM, RFC Er= rata System <rfc-editor@rfc-editor.org> wrote:
>
> The following = errata report has been submitted for RFC2633,
> "S/MIME Version = 3 Message Specification".
>
> ----------------------------= ----------
> You may review the report below and at:
> http://= www.rfc-editor.org/errata/eid5019
>
> ----------------= ----------------------
> Type: Technical
> Reported by: Jo= sh Soref <jsoref@g= mail.com>
>
> Section: 5
>
> Original Text> -------------
> id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {i= d-aa 11}
>
>
> Corrected Text
> --------------
&= gt; id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {id-aa 11}
>> Notes
> -----
> encryp isn't a word, it's a typo.= Unfortunately, like http's (rfc1945) referer [sic] before it, this is = now part of the API.
>
> This error should be highlighted (as r= fc2068 does for referer [sic]) so that people are aware that the natural sp= elling doesn't apply.
>
> If it's possible for a revise= d RFC to be published suggesting the correct spelling w/ a way for clients/= servers to handle the old spelling, that would be nice, but based on preced= ent, that seems unlikely.
>
> Instructions:
> -----------= --
> This erratum is currently posted as "Reported". If nec= essary, please
> use "Reply All" to discuss whether it shou= ld be verified or
> rejected. When a decision is reached, the verifyi= ng party
> can log in to change the status and edit the report, if ne= cessary.
>
> --------------------------------------
>= ; RFC2633 (draft-ietf-smime-msg-08)
> ------------------------------<= wbr>--------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: S/MIME Version 3 Message Specification
> Publication Date=C2= =A0 =C2=A0 : June 1999
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: B. Ramsdell, Ed.
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 : PROPOSED STANDARD
> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : S/MIME Mail Security
> Area=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
> Stream=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2= =A0 =C2=A0: IESG
>
> _____________________________________= __________
> smime mailing list
> smime@ietf.org
> https://www.ietf.org/mailm= an/listinfo/smime

=

=C2=A0


--001a114fb0f613de30054f8289c8-- From nobody Sun May 14 15:42:49 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C99129B5A for ; Sun, 14 May 2017 15:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com 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 JDoWSGkQ9BGo for ; Sun, 14 May 2017 15:42:45 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2AC129B3A for ; Sun, 14 May 2017 15:38:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01D2CCC6.AACE8DA0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494801530; h=from:subject:to:date:message-id; bh=eli5OiF9/qLbs69usnvFN1O6V68YJhDHDsxpEZMUpkM=; b=cD9FWMlo8t8LalGROsXzSLmtB6fi/C+kbYZl2L2zCdJB4P3c0YHm7YGS/2/8sE2eXFTQaxKFLPq ZDwYavC2KoHlbQOTpjxbMv++lHIugky6wifp3GlL/UI+tL6tKUV8rMo0xlvjt52pYwdu0ieoBP8DQ w1H7QKEB2j+EXgk95uAqtQvguHlgerGyadR4xRrsD0NeXffUvHi5njiUsxSXIVD2L59gWRXdbZjbx 82V3d2Y34JyfvcczpLQTDU03Oia2gaTKFLwnLAMIDk7SF4T0zqM/iK8X4I9YM1C6gDwUeAHGFVpnS yDbp12tCwxevkywXE4LXhd5e4Ob7ADi96/rA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 14 May 2017 15:38:49 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 14 May 2017 15:38:41 -0700 From: Jim Schaad To: 'Josh Soref' CC: 'Paul Hoffman' , 'IETF SMIME' , 'Eric Rescorla' , 'Russ Housley' , 'Kathleen Moriarty' References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> <000a01d2ccf0$1dc9fdc0$595df940$@augustcellars.com> In-Reply-To: Date: Sun, 14 May 2017 15:27:55 -0700 Message-ID: <001901d2cd01$572946f0$057bd4d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI0BoUGR6L9DvGoPD7iHYv3bniZuALJ2VGWAVdCe5UC2/hnRwIDkXSsAdWYujag2z6E8A== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 22:42:48 -0000 ------=_NextPart_000_001A_01D2CCC6.AACE8DA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I did not intend to be offensive, and I apologize if you have found it = so. =20 I thought that I offered two reasons why the current suggested errata = was incorrect. If they were both fixed, then I do not know what my = position on this suggestion would be. =20 I am unclear if the use of sic as presented in the errata is correct or = not. I would need to ask the RFC editor on that point, but if this was = editorial and held for update then that is not of any immediate = importance. My general understanding is that =E2=80=9Csic=E2=80=9D is = used, not in original source material, but in quotes to say that I did a = faithful transcription of what was in the original document and the = spelling (or other) errors are theirs and not mine. That would be a = question for others and not for me. This could be a correct usage that = I am unaware of. =20 Going back and looking at RC 2616, it is clear that this is a technical = issue in that document. The string =E2=80=9CReferer=E2=80=9D appears as = bits transported on the wire and needs to be spelt as it is in the = document rather than having the spelling corrected. If the correct = spelling is used, there would be an interoperability issue. This makes = the usage of =E2=80=9Csic=E2=80=9D correct in this location and it would = have been a technical errata if it was raised. =20 The use of the errata mechanism is an appropriate method for raising = these types of issues, however it must be recognized that we do not all = have the same level of significance when it comes to technical vs = editorial. Some people are more strict in terms of how significant an = errata issue affects the document and consider anything which, even if = it might lead to difference of opinion on implementation, to be = editorial. I think however, that this suggestion was clearly editorial = in nature as it would not cause confusion in how things are to be = implemented or change bits on the wire if one were to change the string = in the ASN.1 file. =20 Jim =20 =20 From: Josh Soref [mailto:jsoref@gmail.com]=20 Sent: Sunday, May 14, 2017 1:43 PM To: Jim Schaad Cc: Paul Hoffman ; IETF SMIME ; = Eric Rescorla ; Russ Housley ; = Kathleen Moriarty Subject: RE: [smime] [Technical Errata Reported] RFC2633 (5019) =20 Ok. Let's say that I'm new to IETF process. The feedback provided so far = is offensive. =20 Please suggest the proper way to annotate that there is an error in a = number of the documents hosted by IETF. =20 Clearly someone successfully ridiculed IETF once such that future = standards appropriately included "[sic]" wherever "referer" is used. It = shouldn't be hard to suggest to a submitter the correct way to do that = today, decades later. =20 On May 14, 2017 4:35 PM, "Jim Schaad" > wrote: The name chosen has absolutely no change of what is one the wire. That = means that this is at best editorial and is definitely not technical. =20 This is only going to affect those people who decide to use = autogenerated constant names from the ASN.1 file. The suggested change = would make for an invalid ASN.1 file so it not correct. Changing this = name at this point would be a hassle for any one doing auto generation = and highlighting that this is not, in some sense, a word does not affect = the standard in any way. =20 This should be rejected. =20 Jim =20 =20 From: smime [mailto:smime-bounces@ietf.org = ] On Behalf Of Russ Housley Sent: Sunday, May 14, 2017 10:55 AM To: Josh Soref > Cc: Kathleen Moriarty >; Paul Hoffman = >; Eric Rescorla = >; IETF SMIME > Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) =20 It is the name that the author chose to use in the ASN.1. If it was a = typo, then it would have been changed in the subsequent update to the = RFC. =20 Russ =20 =20 On May 14, 2017, at 1:44 PM, Josh Soref > wrote: =20 It isn't an abbreviation, other tokens are clearly longer such as = signingCertificate and smimeEncryptCerts. It's likely that the errata = applies to multiple RFCs. =20 On May 14, 2017 1:15 PM, "Russ Housley" > wrote: I believe that this errata should be rejected. The author used an = abbreviation, and the same spelling is used in RFC 3851. Russ > On May 14, 2017, at 12:35 PM, RFC Errata System = > wrote: > > The following errata report has been submitted for RFC2633, > "S/MIME Version 3 Message Specification". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5019 > > -------------------------------------- > Type: Technical > Reported by: Josh Soref > > > Section: 5 > > Original Text > ------------- > id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11} > > > Corrected Text > -------------- > id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {id-aa 11} > > Notes > ----- > encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945) = referer [sic] before it, this is now part of the API. > > This error should be highlighted (as rfc2068 does for referer [sic]) = so that people are aware that the natural spelling doesn't apply. > > If it's possible for a revised RFC to be published suggesting the = correct spelling w/ a way for clients/servers to handle the old = spelling, that would be nice, but based on precedent, that seems = unlikely. > > Instructions: > ------------- > This erratum 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 > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2633 (draft-ietf-smime-msg-08) > -------------------------------------- > Title : S/MIME Version 3 Message Specification > Publication Date : June 1999 > Author(s) : B. Ramsdell, Ed. > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > smime mailing list > smime@ietf.org =20 > https://www.ietf.org/mailman/listinfo/smime =20 ------=_NextPart_000_001A_01D2CCC6.AACE8DA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I did not = intend to be offensive, and I apologize if you have found it = so.

 

I thought that I offered two reasons why the current = suggested errata was incorrect.=C2=A0 If they were both fixed, then I do = not know what my position on this suggestion would be.

 

I am unclear = if the use of sic as presented in the errata is correct or not.=C2=A0 I = would need to ask the RFC editor on that point, but if this was = editorial and held for update then that is not of any immediate = importance.=C2=A0 My general understanding is that =E2=80=9Csic=E2=80=9D = is used, not in original source material, but in quotes to say that I = did a faithful transcription of what was in the original document and = the spelling (or other) errors are theirs and not mine.=C2=A0 That would = be a question for others and not for me. =C2=A0This could be a correct = usage that I am unaware of.

 

Going back = and looking at RC 2616, it is clear that this is a technical issue in = that document.=C2=A0 The string =E2=80=9CReferer=E2=80=9D appears as = bits transported on the wire and needs to be spelt as it is in the = document rather than having the spelling corrected.=C2=A0 If the correct = spelling is used, there would be an interoperability issue.=C2=A0 This = makes the usage of =E2=80=9Csic=E2=80=9D correct in this location and it = would have been a technical errata if it was raised.

 

The use of = the errata mechanism is an appropriate method for raising these types of = issues, however it must be recognized that we do not all have the same = level of significance when it comes to technical vs editorial.=C2=A0 = Some people are more strict in terms of how significant an errata issue = affects the document and consider anything which, even if it might lead = to difference of opinion on implementation, to be editorial.=C2=A0 I = think however, that this suggestion was clearly editorial in nature as = it would not cause confusion in how things are to be implemented or = change bits on the wire if one were to change the string in the ASN.1 = file.

 

Jim

 

 

From: = Josh Soref [mailto:jsoref@gmail.com]
Sent: Sunday, May 14, = 2017 1:43 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Paul Hoffman = <paul.hoffman@vpnc.org>; IETF SMIME <smime@ietf.org>; Eric = Rescorla <ekr@rtfm.com>; Russ Housley = <housley@vigilsec.com>; Kathleen Moriarty = <Kathleen.Moriarty.ietf@gmail.com>
Subject: RE: [smime] = [Technical Errata Reported] RFC2633 (5019)

 

Ok. = Let's say that I'm new to IETF process. The feedback provided so far is = offensive.

 

Please suggest the proper way to annotate that there = is an error in a number of the documents hosted by = IETF.

 

Clearly someone successfully ridiculed IETF once such = that future standards appropriately included "[sic]" wherever = "referer" is used. It shouldn't be hard to suggest to a = submitter the correct way to do that today, decades = later.

 

On May = 14, 2017 4:35 PM, "Jim Schaad" <ietf@augustcellars.com> = wrote:

The name = chosen has absolutely no change of what is one the wire. =   That means that this is at best editorial and is definitely = not technical.

 <= /o:p>

This is = only going to affect those people who decide to use autogenerated = constant names from the ASN.1 file.  The suggested change would = make for an invalid ASN.1 file so it not correct.  Changing this = name at this point would be a hassle for any one doing auto generation = and highlighting that this is not, in some sense, a word does not affect = the standard in any way.

 <= /o:p>

This should = be rejected.

 <= /o:p>

Jim

 <= /o:p>

 <= /o:p>

From:= smime [mailto:smime-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Sunday, May 14, 2017 10:55 AM
To: Josh = Soref <jsoref@gmail.com>
Cc: Kathleen = Moriarty <Kathleen.Moriarty.ietf@gmail.com>; Paul Hoffman = <paul.hoffman@vpnc.org>; Eric Rescorla <ekr@rtfm.com>; = IETF SMIME <smime@ietf.org>
Subject: Re: [smime] = [Technical Errata Reported] RFC2633 (5019)

 <= /o:p>

It is the = name that the author chose to use in the ASN.1.  If it was a typo, = then it would have been changed in the subsequent update to the = RFC.

 <= /o:p>

Russ

 <= /o:p>

 <= /o:p>

On May 14, = 2017, at 1:44 PM, Josh Soref <jsoref@gmail.com> wrote:

 <= /o:p>

It isn't an = abbreviation, other tokens are clearly longer such as signingCertificate = and smimeEncryptCerts. It's likely that the errata applies to multiple = RFCs.

 <= /o:p>

On May 14, = 2017 1:15 PM, "Russ Housley" <housley@vigilsec.com> = wrote:

I believe that = this errata should be rejected.  The author used an abbreviation, = and the same spelling is used in RFC 3851.

Russ


> = On May 14, 2017, at 12:35 PM, RFC Errata System <rfc-editor@rfc-editor.org> = wrote:
>
> The following errata report has been submitted = for RFC2633,
> "S/MIME Version 3 Message = Specification".
>
> = --------------------------------------
> You may review the report = below and at:
> http://www.rfc-editor.org/errata/eid5019
>> --------------------------------------
> Type: = Technical
> Reported by: Josh Soref <jsoref@gmail.com>
>
> Section: = 5
>
> Original Text
> -------------
> = id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa = 11}
>
>
> Corrected Text
> = --------------
> id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D = {id-aa 11}
>
> Notes
> -----
> encryp isn't a = word, it's a typo. Unfortunately, like http's (rfc1945) referer [sic] = before it, this is now part of the API.
>
> This error = should be highlighted (as rfc2068 does for referer [sic]) so that people = are aware that the natural spelling doesn't apply.
>
> If = it's possible for a revised RFC to be published suggesting the correct = spelling w/ a way for clients/servers to handle the old spelling, that = would be nice, but based on precedent, that seems = unlikely.
>
> Instructions:
> -------------
> = This erratum 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
> can log in to change the status and edit the report, if = necessary.
>
> = --------------------------------------
> RFC2633 = (draft-ietf-smime-msg-08)
> = --------------------------------------
> Title      =          : S/MIME Version 3 Message = Specification
> Publication Date    : June 1999
> = Author(s)           : B. Ramsdell, = Ed.
> Category            : PROPOSED = STANDARD
> Source              = : S/MIME Mail Security
> Area          =       : Security
> Stream      =         : IETF
> Verifying Party    =  : IESG
>
> = _______________________________________________
> smime mailing = list
> smime@ietf.org
> https://www.ietf.org/mailman/listinfo/smime

 <= /o:p>

------=_NextPart_000_001A_01D2CCC6.AACE8DA0-- From nobody Sun May 14 17:56:59 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BCC127A90 for ; Sun, 14 May 2017 17:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 Jc62AkeAlpF2 for ; Sun, 14 May 2017 17:56:57 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56251294FD for ; Sun, 14 May 2017 17:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1494809607; x=1526345607; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pPRaKbUKC+GneekZwLs00oTyalGawF5wmRgr5DutMkA=; b=VK7nVuGWN/FyCfLj6yOBYiktWUlWU/wCEk1V+P+a7ze9OZr2Nhh4DuaE 4HIMRKykHovKdgYJ1UsyDYATxtb70uOfhDlyFPlseys7DQv//qfQUZbJs xM+6FD/YlacrlxADUDNTjsL0V61/AeV/LSWEc+nZbL1slva1lGon5oQQe fPBoLb/phsm0Hc8FoBWh6+jS7GJzlax8WH7/wLc4tl1Gh/jgDae8LYDNJ tv8cTEgKEhk4X6xZ+Z5tj7hFpgACaGeifMyK3gEM4HeakAxMZyrTzz+TV xYzjpAGil8wg1zVesizelaOXmeqOOaU0Bpo428P+Iz2sR3r4srtIeCpTc Q==; X-IronPort-AV: E=Sophos;i="5.38,342,1491220800"; d="scan'208";a="154166069" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 May 2017 12:53:22 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 15 May 2017 12:53:21 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Mon, 15 May 2017 12:53:21 +1200 From: Peter Gutmann To: Russ Housley , Josh Soref CC: Kathleen Moriarty , Paul Hoffman , Eric Rescorla , IETF SMIME , "blaker@gmail.com" Thread-Topic: [smime] [Technical Errata Reported] RFC2633 (5019) Thread-Index: AQHSzNBi+k9W3wqO00WxdgSX/alnY6HzSG+AgAAIRwCAAALEAIABO9PG Date: Mon, 15 May 2017 00:53:21 +0000 Message-ID: <1494809561399.43186@cs.auckland.ac.nz> References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 00:56:59 -0000 Russ Housley writes:=0A= =0A= >If it was a typo, then it would have been changed in the subsequent update= to=0A= >the RFC.=0A= =0A= "If cigarettes were bad for you then the government wouldn't allow them to = be=0A= sold".=0A= =0A= All this means is that it's a typo that wasn't noticed until now. Given th= at=0A= the full thing is called "SMIMEEncryptionKeyPreference" it does seem like i= t's=0A= a typo. The fact that it's rarely used compared to, say, sMIMECapabilities= ,=0A= means that it could easily have been overlooked until now. =0A= =0A= Or we could do something completely radical and ask Blake what he meant the= re.=0A= =0A= In fact, why don't I do that right now...=0A= =0A= Peter.=0A= From nobody Sun May 14 21:48:12 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023661270A3 for ; Sun, 14 May 2017 21:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WyQcSamZdC5O for ; Sun, 14 May 2017 21:48:08 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017B9129AD2 for ; Sun, 14 May 2017 21:43:23 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id w50so72906026wrc.0 for ; Sun, 14 May 2017 21:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wH4aocjsjuX+li4lE0Ymsx8AcMcareckp05kJRF15bA=; b=S1N0Xjp7vvEilmHr47lbBzn/XMGuONtLn7jKPPvCchx8RMmqImRRJQPp/Nkk2a8cNH GYvMMULtqkCas1BW++HHVAfv015R8Opf/HxX7eN2mMZ61dQmxbUHP4KpKIMNxcfJLeZo iWIqa/oSbuMR1nrzW7AuVPdljP5diaTYa5z/QM4M8Ng7AS1caVn7gex4UAb/B2AdFzdD NQu+pa/EP7ANBeA5LW3VJwCzibPSu8YBqn4bSahYHf5kxByUNKBDk3kh182kgBnDkHxC wTvhcUBiFoW9i7bmWQRVcylztVPl6PmeCKtISF8Cm6LVZ1C4Ubnnb512Dz4ee6G3TjIW eYCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wH4aocjsjuX+li4lE0Ymsx8AcMcareckp05kJRF15bA=; b=D8YR69xZjqrodKfu6mQtSoZnWGX8XXV2VccSVu3lZZuiock6ZL9+zpfCLSrujpPrHH X6OfUqW7WGKFnhgncp8Y2IY94//HoIul+rYqUr5q82eNMOQPXdKWLMaie1VYG7n+69z+ fvCjCfMDuLYkW7piKdlpb3TbxM8sX5CQzp4BBpPL47ubY1wjdywu5bhNpMencC7fCUA/ 8OKVUza7n92PAxRKOgIgRCNxtq9phnwueuUYsbne8hFuNZxxIQOvvFNzF4gHRQfCQBYB wsXFslR+aNPsCop4zMisP5LBTkgaCC1e+NMV/F7G2YKajHEsLI3w1RT6zavtfp4sTKpb 27CQ== X-Gm-Message-State: AODbwcA12hMe8STk3GHbHLrorrn6CuMJty0hdD3CEq19cERtZG5KrsVf qOu5e5K4sjqqN9YMjMdgj9naGiP1ew== X-Received: by 10.223.176.163 with SMTP id i32mr3122999wra.32.1494823401503; Sun, 14 May 2017 21:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.147.230 with HTTP; Sun, 14 May 2017 21:43:20 -0700 (PDT) In-Reply-To: <1494809561399.43186@cs.auckland.ac.nz> References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> <1494809561399.43186@cs.auckland.ac.nz> From: Blake Ramsdell Date: Sun, 14 May 2017 21:43:20 -0700 Message-ID: To: Peter Gutmann Cc: Russ Housley , Josh Soref , Kathleen Moriarty , Paul Hoffman , Eric Rescorla , IETF SMIME Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 04:48:10 -0000 On Sun, May 14, 2017 at 5:53 PM, Peter Gutmann wrote: > Or we could do something completely radical and ask Blake what he meant there. I did a search through my email, and this may go back farther than my records. From my standpoint I probably would have named it id-aa-smimeEncryptionKeyPreference. I think that I had support from one or more ASN.1 specialists to create the final name, and the name wasn't really that critical for me, and it may have required truncation due to ASN.1 compiler limitations or some other technical thing. I see this discussion going all the way back to 1999 in an ASN.1 module that Jim Schaad created. As has been pointed out, this is used internally in technical tools for the construction, parsing, and debug dumping out, so it has no real user-facing impact. Channeling 1990's Blake, I think I didn't have a strong opinion about what the human-readable name was for the attribute, the interoperability was based on the object identifier and semantics defined for it, and as long as the same OID ended up in the right place, and if everyone uses the same one when they talk about it, the world has order for me. I have seen multiple people chime in with a position that this is not a technically important fix, and I agree with that position. From nobody Mon May 15 02:23:22 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E311128C84 for ; Mon, 15 May 2017 02:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 w0Xw_pX97Zms for ; Mon, 15 May 2017 02:23:17 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1F91294A1 for ; Mon, 15 May 2017 02:19:15 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id b204so123303395oii.1 for ; Mon, 15 May 2017 02:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8NjqML/AMOs3FHn/eewxUTFwFtqrlgpeJ/24tSsIywQ=; b=aC3F2Ij97EqVM+iZkJSHMGPQLcUNiTJ6gtu/mQsleU3ZpUB6DXcsE+8U6b7pPQGe4h LNf91UyXP1WPXVAuPb+f5oiOpXYaNJpnb8hxsd3otoJmCXBWJnSAsjaoF0s3B3gxbCCY rhhMYBZjv4T/m3i7WSJ4Eiz+pQJAR0TuRX29iyGZh+oQaA4HGDV2MR0gEM7tQ6kTh9dU 0hINpISKpgkYEk1Yc1hlgvXwzLp2AXnErca4BvQZ2LX5sQQUYRSllwpi6AumalYysXOl LYXFTujf7pYuSSu30Sky6uxXNeNBiNdOLeXyrx9wTqmi2D3x3rdexjooSJb8XqkansPs Fy7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8NjqML/AMOs3FHn/eewxUTFwFtqrlgpeJ/24tSsIywQ=; b=Mw+1OSvn5L/pKDcxEqQ7hSlPTAleZeZdeA1/nEQUejbOGpfaXmwRh3WgY5drfKqzaL gYJYs/N/EubiPmHTD9G1Vqi3XIZESpLHHgdB1qFR/P5mgSk1xUjHRajSMdnLcmJZXlyZ 3kk3DarwEO9pJNYI8cPY6Aj/p2JCHf1K2n+DXAeVh6/0RRmtH8XCm9lqEzr3zSSfPqc3 u6glj1ChYzrL5EElkebmbQMP/VL2wFpb30RoKGv3Cw9sO/A5wwGt76YkDUavDQgccthp FLaAFOV7sDBScRJxSDmbDSYh1E76bUSagdI9N0l63275nPuit535X8g5K5jhAs+cE/KU gu2A== X-Gm-Message-State: AODbwcAnnsD6/bt+aINMRkH7wjGfAKaNQ8XdE9GV4Dv9wD1xDm4ZyG+u mqCyuaNpPHx6lM9HMpTEu+Yn49FysA== X-Received: by 10.202.181.194 with SMTP id e185mr1982633oif.221.1494839954668; Mon, 15 May 2017 02:19:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.14 with HTTP; Mon, 15 May 2017 02:19:13 -0700 (PDT) Received: by 10.157.4.14 with HTTP; Mon, 15 May 2017 02:19:13 -0700 (PDT) In-Reply-To: <001901d2cd01$572946f0$057bd4d0$@augustcellars.com> References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> <000a01d2ccf0$1dc9fdc0$595df940$@augustcellars.com> <001901d2cd01$572946f0$057bd4d0$@augustcellars.com> From: Josh Soref Date: Mon, 15 May 2017 05:19:13 -0400 Message-ID: To: Jim Schaad Cc: Paul Hoffman , IETF SMIME , Kathleen Moriarty , Russ Housley , Blake Ramsdell , Peter Gutmann , Eric Rescorla Content-Type: multipart/alternative; boundary="001a113ce0007e8040054f8c8cb2" Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 09:23:20 -0000 --001a113ce0007e8040054f8c8cb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/rfc5751 says: id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11} SMIMEEncryptionKeyPreference ::=3D CHOICE { issuerAndSerialNumber [0] IssuerAndSerialNumber, receipentKeyId [1] RecipientKeyIdentifier, subjectAltKeyIdentifier [2] SubjectKeyIdentifier } -- receipentKeyId is spelt incorrectly, but kept for historical -- reasons. I'm trying to ask for a similar note. Responding with reject and not suggesting a way forward is insulting. Instead of responding "reject". Someone could have checked the related documents and suggested that this would have been the correct way to address my concern. No one did that. No one really suggested that a fix would need to be applied to multiple RFCs or whatever the correct approach would be. As Peter notes, and I'm paraphrasing, just because a section isn't examined doesn't mean it's correct. I'd argue that given that this general section indeed has other typos, it's likely that it's in fact a dark corner with less review. Picking between editorial and technical is fairly hard. I generally send both kinds of feedback and this is clearly near the edge. It isn't a comma or similar. Changing the spelling would as noted by someone here potentially break clients that consume human readable formats. The reason I sent this feedback in the first place is that I was searching for spelling errors in a derived product and identified this one. No one rejected it as "not a spelling error", they didn't try to defend it as "a proper abbreviation". The only concern that was raised was that it would be an API change and impact interoperability. At which point I realized that it was probably from the RFC and came here to raise the issue. The errata tool forces over to choose between technical and editorial. Given that had I made the downstream change it would have technically broken clients if the tool I was using, technical felt like the right choice. A call-out is needed to tell implementers "this is misspelled in the source and if you use the correct spelling, you will break something". Whether that be done using shorthand "[sic]" or longhand as in the later RFC quoted above is immaterial to me. As for who has seen this error, I think I run into it every 5 or so years when I run a similar tool against=E2=80=8Ba different system (historically = this would have been Mozilla mail or NSS). If you need to consult with the RFC editor for the correct way forward, then you should do that. Just as Peter took the effort to consult the original author. When I attended W3C meetings, an IETF representative would occasionally come and try to encourage people to participate in IETF. This is not how one encourages participation. On May 14, 2017 6:38 PM, "Jim Schaad" wrote: I did not intend to be offensive, and I apologize if you have found it so. I thought that I offered two reasons why the current suggested errata was incorrect. If they were both fixed, then I do not know what my position on this suggestion would be. I am unclear if the use of sic as presented in the errata is correct or not. I would need to ask the RFC editor on that point, but if this was editorial and held for update then that is not of any immediate importance. My general understanding is that =E2=80=9Csic=E2=80=9D is used= , not in original source material, but in quotes to say that I did a faithful transcription of what was in the original document and the spelling (or other) errors are theirs and not mine. That would be a question for others and not for me. This could be a correct usage that I am unaware of. Going back and looking at RC 2616, it is clear that this is a technical issue in that document. The string =E2=80=9CReferer=E2=80=9D appears as bi= ts transported on the wire and needs to be spelt as it is in the document rather than having the spelling corrected. If the correct spelling is used, there would be an interoperability issue. This makes the usage of =E2=80=9Csic= =E2=80=9D correct in this location and it would have been a technical errata if it was raised= . The use of the errata mechanism is an appropriate method for raising these types of issues, however it must be recognized that we do not all have the same level of significance when it comes to technical vs editorial. Some people are more strict in terms of how significant an errata issue affects the document and consider anything which, even if it might lead to difference of opinion on implementation, to be editorial. I think however, that this suggestion was clearly editorial in nature as it would not cause confusion in how things are to be implemented or change bits on the wire if one were to change the string in the ASN.1 file. Jim *From:* Josh Soref [mailto:jsoref@gmail.com] *Sent:* Sunday, May 14, 2017 1:43 PM *To:* Jim Schaad *Cc:* Paul Hoffman ; IETF SMIME ; Eric Rescorla ; Russ Housley ; Kathleen Moriarty *Subject:* RE: [smime] [Technical Errata Reported] RFC2633 (5019) Ok. Let's say that I'm new to IETF process. The feedback provided so far is offensive. Please suggest the proper way to annotate that there is an error in a number of the documents hosted by IETF. Clearly someone successfully ridiculed IETF once such that future standards appropriately included "[sic]" wherever "referer" is used. It shouldn't be hard to suggest to a submitter the correct way to do that today, decades later. On May 14, 2017 4:35 PM, "Jim Schaad" wrote: The name chosen has absolutely no change of what is one the wire. That means that this is at best editorial and is definitely not technical. This is only going to affect those people who decide to use autogenerated constant names from the ASN.1 file. The suggested change would make for an invalid ASN.1 file so it not correct. Changing this name at this point would be a hassle for any one doing auto generation and highlighting that this is not, in some sense, a word does not affect the standard in any way. This should be rejected. Jim *From:* smime [mailto:smime-bounces@ietf.org] *On Behalf Of *Russ Housley *Sent:* Sunday, May 14, 2017 10:55 AM *To:* Josh Soref *Cc:* Kathleen Moriarty ; Paul Hoffman < paul.hoffman@vpnc.org>; Eric Rescorla ; IETF SMIME < smime@ietf.org> *Subject:* Re: [smime] [Technical Errata Reported] RFC2633 (5019) It is the name that the author chose to use in the ASN.1. If it was a typo, then it would have been changed in the subsequent update to the RFC. Russ On May 14, 2017, at 1:44 PM, Josh Soref wrote: It isn't an abbreviation, other tokens are clearly longer such as signingCertificate and smimeEncryptCerts. It's likely that the errata applies to multiple RFCs. On May 14, 2017 1:15 PM, "Russ Housley" wrote: I believe that this errata should be rejected. The author used an abbreviation, and the same spelling is used in RFC 3851. Russ > On May 14, 2017, at 12:35 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC2633, > "S/MIME Version 3 Message Specification". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5019 > > -------------------------------------- > Type: Technical > Reported by: Josh Soref > > Section: 5 > > Original Text > ------------- > id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11} > > > Corrected Text > -------------- > id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {id-aa 11} > > Notes > ----- > encryp isn't a word, it's a typo. Unfortunately, like http's (rfc1945) referer [sic] before it, this is now part of the API. > > This error should be highlighted (as rfc2068 does for referer [sic]) so that people are aware that the natural spelling doesn't apply. > > If it's possible for a revised RFC to be published suggesting the correct spelling w/ a way for clients/servers to handle the old spelling, that would be nice, but based on precedent, that seems unlikely. > > Instructions: > ------------- > This erratum 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 > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2633 (draft-ietf-smime-msg-08) > -------------------------------------- > Title : S/MIME Version 3 Message Specification > Publication Date : June 1999 > Author(s) : B. Ramsdell, Ed. > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime --001a113ce0007e8040054f8c8cb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0 =C2=A0id-aa-encrypKeyPref OBJECT IDENTIFIER ::= =3D {id-aa 11}
=C2= =A0 =C2=A0SMIMEEncryptionKeyPreference ::=3D CHOICE {
=C2=A0 =C2=A0 =C2=A0 issuerAndSerial= Number =C2=A0 [0] IssuerAndSerialNumber,
=C2=A0 =C2=A0 =C2=A0 receipentKeyId =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[1] RecipientKeyIdentifier,
=C2=A0 =C2=A0 =C2=A0 subjectAltKeyIdentifier [2= ] SubjectKeyIdentifier
=C2=A0 =C2=A0}
=
=C2=A0 =C2=A0-= - receipentKeyId is spelt incorrectly, but kept for historical
=C2=A0 =C2=A0-- reasons.
<= div dir=3D"auto" style=3D"font-family:sans-serif">
I'm trying to ask for a similar not= e.
Responding with = reject and not suggesting a way forward is insulting.

Instead of responding "reject". Someone = could have checked the related documents and suggested that this would have= been the correct way to address my concern.
No one did that.
No one really suggested that a fix would need t= o be applied to multiple RFCs or whatever the correct approach would be.

As Peter notes, and I'm paraphr= asing, just because a section isn't examined doesn't mean it's = correct. I'd argue that given that this general section indeed has othe= r typos, it's likely that it's in fact a dark corner with less revi= ew.

Picking between editorial and= technical is fairly hard. I generally send both kinds of feedback and this= is clearly near the edge. It isn't a comma or similar. Changing the sp= elling would as noted by someone here potentially break clients that consum= e human readable formats.

The rea= son I sent this feedback in the first place is that I was searching for spe= lling errors in a derived product and identified this one. No one rejected = it as "not a spelling error", they didn't try to defend it as= "a proper abbreviation". The only concern that was raised was th= at it would be an API change and impact interoperability. At which point I = realized that it was probably from the RFC and came here to raise the issue= .

The errata tool forces over to = choose between technical and editorial. Given that had I made the downstrea= m change it would have technically broken clients if the tool I was using, = technical felt like the right choice.

A call-out is needed to tell implementers "this is misspelled in = the source and if you use the correct spelling, you will break something&qu= ot;. Whether that be done using shorthand "[sic]" or longhand as = in the later RFC quoted above is immaterial to me.

As for who has seen this error, I think I run into it eve= ry 5 or so years when I run a similar tool against=E2=80=8Ba different syst= em (historically this would have been Mozilla mail or NSS).

If you need to consult with the RFC editor for= the correct way forward, then you should do that. Just as Peter took the e= ffort to consult the original author.

When I attended W3C meetings, an IETF representative would occasionall= y come and try to encourage people to participate in IETF. This is not how = one encourages participation.
=
On May 14, 2017 6:38 PM, "Jim Schaad&qu= ot; <ietf@au= gustcellars.com> wrote:
=

I did not intend to be offensive, and I apologize if= you have found it so.

=C2= =A0

I thought that I offered two reasons w= hy the current suggested errata was incorrect.=C2=A0 If they were both fixe= d, then I do not know what my position on this suggestion would be.<= u>

=C2=A0

I am unclear if the use of sic as presented in the errata is correct o= r not.=C2=A0 I would need to ask the RFC editor on that point, but if this = was editorial and held for update then that is not of any immediate importa= nce.=C2=A0 My general understanding is that =E2=80=9Csic=E2=80=9D is used, = not in original source material, but in quotes to say that I did a faithful= transcription of what was in the original document and the spelling (or ot= her) errors are theirs and not mine.=C2=A0 That would be a question for oth= ers and not for me.=C2=A0 This could be a correct usage that I am unaware o= f.

=C2=A0

Going back and looking at RC 2616, it is clear that this is = a technical issue in that document.=C2=A0 The string =E2=80=9CReferer=E2=80= =9D appears as bits transported on the wire and needs to be spelt as it is = in the document rather than having the spelling corrected.=C2=A0 If the cor= rect spelling is used, there would be an interoperability issue.=C2=A0 This= makes the usage of =E2=80=9Csic=E2=80=9D correct in this location and it w= ould have been a technical errata if it was raised.

=C2=A0

The use of = the errata mechanism is an appropriate method for raising these types of is= sues, however it must be recognized that we do not all have the same level = of significance when it comes to technical vs editorial.=C2=A0 Some people = are more strict in terms of how significant an errata issue affects the doc= ument and consider anything which, even if it might lead to difference of o= pinion on implementation, to be editorial.=C2=A0 I think however, that this= suggestion was clearly editorial in nature as it would not cause confusion= in how things are to be implemented or change bits on the wire if one were= to change the string in the ASN.1 file.

=C2=A0

Jim

<= p class=3D"MsoNormal">=C2=A0

=C2=A0

From: Josh Soref [mailto:jsoref@gmail.com] <= br>Sent: Sunday, May 14, 2017 1:43 PM
To: Jim Schaad <<= a href=3D"mailto:ietf@augustcellars.com" target=3D"_blank">ietf@augustcella= rs.com>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>; IETF SMIME <= ;smime@ietf.org>= ; Eric Rescorla <ekr@r= tfm.com>; Russ Housley <housley@vigilsec.com>; Kathleen Moriarty <Kathleen.Mo= riarty.ietf@gmail.com>
Subject: RE: [smime] [Technica= l Errata Reported] RFC2633 (5019)

=C2=A0

Ok. Let's say that I'm new to IETF process= . The feedback provided so far is offensive.

=C2=A0

Pl= ease suggest the proper way to annotate that there is an error in a number = of the documents hosted by IETF.

=C2=A0

Clearly = someone successfully ridiculed IETF once such that future standards appropr= iately included "[sic]" wherever "referer" is used. It = shouldn't be hard to suggest to a submitter the correct way to do that = today, decades later.

=C2=A0

On May 14, 2017 4:3= 5 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:

The name chosen has absolutely no change of what is one the wire. = =C2=A0=C2=A0That means that this is at best editorial and is definitely not= technical.

=C2=A0

This is only going to affect those people who decid= e to use autogenerated constant names from the ASN.1 file.=C2=A0 The sugges= ted change would make for an invalid ASN.1 file so it not correct.=C2=A0 Ch= anging this name at this point would be a hassle for any one doing auto gen= eration and highlighting that this is not, in some sense, a word does not a= ffect the standard in any way.

=C2= =A0

This should be rejected.=

=C2=A0

Jim

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

From: smime [mailto:smime-bounces@ietf.org] On Behalf Of Ru= ss Housley
Sent: Sunday, May 14, 2017 10:55 AM
To: Josh= Soref <jsoref@gma= il.com>
Cc: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.= com>; Paul Hoffman <paul.hoffman@vpnc.org>; Eric Rescorla <ekr@rtfm.com>; IETF SMIME= <smime@ietf.org= >
Subject: Re: [smime] [Technical Errata Reported] RFC2633 (50= 19)

=C2=A0

It is the name that the author chose to use in = the ASN.1.=C2=A0 If it was a typo, then it would have been changed in the s= ubsequent update to the RFC.

= =C2=A0

Russ

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

On May 14, 2= 017, at 1:44 PM, Josh Soref <jsoref@gmail.com> wrote:

=C2=A0

It = isn't an abbreviation, other tokens are clearly longer such as signingC= ertificate and smimeEncryptCerts. It's likely that the errata applies t= o multiple RFCs.

=C2=A0<= u>

On May 14, 2017 1:15 PM, "= ;Russ Housley" <housley@vigilsec.com> wrote:

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">I believe that this er= rata should be rejected.=C2=A0 The author used an abbreviation, and the sam= e spelling is used in RFC 3851.

Russ


> On May 14, 2017= , at 12:35 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>> The following errata report has been submitted for RFC2633,
> = "S/MIME Version 3 Message Specification".
>
> -------= -------------------------------
> You may review the report belo= w and at:
> http://www.rfc-editor.org/errata/eid5019
>
= > --------------------------------------
> Type: Technical> Reported by: Josh Soref <jsoref@gmail.com>
>
> Section: 5
>> Original Text
> -------------
> id-aa-encrypKeyPref OBJEC= T IDENTIFIER ::=3D {id-aa 11}
>
>
> Corrected Text
>= ; --------------
> id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D = {id-aa 11}
>
> Notes
> -----
> encryp isn't a w= ord, it's a typo. Unfortunately, like http's (rfc1945) referer [sic= ] before it, this is now part of the API.
>
> This error should= be highlighted (as rfc2068 does for referer [sic]) so that people are awar= e that the natural spelling doesn't apply.
>
> If it's = possible for a revised RFC to be published suggesting the correct spelling = w/ a way for clients/servers to handle the old spelling, that would be nice= , but based on precedent, that seems unlikely.
>
> Instructions= :
> -------------
> This erratum is currently posted as "R= eported". If necessary, please
> use "Reply All" to di= scuss whether it should be verified or
> rejected. When a decision is= reached, the verifying party
> can log in to change the status and e= dit the report, if necessary.
>
> -----------------------------= ---------
> RFC2633 (draft-ietf-smime-msg-08)
> ----------= ----------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: S/MIME Version 3 Message Specification
>= Publication Date=C2=A0 =C2=A0 : June 1999
> Author(s)=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: B. Ramsdell, Ed.
> Category=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
> Source=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S/MIME Mail Security
> Area= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
> = Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verif= ying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> ______________________= _________________________
> smime mailing list
> smime@ietf.org
> http= s://www.ietf.org/mailman/listinfo/smime

=C2=A0

<= /blockquote>
--001a113ce0007e8040054f8c8cb2-- From nobody Wed May 17 07:28:24 2017 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5E112EBE4 for ; Wed, 17 May 2017 07:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 3Y9iOd7dGt1L for ; Wed, 17 May 2017 07:28:19 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCA5129ADF for ; Wed, 17 May 2017 07:21:27 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id c15so82058967ith.0 for ; Wed, 17 May 2017 07:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pSLWVkfE9etROeVI/rEQTSpz5BK+cGSyQeXLVXVL7xo=; b=hOd4PHchehSNVdwv5D8KgOGTP/UVc1DfLJhTgD2VgP2P8GxYBKFzzbFYssq6zjAa30 0ATD7fXOS8Obttgwt01c0KWY5zTFX3SAOvFBsy/SOxaY6+zlcvCWkG4WCzo/yQuXtqxs SEnNpp7deGvyUHwo+/2HHB4OoCP6VWZZ9eQsU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pSLWVkfE9etROeVI/rEQTSpz5BK+cGSyQeXLVXVL7xo=; b=ZhwENIPM5cxqMG1K0NG3vsBNCwAYo1Ij1LzNi+1FrGpshgt5pl/igSG+Fzo4zhP/JV zaFIS1AVtfBtE4ZZ+DnE83h3NjEf2tFLx2QoRhHdGEjVMTKbEbgewDa/qEG8nDNLRk0H zqoaCSXd05zZSJtI8FgYtf+ztRWgwuBttNkeIsxNLehcsXpm4eMhNeRU+yotub1uVQvD OK1SLFMH3kmi1mFjL0EQuqBM6AcFPcAcdwph9/10aSOaWYTt1CVawaaplJKmOV6S+ENL pgxwwI9vblhBxXDOnANU0Vvuw8lMgTajFdDL/uoJjGFMC1Xcif5cMTNJbxIE3WJ7KghP 0ngQ== X-Gm-Message-State: AODbwcDwUq+xirHiBnInVcaV/LQXRM6aguaBS46L8yj5J26oyrSq61Bq ND3XFigqHQUj+ldA X-Received: by 10.36.139.69 with SMTP id g66mr4478002ite.114.1495030886450; Wed, 17 May 2017 07:21:26 -0700 (PDT) Received: from [5.5.33.119] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id g18sm969200iod.19.2017.05.17.07.21.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 07:21:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Wed, 17 May 2017 10:21:19 -0400 Cc: Eric Rescorla , IETF SMIME , Paul Hoffman , Kathleen Moriarty , Jim Schaad Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170514163550.3ECC2B80A6E@rfc-editor.org> <13A0972A-2D00-4DF8-BFA9-C022D914BCEF@vigilsec.com> <000a01d2ccf0$1dc9fdc0$595df940$@augustcellars.com> <001901d2cd01$572946f0$057bd4d0$@augustcellars.com> To: Josh Soref X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 14:28:23 -0000 > On May 15, 2017, at 05:19, Josh Soref wrote: >=20 > https://tools.ietf.org/html/rfc5751 says: > id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11} > SMIMEEncryptionKeyPreference ::=3D CHOICE { > issuerAndSerialNumber [0] IssuerAndSerialNumber, > receipentKeyId [1] RecipientKeyIdentifier, > subjectAltKeyIdentifier [2] SubjectKeyIdentifier > } >=20 > -- receipentKeyId is spelt incorrectly, but kept for historical > -- reasons. >=20 > I'm trying to ask for a similar note. > Responding with reject and not suggesting a way forward is insulting. I look at it this way: 0) There are three options for an errata: - Approve - Reject - Hold For Document Update (HFDU) The mailing list participants are copied on these errata to get their = opinion in order to inform the AD how to dispose of the errata. Most = folks are just making their opinions known. 1) The next thing that folks look at is whether it=E2=80=99s technical = or not. Debate ensues, but generally technical errata are those that = affect interoperability. This one I don=E2=80=99t think does because = there are no changes to the bits on the wire. 2) And, well folks want to get lots of changes, but the change has to = run through the consensus process (back to mailing list input). So to the import bit: As I see it, there are two ways to get the note incorporated: 1. Write a draft that adds the note; this seems a bit heavy weight for = what you are trying to do. 2. Apply the note to the latest RFC/draft that obsoletes RFC 2633; I = guess you went for upstream, but generally the IETF applies changes to = the latest/greatest RFC/draft. That obsoletes chain is: RFC 3851 = obsoleted RFC 2633, RFC 3851 was obsoleted by RFC 5751, and = draft-ietf-lamps-rfc5751-bis is about to obsolete RFC 5751. Luckily, = draft-ietf-lamps-rfc5751-bis isn=E2=80=99t yet an RFC so there=E2=80=99s = an option to have the note added there. Any objections to adding a note in draft-ietf-lamps-rfc5751-bis along = the same lines as the note for receipentKeyId? spt > On May 14, 2017 6:38 PM, "Jim Schaad" wrote: > I did not intend to be offensive, and I apologize if you have found it = so. >=20 > =20 >=20 > I thought that I offered two reasons why the current suggested errata = was incorrect. If they were both fixed, then I do not know what my = position on this suggestion would be. >=20 > =20 >=20 > I am unclear if the use of sic as presented in the errata is correct = or not. I would need to ask the RFC editor on that point, but if this = was editorial and held for update then that is not of any immediate = importance. My general understanding is that =E2=80=9Csic=E2=80=9D is = used, not in original source material, but in quotes to say that I did a = faithful transcription of what was in the original document and the = spelling (or other) errors are theirs and not mine. That would be a = question for others and not for me. This could be a correct usage that = I am unaware of. >=20 > =20 >=20 > Going back and looking at RC 2616, it is clear that this is a = technical issue in that document. The string =E2=80=9CReferer=E2=80=9D = appears as bits transported on the wire and needs to be spelt as it is = in the document rather than having the spelling corrected. If the = correct spelling is used, there would be an interoperability issue. = This makes the usage of =E2=80=9Csic=E2=80=9D correct in this location = and it would have been a technical errata if it was raised. >=20 > =20 >=20 > The use of the errata mechanism is an appropriate method for raising = these types of issues, however it must be recognized that we do not all = have the same level of significance when it comes to technical vs = editorial. Some people are more strict in terms of how significant an = errata issue affects the document and consider anything which, even if = it might lead to difference of opinion on implementation, to be = editorial. I think however, that this suggestion was clearly editorial = in nature as it would not cause confusion in how things are to be = implemented or change bits on the wire if one were to change the string = in the ASN.1 file. >=20 > =20 >=20 > Jim >=20 > =20 >=20 > =20 >=20 > From: Josh Soref [mailto:jsoref@gmail.com]=20 > Sent: Sunday, May 14, 2017 1:43 PM > To: Jim Schaad > Cc: Paul Hoffman ; IETF SMIME ; = Eric Rescorla ; Russ Housley ; = Kathleen Moriarty > Subject: RE: [smime] [Technical Errata Reported] RFC2633 (5019) >=20 > =20 >=20 > Ok. Let's say that I'm new to IETF process. The feedback provided so = far is offensive. >=20 > =20 >=20 > Please suggest the proper way to annotate that there is an error in a = number of the documents hosted by IETF. >=20 > =20 >=20 > Clearly someone successfully ridiculed IETF once such that future = standards appropriately included "[sic]" wherever "referer" is used. It = shouldn't be hard to suggest to a submitter the correct way to do that = today, decades later. >=20 > =20 >=20 > On May 14, 2017 4:35 PM, "Jim Schaad" wrote: >=20 > The name chosen has absolutely no change of what is one the wire. = That means that this is at best editorial and is definitely not = technical. >=20 > =20 >=20 > This is only going to affect those people who decide to use = autogenerated constant names from the ASN.1 file. The suggested change = would make for an invalid ASN.1 file so it not correct. Changing this = name at this point would be a hassle for any one doing auto generation = and highlighting that this is not, in some sense, a word does not affect = the standard in any way. >=20 > =20 >=20 > This should be rejected. >=20 > =20 >=20 > Jim >=20 > =20 >=20 > =20 >=20 > From: smime [mailto:smime-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Sunday, May 14, 2017 10:55 AM > To: Josh Soref > Cc: Kathleen Moriarty ; Paul Hoffman = ; Eric Rescorla ; IETF SMIME = > Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019) >=20 > =20 >=20 > It is the name that the author chose to use in the ASN.1. If it was a = typo, then it would have been changed in the subsequent update to the = RFC. >=20 > =20 >=20 > Russ >=20 > =20 >=20 > =20 >=20 > On May 14, 2017, at 1:44 PM, Josh Soref wrote: >=20 > =20 >=20 > It isn't an abbreviation, other tokens are clearly longer such as = signingCertificate and smimeEncryptCerts. It's likely that the errata = applies to multiple RFCs. >=20 > =20 >=20 > On May 14, 2017 1:15 PM, "Russ Housley" wrote: >=20 > I believe that this errata should be rejected. The author used an = abbreviation, and the same spelling is used in RFC 3851. >=20 > Russ >=20 >=20 > > On May 14, 2017, at 12:35 PM, RFC Errata System = wrote: > > > > The following errata report has been submitted for RFC2633, > > "S/MIME Version 3 Message Specification". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5019 > > > > -------------------------------------- > > Type: Technical > > Reported by: Josh Soref > > > > Section: 5 > > > > Original Text > > ------------- > > id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11} > > > > > > Corrected Text > > -------------- > > id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {id-aa 11} > > > > Notes > > ----- > > encryp isn't a word, it's a typo. Unfortunately, like http's = (rfc1945) referer [sic] before it, this is now part of the API. > > > > This error should be highlighted (as rfc2068 does for referer [sic]) = so that people are aware that the natural spelling doesn't apply. > > > > If it's possible for a revised RFC to be published suggesting the = correct spelling w/ a way for clients/servers to handle the old = spelling, that would be nice, but based on precedent, that seems = unlikely. > > > > Instructions: > > ------------- > > This erratum 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 > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC2633 (draft-ietf-smime-msg-08) > > -------------------------------------- > > Title : S/MIME Version 3 Message Specification > > Publication Date : June 1999 > > Author(s) : B. Ramsdell, Ed. > > Category : PROPOSED STANDARD > > Source : S/MIME Mail Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > smime mailing list > > smime@ietf.org > > https://www.ietf.org/mailman/listinfo/smime >=20 > =20 >=20 >=20 > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime