Minor additional comment (not a show stopper) related to Sean's number 6
comment:
| From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Sean P.
Turner
| Sent: March 2, 2004 11:45 AM
| To: Blake Ramsdell
| Cc: ietf-smime(_at_)imc(_dot_)org
| Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
|
| <<cut>>
|
| 6. Para 5: I'd like to add a security consideration about why it
| might not be good to send CRLs: "CRLs sent with the message
| impose concern when the signer's certificate is revoked, but
| the signer purposely includes a valid CRL but not the most
| recent CRL without the signer's serialNumber thereby
| providing a false verification". (or something like that)
| ....
IF this is added, it may also make sense to emphasize that the transmission of
root certificates may also be a problem (Para 2.3 paragraph 4 uses "SHOULD NOT"
in the context of accepting root certificates - this may not raise the issue
strongly enough). A caution in the Security section something like:
"The ability of a receiver to adopt a self-signed certificate received within a
messages should be
strongly controlled to prevent the inadvertent adoption of root certificates.
The ability of a sender
to transmit self-signed certificates should be controlled to ensure that they
cannot
unexpectedly send root certificates which may potentially alter the trust
settings of receiving entities. Some implementers may choose to permit the
disabling of the ability to send and process-upon-receipt self-signed
certificates."
Some enterprise environments may want to disable the ability of their desktops
to accept or send root certificates in messages.
Tony