Subject: [smime] [Errata Held for Document Update] RFC2633 (5019)

From: RFC Errata System <[email-masked]>
Date: Mon, 19 Mar 2018 03:52:28 -0700 (PDT)

The following errata report has been held for document update 
for RFC2633, "S/MIME Version 3 Message Specification". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5019

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Josh Soref <[email-masked]>
Date Reported: 2017-05-14
Held by: Kathleen Moriarty (IESG)

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.

---
As AD, this discussion needs to be continued and possibly with a different draft.  As such, I am marking this as hold for document update and listing it as editorial so that there are no n the wire changes at this time with this errata.
----
There was quite a bit of on list discussion that should be reviewed for any future changes.

One summary from the discussion:
he 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?

--------------------------------------
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: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Mar 2018 09:19:07 -0400

I agree it would be useful to highlight. But this is an ASN.1 code fragment
and I am not sure it will parse with the comment there.

On Mon, Mar 19, 2018 at 6:52 AM, RFC Errata System <
[email-masked]> wrote:

> 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.
>
> ---
> As AD, this discussion needs to be continued and possibly with a different
> draft.  As such, I am marking this as hold for document update and listing
> it as editorial so that there are no n the wire changes at this time with
> this errata.
> ----
> he 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:
>
> 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?
>
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 20 Mar 2018 10:14:03 +0000

> On Mar 19, 2018, at 10:52, RFC Errata System <[email-masked]> wrote:
> 

It’s slightly different than renaming receipentKeyId because this is an OID so you could also do this:

id-aa-encryptKeyPref OBJECT IDENTIFIER ::= id-aa-encrypKeyPref 

But I also don’t have an issue with just adding the note.

spt

---

From: Jim Schaad <[email-masked]>
Date: Wed, 21 Mar 2018 07:29:19 +0000

It would be

id-aa-encrypKeyPref -- sic -- OBJECT IDENTIFIER ::= ...

Jim

> -----Original Message-----
> From: smime <[email-masked]> On Behalf Of Sean Turner
> Sent: Tuesday, March 20, 2018 10:14 AM
> To: Kathleen Moriarty <[email-masked]>
> Cc: Josh Soref <[email-masked]>; The IESG <[email-masked]>; IETF SMIME
> <[email-masked]>
> Subject: Re: [smime] [Errata Held for Document Update] RFC2633 (5019)
> 
> 
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Mar 2018 04:36:25 -0400

Thank you.  I have sent a follow up message to the secretariat to
correct the text in the errata marked as HFDU.

Best regards,
Kathleen

-- 

Best regards,
Kathleen