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
>-Original Message-
>From: Turner, Sean P. [mailto:[EMAIL PROTECTED]
>Sent: Friday, November 07, 2008 10:29 AM
>To: '[EMAIL PROTECTED]'; 'gen-art@ietf.org'
>Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
>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
>
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>Sent: Friday, November 07, 2008 10:21 AM
>>To: gen-art@ietf.org
>>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>>Subject: review of draft-ietf-smime-3851bis-08.txt
>>
>>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 PROTECTED]
>>
>>PS: congratulations for having got rid of RC2/40, this just took 13
>>years...
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
