[smime] [IANA #1303700] Re: [Errata Verified] RFC2633 (5019)

Hi Paul,

Following up for this errata; do we need to update the description for decimal 11, id-aa-encrypKeyPref, in SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)?

Thank you.

Best regards,

David Dong
IANA Services Sr. Specialist

On Fri Jan 12 20:22:28 2024, housley@vigilsec.com wrote:
> I think it would be better to put an ASC.1 comment after the line.
> Otherwise, [sic] looks like an undefined ASN.1 tag.
> 
> Russ
> 
> > On Jan 12, 2024, at 3:08 PM, RFC Errata System <rfc-editor@rfc-
> > editor.org> wrote:
> >
> > The following errata report has been verified for RFC2633,
> >  "S/MIME Version 3 Message Specification".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5019
> >
> > --------------------------------------
> > Status: Verified
> > Type: Editorial
> >
> > Reported by: Josh Soref <jsoref@gmail.com>
> > Date Reported: 2017-05-14
> > Verified by: Paul Wouters (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.
> >
> > ---
> > Kathleen Moriarty: 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?
> >
> > Paul Wouters (AD): This note made it into RFC 8551, so marking this
> > errata Verified to close it
> >
> > --------------------------------------
> > 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