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
<mailto: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
<mailto: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
<http://www.rfc-editor.org/errata/eid5019>
--------------------------------------
Type: Technical
Reported by: Josh Soref <jsoref(_at_)gmail(_dot_)com
<mailto: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 <mailto:smime(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/smime
<https://www.ietf.org/mailman/listinfo/smime>
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime