Re: [Technical Errata Reported] RFC2634 (6562)

Roman and Ben:

This was discussed on the mail list, and people agree that the proposed text adds clarity.  I think that the MUST in the first sentence was implied, but others think otherwise.  I recommend approving this one.

Russ


> On Apr 28, 2021, at 2:07 PM, RFC Errata System <[email protected]> wrote:
> 
> The following errata report has been submitted for RFC2634,
> "Enhanced Security Services for S/MIME".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6562
> 
> --------------------------------------
> Type: Technical
> Reported by: David von Oheimb <[email protected]>
> 
> Section: 5.4
> 
> Original Text
> -------------
>   The first certificate identified in the sequence of certificate
>   identifiers MUST be the certificate used to verify the signature. The
>   encoding of the ESSCertID for this certificate SHOULD include the
>   issuerSerial field. If other constraints ensure that
>   issuerAndSerialNumber will be present in the SignerInfo, the
>   issuerSerial field MAY be omitted. The certificate identified is used
>   during the signature verification process. If the hash of the
>   certificate does not match the certificate used to verify the
>   signature, the signature MUST be considered invalid.
> 
>   If more than one certificate is present in the sequence of
>   ESSCertIDs, the certificates after the first one limit the set of
>   authorization certificates that are used during signature validation.
> 
> 
> Corrected Text
> --------------
>   The sequence of certificate identifiers MUST contain at least one element.
>   The first certificate identified MUST be the certificate used to verify the signature.
>   The encoding of the ESSCertID for this certificate SHOULD include the
>   issuerSerial field. If other constraints ensure that
>   issuerAndSerialNumber will be present in the SignerInfo, the
>   issuerSerial field MAY be omitted. The certificate identified is used
>   during the signature verification process. If the hash of the
>   certificate does not match the certificate used to verify the
>   signature, the signature MUST be considered invalid.
> 
>   If more than one certificate identifier is present in the sequence of ESSCertIDs,
>   all certificates referenced there MUST be part of the signature validation chain.
> 
> 
> Notes
> -----
> Some aspects of the 'certs' field of a SigningCertificate attribute:
> 
>   SigningCertificate ::=  SEQUENCE {
>       certs        SEQUENCE OF ESSCertID,
>       policies     SEQUENCE OF PolicyInformation OPTIONAL
>   }
> 
> described in the sentences quoted above are very vague.
> This lead to major confusion and wrong implementations.
> As meanwhile has been clarified, they should be re-phrased;
> see suggested new version above.
> 
> (One may further mandate/clarify that the certificate identifiers must be given in the same order
> as they are expected in the validation chain, but I think this is not important because
> the order should not play a critical role and will be determined by the validation chain anyway.)
> 
> 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. 
> 
> --------------------------------------
> RFC2634 (draft-ietf-smime-ess-12)
> --------------------------------------
> Title               : Enhanced Security Services for S/MIME
> Publication Date    : June 1999
> Author(s)           : P. Hoffman, Ed.
> Category            : PROPOSED STANDARD
> Source              : S/MIME Mail Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> smime mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/smime