Thanks Jim,
I can't think of any justifications for differences myself so it will be
hard for me to add any to the spec.
If you still think we should specify differences, could you share your
justifications for them for consideration?
Otherwise I will be happy to just add text stating that there are no
differences.
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
-----Original Message-----
From: Jim Schaad [mailto:ietf(_at_)augustcellars(_dot_)com]
Sent: den 13 december 2004 17:23
To: Stefan Santesson
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
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