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

["Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxx 
> [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Tony Capel
> Sent: Wednesday, February 16, 2005 12:52 PM
> To: ietf@xxxxxxxxxxxxxxxxx; 'Stefan Santesson'
> Cc: ietf-smime@xxxxxxx
> 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@xxxxxxxxxxxx 
> [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Jim Schaad
> Sent: February 16, 2005 12:46 PM
> To: ietf@xxxxxxxxxxxxxxxxx; 'Stefan Santesson'
> Cc: ietf-smime@xxxxxxx
> 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.
> 
> 
> 
> 
>