Re: [Gen-art] review of draft-ietf-pkix-ecc-subpubkeyinfo-10.txt
Francis, Thanks for the review. Proposed resolutions for comments are inline. spt >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Friday, December 05, 2008 4:33 AM >To: gen-art@ietf.org >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; >[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: review of draft-ietf-pkix-ecc-subpubkeyinfo-10.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 wait for direction from your document shepherd or AD >before posting a new version of the draft. > >Document: draft-ietf-pkix-ecc-subpubkeyinfo-10.txt >Reviewer: Francis Dupont >Review Date: 2008-12-03 >IETF LC End Date: 2008-12-09 >IESG Telechat date: 1008-12-18 > >Summary: Ready > >Major issues: None >Minor issues: None >Nits/editorial comments: > - the Abstract mentions RFC 3279 when the body of the >document uses only the reference [PKI-ALG]. The standard >solution should be to add the reference into the Abstract but >it is forbidden so I propose to add the title of RFC 3279 in >the Abstract. r/RFC 3279/Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3279. > - TOC page 2: Acknowledgements -> Acknowledgments Fixed. > - 1 page 2: I propose to add "RFC 3279" before the first [PKI-ALG] Fixed. > - 2.1 page 4: "This value is also used when a key is used with ECDSA." > wording can be improved if the word "used" is not used twice? Replaced text with: This value is also included in certificates when a public key is used with ECDSA. > - 2.1.1 page 5: "The AlgorithmIdentifier within >subjectPublicKeyInfo is > the only place ..." formally the AlgorithmIdentifier is the type of > the field, not the field name so is not a "place" r/place/field > - 3 page 7: at the first occurrence: CA -> Certification >Authority (CA) Fixed. > - 3 page 8: atthe first occurrence: EE -> End Entity (EE) Fixed. > - 4 page 10: please either add a reference for the MOV >(Menezes, Okamoto > and Vanstone) "condition" or improve the the wording making clear the > whole sentence is referenced by [X9.62]. r/the MOV/the Menezes-Okamoto-Vanstone (MOV) condition [X9.62] > - 4 page 10: IMHO it is not really necessary to add references for MD2 > and MD5. The WG specifically wanted this text in there so. > - 6 page 11: in NIST's arc -> in the NIST arc Fixed. > - 7 page 11: Acknowledgements -> Acknowledgments Fixed. > - 8.1 page 12: Standards for Efficient Cryptography -> > Standards for Efficient Cryptography Group (SECG) Fixed. >Regards > >[EMAIL PROTECTED] > >PS: I don't comment about the technical details (I believe a >consensus was reached even this took a long time and many >messages :-) and I assume the ASN.1 part was (or will soon be) >checked with dedicated tools. I did run the ASN.1 though a compiler and I got no errors. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-smime-3851bis-08.txt
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
Re: [Gen-art] 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
Re: [Gen-art] Gen-art review of draft-ietf-smime-multisig-04.txt
Elwyn, Thanks for the review. Responses inline... spt >-Original Message- >Comments: >s3: The first part of the specification for MultipleSignatures is : > >>The fields in MultipleSignatures have the following meaning: >> >> - bodyHashAlg includes the digest algorithmIdentifier for the >> referenced multiple-signatures attribute. >> >> - signAlg includes the signature algorithmIdentifier for the >> referenced multiple-signatures attribute. >> >I am confused by the use of 'includes' here: Do these specs >imply that the values of these fields are comma separated >lists of all relevant alg identifiers for the signatures? An >example with three signatures might clarify what is going on, >but the spec should be clarified in any case, I think (but I >may just not be sufficiently knowledgable about this sort of spec). The attribute is multivalued (discussed before the ASN.1) so there is a set of values for each signature applied. The reason for only using two in the example was purely based on page real estate. >Editorial: >idnits reports a clean bill of health. > >Abstract: Expand CMS acronym. fixed >s5: s/in a singled/in a single/ fixed >s5.2: s/the rquire application/the required application/ fixed >s5.3, para 5: The first sentence >> >> If signatures are added for the support of [ESS] features, then the >>fact that an outer layer signature can be treated as a non- >>significant failure. >> >does not parse. Probably missing 'is invalid' or some such >relating to outer layer signature. fixed >Appendix B: 'hashes CMS'??? Does not parse! fixed (reword) >B.1: s/is needed/are needed/ fixed (reword) >B.2 1/a/ii: s/Reistance/Resistance/ fixed >B.2 1/c/iii: s/success/successful/ fixed >B.2 2: Expand DER acronym. fixed >B.2: is not normative but uses SHOULD NOT. fixed >B.2 (2nd para on p18): s/that the attack/than the attack/ fixed ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Review of draft-ietf-smime-sha2-03.txt
Spencer, Thanks for taking the time to read the draft. Responses are inline. spt >-Original Message- >From: Spencer Dawkins [mailto:[EMAIL PROTECTED] >Sent: Friday, February 29, 2008 12:27 AM >To: General Area Review Team >Cc: Sean Turner; Blake Ramsdell; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Gen-ART Review of draft-ietf-smime-sha2-03.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. Will do. >Document: draft-ietf-smime-sha2-03.txt >Reviewer: Spencer Dawkins >Review Date: 2008 02 28 >IETF LC End Date: 2008-03-07 >IESG Telechat date: (if known) > >Summary: This document isn't ready for publication as a >Proposed Standard - it's got enough cut-and-paste errors and >apparently-omitted text that I'd think twice about trying to >implement it. And if it has a note that says "normative >reference still in progress, should be brought in line with >normative reference before publishing as an RFC", I'm not sure >why it's being last called now (of course, that decision is >above my pay grade). Wrt the reference, that draft is being worked in PKIX. Hopefully, it will progress quickly - I'm hoping for this summer (or sooner) for it to complete WG LC and IETF LC. Also, the reference is for object identifiers all of which were assigned years ago and are stable. >Comments: > >Please include any nits listed in >http://www.ietf.org/mail-archive/web/ietf/current/msg50518.html > that I may have missed in this review, by reference :-( Will do. >When one of the last call comments is "There are obvious >errors (intentionnaly left by the editor in order to know how >many people read the document)", this does not inspire >confidence. I note there is no shepherd writeup in the tracker >yet. The "of for" typo below has been in every version since >00. Who else has read this draft? This was, I believe, his attempt at humor. See my response to Denis' email. >Abstract > > This document describes the conventions for using the message digest > algorithms SHA-224, SHA-256, SHA-384, SHA-512, as defined in FIPS > >Nit - I'm not sure what passes for normal in security drafts, >but I'd expect to see SHA and FIPS expanded on first use in >the abstract, and in the introduction of the document. Ditto >for DSA, RSA, and ECDSA. I will expand the acronyms. > 180-3, with the Cryptographic Message Syntax (CMS). It also >describes > the conventions for using these algorithms with CMS and the >DSA, RSA, > and ECDSA signature algorithms. > >Conventions used in this document > >Nit - it is odd to see this section as part of the abstract... For some reason the tool picks up this section as part of the abstract. It's got a heading title so I don't think it's in the abstract. >1. Introduction > > This document specifies the algorithm identifiers and specifies > parameters for the message digest algorithms SHA-224, SHA-256, SHA- > 384, and SHA-512 for use with the Cryptographic Message Syntax (CMS) > [RFC3852]. The message digest algorithms are defined in and [SHS]. > >Concern: "in and" seems to be missing something. Denis caught this too. Will fix by removing the "and". > If an implementation chooses to support one of the algorithms > discussed in this document, then the implementation MUST do so as > described in this document. > >Concern: this MUST (and the parallel MUST in the next >paragraph) seem odd - do you need to say this? Hmmm ... I guess not. I'll remove both sentences. > Note that [RFC4231] specifies the conventions for use of for the > >Concern: "of for" seems to be missing something. I will remove "for use of" so the sentence will read: Note that [RFC4231] specifies the conventions for the message authentication code (MAC) algorithms > message authentication code (MAC) algorithms: HMAC with >SHA-224, HMAC > with SHA-256, HMAC with SHA-384, and HMAC with SHA-512. > >2. Message Digest Algorithms > > The following addresses the parameters field: > >Nit - this sentence isn't clear and isn't required. I'd strike it. Removed. > There are two possible encodings for the SHA AlgorithmIdentifier > parameters field. The two alternatives arise from the fact >that when > the 1988 syntax for AlgorithmIdentifier was translated into the 1997 > syntax, the OPTIONAL associated with the AlgorithmIdentifier > parameters got lost. Later the OPTIONAL was recovered via a defect > report, but by then many people thought that algorithm parameters > were mandatory. Because of this history some implementations encode > parameters as a NULL element and others omit them entirely. The > correct encoding is to omit the parameters field; however, > implementations MUST also handle a SHA AlgorithmIdentifier >parameters
