Stefan,
I believe that I could easily justify differences in behaviors here.
However I think you need to put in some text saying that there is no
difference as to what is included and a small justification for this.
jim
-----Original Message-----
From: Stefan Santesson [mailto:stefans(_at_)microsoft(_dot_)com]
Sent: Monday, December 13, 2004 3:48 PM
To: ietf(_at_)augustcellars(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
Thanks Jim,
I agree on 1 3 and 4 to be fixed.
I'm not so sure with 2. I think any such recommendations
should be handled in RFC 3851 where the S/MIME Capabilities
attribute is defined.
No use of this extension in certificate should differ in any
way from its use as signed attribute in S/MIME messages.
I think that it would be confusing if we started to actually
specify/recommend the attribute content in 2 separate RFCs.
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
-----Original Message-----
From: Jim Schaad [mailto:ietf(_at_)augustcellars(_dot_)com]
Sent: den 13 december 2004 15: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'.
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?
3. RFC 2199 is a reference, but the text refering to it is absent.
4. RFC 3280 is referenced only from the abstract. Duplicate text
should
be
placed in section 1.
jim