Sorry for the delayed response. #1: Regarding the NR bit, since the Suite B cert profile states that the NR bit MAY be set, I'm inclined to leave it as is for now. If you feel strongly that I'm making a bad decision, please let me know. #2: Done #3: Done #4: Done #5: Changed references to RFC5480 and SEC1. #6: Changed references to RFC5480 and SEC1. #7: Done Thanks, Lydia Lydia Zieglar 301-688-1028 llziegl@xxxxxxxxxxxxxx -----Original Message----- From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Sean Turner Sent: Friday, June 05, 2009 12:39 PM To: ietf@xxxxxxxx; Zieglar, Lydia L.; Solinas, Jerry Cc: pkix Subject: Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate and Certificate Revocation List (CRL) Profile) to Informational RFC The IESG wrote: > The IESG has received a request from an individual submitter to > consider the following document: > > - 'Suite B Certificate and Certificate Revocation List (CRL) Profile ' > <draft-solinas-suiteb-cert-profile-03.txt> as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the ietf@xxxxxxxx mailing lists by 2009-07-01. Exceptionally, comments > may be sent to iesg@xxxxxxxx instead. In either case, please retain > the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile- > 03.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa > g=18056&rfc_flag=0 > Lydia and Jim, Here are some comments. #1 Non-repudiation bit During the development of other profiles where the NR bit wasn't set, sometime after the profile gets developed I've usually gotten questions like "so you're not setting N-R can I use it for non-repudiation services?" To answer this question, I sometimes put text in that said yes you can (below). Maybe we should add something like this maybe in the security considerations? Note that setting keyCertSign, cRLSign, and digitialSignature also means that the certificate could be used by applications that require non-repudiation services for certificate, CRL, and content signing, respectively. #2 Section 3.1 (add dashes) r/SHA256/SHA-256 r/SHA384/SHA-384 #3 Section 3.2 (add a new line): OLD: certicom-arc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) } id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) 1 } NEW: certicom-arc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) } id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) 1 } #4 Section 4.2 (add reference to 5480 and ECDSA-Sig-Value) I sometimes think it's easier to understand that we've defined an ASN.1 structure for the r/s combo: ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } It's in RFC 3279 and in RFC 5480. Don't point to X9.62 they did some odd things to this structure. Maybe the 2nd para in 4.2 could be changed as follows: OLD: The ECDSA signatureValue in an X.509 certificate is encoded as a BIT STRING value of a DER encoded SEQUENCE of the two INTEGERS. For example, in a signature using P-256 and hex notation: NEW: The ECDSA signatureValue in an X.509 certificate is encoded as a BIT STRING value of a DER encoded SEQUENCE of the two INTEGERS. As per [RFC5480], the structure, included for convenience, is as follows: ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } For example, in a signature using P-256 and hex notation: #5 Question: 4.2 Conversion Routine Aren't the conversion routines in SEC1 and ANSI X9.62 the same? 5480 pointed to SEC1 because it was more readily available (online and free versus online and not free for ANSI). Curious why you chose to point to 3279 and not 5480? 2.3.5 of 3279 points to 4.3.3 and 4.3.6 of ANSI X9.62. 2.2 of 5480 points to 2.3.1 and 2.3.2 of SEC1G. If we don't point to 3279 here and the next one, you could delete it as a reference. #6 Section 4.2 5th para: r/RFC3279/RFC5480 (the same routine is in 5480 section 2.2) #7 Section 4.5.2: r/[5280]/[RFC5280] Cheers, spt _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf