[pkix] Re: [Technical Errata Reported] RFC5272 (8137 )
Sean Turner <[email protected]> Wed, 8 Jan 2025 12:31:25 -0500
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <[email protected]> |
--===============4495016862168001695== Content-Type: multipart/alternative; boundary="Apple-Mail=_0C1BBDB4-A025-44AC-BEB1-EF270B3F2711" --Apple-Mail=_0C1BBDB4-A025-44AC-BEB1-EF270B3F2711 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Deb, Since we are in the process of obsoleting RFC 5272 [1], I think we = should mark this HFDU even though RFC 6402 fixed this. spt [1] https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5272bis/ > On Oct 29, 2024, at 1:51=E2=80=AFPM, Michael StJohns = <[email protected]> wrote: >=20 > And this is what I get for going backwards in my emails. I think = 6402 fixed it properly - ignore my email.=20 >=20 > We *really* need a "Rejected - fixed in later RFC" or "Rejected OBE" = status. >=20 > Mike >=20 > On 10/29/2024 11:43 AM, Deb Cooley wrote: >> obsoleted by RFC 6402? >>=20 >> On Tue, Oct 29, 2024 at 11:41=E2=80=AFAM Deb Cooley = <[email protected] <mailto:[email protected]>> wrote: >>> opinions? >>>=20 >>> Deb >>>=20 >>> On Sat, Oct 12, 2024 at 6:36=E2=80=AFAM RFC Errata System = <[email protected] <mailto:[email protected]>> wrote: >>>> The following errata report has been submitted for RFC5272, >>>> "Certificate Management over CMS (CMC)". >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> https://www.rfc-editor.org/errata/eid8137 >>>>=20 >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: David von Oheimb <[email protected] = <mailto:[email protected]>> >>>>=20 >>>> Section: C.1 >>>>=20 >>>> Original Text >>>> ------------- >>>> NoSignatureValue contains the hash of the certification request.=20 >>>>=20 >>>> Corrected Text >>>> -------------- >>>> NoSignatureValue contains the SHA-1 hash value of the certification = request.=20 >>>> The hash value given by NoSignatureValue SHOULD be ignored. >>>>=20 >>>> Notes >>>> ----- >>>> The hash value was not sufficiently defined because the choice of = the hash algorithm was not specified. >>>> At that time presumably the use of SHA-1 was implied. >>>>=20 >>>> I suggest requiring SHA-1 here simply for backward compatibility. >>>> >=46rom today's perspective more flexibility may be demanded and = SHA-1 likely no more is the best choice. >>>>=20 >>>> Anyway I see no real value in NoSignatureValue (pun intended), so = it should not matter. >>>> For this reason I propose ignoring the hash value. >>>>=20 >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". (If it is spam, it=20= >>>> will be removed shortly by the RFC Production Center.) Please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party =20 >>>> will log in to change the status and edit the report, if necessary. >>>>=20 >>>> -------------------------------------- >>>> RFC5272 (draft-ietf-pkix-2797-bis-07) >>>> -------------------------------------- >>>> Title : Certificate Management over CMS (CMC) >>>> Publication Date : June 2008 >>>> Author(s) : J. Schaad, M. Myers >>>> Category : PROPOSED STANDARD >>>> Source : Public-Key Infrastructure (X.509) >>>> Stream : IETF >>>> Verifying Party : IESG >>=20 >>=20 >> _______________________________________________ >> pkix mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] = <mailto:[email protected]> >=20 > _______________________________________________ > pkix mailing list -- [email protected] > To unsubscribe send an email to [email protected] --Apple-Mail=_0C1BBDB4-A025-44AC-BEB1-EF270B3F2711 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: = after-white-space;">Deb,<div><br></div><div>Since we are in the process = of obsoleting RFC 5272 [1], I think we should mark this HFDU even though = RFC 6402 fixed = this.</div><div><br></div><div>spt</div><div><br></div><div>[1] <a = href=3D"https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5272bis/">htt= ps://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5272bis/</a><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Oct 29, 2024, at 1:51=E2=80=AFPM, Michael StJohns = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div> =20 <meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3DUTF-8"> =20 <div> <div class=3D"moz-cite-prefix">And this is what I get for going backwards in my emails. I think 6402 fixed it properly = - ignore my email. <br> </div> <div class=3D"moz-cite-prefix"><br> </div> <div class=3D"moz-cite-prefix">We *really* need a "Rejected - fixed = in later RFC" or "Rejected OBE" status.</div> <div class=3D"moz-cite-prefix"><br> </div> <div class=3D"moz-cite-prefix">Mike<br> </div> <div class=3D"moz-cite-prefix"><br> </div> <div class=3D"moz-cite-prefix">On 10/29/2024 11:43 AM, Deb Cooley wrote:<br> </div> <blockquote type=3D"cite" = cite=3D"mid:[email protected]= .com"> <meta http-equiv=3D"content-type" content=3D"text/html; = charset=3DUTF-8"> <div dir=3D"ltr">obsoleted by RFC 6402?<br> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 29, 2024 at 11:41=E2=80=AFAM Deb Cooley <<a = href=3D"mailto:[email protected]" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr"> <div>opinions?</div> <div><br> </div> <div>Deb<br> </div> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Sat, Oct 12, 2024 = at 6:36=E2=80=AFAM RFC Errata System <<a = href=3D"mailto:[email protected]" target=3D"_blank" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The following errata report has been submitted for = RFC5272,<br> "Certificate Management over CMS (CMC)".<br> <br> --------------------------------------<br> You may review the report below and at:<br> <a href=3D"https://www.rfc-editor.org/errata/eid8137" = rel=3D"noreferrer" target=3D"_blank" moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/errata/eid8137<= /a><br> <br> --------------------------------------<br> Type: Technical<br> Reported by: David von Oheimb <<a = href=3D"mailto:[email protected]" target=3D"_blank" = moz-do-not-send=3D"true" = class=3D"moz-txt-link-freetext">[email protected]</a>><br> <br> Section: C.1<br> <br> Original Text<br> -------------<br> NoSignatureValue contains the hash of the certification request. <br> <br> Corrected Text<br> --------------<br> NoSignatureValue contains the SHA-1 hash value of the certification request. <br> The hash value given by NoSignatureValue SHOULD be ignored.<br> <br> Notes<br> -----<br> The hash value was not sufficiently defined because the choice of the hash algorithm was not specified.<br> At that time presumably the use of SHA-1 was implied.<br> <br> I suggest requiring SHA-1 here simply for backward compatibility.<br> >=46rom today's perspective more flexibility may be demanded and SHA-1 likely no more is the best choice.<br> <br> Anyway I see no real value in NoSignatureValue (pun intended), so it should not matter.<br> For this reason I propose ignoring the hash value.<br> <br> Instructions:<br> -------------<br> This erratum is currently posted as "Reported". (If it is spam, it <br> will be removed shortly by the RFC Production Center.) Please<br> use "Reply All" to discuss whether it should be verified or<br> rejected. When a decision is reached, the verifying = party <br> will log in to change the status and edit the report, if necessary.<br> <br> --------------------------------------<br> RFC5272 (draft-ietf-pkix-2797-bis-07)<br> --------------------------------------<br> Title = : Certificate Management over CMS (CMC)<br> Publication Date : June 2008<br> Author(s) : J. = Schaad, M. Myers<br> Category : = PROPOSED STANDARD<br> Source : = Public-Key Infrastructure (X.509)<br> Stream : = IETF<br> Verifying Party : IESG<br> </blockquote> </div> </blockquote> </div> <br> <fieldset class=3D"moz-mime-attachment-header"></fieldset> <pre class=3D"moz-quote-pre" = wrap=3D"">_______________________________________________ pkix mailing list -- <a class=3D"moz-txt-link-abbreviated" = href=3D"mailto:[email protected]">[email protected]</a> To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" = href=3D"mailto:[email protected]">[email protected]</a> </pre> </blockquote><p><br> </p> </div> _______________________________________________<br>pkix mailing list -- = [email protected]<br>To unsubscribe send an email to = [email protected]<br></div></blockquote></div><br></div></body></html>= --Apple-Mail=_0C1BBDB4-A025-44AC-BEB1-EF270B3F2711-- --===============4495016862168001695== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBraXgtbGVhdmVAaWV0Zi5vcmcK --===============4495016862168001695==--