[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:turners@xxxxxxxx] 
Sent: den 8 november 2004 15:46
To: ietf-smime@xxxxxxx; 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.


Internet-Drafts@xxxxxxxx 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 
i-d-announce-request@xxxxxxxx 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:
	mailserv@xxxxxxxxx
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.