Hi David,
It looks like this text is from RFC 5035
(https://www.rfc-editor.org/rfc/rfc5035.txt) not RFC 2643.
We have deleted EID 6563 assuming this is the case. Please resubmit using the
correct RFC number. (Unfortunately, that is one thing I can’t change from my
end.)
Please let us know if we can be of further assistance.
Thank you.
RFC Editor/mf
On Apr 28, 2021, at 2:10 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/eid6563
--------------------------------------
Type: Technical
Reported by: David von Oheimb
<David(_dot_)von(_dot_)Oheimb(_at_)siemens(_dot_)com>
Section: 3
Original Text
-------------
certs
contains the list of certificates that are to be used in
validating the message. The first certificate identified in the
sequence of certificate identifiers MUST be the certificate used
to verify the signature. The encoding of the ESSCertIDv2 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, subsequent certificates
limit the set of certificates that are used during validation.
Corrected Text
--------------
certs
contains the list of certificates that are to be used in
validating the message. It MUST contain at least one element.
The first certificate identified in the
sequence of certificate identifiers MUST be the certificate used
to verify the signature. The encoding of the ESSCertIDv2 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
ESSCertIDv2s,
all certificates referenced there MUST be part of the signature
validation chain.
Notes
-----
Some aspects of the 'certs' field of a SigningCertificateV2 attribute:
SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
described in the sentences quoted above are rather 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