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

["Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx] 
> Sent: Monday, December 13, 2004 3:48 PM
> To: ietf@xxxxxxxxxxxxxxxxx
> Cc: ietf-smime@xxxxxxx
> 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@xxxxxxxxxxxxxxxxx]
> > Sent: den 13 december 2004 15:01
> > To: Stefan Santesson
> > Cc: ietf-smime@xxxxxxx
> > 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
> > 
> 
> 
>