Hi Tony,
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
editorial.
I comment below;
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
-----Original Message-----
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
Stefan:
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
mechanism
to signal the receiver's available and default encryption algorithms,
but
it
might be appropriate to mention in the introduction that the mechanism
will also
allow other receiver capabilities to be obtained. In the first
paragraph
you
may wish to add a sentence indicating that capabilities in addition to
the
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
initial
signed messages as well (e.g. initial signed message may be
compressed).
Possibly change "encrypted message" to "S/MIME message" to make it
more
general.
[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
should be
considered as a more reliable source of this information. However, I
would have
preferred a note at least introducing the options for establishing the
precedence of capability information from multiple sources. For
example:
The Capabilities in the PKC are inherently signed by the certificate
issuer, who
is normally considered more trusted than the end-user who signed the
Capabilities in a signed message. (So one approach is to take PKC
information
in precedence to Capabilities received in a signed message.)
Another approach is to presume that the "latest" list should be used.
I
believe
this was discussed earlier on the list.
Another approach when receiving the capabilities from more than one
source
is to
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
that.
3 Other Issues.
3.1 There is no explicit statement that the S/MIME Capabilities are
only
(?) to
be included in the encryption PKC in multiple keypair implementations.
I
assume
this is intended since it does not make sense to include most
currently
defined
S/MIME capability attributes in signing PKC's. But I worry about the
compression attribute (for signed-only exchanges where there need be
no
encryption certificate), and S/MIME Capability attributes are
extensible
so we
cannot know the future. Some explicit guidance may be appropriate
("...
put the
attributes in the relevant PKC ..."), and noting that if attributes
are
duplicated across PKC's they should not conflict. Right now I think
what
is put
in which PKC(s) is open to interpretation (some implementers may put
the
info in
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
this
approach
on certificate revocation, both in terms of the overhead of re-issuing
certificates and the impact on the size of the CRL. In large
organizations with
many certificates this may represent a barrier to the use of this
mechanism.
[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.
Regards,
Tony