ietf-smime
[Top] [All Lists]

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

2005-02-17 10:06:33

Hi Tony,

Would it be sufficient to say that the SMIMECapabilities extension
SHOULD only be included in certificates that support S/MIME encryption?

If not, what would you suggest?


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

-----Original Message-----
From: Tony Capel [mailto:capel(_at_)comgate(_dot_)com]
Sent: den 17 februari 2005 08:38
To: ietf(_at_)augustcellars(_dot_)com; Stefan Santesson
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt

Sorry for the incorrect link to comment 3.1, it should be:

http://www.imc.org/ietf-smime/mail-archive/msg02112.html

(November 11, 2004 message)

Tony

-----Original Message-----
From: Jim Schaad [mailto:ietf(_at_)augustcellars(_dot_)com]
Sent: February 16, 2005 7:37 PM
To: 'Tony Capel'; 'Stefan Santesson'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt


Tony,  your linked message makes no sense as it refers to the ESS
update
not to
this draft.

jim

-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Tony 
Capel
Sent: Wednesday, February 16, 2005 12:52 PM
To: ietf(_at_)augustcellars(_dot_)com; 'Stefan Santesson'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt


Stefan:

I was happy with the way you addressed most of my Nov 11,
2004 comments, however one comment (3.1) may not have been
fully addressed and is relevant to Jim's:

When viewing this draft from the viewpoint of enterprises
using multiple key-pairs (e.g. dual keypairs), some S/MIME
Capabilities should probably be in certain certificates (and
optionally or never in others).  For example, it appears to
make no sense to put the encryption algorithm choices in the
signing certificate in dual-keypair configurations.  Some
attributes might be in both certs (e.g. compression
capabilities), however there should also be a note that for
those attributes in both certs they must be the same.

So if you make changes to address Jim's comment could I
request you take another look at comment 3.1 in
http://www.imc.org/ietf-smime/mail-archive/msg02117.html
- and especially review the revised certcapa text in the
contest of multiple keypair configs where there is more than
one public key certificate corresponding to the entity?

Thanks

Tony

-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Jim 
Schaad
Sent: February 16, 2005 12:46 PM
To: ietf(_at_)augustcellars(_dot_)com; 'Stefan Santesson'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt



Stefan,

I am not really happy with how the following item was addressed.

2.  I would like to see the addition of a paragraph describing the
types of capabilities that are expected to be listed.  It
seems obious
that bulk encryption algorithms are listed as, potentially, are
key
encryption algorithms (consider RSA-OAEP as an example).
However it
is not clear about some of the other potential capabililties.
What
about signature and hash algorithms?  What about MAC algorithms?
What about S/MIME specifics such as id-cap-preferBinaryInside?


Since I did not care for the paragraph that you have, I am
suggesting the following paragraph instead.



There are numerous different types of S/MIME capabilities
that have been defined by different documents.  While all of
the different capabilties can be placed in this attribute, in
many cases not all of them need to be included.  Generally
only those items relating to encryption capabities are included.

- Signature/Hash Algorithms: As a general rule, the signature
processing capaiblities of a client are assumed rather than
checked, this means that if they are placed in this extension
they may be ignored.

- Content Encryption Algorrithms: This is the general set of
capabities that will be placed in the extension.

- Key Encryption/Key Transport Algorithms: These capabilities
are placed in the extension in thoses cases where additional
constraints are placed on the the public key algorithm.  (An
example would be using RSA-OAEP for a generic RSA key.)

- MAC Algorithms: These capabilties are genreally omitted
from the extension.

- Other capabitlies: This includes such items as binary
content prefered.
These capabilties may or may not be generally included
depending on wither the item is related to encryption or
signature operations.