Russ,
Since you asked ..
Comment 1. Section 2.2. The text states :
Receiving agents MUST support v1 X.509 and v3 X.509 identity
certificates as profiled in [KEYM].
I took a look at RFC 5280 [KEYM] and searched for ?identity certificate?.
There is not such a term in this document.
Please provide the correct reference and section number.
Since the sentence includes a MUST, this is rather important.
Comment 2. Section 2.3. The text states :
Agents MAY send CA certificates, that is, certificates which can be
considered the "root" of other chains, and which MAY be self-signed.
This is incorrect. A CA certificate is not necessarily a self-signed
certificate. The text should be changed into :
Agents MAY send CA certificates, i.e. cross-certificates,
self-issued certificates, and self-signed certificates.
Comment 3. Section 4.3. The text states :
The following are the RSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification:
0 < key size < 512 : MAY (see Section 6 [SMIME-MSG])
512 <= key size <= 4096 : MUST (see Section 6 [SMIME-MSG])
4096 < key size : MAY (see Section 6 [SMIME-MSG])
The following are the RSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification:
512 <= key size <= 1024 : MAY (see Section 6 [SMIME-MSG])
Section 6 from [SMIME-MSG] does not explain why these key sizes have been
chosen.
So the reference to that section from that document is not appropriate and
should be deleted.
Furthermore, this is inconsistent: if the key size is 900 bits, should we apply
a MUST or a MAY ?
draft-ietf-smime-3851bis-05.txt contains the following requirements :
4.2. Signature Generation
The following are the requirements for an S/MIME agent generated RSA
signatures:
512 <= key size < 1024 : MAY (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent generated DSA
signatures:
512 <= key size <= 1024 : SHOULD (see Security Considerations)
4.3. Signature Verification
The following are the requirements for S/MIME receiving agents during
signature verification of RSA signatures:
512 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for S/MIME receiving agents during
signature verification of DSA signatures:
512 <= key size <= 1024 : SHOULD (see Security Considerations)
4.4. Encryption
The following are the requirements for an S/MIME agent when
establishing keys for content encryption using the RSA algorithms:
512 <= key size < 1024 : MAY (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent when
establishing keys for content encryption using the DH algorithms:
512 <= key size <= 1024 : SHOULD (see Security Considerations)
4.5. Decryption
The following are the requirements for an S/MIME agent when
establishing keys for content decryption using the RSA algorithms:
512 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent when
establishing keys for content decryption using the DH algorithms:
512 <= key size <= 1024 : SHOULD (see Security Considerations)
draft-ietf-smime-3851bis places a boundary at 2048 bits.
This is far sufficient today, since RSA 1024 is far from being broken.
4096 bits provides higher security, but this not needed today.
This key size should not be mandated to support. Supporting key size higher
than 4096 bits
can create denial of service, so implementations should not support them.
I would rather think that the text should be changed into:
The following are the RSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification:
0 < key size <= 512 : MAY
512 < key size <= 2048 : MUST
2048 < key size <= 4096 : SHOULD
4096 < key size : SHOULD NOT
Comment 4. Section 4.2. The text states:
Certificate, CRL, and path
validation MUST be performed as per [KEYM] when validating a
correspondent's public key. This is necessary before using a public
key to provide security services such as: verifying a signature;
encrypting a content-encryption key (ex: RSA); or forming a pairwise
symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a
content-encryption key.
The text is silent on the way to identify the right certificate to be used
as the input certificate for the path validation. I have focussed my efforts to
provide
some additional text when verifying a signature. Additional efforts should be
done
on decrypting a content-encryption key or forming a pairwise symmetric key.
Additional text proposal:
When verifying a signature, if a signingCertificate or a signingCertificateV2
attribute
is found in an S/MIME message, it SHALL be used to identify the signer?s
certificate.
Otherwise, the certificate is identified in an S/MIME message, either using the
issuerAndSerialNumber which identifies the signer's certificate by the issuer's
distinguished name and the certificate serial number, or the
subjectKeyIdentifier
which identifies the signer's certificate by a key identifier.
Comment 5. Section 6.
There is duplication of text. The two following paragraph say the same.
Please delete one of them:
In addition to the Security Considerations identified in [KEYM],
caution should be taken when processing certificates which have not
first been validated to a trust anchor. Certificates could be
manufactured by untrusted sources for the purpose of mounting denial
of service or other attacks. For example, keys selected to require
excessive cryptographic processing, or extensive lists of CDP and/or
AIA addresses in the certificate, could be used to mount denial of
service attacks. Similarly, originator-specified CDP and/or AIA
addresses could be inserted into bogus certificates to allow the
originator to detect receipt of the message even if signature
verification fails.
In addition to the Security Considerations identified in [KEYM],
caution should be taken when processing certificates which have not
first been validated to a trust anchor. Certificates could be
manufactured by untrusted sources for the purpose of mounting denial
of service or other attacks. For example, keys selected to require
excessive cryptographic processing, or extensive lists of CDP and/or
AIA addresses in the certificate, could be used to mount denial of
service attacks. Similarly, attacker-specified CRL distribution
point and/or authority information access addresses could be included
into fake certificates to allow the originator to detect receipt of
the message even if signature verification fails.
Denis
----- Message reçu -----
De : owner-ietf-smime
À : Turner,Sean P.,ietf-smime
Date : 2008-09-07, 21:44:29
Sujet : Re: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt
So far, I have not seen any comments on this WG last Call
thread. Note that the WG Last Call ends tomorrow.
Russ
At 08:32 PM 8/21/2008, Turner, Sean P. wrote:
This message initiates an SMIME Working Group Last Call on the document:
Title : Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 3.2 Certificate Handling
Author(s) : S. Turner, B. Ramsdell
Filename : draft-ietf-smime-3850bis-05.txt
Pages : 20
Date : 2008-8-21
This document specifies conventions for X.509 certificate usage by
Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME
provides a method to send and receive secure MIME messages, and certificates
are an integral part of S/MIME agent processing. S/MIME agents validate
certificates as described in RFC 5280, the Internet X.509 Public Key
Infrastructure Certificate and CRL Profile. S/MIME agents must meet the
certificate processing requirements in this document as well as those in RFC
5280. This document obsoletes RFC 3850.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-05.txt
The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Standards Track RFC.
Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may be
sent to the document editor.
The Last Call period will end on 8 September 2008.
Upon completion of the last call, the WG chairs will take action based upon
the consensus of the WG. As the authors are also the WG co-chairs, Russ
Housley has offered to make consensus calls and the WG chairs have agreed to
abide by Russ's consensus calls. Possible actions include:
1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as an Informational RFC
(which generally involves an IETF-wide Last Call); or
2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).
Remember that it is our responsibility as Working Group members to ensure
the quality of our documents and of the Internet Standards process. So,
please read and comment!
spt