Subject: Re: I-D ACTION:draft-ietf-smime-certcapa-00.txt

From: "Sean P. Turner" <[email-masked]>
Date: Mon, 08 Nov 2004 09:45:54 -0500

Stefan,

Here are my comments on the draft:

clause 1, I'd like to see something about why it's better to have
it in the PKC than to just rely on the mechanism you used to get the
recipient's certificate in the 1st place (you need get the certificate
somehow).

clause 1, I'd like to see something about this being the "static"
solution and that dynamic solutions may be defined elsewhere.

clause 1, Last para, 1st sentence: r leverage/leverages.

clause 2, 2nd para: r RFC 2633/3851.

clause 2, a "(the following is included for illustrative purposes
only)" after following.

clause 2, We have to specify whether it's a critical or
non-critical extension.

clause 2, last para: add period to end of sentence.

clause 4, Are we going to need a module OID for this extension
:)  I'm interested to see if using the same attribute/extension OID
causes any compilers problems.

clause 5: You need specify which references are
normative/informative.

spt

[email-masked] wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

Title : Certificate extension for S/MIME Capabilities
Author(s) : S. Santesson
Filename : draft-ietf-smime-certcapa-00.txt
Pages : 5
Date : 2004-10-15

This document defines a certificate extension for inclusion of S/MIME
capabilities in public key certificates defined by RFC 3280.

S/MIME Capabilities provides an optional method to communicate
cryptographic capabilities of the certified subject as a complement
to use of the S/MIME Capabilities signed attribute in S/MIME messages
according to RFC 3851.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-certcapa-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-smime-certcapa-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-smime-certcapa-00.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 12 Nov 2004 21:43:15 -0000

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:[email-masked]]
> Sent: den 11 november 2004 21:42
> To: Stefan Santesson; [email-masked]
> 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