[Top] [All Lists]

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

2004-11-11 13:16:47

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.


Stefan Santesson wrote:

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(_at_)ieca(_dot_)com] Sent: den 8 november 2004 15:46
To: ietf-smime(_at_)imc(_dot_)org; Stefan Santesson
Subject: Re: I-D ACTION:draft-ietf-smime-certcapa-00.txt


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 

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 

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

[SS] Done.

Internet-Drafts(_at_)ietf(_dot_)org 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:

To remove yourself from the I-D Announcement list, send a message to i-d-announce-request(_at_)ietf(_dot_)org with the word unsubscribe in the body of the message. You can also visit 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 or

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

Send a message to:
In the body type:
        "FILE /internet-drafts/draft-ietf-smime-certcapa-00.txt".
NOTE:   The mail server at 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

<Prev in Thread] Current Thread [Next in Thread>