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

["Zieglar, Lydia L." <[e-mail]>]

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
[e-mail]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sean Turner
Sent: Friday, June 05, 2009 12:39 PM
To: [e-mail]; 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 [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&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