Re: [smime] [Technical Errata Reported] RFC5753 (4777)

[Jim Schaad <[e-mail]>]

I will be honest.  I would be happier with an update of this document rather
than just having the errata.

I would be happy to look at this in a couple of days and see if I can make
the text clearer than it currently is.  I find the text that does the same
thing in RFC5480 to be hard to decipher but the easiest thing might still
just be to point to that document for how to do this.

Jim


> -----Original Message-----
> From: Paul Hoffman [mailto:[e-mail]]
> Sent: Saturday, August 13, 2016 2:47 PM
> To: RFC Errata System <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Technical Errata Reported] RFC5753 (4777)
> 
> Please do not accept this errata until further discussion.
> 
> Discussion:
> 
> 1) I believe that the errata would be *much* clearer if the errata was
only for
> the changed sentences, not the whole paragraph. Thus, I think the
"Original
> Text" should start with "The originatorKey publicKey field MUST". If
others
> agree, the submitter could turn in a new errata.
> 
> 2) The submitter says "This error is also present in sections 3.1.2,
3.1.3, 3.2.1,
> 3.2.2, 7.2". That feels like it *might* be sufficient for the reader to
understand,
> but it would be clearer if the errata included the change for each of
those
> sections. If others agree, the submitter could turn in a new errata.
> 
> --Paul Hoffman
> 
> On 13 Aug 2016, at 14:34, RFC Errata System wrote:
> 
> > The following errata report has been submitted for RFC5753, "Use of
> > Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message
> > Syntax (CMS)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=5753&eid=4777
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Jim Schaad <[e-mail]>
> >
> > Section: 3.1.1
> >
> > Original Text
> > -------------
> > -  originator MUST be the alternative originatorKey.  The
> >       originatorKey algorithm field MUST contain the id-ecPublicKey
> >       object identifier (see Section 7.1.2).  The parameters
> > associated
> >       with id-ecPublicKey MUST be absent, ECParameters, or NULL.  The
> >       parameters associated with id-ecPublicKey SHOULD be absent or
> >       ECParameters, and NULL is allowed to support legacy
> >       implementations.  The previous version of this document required
> >       NULL to be present.  If the parameters are ECParameters, then
> > they
> >       MUST be namedCurve.  The originatorKey publicKey field MUST
> >       contain the DER encoding of the value of the ASN.1 type ECPoint
> >       (see Section 7.2), which represents the sending agent's
> > ephemeral
> >       EC public key.  The ECPoint in uncompressed form MUST be
> >       supported.
> >
> > Corrected Text
> > --------------
> > -  originator MUST be the alternative originatorKey.  The
> >       originatorKey algorithm field MUST contain the id-ecPublicKey
> >       object identifier (see Section 7.1.2).  The parameters
> > associated
> >       with id-ecPublicKey MUST be absent, ECParameters, or NULL.  The
> >       parameters associated with id-ecPublicKey SHOULD be absent or
> >       ECParameters, and NULL is allowed to support legacy
> >       implementations.  The previous version of this document required
> >       NULL to be present.  If the parameters are ECParameters, then
> > they
> >       MUST be namedCurve.  The originatorKey publicKey field MUST
> >       contain the encoded public key as defined in [X9.62].  The
> > hybred
> >       form MUST NOT be used.  The ECPoint in uncompressed form MUST be
> >       supported.  This mirrors the same format used in public key
> >       certificates as defined in Section 2.2 of [RFC5480].
> >
> > Notes
> > -----
> > There is a problem in that for ECPoints, the public key is defined to
> > be encoded differently in this document than it is in a public key
> > certificate.  The difference is the presence of the ASN.1 OCTET STRING
> > wrapper.
> >
> > OpenSSL and BouncyCastle both use the unwrapped version per Dr.
> > Stephen Henson note to me in mail.
> >
> > This error is also present in sections 3.1.2, 3.1.3, 3.2.1, 3.2.2, 7.2
> >
> > 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 (IESG) can log in to
> > change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC5753 (draft-ietf-smime-3278bis-09)
> > --------------------------------------
> > Title               : Use of Elliptic Curve Cryptography (ECC)
> > Algorithms in Cryptographic Message Syntax (CMS)
> > Publication Date    : January 2010
> > Author(s)           : S. Turner, D. Brown
> > Category            : INFORMATIONAL
> > Source              : S/MIME Mail Security
> > Area                : Security
> > Stream              : IETF
> > Verifying Party     : IESG