Thanks for your review.
Believe it or not but your mail arrived 5 seconds after I hit the send
button to submit an updated draft based on Sean's review :)
So I will hold on the trigger and wait with any changes based on your
comments for inclusion in the next update provided that they are only
I comment below;
Microsoft Security Center of Excellence (SCOE)
From: Tony Capel [mailto:capel(_at_)comgate(_dot_)com]
Sent: den 11 november 2004 21:42
To: Stefan Santesson; ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-00.txt
A nice short document, hopefully the following will be helpful!:
1. Clause 1, Introduction:
It is understood that the prime driver for this draft is to provide a
to signal the receiver's available and default encryption algorithms,
might be appropriate to mention in the introduction that the mechanism
allow other receiver capabilities to be obtained. In the first
may wish to add a sentence indicating that capabilities in addition to
encryption algorithms may also be provided.
In the third paragraph, you may not wish to restrict the mechanism's
applicability to only encrypted first messages, since it is useful for
signed messages as well (e.g. initial signed message may be
Possibly change "encrypted message" to "S/MIME message" to make it
[Stefan] The intention behind this work has primary been to support
encryption in initial messages, but provided that there might be some
use in terms of selecting appropriate signing properties, I have no
problem generalizing the text to "S/MIME message" and using encryption
as a prime example.
If someone thinks this is wrong, then please note me.
2. Clause 3
In the second paragraph, it is declared out of scope to discuss what
considered as a more reliable source of this information. However, I
preferred a note at least introducing the options for establishing the
precedence of capability information from multiple sources. For
The Capabilities in the PKC are inherently signed by the certificate
is normally considered more trusted than the end-user who signed the
Capabilities in a signed message. (So one approach is to take PKC
in precedence to Capabilities received in a signed message.)
Another approach is to presume that the "latest" list should be used.
this was discussed earlier on the list.
Another approach when receiving the capabilities from more than one
use the most restrictive set.
[Stefan] Going into such suggestions is in my mind hard and dangerous.
This draft is limited to the protocol definitions and can't make
authoritative decisions or recommendations regarding the security policy
applied by implementers. Examples you give may be true in some
environments but not in others and this document lack the context to
make any suggestions.
The most we can do is to raise a flag in the security considerations
sections which is already done. I doubt that we can go further than
3 Other Issues.
3.1 There is no explicit statement that the S/MIME Capabilities are
be included in the encryption PKC in multiple keypair implementations.
this is intended since it does not make sense to include most
S/MIME capability attributes in signing PKC's. But I worry about the
compression attribute (for signed-only exchanges where there need be
encryption certificate), and S/MIME Capability attributes are
cannot know the future. Some explicit guidance may be appropriate
attributes in the relevant PKC ..."), and noting that if attributes
duplicated across PKC's they should not conflict. Right now I think
in which PKC(s) is open to interpretation (some implementers may put
all the PKC's).
[Stefan] I object also to this suggestion by the same reason. Every
certificate must be correct on its own merits. A certificate is correct
if it contain the appropriate information for its intended usage. That
is not affected by other certificates hold by the user.
3.2 I believe there should be more discussion about the impact of
on certificate revocation, both in terms of the overhead of re-issuing
certificates and the impact on the size of the CRL. In large
many certificates this may represent a barrier to the use of this
[Stefan] First I would disagree that this is a likely problem. Our own
experience with using this extension for over 50.000 users has not
driven any increased revocation activity because there is hardly any
event that would cause any such need. The only event we could see is in
the case where a supported algorithm suddenly gets severely broken. In
other cases we find that the encryption policy can be updated in sync
with regular certificate renewals. If an algorithm must be added on
short notice, then we can renew without any need for revocation (the old
list would still be valid, just incomplete).
This issue is however discussed in the security considerations section.
I believe this is sufficient.
Finally, in Clause 4, "week" should be "weak".
[Stefan] Thanks. This will be changed.