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

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxx]
> Sent: den 13 december 2004 17:23
> To: Stefan Santesson
> Cc: ietf-smime@xxxxxxx
> 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@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
> > >
> >
> >
> >
>