Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate and Certificate Revocation List (CRL) Profile) to Informational RFC

[Sean Turner <[e-mail]>]

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
> [e-mail] mailing lists by 2009-07-01. Exceptionally, 
> comments may be sent to [e-mail] 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