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

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 11 Nov 2004 16:57:49 -0000

Thanks for the review Sean,

I comment your observations below.
I have incorporated these changes in a new ID-01 which I will submit as soon as we have agreed on all issues.

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: Sean P. Turner [mailto:[email-masked]] 
Sent: den 8 november 2004 15:46
To: [email-masked]; Stefan Santesson
Subject: Re: I-D ACTION:draft-ietf-smime-certcapa-00.txt

Stefan,

Here are my comments on the draft:
1. 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).

[SS] This is the only one I don't understand. What mechanism to obtain the users certificate are u referring to?

If you obtain the certificate from a directory or some other database then there are no specified means of having a signed S/MIME attribute. If you obtain the certificate from a signed mail, then the capabilities in the signed mail should normally have preference, which is stated in section 3.

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

[SS] OK, I have added that in the draft update.

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

[SS] Fixed in the update.

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

[SS] Error corrected in update. I only refer to 3851 though since it obsoletes 2633.

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

[SS] Fixed in update.

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

[SS] Fixed. Now says it MUST NOT be critical.

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

[SS] Fixed.

8. 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.

[SS] No we don't. I talked to Russ about that. And thus we don't need an ASN.1 section either. I have removed that from the updated ID.

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

[SS] Done.

[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: "Sean P. Turner" <[email-masked]>
Date: Thu, 11 Nov 2004 15:14:30 -0500

I guess I should withdraw #1.  I had this simple idea in mind that we 
had an attribute why not just put it in the repository entry that also 
contains the certificate.  But, we've only got an S/MIME attribute not a 
repository (LDAP/X.500) attribute.

The rest of it looks fine to me.

spt

---

From: "Tony Capel" <[email-masked]>
Date: Thu, 11 Nov 2004 15:42:17 -0500

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.

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.

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).

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.

Finally, in Clause 4, "week" should be "weak".

Regards,

Tony