|
Re: [smime] [Technical Errata Reported] RFC2633 (5019)
2017-05-17 09:28:27
On May 15, 2017, at 05:19, Josh Soref <jsoref(_at_)gmail(_dot_)com> wrote:
https://tools.ietf.org/html/rfc5751 says:
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
-- receipentKeyId is spelt incorrectly, but kept for historical
-- reasons.
I'm trying to ask for a similar note.
Responding with reject and not suggesting a way forward is insulting.
I look at it this way:
0) There are three options for an errata:
- Approve
- Reject
- Hold For Document Update (HFDU)
The 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?
spt
On May 14, 2017 6:38 PM, "Jim Schaad" <ietf(_at_)augustcellars(_dot_)com>
wrote:
I did not intend to be offensive, and I apologize if you have found it so.
I thought that I offered two reasons why the current suggested errata was
incorrect. If they were both fixed, then I do not know what my position on
this suggestion would be.
I am unclear if the use of sic as presented in the errata is correct or not.
I would need to ask the RFC editor on that point, but if this was editorial
and held for update then that is not of any immediate importance. My general
understanding is that “sic” is used, not in original source material, but in
quotes to say that I did a faithful transcription of what was in the original
document and the spelling (or other) errors are theirs and not mine. That
would be a question for others and not for me. This could be a correct usage
that I am unaware of.
Going back and looking at RC 2616, it is clear that this is a technical issue
in that document. The string “Referer” appears as bits transported on the
wire and needs to be spelt as it is in the document rather than having the
spelling corrected. If the correct spelling is used, there would be an
interoperability issue. This makes the usage of “sic” correct in this
location and it would have been a technical errata if it was raised.
The use of the errata mechanism is an appropriate method for raising these
types of issues, however it must be recognized that we do not all have the
same level of significance when it comes to technical vs editorial. Some
people are more strict in terms of how significant an errata issue affects
the document and consider anything which, even if it might lead to difference
of opinion on implementation, to be editorial. I think however, that this
suggestion was clearly editorial in nature as it would not cause confusion in
how things are to be implemented or change bits on the wire if one were to
change the string in the ASN.1 file.
Jim
From: Josh Soref [mailto:jsoref(_at_)gmail(_dot_)com]
Sent: Sunday, May 14, 2017 1:43 PM
To: Jim Schaad <ietf(_at_)augustcellars(_dot_)com>
Cc: Paul Hoffman <paul(_dot_)hoffman(_at_)vpnc(_dot_)org>; IETF SMIME
<smime(_at_)ietf(_dot_)org>; Eric Rescorla <ekr(_at_)rtfm(_dot_)com>; Russ
Housley <housley(_at_)vigilsec(_dot_)com>; Kathleen Moriarty
<Kathleen(_dot_)Moriarty(_dot_)ietf(_at_)gmail(_dot_)com>
Subject: RE: [smime] [Technical Errata Reported] RFC2633 (5019)
Ok. Let's say that I'm new to IETF process. The feedback provided so far is
offensive.
Please suggest the proper way to annotate that there is an error in a number
of the documents hosted by IETF.
Clearly someone successfully ridiculed IETF once such that future standards
appropriately included "[sic]" wherever "referer" is used. It shouldn't be
hard to suggest to a submitter the correct way to do that today, decades
later.
On May 14, 2017 4:35 PM, "Jim Schaad" <ietf(_at_)augustcellars(_dot_)com>
wrote:
The name chosen has absolutely no change of what is one the wire. That
means that this is at best editorial and is definitely not technical.
This is only going to affect those people who decide to use autogenerated
constant names from the ASN.1 file. The suggested change would make for an
invalid ASN.1 file so it not correct. Changing this name at this point would
be a hassle for any one doing auto generation and highlighting that this is
not, in some sense, a word does not affect the standard in any way.
This should be rejected.
Jim
From: smime [mailto:smime-bounces(_at_)ietf(_dot_)org] On Behalf Of Russ
Housley
Sent: Sunday, May 14, 2017 10:55 AM
To: Josh Soref <jsoref(_at_)gmail(_dot_)com>
Cc: Kathleen Moriarty
<Kathleen(_dot_)Moriarty(_dot_)ietf(_at_)gmail(_dot_)com>; Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org>; Eric Rescorla
<ekr(_at_)rtfm(_dot_)com>; IETF SMIME <smime(_at_)ietf(_dot_)org>
Subject: Re: [smime] [Technical Errata Reported] RFC2633 (5019)
It is the name that the author chose to use in the ASN.1. If it was a typo,
then it would have been changed in the subsequent update to the RFC.
Russ
On May 14, 2017, at 1:44 PM, Josh Soref <jsoref(_at_)gmail(_dot_)com> wrote:
It isn't an abbreviation, other tokens are clearly longer such as
signingCertificate and smimeEncryptCerts. It's likely that the errata applies
to multiple RFCs.
On May 14, 2017 1:15 PM, "Russ Housley" <housley(_at_)vigilsec(_dot_)com>
wrote:
I believe that this errata should be rejected. The author used an
abbreviation, and the same spelling is used in RFC 3851.
Russ
On May 14, 2017, at 12:35 PM, RFC Errata System
<rfc-editor(_at_)rfc-editor(_dot_)org> wrote:
The following errata report has been submitted for RFC2633,
"S/MIME Version 3 Message Specification".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5019
--------------------------------------
Type: Technical
Reported by: Josh Soref <jsoref(_at_)gmail(_dot_)com>
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.
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.
--------------------------------------
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
|
|