Re: [IANA #1303700] [Errata Verified] RFC2633 (5019)
Paul Wouters <[email protected]> Mon, 12 Feb 2024 17:07:49 -0500
| Newsgroups | gmane.ietf.smime |
|---|---|
| Message-ID | <CAGL5yWbUCC6RaY=y4aGK6_cjikLx+R4dEKHV46__Dqj5iZR5tQ@mail.gmail.com> |
--===============2129775862819576328== Content-Type: multipart/alternative; boundary="000000000000d6d3c90611368246" --000000000000d6d3c90611368246 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Russ, If there had been a Notes column, we could have added a note. I guess now developers will have to ponder the weirdness until they read the errata of the RFC that is linked to item 11 there. Paul On Tue, Feb 6, 2024 at 9:08=E2=80=AFAM Russ Housley <[email protected]> = wrote: > 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 < > [email protected]> 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, [email protected] 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 <[email protected]> > >>> Date Reported: 2017-05-14 > >>> Verified by: Paul Wouters (IESG) > >>> > >>> Section: 5 > >>> > >>> Original Text > >>> ------------- > >>> id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11} > >>> > >>> > >>> Corrected Text > >>> -------------- > >>> id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {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=E2=80=99s technica= l or > >>> not. Debate ensues, but generally technical errata are those that > >>> affect interoperability. This one I don=E2=80=99t 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=E2=80=99t yet an RFC so there=E2=80= =99s 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 > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/smime > > > > --000000000000d6d3c90611368246 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>I agree with Russ,</div><div><br></div><div>If there = had been a Notes column, we could have added a note. I guess now developers= will have to ponder the weirdness until they read the errata of the RFC th= at is linked to item 11 there.</div><div><br></div><div>Paul</div><div><br>= </div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_= attr">On Tue, Feb 6, 2024 at 9:08=E2=80=AFAM Russ Housley <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> wrote:<br></div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex">I do not see any updates nee= ded to the SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2) reg= istry.<br> <br> Russ<br> <br> > On Feb 5, 2024, at 10:06 PM, David Dong via RT <<a href=3D"mailto:i= [email protected]" target=3D"_blank">[email protected]= </a>> wrote:<br> > <br> > Hi Paul,<br> > <br> > 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)?<br> > <br> > Thank you.<br> > <br> > Best regards,<br> > <br> > David Dong<br> > IANA Services Sr. Specialist<br> > <br> > On Fri Jan 12 20:22:28 2024, <a href=3D"mailto:[email protected]" t= arget=3D"_blank">[email protected]</a> wrote:<br> >> I think it would be better to put an ASC.1 comment after the line.= <br> >> Otherwise, [sic] looks like an undefined ASN.1 tag.<br> >> <br> >> Russ<br> >> <br> >>> On Jan 12, 2024, at 3:08 PM, RFC Errata System <rfc-editor@= rfc-<br> >>> <a href=3D"http://editor.org" rel=3D"noreferrer" target=3D"_bl= ank">editor.org</a>> wrote:<br> >>> <br> >>> The following errata report has been verified for RFC2633,<br> >>> "S/MIME Version 3 Message Specification".<br> >>> <br> >>> --------------------------------------<br> >>> You may review the report below and at:<br> >>> <a href=3D"https://www.rfc-editor.org/errata/eid5019" rel=3D"n= oreferrer" target=3D"_blank">https://www.rfc-editor.org/errata/eid5019</a><= br> >>> <br> >>> --------------------------------------<br> >>> Status: Verified<br> >>> Type: Editorial<br> >>> <br> >>> Reported by: Josh Soref <<a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a>><br> >>> Date Reported: 2017-05-14<br> >>> Verified by: Paul Wouters (IESG)<br> >>> <br> >>> Section: 5<br> >>> <br> >>> Original Text<br> >>> -------------<br> >>> id-aa-encrypKeyPref OBJECT IDENTIFIER ::=3D {id-aa 11}<br> >>> <br> >>> <br> >>> Corrected Text<br> >>> --------------<br> >>> id-aa-encrypKeyPref [sic] OBJECT IDENTIFIER ::=3D {id-aa 11}<b= r> >>> <br> >>> Notes<br> >>> -----<br> >>> encryp isn't a word, it's a typo. Unfortunately, like = http's<br> >>> (rfc1945) referer [sic] before it, this is now part of the API= .<br> >>> <br> >>> This error should be highlighted (as rfc2068 does for referer = [sic])<br> >>> so that people are aware that the natural spelling doesn't= apply.<br> >>> <br> >>> If it's possible for a revised RFC to be published suggest= ing the<br> >>> correct spelling w/ a way for clients/servers to handle the ol= d<br> >>> spelling, that would be nice, but based on precedent, that see= ms<br> >>> unlikely.<br> >>> <br> >>> ---<br> >>> Kathleen Moriarty: As AD, this discussion needs to be continue= d and<br> >>> possibly with a different draft.=C2=A0 As such, I am marking t= his as hold<br> >>> for document update and listing it as editorial so that there = are no<br> >>> n the wire changes at this time with this errata.<br> >>> ----<br> >>> There was quite a bit of on list discussion that should be rev= iewed<br> >>> for any future changes.<br> >>> <br> >>> One summary from the discussion:<br> >>> he mailing list participants are copied on these errata to get= their<br> >>> opinion in order to inform the AD how to dispose of the errata= .=C2=A0 Most<br> >>> folks are just making their opinions known.<br> >>> <br> >>> 1) The next thing that folks look at is whether it=E2=80=99s t= echnical or<br> >>> not.=C2=A0 Debate ensues, but generally technical errata are t= hose that<br> >>> affect interoperability.=C2=A0 This one I don=E2=80=99t think = does because there<br> >>> are no changes to the bits on the wire.<br> >>> <br> >>> 2) And, well folks want to get lots of changes, but the change= has to<br> >>> run through the consensus process (back to mailing list input)= .<br> >>> <br> >>> So to the import bit:<br> >>> <br> >>> As I see it, there are two ways to get the note incorporated:<= br> >>> <br> >>> 1. Write a draft that adds the note; this seems a bit heavy we= ight<br> >>> for what you are trying to do.<br> >>> <br> >>> 2. Apply the note to the latest RFC/draft that obsoletes RFC 2= 633; I<br> >>> guess you went for upstream, but generally the IETF applies ch= anges<br> >>> to the latest/greatest RFC/draft.=C2=A0 That obsoletes chain i= s: RFC 3851<br> >>> obsoleted RFC 2633, RFC 3851 was obsoleted by RFC 5751, and dr= aft-<br> >>> ietf-lamps-rfc5751-bis is about to obsolete RFC 5751.=C2=A0 Lu= ckily,<br> >>> draft-ietf-lamps-rfc5751-bis isn=E2=80=99t yet an RFC so there= =E2=80=99s an option to<br> >>> have the note added there.<br> >>> <br> >>> Any objections to adding a note in draft-ietf-lamps-rfc5751-bi= s along<br> >>> the same lines as the note for receipentKeyId?<br> >>> <br> >>> Paul Wouters (AD): This note made it into RFC 8551, so marking= this<br> >>> errata Verified to close it<br> >>> <br> >>> --------------------------------------<br> >>> RFC2633 (draft-ietf-smime-msg-08)<br> >>> --------------------------------------<br> >>> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = S/MIME Version 3 Message Specification<br> >>> Publication Date=C2=A0 =C2=A0 : June 1999<br> >>> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: B. Ramsdel= l, Ed.<br> >>> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED S= TANDARD<br> >>> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S/MIM= E Mail Security<br> >>> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Security<br> >>> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF<= br> >>> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG<br> >>> <br> >>> _______________________________________________<br> >>> smime mailing list<br> >>> <a href=3D"mailto:[email protected]" target=3D"_blank">smime@ietf= .org</a><br> >>> <a href=3D"https://www.ietf.org/mailman/listinfo/smime" rel=3D= "noreferrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/smime<= /a><br> > <br> <br> </blockquote></div> --000000000000d6d3c90611368246-- --===============2129775862819576328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ smime mailing list [email protected] https://www.ietf.org/mailman/listinfo/smime --===============2129775862819576328==--