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

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 17 Feb 2005 17:05:43 -0000

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:[email-masked]]
> Sent: den 17 februari 2005 08:38
> To: [email-masked]; Stefan Santesson
> Cc: [email-masked]
> 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:[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
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Tony Capel
> > Sent: Wednesday, February 16, 2005 12:52 PM
> > To: [email-masked]; 'Stefan Santesson'
> > Cc: [email-masked]
> > 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: [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,
> >
> > 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: Eric Norman <[email-masked]>
Date: Thu, 17 Feb 2005 13:22:35 -0600

> SHOULD only be included in certificates that support S/MIME encryption?

Why be so restrictive?  Why not just point out that it makes sense to 
include this
extension in certificates than can be used for encryption; it doesn't 
make sense
to include it in certificates constrained to signing operations, and 
leave it at that?
I don't see any reason for MUST or SHOULDs here.

You can mention that inclusion of the SMIMECapabilities extension in a 
place
where it doesn't make sense is to be handled gracefully; e.g. you 
ignore it; you
don't use it as an excuse to reject the certificate.

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

In the above message, the suggestion is made that precedence be 
determined
by who is more trustworthy.  I think it should be determined by who is 
more
knowledgeable.  It's the sender of a message that has more current 
knowledge
of cryptographic capabilities of her equipment or cryptographic tokens 
and has
more knowledge about where replies to the message will be delivered and 
the
cryptographic capabilities that exist there.  Ergo, the 
SMIMECapabilities in the
message should take precedence if there's a conflict.

Eric Norman
University of Wisconsin -- DoIT

---

From: "Tony Capel" <[email-masked]>
Date: Thu, 17 Feb 2005 14:35:41 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: February 17, 2005 12:06 PM
To: Tony Capel; [email-masked]
Cc: [email-masked]
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?

Stefan Santesson

update
> > 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 
> > - 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
> >
key
What
> > 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.
> >
> > processing capaiblities of a client are assumed rather than checked, 
> > this means that if they are placed in this extension they may be 
> > ignored.
> >
> > - 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

---

From: Eric Norman <[email-masked]>
Date: Thu, 17 Feb 2005 14:36:55 -0600

> relevant for both, should they be in both certs or only one - and 

I'm having a problem with the notion of capabilities that relate to 
signing.
These would be capabilities that I have and someone else needs to know
about before they can send me a signed message, right?  How is the
distribution bootstrapped?  I send them to him in a signed message?
But what if he has the same problem and needs to inform me about his
capabilities before I can sign that message?

Eric Norman

---

From: "Tony Capel" <[email-masked]>
Date: Thu, 17 Feb 2005 17:40:31 -0500

Eric:

In a signed-only conversation the initial message would use "default".  But
message could contain compression attribute in cert allowing subsequent messages
to be compressed.  I agree that many other attributes associated with signing
make no sense to include for the reasons you suggest, and I think that's what
Jim was referring to in his original post.

However, the main thrust of my suggestion is to provide some guidance as to
which attributes should be in which certs (and Jim's: which attributes make
sense).

Cheers,

tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Norman
Sent: February 17, 2005 3:37 PM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-certcapa-02.txt

I'm having a problem with the notion of capabilities that relate to 
signing.
These would be capabilities that I have and someone else needs to know about
before they can send me a signed message, right?  How is the distribution
bootstrapped?  I send them to him in a signed message? But what if he has the
same problem and needs to inform me about his capabilities before I can sign
that message?

Eric Norman

---

From: "Tony Capel" <[email-masked]>
Date: Fri, 18 Feb 2005 10:50:43 -0500

Eric to answer your specific bootstrap question:

You don't necessarily need to know the specific 
capabilities of the receiver to sign.
A strategy could be to sign with all algorithms
(multiple signerinfos).  Once you have
confirmed capabilities by receiving the
SMIMECapabilities, from then on you could avoid
having to generate the extra signerinfos.
Thus the bootstrap approach could be to start
with the "default" of "all algorithms".

Tony

-----Original Message-----

>signing. These would be capabilities that I have and someone else
> needs to know about before they can send me a signed message,
>right?  How is the distribution bootstrapped?  I send them to
> him in a signed message? But what if he has the same problem
>and needs to inform me about his capabilities before I can sign that message?

Eric Norman

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 18 Feb 2005 10:50:56 -0800

Tony,

If you start with the proprosed text that I gave, re-write it to address
your concern.

jim 

> Sent: Thursday, February 17, 2005 11:36 AM
> To: 'Stefan Santesson'; [email-masked]
> Cc: [email-masked]
> 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
> 
> 
> 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Would it be sufficient to say that the SMIMECapabilities 
> extension SHOULD only be included in certificates that 
> support S/MIME encryption?
> 
> contest of 
> that have 
> from the 
> signature 
> > > operations.