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

From: Sean Turner <[email-masked]>
Date: Fri, 05 Jun 2009 12:39:09 -0400

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jun 2009 16:09:32 -0700

At 12:39 PM -0400 6/5/09, Sean Turner wrote:
>#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?
>

I disagree that this needs to be added, and I certainly don't think this qualifies as a security consideration. The draft already says (three times...) that the nonRepudiation bit MAY be set.

>point to 3279 here and the next one, you could delete it as a reference.

That's a good question. It is good for us to point to free and easily-retrieved documents when possible.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Zieglar, Lydia L." <[email-masked]>
Date: Mon, 22 Jun 2009 09:46:31 -0400

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
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sean Turner
Sent: Friday, June 05, 2009 12:39 PM
To: [email-masked]; 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:
> 
> final comments on this action.  Please send substantive comments to 
> the [email-masked] mailing lists by 2009-07-01. Exceptionally, comments

> may be sent to [email-masked] instead. In either case, please retain 
> the beginning of the Subject line to allow automated sorting.
> 

Lydia and Jim,

Here are some comments.

#1 Non-repudiation bit

r/SHA256/SHA-256
r/SHA384/SHA-384

OLD:

NEW:

OLD:

NEW:

Cheers,

spt