Re: [smime] [Technical Errata Reported] RFC2633 (5019)

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
<mailto: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
<mailto: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
<mailto: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 <mailto: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 <mailto:smime@ietf.org> 
> https://www.ietf.org/mailman/listinfo/smime