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

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 8 Feb 2005 15:12:47 -0000

I have just submitted a new draft 03 which includes resolutions to all
WG last call issues on the S/MIME capability extension document.

The only comments recorded were the comments submitted by Jim Schaad.
The resolutions to Jim's issues are summarized in-line below.

The new draft will hopefully surface in the course of a few days.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: den 14 december 2004 00:01
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
> 
> Stefan,
> 
> A couple of small comments on the draft, although I believe that it
could
> go
> to last call in its current state.
> 
> 1.  In section 2 you have the statement 'Algorithms should be ordered
by
> preference.'  As I general rule I attempt to avoid the use of must,
should
> and may when writing documents to avoid confusion with MUST, SHOULD
and
> MAY
> (did he just forget to capatilize it?).  A better statement might be
> 'Algorithms are expected to be be ordered by preference'.
> 
[Stefan] Resolution: I removed this statement and replaced it with a
clarification to the fact that all requirements and recommendations
concerning information content, stated in RFC 3851, apply to this spec
as well.

> 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?
> 

[Stefan] Resolution: New text added after the ASN.1 section stating that
the attribute and this extension are expected to hold the same type of
data.

> 3.  RFC 2199 is a reference, but the text refering to it is absent.
> 

[Stefan] Resolution: I added this text in a new section 1.1

> 4.  RFC 3280 is referenced only from the abstract.  Duplicate text
should
> be
> placed in section 1.

[Stefan] Resolution: This is done right at the beginning of section 1.

> jim

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 16 Feb 2005 20:17:20 -0000

Thanks Jim,

I agree to the text. Unless there are any objections on the list I have
no problem including this text in the draft for the IESG process.

Stefan Santesson

> Sent: den 16 februari 2005 09:46
> To: [email-masked]; Stefan Santesson
> Cc: [email-masked]
> 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: "Stefan Santesson" <[email-masked]>
Date: Fri, 18 Feb 2005 21:34:54 -0000

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

> Sent: den 18 februari 2005 10:51
> To: 'Tony Capel'; Stefan Santesson
> Cc: [email-masked]
> Tony,
> If you start with the proprosed text that I gave, re-write it to
address
> your concern.
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Tony Capel
> > Sent: Thursday, February 17, 2005 11:36 AM
> > To: 'Stefan Santesson'; [email-masked]
> > Cc: [email-masked]
> > 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
> >
> >
> >
> > 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]
> > 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
> > > From: Tony Capel [mailto:[email-masked]]
> > > Sent: den 17 februari 2005 08:38
> > > 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
> > >
> > > Sent: February 16, 2005 7:37 PM
> > > To: 'Tony Capel'; 'Stefan Santesson'
> > > Cc: [email-masked]
> > > 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
> > > > To: [email-masked]; 'Stefan Santesson'
> > > > Cc: [email-masked]
> > > > 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
> > > >
> > > > 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]
> > 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.
> > > >
> > > >
> > > >
> > > > 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.
> > > >
> > > > capabities that will be placed in the extension.
> > > >
> > > > 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.)
> > > >
> > > > prefered. These capabilties may or may not be generally included
> > > > depending on wither the item is related to encryption or
> > signature
> > > > operations.
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
>