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.
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)"
[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.
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
[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.
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 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
A list of Internet-Drafts directories can be found in
Internet-Drafts can also be obtained by e-mail.
Send a message to:
In the body type:
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