Jim, and the working group
1 - This topic has been debated on the PKIX mailing list and a
proposal has been made. The proposed ASN.1 structure is different
from the one described in draft-ietf-smime-escertid-00.txt.
The current ASN.1 in RFC 2634 is:
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
The proposal from draft-ietf-smime-escertid-00.txt is:
ESSCertIDEx ::= SEQUENCE {
certHash Hash,
hashAlg AlgorithmIdentifier DEFAULT {id-sha256},
issuerSerial IssuerSerial OPTIONAL
}
The proposal made on the PKIX mailing list is:
ESSCertIDv2 ::= SEQUENCE {
certHash OCTET STRING,
issuerSerial IssuerSerial,
hashAlgorithm AlgorithmIdentifier DEFAULT { sha-1 }
The advantage of the last proposal is backward compatibility with the existing
structure. The disadvantage is that it is less "natural" than invented from
scratch, but some explanations can easily overcome this drawback.
I would propose to adopt the proposal made on the PKIX mailing list.
In addition, I would take advantage of the rewriting of this section to correct
some past "errors" in section 5.4.1.
2 - Proposed rewritting:
"5.4.1. Certificate Identification
The best way to identify certificates is an often-discussed issue.
When an issuer/serial number pair is included in the SignedData
object, that information is not part of the message digest
calculation process may thus be changed without being detected.
That information may only be used as an hint and by itself, does
not allow to make sure that the right certificate is being accessed.
A hash of the entire certificate allows a verifier to verify that
the certificate that was chosen by the signer is being used when the
signature is verified. It permits a detection of certificate
substitution attacks.
Duplication of the issuer/serial number pair within the Signing
Certificate attribute is not fully necessary, but has the
advantage to get the whole information from that attribute.
Attribute certificates and additional public key certificates
containing authorization information do not have an issuer/serial
number pair represented anywhere in a SignerInfo object. When an
attribute certificate or an additional public key certificate is not
included in the SignedData object, it becomes much more difficult to
get the correct set of certificates based only on a hash of the
certificate. For this reason, these certificates SHOULD be identified
by the IssuerSerial object."
3 - It is a matter of taste, but I would rather prefer:
SigningCertificatev2 instead of SigningCertificateEx
4 - It would be nice to correct the typos from RFC 2634, e.g. "requred".
There are other typos like: "certficates", "subsiquent", "Indentification",
...
Please use a spell checker.
Denis
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the
IETF.
Title : ESS Update: Adding CertID Algorithm Agility
Author(s) : J. Schaad
Filename : draft-ietf-smime-escertid-00.txt
Pages : 18
Date : 2006-3-24
In the original Enhanged Security Services for S/MIME draft, a
structure for cryptographically linking the certificate to be used in
validation with the signature was introduced, this structure was
hardwired to use SHA-1. This document allows for the structure to
have algorithm agility and defines new attributes to deal with the
updating.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-00.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request(_at_)ietf(_dot_)org with the word unsubscribe in the body
of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-smime-escertid-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv(_at_)ietf(_dot_)org(_dot_)
In the body type:
"FILE /internet-drafts/draft-ietf-smime-escertid-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2006-3-24165058(_dot_)I-D(_at_)ietf(_dot_)org>
ENCODING mime
FILE /internet-drafts/draft-ietf-smime-escertid-00.txt