Re: [smime] [Technical Errata Reported] RFC2633 (5019)
Josh Soref <jsoref@gmail.com> Mon, 15 May 2017 09:23 UTC
Return-Path: <jsoref@gmail.com>
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 <smime@ietfa.amsl.com>; 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 <smime@ietfa.amsl.com>; 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 <smime@ietf.org>; Mon, 15 May 2017 02:19:15 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id b204so123303395oii.1 for <smime@ietf.org>; 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> <CACZqfqCek=p0y00mAWGs5Sw6xbNJWDJOFk_N8kWa+uwk2JWa4Q@mail.gmail.com> <B4CB5D68-ABFA-4055-986B-75AA747CE66E@vigilsec.com> <000a01d2ccf0$1dc9fdc0$595df940$@augustcellars.com> <CACZqfqC+Px3Hb3ZepMfY2Ci4iCOi85ydEaJ8jsZwziZBTsz6Vw@mail.gmail.com> <001901d2cd01$572946f0$057bd4d0$@augustcellars.com>
From: Josh Soref <jsoref@gmail.com>
Date: Mon, 15 May 2017 05:19:13 -0400
Message-ID: <CACZqfqDrpYBN4m3bKop9YCOMbkTHUyajBUYyuwxsTcFi+-49MA@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, IETF SMIME <smime@ietf.org>, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, Russ Housley <housley@vigilsec.com>, Blake Ramsdell <blaker@gmail.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a113ce0007e8040054f8c8cb2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/mG2gkd3U627vMVbPODe2s-JqGwA>
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 <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smime/>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2017 09:23:20 -0000
https://tools.ietf.org/html/rfc5751 says: id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} SMIMEEncryptionKeyPreference ::= 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 againsta 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" <ietf@augustcellars.com> 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 “sic” 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 “Referer” 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 “sic” 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 <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. 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> 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 ::= {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
- [smime] [Technical Errata Reported] RFC2633 (5019) RFC Errata System
- Re: [smime] [Technical Errata Reported] RFC2633 (… Russ Housley
- Re: [smime] [Technical Errata Reported] RFC2633 (… Josh Soref
- Re: [smime] [Technical Errata Reported] RFC2633 (… Russ Housley
- Re: [smime] [Technical Errata Reported] RFC2633 (… Jim Schaad
- Re: [smime] [Technical Errata Reported] RFC2633 (… Josh Soref
- Re: [smime] [Technical Errata Reported] RFC2633 (… Eric Rescorla
- Re: [smime] [Technical Errata Reported] RFC2633 (… Jim Schaad
- Re: [smime] [Technical Errata Reported] RFC2633 (… Peter Gutmann
- Re: [smime] [Technical Errata Reported] RFC2633 (… Blake Ramsdell
- Re: [smime] [Technical Errata Reported] RFC2633 (… Josh Soref
- Re: [smime] [Technical Errata Reported] RFC2633 (… Sean Turner