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

From: RFC Errata System <[email-masked]>
Date: Sun, 14 May 2017 09:35:50 -0700 (PDT)

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 <[email-masked]>

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: Russ Housley <[email-masked]>
Date: Sun, 14 May 2017 13:14:59 -0400

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 <[email-masked]> wrote:
> 
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime

---

From: Josh Soref <[email-masked]>
Date: Sun, 14 May 2017 13:44:36 -0400

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" <[email-masked]> wrote:

> I believe that this errata should be rejected.  The author used an
> abbreviation, and the same spelling is used in RFC 3851.
>
> Russ
>
>
> > 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:
> > -------------

---

From: Russ Housley <[email-masked]>
Date: Sun, 14 May 2017 13:54:30 -0400

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 <[email-masked]> 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" <[email-masked] <mailto:[email-masked]>> wrote:
> > On May 14, 2017, at 12:35 PM, RFC Errata System <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > http://www.rfc-editor.org/errata/eid5019 <http://www.rfc-editor.org/errata/eid5019>
> >
> > Reported by: Josh Soref <[email-masked] <mailto:[email-masked]>>
> >
> > Section: 5
> >
> > Original Text
> > -------------
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/smime <https://www.ietf.org/mailman/listinfo/smime>
>

---

From: Jim Schaad <[email-masked]>
Date: Sun, 14 May 2017 13:24:37 -0700

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:[email-masked]] On Behalf Of Russ Housley
Sent: Sunday, May 14, 2017 10:55 AM
To: Josh Soref <[email-masked]>
Cc: Kathleen Moriarty <[email-masked]>; Paul Hoffman
<[email-masked]>; Eric Rescorla <[email-masked]>; IETF SMIME
<[email-masked]>
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 <[email-masked]
<mailto:[email-masked]> > wrote:

On May 14, 2017 1:15 PM, "Russ Housley" <[email-masked]
<mailto:[email-masked]> > wrote:

Russ

> On May 14, 2017, at 12:35 PM, RFC Errata System <[email-masked]
<mailto:[email-masked]> > wrote:
> Reported by: Josh Soref <[email-masked] <mailto:[email-masked]> >
>
> Section: 5
>
> Original Text
> -------------
>
> 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.

---

From: Josh Soref <[email-masked]>
Date: Sun, 14 May 2017 16:42:38 -0400

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" <[email-masked]> wrote:

> *From:* smime [mailto:[email-masked]] *On Behalf Of *Russ Housley
> *Sent:* Sunday, May 14, 2017 10:55 AM
> *To:* Josh Soref <[email-masked]>
> *Cc:* Kathleen Moriarty <[email-masked]>; Paul Hoffman <
> [email-masked]>; Eric Rescorla <[email-masked]>; IETF SMIME <
> [email-masked]>
> *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
>
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 14 May 2017 14:21:47 -0700

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 <[email-masked]> wrote:

> Ok. Let's say that I'm new to IETF process. The feedback provided so far
> is offensive.
>
> 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.
>
>> *Cc:* Kathleen Moriarty <[email-masked]>; Paul Hoffman
>> <[email-masked]>; Eric Rescorla <[email-masked]>; IETF SMIME <
>> [email-masked]>

---

From: Jim Schaad <[email-masked]>
Date: Sun, 14 May 2017 15:27:55 -0700

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:[email-masked]] 
Sent: Sunday, May 14, 2017 1:43 PM
To: Jim Schaad <[email-masked]>
Cc: Paul Hoffman <[email-masked]>; IETF SMIME <[email-masked]>; Eric Rescorla <[email-masked]>; Russ Housley <[email-masked]>; Kathleen Moriarty <[email-masked]>
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" <[email-masked] <mailto:[email-masked]> > 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:[email-masked] <mailto:[email-masked]> ] On Behalf Of Russ Housley
Sent: Sunday, May 14, 2017 10:55 AM
To: Josh Soref <[email-masked] <mailto:[email-masked]> >
Cc: Kathleen Moriarty <[email-masked] <mailto:[email-masked]> >; Paul Hoffman <[email-masked] <mailto:[email-masked]> >; Eric Rescorla <[email-masked] <mailto:[email-masked]> >; IETF SMIME <[email-masked] <mailto:[email-masked]> >
Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019)

Russ

On May 14, 2017, at 1:44 PM, Josh Soref <[email-masked] <mailto:[email-masked]> > wrote:

On May 14, 2017 1:15 PM, "Russ Housley" <[email-masked] <mailto:[email-masked]> > wrote:

Russ

> On May 14, 2017, at 12:35 PM, RFC Errata System <[email-masked] <mailto:[email-masked]> > wrote:
>

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 15 May 2017 00:53:21 +0000

Russ Housley <[email-masked]> writes:

>If it was a typo, then it would have been changed in the subsequent update to
>the RFC.

"If cigarettes were bad for you then the government wouldn't allow them to be
 sold".

All this means is that it's a typo that wasn't noticed until now.  Given that
the full thing is called "SMIMEEncryptionKeyPreference" it does seem like it's
a typo.  The fact that it's rarely used compared to, say, sMIMECapabilities,
means that it could easily have been overlooked until now.	

Or we could do something completely radical and ask Blake what he meant there.

In fact, why don't I do that right now...

Peter.

---

From: Blake Ramsdell <[email-masked]>
Date: Sun, 14 May 2017 21:43:20 -0700

> 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: Josh Soref <[email-masked]>
Date: Mon, 15 May 2017 05:19:13 -0400

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 against​a 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" <[email-masked]> wrote:

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:[email-masked]]
*Sent:* Sunday, May 14, 2017 1:43 PM
*To:* Jim Schaad <[email-masked]>
*Cc:* Paul Hoffman <[email-masked]>; IETF SMIME <[email-masked]>;
Eric Rescorla <[email-masked]>; Russ Housley <[email-masked]>; Kathleen
Moriarty <[email-masked]>
*Subject:* RE: [smime] [Technical Errata Reported] RFC2633 (5019)

This should be rejected.

Jim

Russ

Russ

> 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.

---

From: Sean Turner <[email-masked]>
Date: Wed, 17 May 2017 10:21:19 -0400

> On May 15, 2017, at 05:19, Josh Soref <[email-masked]> wrote:
> 

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’s technical or not.  Debate ensues, but generally technical errata are those that affect interoperability.  This one I don’t 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’t yet an RFC so there’s 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
> Cc: Kathleen Moriarty <[email-masked]>; Paul Hoffman <[email-masked]>; Eric Rescorla <[email-masked]>; IETF SMIME <[email-masked]>