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

From: "Jim Schaad" <[email-masked]>
Date: Wed, 16 Feb 2005 09:45:35 -0800

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.

---

From: "Tony Capel" <[email-masked]>
Date: Wed, 16 Feb 2005 15:52:21 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jim Schaad
Sent: February 16, 2005 12:46 PM
To: [email-masked]; 'Stefan Santesson'
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt

Stefan,

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 16 Feb 2005 16:36:37 -0800

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

jim 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tony Capel
> Sent: Wednesday, February 16, 2005 12:52 PM
> 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
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Schaad
> > 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?
> 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.
> 
> These capabilties may or may not be generally included 
> depending on wither the item is related to encryption or 
> signature operations.
> 
> 
> 
> 
>

---

From: "Tony Capel" <[email-masked]>
Date: Thu, 17 Feb 2005 11:37:30 -0500

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:[email-masked]] 
Sent: February 16, 2005 7:37 PM
To: 'Tony Capel'; 'Stefan Santesson'
Cc: [email-masked]
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