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 <[email protected]>
>
> 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

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime