|
RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
2005-02-18 14:35:28
I'm just leaving RSA and will try to look a bit into this as well on my
flight home to see how these issues could be combined.
I want to focus the text on straightforward and specific requirements
and recommendations that can be understood and tested by implementers.
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
-----Original Message-----
From: Jim Schaad [mailto:ietf(_at_)augustcellars(_dot_)com]
Sent: den 18 februari 2005 10:51
To: 'Tony Capel'; Stefan Santesson
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
Tony,
If you start with the proprosed text that I gave, re-write it to
address
your concern.
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: Thursday, February 17, 2005 11:36 AM
To: 'Stefan Santesson'; ietf(_at_)augustcellars(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
Stefan:
The logic of putting the encryption capabilities in the
encryption public key certificate (and NOT the signing public
key certificate) - !I think! - is straightforward. My
problem is with the capabilities that relate to signing,
should they be in the signing public key certificate? And
for capabilities relevant for both, should they be in both
certs or only one - and which one?
Maybe something like:
"In situations where more than one public key certificate is
issued for a single SMIME entity (e.g. in dual keypair
configurations where separate signing and encryption public
key certificates are used) the SMIMECapabilities attributes
in each certificate SHOULD be those which are relevant for
the functions associated with the certificate.
For example, Content Encryption and Key Encryption/Key
Transport algorithm SMIMECapabilities SHOULD be in the
encryption public key certificate. Their inclusion in the
signing public key certificate, while OPTIONAL, would be
redundant, would unnecessarily increase certificate size, and
may result in the need to unnecessarily revoke the
certificate if the algorithms are changed (changes to
SMIMECapabilities are discussed in Section 4).
Some SMIMECapabilities, e.g. binary content preferred,
compression capabilities [RFC3274], may be relevant for
signing operations as well. In such cases the capabilities
SHOULD be included in both certificates if the applications
using them do not guarantees the delivery of both
certificates. For example, in situations where signed
messaging is used and encryption public key certificates are
not exchanged (or may not even exist), these attributes
SHOULD be provided in the signing public key certificate (as well)."
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 Stefan
Santesson
Sent: February 17, 2005 12:06 PM
To: Tony Capel; ietf(_at_)augustcellars(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
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.
|
|