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(_at_)ietf(_dot_)org mailing lists by 2009-07-01. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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&dTag=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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf