ietf-smime
[Top] [All Lists]

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

2005-02-08 08:13:28

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:ietf(_at_)augustcellars(_dot_)com]
Sent: den 14 december 2004 00:01
To: Stefan Santesson
Cc: ietf-smime(_at_)imc(_dot_)org
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