Denis,
Thanks for your comments.
spt
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Denis
Pinkas
Sent: Monday, September 08, 2008 10:19 AM
To: ietf-smime
Cc: owner-ietf-smime; Sean Turner
Subject: Re: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt
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.
I think we can just strike "identity". Note that I also deleted "identity"
from section 3.
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.
Okay.
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.
The 1024 text in draft-ietf-smime-3851bis addresses the 1024 size for
DSA/DH. I'll add something for 2048 RSA. Something along the lines of (I
won't try to change what's in RFC3766 to be todays equipment):
The choice of 2048 bits as the RSA asymmetric key size in this specification
is based on the desire to provide 100 bits of security. The choice of 1024
bits as the DSA, and DH asymmetric key size in this specification is based
on the desire to provide 80 bits of security.
Furthermore, this is inconsistent: if the key size is 900
bits, should we apply a MUST or a MAY ?
Don't understand this one. If the key is 900-bits then it MUST be
supported.
draft-ietf-smime-3851bis-05.txt contains the following requirements :
...snip
draft-ietf-smime-3851bis places a boundary at 2048 bits.
This is far sufficient today, since RSA 1024 is far from being broken.
The WG consensus was 2048 for RSA as the upper limit.
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.
draft-ietf-smime-3850bis only addresses validation of certificates and since
4096 is already in root cert stores it seems appropriate to support this.
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
We argued about this for a long time. What's in the document was the WG
consensus.
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.
Okay.
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.
Others caught this too. I deleted one.
Denis
... snip