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
<rfc-editor(_at_)rfc-editor(_dot_)org> 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
<David(_dot_)von(_dot_)Oheimb(_at_)siemens(_dot_)com>
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
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