Subject: [Gen-art] review of draft-ietf-smime-3851bis-08.txt

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Nov 2008 16:21:14 +0100

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-smime-3851bis-08.txt
Reviewer: Francis Dupont
Review Date: 2008-11-06
IETF LC End Date: 2008-11-13
IESG Telechat date: unknown

Summary: Ready

Comments: a few editorial comments (i.e., to be handled by the RFC Editor
if no new version of the document is published for another reason).

Note I don't comment about the cryptographic strength requirements even
IMHO these should be handled by profiles according to specific environment
context, the document specifying only the default (and minimum) profile
(but the document doesn't make the adoption of this idea impossible or
even hard, and if there was an agreement for following this kind of way
this should have been done before).

Comment details:
 - Discussion page 2: if this should be removed prior to publication by
 the RFC editor it is better to mention it.

 - TOC page 3: Appendix C (Acknowledgments) is missing, same for
  Authors' Addresses

 - 1.6 page 7: WithRSAEncrption -> WithRSAEncryption

 - 3.4.3.2 page 28: why SHA-2 algorithms are still not recommended?
  (IMHO the paragraph still waits to be removed :-)

 - 7.1 page 38: I note an I-D (CMS-SHA2) is in the normative references
  (not a problem, the publication of the document will just be defered
   until the I-D is published)
 
 - 7.1 pages 38 and 39: two FIPS publications (FIPS180-3 and 186-3) are
  marked as "draft". I don't know if this can be an issue...

 - Appendix A page 42: prefersBinaryInside -> preferBinaryInside

 - Appendix A page 43: receipentKeyId -> recipientKeyId

 - Appendix C page 44: Acknowledgements -> Acknowledgments

 - Author's Addresses page 44: Author's -> Authors'

Regards

[email-masked]

PS: congratulations for having got rid of RC2/40,
this just took 13 years...
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 7 Nov 2008 11:28:34 -0500

Francis,

Thanks for your comments.  The only one I feel like I should reply to is the
comment on  is 3.4.3.2: we do require SHA-256, which is a SHA2 algorithm,
just not the others.  Basically, we had to pick one and SHA-256 seemed like
the one to go with.  Technically, we could remove the paragraph because it's
not really needed.  For example, we point to RFC3370 and we don't have a
paragraph explaining that we don't use SS-DH or PBKDF2.

Tim,

I'll whip up another version after the IETF LC closes to save the editor
some work.

spt

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Friday, November 07, 2008 10:21 AM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: review of draft-ietf-smime-3851bis-08.txt
>
>Please resolve these comments along with any other Last Call 
>comments you may receive.
>
>
>Comments: a few editorial comments (i.e., to be handled by the 
>RFC Editor if no new version of the document is published for 
>another reason).
>
>Note I don't comment about the cryptographic strength 
>requirements even IMHO these should be handled by profiles 
>according to specific environment context, the document 
>specifying only the default (and minimum) profile (but the 
>document doesn't make the adoption of this idea impossible or 
>even hard, and if there was an agreement for following this 
>kind of way this should have been done before).
>
>Comment details:
> - Discussion page 2: if this should be removed prior to 
>publication by  the RFC editor it is better to mention it.
>
>PS: congratulations for having got rid of RC2/40, this just 
>took 13 years...

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 17 Nov 2008 18:37:27 -0600

I checked with some people on renaming the receipentKeyId field to
recipientKeyid, and it's a no go.  That name is used by compilers to name C
code and changing it is going to cause problems.  It's also been mispelled
since about 1999 and nobody has said anything ;) I added a note in the ASN.1
that says:

-- receipentKeyId is spelt incorrectly, but kept for historical
-- reasons.

spt

>From: Turner, Sean P. [mailto:[email-masked]] 
>Sent: Friday, November 07, 2008 10:29 AM
>To: [email-masked]'; [email-masked]'
>Cc: [email-masked]'; [email-masked]'
>Subject: RE: review of draft-ietf-smime-3851bis-08.txt
>
>Francis,
>
>Thanks for your comments.  The only one I feel like I should 
>reply to is the comment on  is 3.4.3.2: we do require SHA-256, 
>which is a SHA2 algorithm, just not the others.  Basically, we 
>had to pick one and SHA-256 seemed like the one to go with.  
>Technically, we could remove the paragraph because it's not 
>really needed.  For example, we point to RFC3370 and we don't 
>have a paragraph explaining that we don't use SS-DH or PBKDF2.
>
>Tim,
>
>I'll whip up another version after the IETF LC closes to save 
>the editor some work.
>
>spt
>
>>I have been selected as the General Area Review Team 
>(Gen-ART) reviewer 
>>for this draft (for background on Gen-ART, please see 
>>Comments: a few editorial comments (i.e., to be handled by the RFC 
>>Editor if no new version of the document is published for another 
>>reason).
>>
>requirements even 
>>IMHO these should be handled by profiles according to specific 
>>environment context, the document specifying only the default (and 
>>minimum) profile (but the document doesn't make the adoption of this 
>>idea impossible or even hard, and if there was an agreement for 
>>following this kind of way this should have been done before).
>>
>>Comment details:
>publication by  
>>PS: congratulations for having got rid of RC2/40, this just took 13 
>>years...
>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Nov 2008 01:55:59 +0100

In your previous mail you wrote:

=> my spell checker complained so I believed it was just a typo...

=> I am fine with this.

Thanks