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

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 13 Dec 2004 23:48:25 -0000

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:[email-masked]]
> Sent: den 13 december 2004 15: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'.
> 
> 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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 13 Dec 2004 17:22:41 -0800

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 

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Monday, December 13, 2004 3:48 PM
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
> > about some of the other potential capabililties.  What 
> about signature 
> > and
> hash