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

I do not see any updates needed to the SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2) registry.

Russ

> On Feb 5, 2024, at 10:06 PM, David Dong via RT <iana-matrix-comment@iana.org> wrote:
> 
> 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
> 