Subject: Way forward - updating RFC 3161

From: Stefan Santesson <[email-masked]>
Date: Wed, 01 Jul 2009 02:59:56 +0200

We need to resolve how to update RFC 3161 with respect to allowing support
of RFC 5035 (ESSV2)
One particular reason is because ETSI ESI is dependent on progression of
this issue in PKIX.

I would like to open this issue up for debate and then hopefully conclude
this issue, possibly after a straw poll.

My personal opinion, and what I interpret as the general opinion of this
working group is that we should reject draft-ietf-pkix-rfc3161bis-01 as
basis for updating rfc 3161. This draft intends to obsolete RFC 3161 and
introduces major changes to terminology and role description to align RFC
3161 with the informational document RFC 3628.

It is problematic to introduce such major changes to a standard that is
widely deployed. It is neither required from a protocol implementation
perspective as these changes are not intended to change any bits on the
wire. The optional usage of ESSV2 does not motivate a total rewrite of the
current standard, but is better handled in an update RFC.

If description of roles and responsibilities that so not change any bits on
the wire need to be clarified in relation to RFC 3628 and RFC 3161, then
this should be handled either as an update to RFC 3628 or as a separate
informational document.

/Stefan

---

From: Adriano Santoni <[email-masked]>
Date: Wed, 01 Jul 2009 07:59:52 +0200

I fully agree with Stefan.

Adriano

Stefan Santesson ha scritto:
> We need to resolve how to update RFC 3161 with respect to allowing 
> support of RFC 5035 (ESSV2)
> One particular reason is because ETSI ESI is dependent on progression 
> of this issue in PKIX.
>
> I would like to open this issue up for debate and then hopefully 
> conclude this issue, possibly after a straw poll.
>
> My personal opinion, and what I interpret as the general opinion of 
> this working group is that we should reject 
> draft-ietf-pkix-rfc3161bis-01 as basis for updating rfc 3161. This 
> draft intends to obsolete RFC 3161 and introduces major changes to 
> terminology and role description to align RFC 3161 with the 
> informational document RFC 3628.
>
> It is problematic to introduce such major changes to a standard that 
> is widely deployed. It is neither required from a protocol 
> implementation perspective as these changes are not intended to change 
> any bits on the wire. The optional usage of ESSV2 does not motivate a 
> total rewrite of the current standard, but is better handled in an 
> update RFC.
>
> If description of roles and responsibilities that so not change any 
> bits on the wire need to be clarified in relation to RFC 3628 and RFC 
> 3161, then this should be handled either as an update to RFC 3628 or 
> as a separate informational document.
>
> /Stefan 

From: "Liaquat Khan" <[email-masked]>
To: "'Adriano Santoni'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Cc: <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "'Pope, Nick'" <[email-masked]>
Subject: RE: Way forward - updating RFC 3161
Date: Wed, 1 Jul 2009 10:42:00 +0400
Sender: [email-masked]

Yes, me too.

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adriano Santoni
Sent: 01 July 2009 10:00
To: Stefan Santesson
Cc: [email-masked]; Denis Pinkas; Pope, Nick
Subject: Re: Way forward - updating RFC 3161

I fully agree with Stefan.

Adriano

Stefan Santesson ha scritto:
> We need to resolve how to update RFC 3161 with respect to allowing 
> support of RFC 5035 (ESSV2)
> One particular reason is because ETSI ESI is dependent on progression 
> of this issue in PKIX.
>
> I would like to open this issue up for debate and then hopefully 
> conclude this issue, possibly after a straw poll.
>
> My personal opinion, and what I interpret as the general opinion of 
> this working group is that we should reject 
> draft-ietf-pkix-rfc3161bis-01 as basis for updating rfc 3161. This 
> draft intends to obsolete RFC 3161 and introduces major changes to 
> terminology and role description to align RFC 3161 with the 
> informational document RFC 3628.
>
> It is problematic to introduce such major changes to a standard that 
> is widely deployed. It is neither required from a protocol 
> implementation perspective as these changes are not intended to change 
> any bits on the wire. The optional usage of ESSV2 does not motivate a 
> total rewrite of the current standard, but is better handled in an 
> update RFC.
>
> If description of roles and responsibilities that so not change any 
> bits on the wire need to be clarified in relation to RFC 3628 and RFC 
> 3161, then this should be handled either as an update to RFC 3628 or 
> as a separate informational document.
>
> /Stefan 

Date: Wed, 01 Jul 2009 07:59:52 +0200
From: Adriano Santoni <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Denis Pinkas <[email-masked]>, "Pope, Nick" <[email-masked]>
Subject: Re: Way forward - updating RFC 3161
Sender: [email-masked]

I fully agree with Stefan.

Adriano

Stefan Santesson ha scritto:
> We need to resolve how to update RFC 3161 with respect to allowing 
> support of RFC 5035 (ESSV2)
> One particular reason is because ETSI ESI is dependent on progression 
> of this issue in PKIX.
>
> I would like to open this issue up for debate and then hopefully 
> conclude this issue, possibly after a straw poll.
>
> My personal opinion, and what I interpret as the general opinion of 
> this working group is that we should reject 
> draft-ietf-pkix-rfc3161bis-01 as basis for updating rfc 3161. This 
> draft intends to obsolete RFC 3161 and introduces major changes to 
> terminology and role description to align RFC 3161 with the 
> informational document RFC 3628.
>
> It is problematic to introduce such major changes to a standard that 
> is widely deployed. It is neither required from a protocol 
> implementation perspective as these changes are not intended to change 
> any bits on the wire. The optional usage of ESSV2 does not motivate a 
> total rewrite of the current standard, but is better handled in an 
> update RFC.
>
> If description of roles and responsibilities that so not change any 
> bits on the wire need to be clarified in relation to RFC 3628 and RFC 
> 3161, then this should be handled either as an update to RFC 3628 or 
> as a separate informational document.
>
> /Stefan 

Date: Wed, 01 Jul 2009 02:59:56 +0200
Subject: Way forward - updating RFC 3161
From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Denis Pinkas <[email-masked]>, "Pope, Nick" <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3329261997_2958318
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

/Stefan

--B_3329261997_2958318
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Way forward - updating RFC 3161</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>We need to resolve how to update RFC 3161 with respect to allowing support=
 of RFC 5035 (ESSV2)<BR>
One particular reason is because ETSI ESI is dependent on progression of th=
is issue in PKIX.<BR>
<BR>
I would like to open this issue up for debate and then hopefully conclude t=
his issue, possibly after a straw poll.<BR>
<BR>
My personal opinion, and what I interpret as the general opinion of this wo=
rking group is that we should reject draft-ietf-pkix-rfc3161bis-01 as basis =
for updating rfc 3161. This draft intends to obsolete RFC 3161 and introduce=
s major changes to terminology and role description to align RFC 3161 with t=
he informational document RFC 3628.<BR>
<BR>
It is problematic to introduce such major changes to a standard that is wid=
ely deployed. It is neither required from a protocol implementation perspect=
ive as these changes are not intended to change any bits on the wire. The op=
tional usage of ESSV2 does not motivate a total rewrite of the current stand=
ard, but is better handled in an update RFC.<BR>
<BR>
If description of roles and responsibilities that so not change any bits on=
 the wire need to be clarified in relation to RFC 3628 and RFC 3161, then th=
is should be handled either as an update to RFC 3628 or as a separate inform=
ational document.<BR>
<BR>
/Stefan</SPAN></FONT>
</BODY>
</HTML>

--B_3329261997_2958318--

Date: Mon, 29 Jun 2009 21:36:02 +0200
Subject: Request for PKIX agenda items - IETF 75
From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3329156164_20567213
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

PKIX is currently scheduled to meet on Wednesday July 29, 1300-1500

Please send me any request for agenda items for the IETF in Stockholm.

As usual I need at least one author of each active draft to send me an
e-mail stating if you need a slot or not.

I myself will request (and grant unless I hear loud objections) a time slot
to talk about solutions for expanded attribute semantics expression. This is
an issue that sorts under liaison with ETSI ESI activities as well as
European ID management projects.

/Stefan

--B_3329156164_20567213
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Request for PKIX agenda items - IETF 75</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>PKIX is currently scheduled to meet on Wednesday July 29, 1300-1500<BR>
<BR>
Please send me any request for agenda items for the IETF in Stockholm.<BR>
<BR>
As usual I need at least one author of each active draft to send me an e-ma=
il stating if you need a slot or not.<BR>
<BR>
I myself will request (and grant unless I hear loud objections) a time slot=
 to talk about solutions for expanded attribute semantics expression. This i=
s an issue that sorts under liaison with ETSI ESI activities as well as Euro=
pean ID management projects.<BR>
<BR>
/Stefan</SPAN></FONT>
</BODY>
</HTML>

--B_3329156164_20567213--

Content-class: urn:content-classes:message
Subject: RE: Last Call: draft-solinas-suiteb-cert-profile (Suite B 	Certificate and Certificate Revocation List (CRL) Profile) to 	Informational RFC
Date: Mon, 22 Jun 2009 09:46:31 -0400
From: "Zieglar, Lydia L." <[email-masked]>
To: "Sean Turner" <[email-masked]>, <[email-masked]>, "Solinas, Jerry" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

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. =20

#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=20
> consider the following document:
>=20
> - 'Suite B Certificate and Certificate Revocation List (CRL) Profile '
>    <draft-solinas-suiteb-cert-profile-03.txt> as an Informational RFC
>=20
> The IESG plans to make a decision in the next few weeks, and solicits=20
> final comments on this action.  Please send substantive comments to=20
> the [email-masked] mailing lists by 2009-07-01. Exceptionally, comments

> may be sent to [email-masked] instead. In either case, please retain=20
> the beginning of the Subject line to allow automated sorting.
>=20
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-
> 03.txt
>=20
>=20
> IESG discussion can be tracked via
> =
https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa
> g=3D18056&rfc_flag=3D0
>=20

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 ::=3D {
          iso(1) identified-organization(3) certicom(132) }
       id-ecPublicKey OBJECT IDENTIFIER ::=3D {
          ansi-X9-62 keyType(2) 1 }

NEW:

       certicom-arc OBJECT IDENTIFIER ::=3D {
          iso(1) identified-organization(3) certicom(132) }

       id-ecPublicKey OBJECT IDENTIFIER ::=3D {
          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 ::=3D 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 ::=3D 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

To: Paul Hoffman <[email-masked]>
Cc: Daniel Brown <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
From: Tom Gindin <[email-masked]>
Date: Fri, 19 Jun 2009 01:19:40 -0400
Sender: [email-masked]

        I'm not in charge of this draft, of course, but my draft paragraph 
is more a citation of others' reasonably informed opinion than an explicit 
recommendation.  It doesn't need either a SHOULD or a MUST.  If we need to 
give firmer guidance, I myself would suggest a pair of SHOULD's, but no 
MUST's.
        The first appropriate SHOULD implied is "An implementor in an 
environment where a symmetric key of length L bits is often used SHOULD 
NOT use a hash algorithm with an output length of less than 2L bits for 
digital signatures".  That's an implication of NIST's analysis, and I see 
no reason not to use it.  The other is "Signatures expected to be verified 
more than a few weeks after they are produced SHOULD NOT use any hash 
algorithm with an output length of 160 bits or less".  Long-term 
verification naturally calls for a margin of safety above other 
signatures, and I would not want to present a signature for long-term 
verification that NIST has already declared too short (as they will do to 
SHA-1 at the end of 2009), unless I had concrete reasons for doubting 
their judgement.

                Tom Gindin

Paul Hoffman <[email-masked]> 
06/18/2009 11:43 AM

To
Tom Gindin/Watson/IBM@IBMUS, Daniel Brown <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

At 9:14 PM -0400 6/17/09, Tom Gindin wrote:
>        Would it be simple enough to just say that NIST SP 800-57 part 1
>table 3 implies that its authors consider the use of a given hash
>algorithm of the SHA family in digital signatures with an output length 
of
>2L bits to have roughly comparable strength (presumably against known
>cryptographic attacks) to the use of a symmetric key of L bits?  We can
>also say that NIST has given its own summaries of appropriate key lengths
>for use after a given date in table 4 of that same document, instead of
>referencing multiple long documents and expecting implementors to read
>them.

That definitely works for me, assuming that you mean "replace the SHOULDs 
and MUSTs" with the above wording.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 18 Jun 2009 08:43:04 -0700
To: Tom Gindin <[email-masked]>, Daniel Brown <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 9:14 PM -0400 6/17/09, Tom Gindin wrote:
>        Would it be simple enough to just say that NIST SP 800-57 part 1
>table 3 implies that its authors consider the use of a given hash
>algorithm of the SHA family in digital signatures with an output length of
>2L bits to have roughly comparable strength (presumably against known
>cryptographic attacks) to the use of a symmetric key of L bits?  We can
>also say that NIST has given its own summaries of appropriate key lengths
>for use after a given date in table 4 of that same document, instead of
>referencing multiple long documents and expecting implementors to read
>them.

That definitely works for me, assuming that you mean "replace the SHOULDs and MUSTs" with the above wording.

--Paul Hoffman, Director
--VPN Consortium

To: Daniel Brown <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
From: Tom Gindin <[email-masked]>
Date: Wed, 17 Jun 2009 21:14:01 -0400
Sender: [email-masked]

        Would it be simple enough to just say that NIST SP 800-57 part 1 
table 3 implies that its authors consider the use of a given hash 
algorithm of the SHA family in digital signatures with an output length of 
2L bits to have roughly comparable strength (presumably against known 
cryptographic attacks) to the use of a symmetric key of L bits?  We can 
also say that NIST has given its own summaries of appropriate key lengths 
for use after a given date in table 4 of that same document, instead of 
referencing multiple long documents and expecting implementors to read 
them.

                Tom Gindin

Daniel Brown <[email-masked]> 
Sent by: [email-masked]
06/12/2009 11:35 AM

To
Paul Hoffman <[email-masked]>, "[email-masked]" 
<[email-masked]>
cc

Subject
RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

Paul,

I propose the following text (sorry for the poor formatting).  A few
non-at-issue parts are left out, marked as "...".  I based the text on 
text
Quynh Dang prepared that was based on your shortened text.  I added some
SHOULDs and MUSTs based on my previous emails, and have below highlighted
these additions with *** above and below, as these are probably the
most-at-issue parts.

Best regards,

                 Dan

...

Abstract
This document updates RFC 3279 [RFC 3279] to specify algorithm identifiers
and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and
Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when
using SHA-224, SHA-256, SHA-384 or SHA-512 as hashing algorithm. This
specification applies to the Internet X.509 Public Key infrastructure 
(PKI)
when digital signatures are used to sign certificates and certificate
revocation lists(CRLs).

1.                  Introduction
This specification defines the contents of the signatureAlgorithm,
signatureValue and signature fields within Internet X.509 certificates and
CRLs when these objects are signed using DSA or ECDSA with a SHA2 hash
algorithm. These fields are more fully described in RFC 5280 [RFC 5280].
This document profiles material presented in the "Secure Hash Standard"
[FIPS 180-3], "Public Key Cryptography for the Financial Services 
Industry:
The Elliptic Curve Digital Signature Standard (ECDSA)"[X9.62], and the
"Digital Signature Standard"[FIPS 186-3].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
 
2.    One-way Hash Functions
This section identifies four additional hash algorithms for use with DSA 
and
ECDSA in the Internet X.509 certificate and CRL profile [RFC 5280]. 
SHA-224,
SHA-256, SHA-384, and SHA-512 produce a 224-bit, 256-bit, 384-bit and
512-bit "hash" of the input respectively and are fully described in the
Federal Information Processing Standard 180-3 [FIPS 180-3].
The listed one-way hash functions are identified by the following object
identifiers (OIDs): 
id-sha224  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) 
us(840)
organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 }
id-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) 
us(840)
organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 }
id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) 
us(840)
organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 }
id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) 
us(840)
organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 }
When one of these OIDs appears in an AlgorithmIdentifier, all
implementations MUST accept both NULL and absent parameters as legal and
equivalent encodings.
***
Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or
SHA-512 when generating certificates, but MAY use SHA-1.
***
3.    Signature Algorithms
This section identifies OIDs for DSA and ECDSA with SHA-224, SHA-256,
SHA-384, and SHA-512. The contents of the parameters    component for each
signature algorithm vary; details are provided for each algorithm. 
3.1                   DSA Signature Algorithm
The DSA is defined in the Digital Signature Standard (DSS) [FIPS 186-3]. 
DSA
was developed by the U.S. Government, and can be used in conjunction with 
a
SHA2 one-way hash function such as SHA-224 or SHA-256. DSA is fully
described in [FIPS 186-3].
 
When SHA-224 is used, the OID is:
id-dsa-with-sha224 OBJECT IDENTIFIER  ::=  { joint-iso-ccitt(2) 
country(16)
us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 
1
}.
When SHA-256 is used, the OID is:
id-dsa-with-sha256 OBJECT IDENTIFIER  ::=  { joint-iso-citt(2) country(16)
us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 
2
}.
When the id-dsa-with-sha224 or id-dsa-with-sha256 algorithm identifier
appears in the algorithm field as an AlgorithmIdentifier, the encoding 
SHALL
omit the parameters field. That is, the AlgorithmIdentifier SHALL be a
SEQUENCE of one component, the OID id-dsa-with-sha224 or 
id-dsa-with-sha256.

Encoding rules for DSA signature values are specified in [RFC 3279]. 
***
Conforming CA implementations that generate DSA signatures for 
certificates
or CRLs MUST generate such DSA signature in accordance with all the
requirements in [FIPS 186-3].  Similarly, such DSA signatures SHOULD also 
be
generated in accordance with all the recommendations in [FIPS 186-3].
***
3.2                   ECDSA Signature Algorithm
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in,
"Public Key Cryptography for the Financial Services Industry: The Elliptic
Curve Digital Signature Standard (ECDSA)" [X9.62]. The ASN.1 OIDs used to
specify that an ECDSA signature was generated using SHA-224, SHA-256,
SHA-384 or SHA-512 are respectively: 

ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 }
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or
ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as 
an
AlgorithmIdentifier, the encoding MUST omit the parameters field. That is,
the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID
ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or
ecdsa-with-SHA512. 
Conforming CA implementations MUST specify the hash algorithm explicitly,
using the OIDs specified above, when encoding ECDSA/SHA2 signatures in
certificates and CRLs.
Conforming client implementations that process ECDSA signatures with any 
of
the SHA2 hash algorithms when processing certificates and CRLs MUST
recognize the corresponding OIDs specified above. 
Encoding rules for ECDSA signature values are specified in [RFC 3279].
***
Conforming CA implementations that generate ECDSA signatures in 
certificates
or CRLs MUST generate such ECDSA signatures in accordance with all the
requirements specified in [X9.62].  Similarly, such ECDSA signatures 
SHOULD
be generated in accordance with all the recommendations in [X9.62].
***

4.    ASN.1 Module 

...

5.    Security Considerations

NIST has defined appropriate use of the hash functions in terms of the
algorithm strengths and expected time frames for secure use in Special
Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP 800-57] and 800-107
[SP 800-107]. These documents can be used as guides to choose appropriate
key sizes for various security scenarios.

***
ANSI also provides security considerations for ECDSA in [X9.62]. These
security considerations may be used as a guide.
*** 

6.    References

...

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, May 28, 2009 4:38 PM
To: Daniel Brown; [email-masked]
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

At 1:59 PM -0400 5/28/09, Daniel Brown wrote:
>Paul,
>
>Regarding your comment 3) below about validation requirements, I suggest
that this RFC 3279 update mandate SHA2 as a "SHOULD" (rather than a MUST 
as
it is in the WGLC draft). 
>
>Not making it a MUST avoids making existing implementations 
non-conformant.
Making it a SHOULD alerts implementers to the security issues and to the
NIST compliance/interoperability issues.

Please be more specific. What exact wording are you proposing? If you were
simply going to replace "MUST" with "SHOULD" in the last paragraph of
section 3, how would an implementer know when it is OK not to follow the
mandate?

As you can tell, this whole train of thought still bothers me. It is fine
for us to list the issues and to make recommendations about them; that is
quite different than invoking RFC 2119 language, particularly in a vague
fashion.

>Regarding your comment 2) below about key sizes and lifetimes, I suggest
this RFC 3279 update make the associated NIST recommendations a SHOULD.
Again, this is for security reasons and better NIST
compliance/interoperability issues. 

And I fully disagree for the same reasons. NIST makes it clear that their
recommendations are for one particular market, not the entire world. If we
want to make them world-wide, then we should help NIST come up with more
consistent and readable recommendations that match the new mandate; so 
far,
NIST has not asked for that type of help, and I would not expect them to 
do
so in the future.

>Generally, the DSA/ECDSA and SHA-1/2 algorithms come from NIST and ANSI,
and have some normative security requirements about key sizes.  Completely
dropping some of the normative security requirements should require strong
justification.

The IETF attempts to create standards that implementers can understand.
Mandating the NIST logic, which conflates different sizes and strengths 
for
reasons that make sense for NIST but not for us, does not lead to such
standards.

Again, it is a good idea to point to the NIST documents as guidance for
implementers. If there were competing documents with different guidance,
pointing to them would be good as well (I'm not aware of any such 
competing
documents). That's quite different than mandating compliance with the NIST
specs that were written for different purposes than we have.

I would still like comment on my greatly-shortened version of this 
document,
as well as on the other concerns expressed on this thread.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 17 Jun 2009 09:21:17 +0100
From: John Larmouth <[email-masked]>
Reply-To:  [email-masked]
To: Tom Gindin <[email-masked]>
CC: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
Sender: [email-masked]

Tom,

I am not sure what draft you are referring to, but we spent a lot of time at the 
last Tokyo meeting to ensure that an additional Unicode label could be added to 
a high-level arc without requiring any changes to zone files for nodes beneath 
the affected node.  This is acheivable by use of a combination of CNAME and 
DNAME records in the DNS.  Use of those records for this purpose will be fully 
described either in the main Standard or as an Implementors Guide.

What you are missing is "long arcs".  A long arc can go from the root to any 
lower-level node.  It does not have a number, only one or more Unicode labels 
(unambiguous among all arcs from the root - long or normal).  It "expands" into 
a sequence of normal arcs to the same node, identified in canonical (numerical) 
form.

So as far as the DNS is concerned, there are arcs from the root in addition to 
the three you are talking about, and the root zone files point directly to the 
servers associated with those lower level nodes (assuming the administrations of 
those nodes choose to run a DNS server, otherwise you just get information about 
children).

The ORS work is not yet complete, and there are some dangling threads, in 
particular xase-folded matching and the use of %encoding or punycode for 
non-Ascii characters, and the handling of case sensitivity for Ascii characters. 
  This will likely be resolved at the Geneva September meeting.

The second Internet Draft for the requested IRI "oid:" scheme will be produced 
as soon as these remaining issues in the ORS (OID Resolution System) are sorted.

John L

Tom Gindin wrote:
>         John:
> 
>         This draft is interesting and useful for some purposes, but I 
> don't see how it addresses the case where a high-level arc (beyond the 
> control of the development organization) is renamed.  Since that's 
> precisely the case we are discussing here (although the change took place 
> quite a while ago and it's reasonable to expect people to adjust), it 
> doesn't actually seem to help us.  Am I missing something?
>         Also, unless I have missed something, there are only three 
> top-level arcs defined for OID's and they all now have names.
> 
>                 Tom Gindin
> 
> 
> 
> 
> John Larmouth <[email-masked]> 
> Sent by: [email-masked]
> 12/22/2008 10:48 AM
> Please respond to
> [email-masked]
> 
> 
> To
> Alfred ï¿½ <[email-masked]>
> cc
> [email-masked], [email-masked], [email-masked]
> Subject
> Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
> 
> 
> 
> 
> 
> 
> Alfred,
> 
> The synonyms were introduced some time ago, and, indeed, the names are 
> non-normative, and may not even be unambiguous.  Only the numbers matter 
> in an OID in an encoding.
> 
> However, the recent introduction of Unicode labels, as normative and 
> unambigous names gives a new naming scheme to the (same) OID tree that 
> enables names (Unicode labels) to be used in machine communication if 
> desired.  The ASN.1 type is called OID_IRI and provides for node 
> identification using Unicode labels.  Unicode labels with names similar to 
> the old ASCII names have been assigned for many of the top-level arcs, and 
> more will be added over time.
> 
> The OID_IRI type  is related to (but not dependent on) the application for 
> an "oid" IRI scheme,  but for consistency this is desired.  See I-D 
> draft-larmouth-oid-iri-00.
> 
> John L
> 
> Alfred ï¿½ wrote: 
> Folks / to whom it concerns,
> 
> during recent reviews of active I-Ds containing ASN.1 related
> to the X.500 framework, I found that a couple of these do not
> consistently employ the revised name of the top-level OID branch
> 
>     joint-iso-itu-t(2) ,
> 
> but instead use the outdated/legacy name
> 
>     joint-iso-ccitt(2) .
> 
> Some drafts use a mix of both names.
> 
> I suggest that the modern version  joint-iso-itu-t(2)  be used
> consistently within all new drafts / draft versions, unless
> intentionally and explicitely for historical evidence reference
> has to be made to the old name.
> 
> Kind regards,
>   Alfred.
> 
>  
> 

-- 
    Prof John Larmouth
    Larmouth T&PDS Ltd
    (Training and Protocol Design Services Ltd)
    1 Blueberry Road
    Bowdon                               [email-masked]
    Altrincham
    Cheshire
    WA14 3LS
    England
    Tel: +44 161 928 1605

Date: Tue, 16 Jun 2009 14:57:34 -0700
To: Daniel Brown <[email-masked]>, Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Sender: [email-masked]

At 4:19 PM -0400 6/16/09, Daniel Brown wrote:
>For ideal interoperability and security, this draft should be as a
>well-defined as possible.  In particular, it could specify what is meant by
>DSA, SHA-2, etc., which can be done by normative reference to other
>specifications, such as ANSI/NIST documents.

Fully agree.

>  (Perhaps, past PKIX practice
>has been to cite a crypto algorithm by informative reference, but wouldn't
>it be better to use a normative reference?)

There is no practical difference unless someone eventually tries to move this forwards on the standards ladder, which basically never happens.

>This draft can explicitly exempt any requirements in the normative
>references that PKIX deems unsuitable, or only require certain parts of the
>normative references, whichever is clearer.  Please suggest a solution along
>these lines if you have one.

FIPS 186-3 has literally dozens of requirements. It is inappropriate to have to list all of the ones we do not want. For example, this list could debate forever about how needed things such as those in section 4.3.2 are. There are, again, literally dozens of similar examples.

>If these approaches are too impractical, I suggest a compromise: apply a
>blanket SHOULD to all the requirements (not recommendations) in the
>corresponding NIST/ANSI documents either with a few explicit exceptions for
>the requirements PKIX deems unsuitable - I again ask for a suggested list of
>exceptions - or with a blanket exemption MAY with reasons similar to the
>reason above for continuing to use SHA-1.

<sigh> As discussed earlier, every SHOULD without an explicit explanation of when an implementer can ignore leads to lack of interop or, in many cases worse, lack of security.

If you cannot do the work of picking which of the requirements of FIPS 186-3 and X9.62 you actually want to be mandatory in the IETF sense, it would be better to simply make this an Informational RFC.

--Paul Hoffman, Director
--VPN Consortium

From: Daniel Brown <[email-masked]>
To: Stefan Santesson <[email-masked]>, Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 16 Jun 2009 16:19:46 -0400
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

------=_NextPart_000_00A1_01C9EE9E.43D5AC50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> Conforming CA implementations SHOULD
> use SHA-224, SHA-256, SHA-384 or SHA-512 when generating certificates, but
MAY
> use SHA-1 if they have a stated policy that requires the use of this
weaker
> algorithm.

Great.

For ideal interoperability and security, this draft should be as a
well-defined as possible.  In particular, it could specify what is meant by
DSA, SHA-2, etc., which can be done by normative reference to other
specifications, such as ANSI/NIST documents.  (Perhaps, past PKIX practice
has been to cite a crypto algorithm by informative reference, but wouldn't
it be better to use a normative reference?)

This draft can explicitly exempt any requirements in the normative
references that PKIX deems unsuitable, or only require certain parts of the
normative references, whichever is clearer.  Please suggest a solution along
these lines if you have one.

If these approaches are too impractical, I suggest a compromise: apply a
blanket SHOULD to all the requirements (not recommendations) in the
corresponding NIST/ANSI documents either with a few explicit exceptions for
the requirements PKIX deems unsuitable - I again ask for a suggested list of
exceptions - or with a blanket exemption MAY with reasons similar to the
reason above for continuing to use SHA-1.

Best regards,

	Dan

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 1:27 PM
To: Paul Hoffman; Daniel Brown; [email-masked]
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

In general I agree with Paul here. Regardless of what we define, it should
be said in a way that is clear and unambiguous. We should also be clear
about what requirements we state. A simple open reference to all
requirements of another standard is not a good way to specify IETF
requirements. 

I personally dislike standards stating requirements on algorithm support for
any reason other than to increase interoperability. The choices of adequate
and secure algorithms is a constantly moving target and is ideally better
stated in BCP documents if the rationale is purely security driven.

We have to remember that our protocols may be used under vastly different
security policies. Without knowing them, it is almost impossible to define
what is appropriate, unless when something is completely broken.

/Stefan

On 09-06-15 9:28 PM, "Paul Hoffman" <[email-masked]> wrote:

> 
> At 11:35 AM -0400 6/12/09, Daniel Brown wrote:
>> ***
>> Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or
>> SHA-512 when generating certificates, but MAY use SHA-1.
>> ***
> 
> I strongly dislike SHOULDs that don't come with reasons: how is an
implementer
> supposed to know what to do? How about: Conforming CA implementations
SHOULD
> use SHA-224, SHA-256, SHA-384 or SHA-512 when generating certificates, but
MAY
> use SHA-1 if they have a stated policy that requires the use of this
weaker
> algorithm.
> 
> 
>> ***
>> Conforming CA implementations that generate DSA signatures for
certificates
>> or CRLs MUST generate such DSA signature in accordance with all the
>> requirements in [FIPS 186-3].  Similarly, such DSA signatures SHOULD also
be
>> generated in accordance with all the recommendations in [FIPS 186-3].
>> ***
> 
> Here you are  saying "in order to conform with this RFC under the IETF
> standard track rules, you must conform to that FIPS document under NIST's
> rules." Of course, you do not list all the requirements from FIPS 186-3
that
> you mean. For example, some of those rules in fact don't live in FIPS
186-3,
> but instead in NIST SP 800-89, and others live in other documents, some of
> which are now under revision.
> 
> This kind of requirement is fine for a NIST document because NIST can make
> their own rules and enforce them as they see fit. This kind of requirement
is
> also fine for an Informational RFC, but is completely inappropriate for a
> standards-track RFC. The requirement should be removed, or the intended
status
> of this document should be Informational RFC. I would prefer the former,
but
> others may prefer the latter.
> 
>> ***
>> Conforming CA implementations that generate ECDSA signatures in
certificates
>> or CRLs MUST generate such ECDSA signatures in accordance with all the
>> requirements specified in [X9.62].  Similarly, such ECDSA signatures
SHOULD
>> be generated in accordance with all the recommendations in [X9.62].
>> ***
> 
> Ditto, except that now it's s/NIST/ANSI/.
> 
>> 5.    Security Considerations
>> 
>> NIST has defined appropriate use of the hash functions in terms of the
>> algorithm strengths and expected time frames for secure use in Special
>> Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP 800-57] and 800-107
>> [SP 800-107]. These documents can be used as guides to choose appropriate
>> key sizes for various security scenarios.
>> 
>> ***
>> ANSI also provides security considerations for ECDSA in [X9.62]. These
>> security considerations may be used as a guide.
>> ***   
> 
> This is very good wording for the security considerations.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 

------=_NextPart_000_00A1_01C9EE9E.43D5AC50
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_00A1_01C9EE9E.43D5AC50--

Date: Tue, 16 Jun 2009 21:43:56 +0200
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
From: Stefan Santesson <[email-masked]>
To: Michael StJohns <[email-masked]>, Paul Hoffman <[email-masked]>, Daniel Brown <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Mike,

I agree and I think we are saying the same thing in slightly different ways.

What I said before your cut was:

 "I personally dislike standards stating requirements on algorithm support
for any reason other than to increase interoperability."

The key is that we list algorithms in standards more to support
interoperability than to state what security level that is adequate for
certain usages of a protocol.

/Stefan

On 09-06-16 8:04 PM, "Michael StJohns" <[email-masked]> wrote:

> 
> Yes and no.
> 
> The policy for the IETF has always been to specify a minimum set of
> interoperable algorithms as MUSTs and those generally get specified in the
> standard or amendments to the standard.  Over time, we recognize that older
> algorithms no longer meet the minimum security needs and they should first be
> deprecated and then obsoleted.
> 
> BCPs are not standards documents per se - they are not generally controlling
> on the implementors, but are targeted for the operators/users who may be quite
> removed from the implementors.  As such, BCPs may not be (IMHO are not) the
> right place for specifying the minimums for algorithm support.
> 
> So - mostly no.
> 
> Mike
> 
> 
> At 01:26 PM 6/16/2009, Stefan Santesson wrote:
>> The choices of adequate
>> and secure algorithms is a constantly moving target and is ideally better
>> stated in BCP documents if the rationale is purely security driven.
> 
> 

Date: Tue, 16 Jun 2009 14:04:22 -0400
To: Stefan Santesson <[email-masked]>, Paul Hoffman <[email-masked]>, Daniel Brown <[email-masked]>, "[email-masked]" <[email-masked]>
From: Michael StJohns <[email-masked]>
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Sender: [email-masked]

Yes and no.

The policy for the IETF has always been to specify a minimum set of interoperable algorithms as MUSTs and those generally get specified in the standard or amendments to the standard.  Over time, we recognize that older algorithms no longer meet the minimum security needs and they should first be deprecated and then obsoleted.  

BCPs are not standards documents per se - they are not generally controlling on the implementors, but are targeted for the operators/users who may be quite removed from the implementors.  As such, BCPs may not be (IMHO are not) the right place for specifying the minimums for algorithm support.

So - mostly no.

Mike

At 01:26 PM 6/16/2009, Stefan Santesson wrote:
>The choices of adequate
>and secure algorithms is a constantly moving target and is ideally better
>stated in BCP documents if the rationale is purely security driven.

Date: Tue, 16 Jun 2009 19:26:59 +0200
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, Daniel Brown <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

In general I agree with Paul here. Regardless of what we define, it should
be said in a way that is clear and unambiguous. We should also be clear
about what requirements we state. A simple open reference to all
requirements of another standard is not a good way to specify IETF
requirements. 

I personally dislike standards stating requirements on algorithm support for
any reason other than to increase interoperability. The choices of adequate
and secure algorithms is a constantly moving target and is ideally better
stated in BCP documents if the rationale is purely security driven.

We have to remember that our protocols may be used under vastly different
security policies. Without knowing them, it is almost impossible to define
what is appropriate, unless when something is completely broken.

/Stefan

On 09-06-15 9:28 PM, "Paul Hoffman" <[email-masked]> wrote:

> 
> At 11:35 AM -0400 6/12/09, Daniel Brown wrote:
>> ***
>> Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or
>> SHA-512 when generating certificates, but MAY use SHA-1.
>> ***
> 
> I strongly dislike SHOULDs that don't come with reasons: how is an implementer
> supposed to know what to do? How about: Conforming CA implementations SHOULD
> use SHA-224, SHA-256, SHA-384 or SHA-512 when generating certificates, but MAY
> use SHA-1 if they have a stated policy that requires the use of this weaker
> algorithm.
> 
> 
>> ***
>> Conforming CA implementations that generate DSA signatures for certificates
>> or CRLs MUST generate such DSA signature in accordance with all the
>> requirements in [FIPS 186-3].  Similarly, such DSA signatures SHOULD also be
>> generated in accordance with all the recommendations in [FIPS 186-3].
>> ***
> 
> Here you are  saying "in order to conform with this RFC under the IETF
> standard track rules, you must conform to that FIPS document under NIST's
> rules." Of course, you do not list all the requirements from FIPS 186-3 that
> you mean. For example, some of those rules in fact don't live in FIPS 186-3,
> but instead in NIST SP 800-89, and others live in other documents, some of
> which are now under revision.
> 
> This kind of requirement is fine for a NIST document because NIST can make
> their own rules and enforce them as they see fit. This kind of requirement is
> also fine for an Informational RFC, but is completely inappropriate for a
> standards-track RFC. The requirement should be removed, or the intended status
> of this document should be Informational RFC. I would prefer the former, but
> others may prefer the latter.
> 
>> ***
>> Conforming CA implementations that generate ECDSA signatures in certificates
>> or CRLs MUST generate such ECDSA signatures in accordance with all the
>> requirements specified in [X9.62].  Similarly, such ECDSA signatures SHOULD
>> be generated in accordance with all the recommendations in [X9.62].
>> ***
> 
> Ditto, except that now it's s/NIST/ANSI/.
> 
>> 5.    Security Considerations
>> 
>> NIST has defined appropriate use of the hash functions in terms of the
>> algorithm strengths and expected time frames for secure use in Special
>> Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP 800-57] and 800-107
>> [SP 800-107]. These documents can be used as guides to choose appropriate
>> key sizes for various security scenarios.
>> 
>> ***
>> ANSI also provides security considerations for ECDSA in [X9.62]. These
>> security considerations may be used as a guide.
>> ***   
> 
> This is very good wording for the security considerations.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-pkix-tac (Traceable Anonymous Certificate)  to Experimental RFC 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Tue, 16 Jun 2009 06:45:00 -0700 (PDT)
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure 
(X.509) WG (pkix) to consider the following document:

- 'Traceable Anonymous Certificate '
   <draft-ietf-pkix-tac-04.txt> as an Experimental 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-06-30. 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-ietf-pkix-tac-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17335&rfc_flag=0

Date: Mon, 15 Jun 2009 12:28:11 -0700
To: Daniel Brown <[email-masked]>, "[email-masked]"	<[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Sender: [email-masked]

At 11:35 AM -0400 6/12/09, Daniel Brown wrote:
>***
>Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or
>SHA-512 when generating certificates, but MAY use SHA-1.
>***

I strongly dislike SHOULDs that don't come with reasons: how is an implementer supposed to know what to do? How about: Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or SHA-512 when generating certificates, but MAY use SHA-1 if they have a stated policy that requires the use of this weaker algorithm.

>***
>Conforming CA implementations that generate DSA signatures for certificates
>or CRLs MUST generate such DSA signature in accordance with all the
>requirements in [FIPS 186-3].  Similarly, such DSA signatures SHOULD also be
>generated in accordance with all the recommendations in [FIPS 186-3].
>***

Here you are  saying "in order to conform with this RFC under the IETF standard track rules, you must conform to that FIPS document under NIST's rules." Of course, you do not list all the requirements from FIPS 186-3 that you mean. For example, some of those rules in fact don't live in FIPS 186-3, but instead in NIST SP 800-89, and others live in other documents, some of which are now under revision.

This kind of requirement is fine for a NIST document because NIST can make their own rules and enforce them as they see fit. This kind of requirement is also fine for an Informational RFC, but is completely inappropriate for a standards-track RFC. The requirement should be removed, or the intended status of this document should be Informational RFC. I would prefer the former, but others may prefer the latter.

>***
>Conforming CA implementations that generate ECDSA signatures in certificates
>or CRLs MUST generate such ECDSA signatures in accordance with all the
>requirements specified in [X9.62].  Similarly, such ECDSA signatures SHOULD
>be generated in accordance with all the recommendations in [X9.62].
>***

Ditto, except that now it's s/NIST/ANSI/.

>5.    Security Considerations
>
>NIST has defined appropriate use of the hash functions in terms of the
>algorithm strengths and expected time frames for secure use in Special
>Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP 800-57] and 800-107
>[SP 800-107]. These documents can be used as guides to choose appropriate
>key sizes for various security scenarios.
>
>***
>ANSI also provides security considerations for ECDSA in [X9.62]. These
>security considerations may be used as a guide.
>***   

This is very good wording for the security considerations.

--Paul Hoffman, Director
--VPN Consortium

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RSA Signature Padding
Cc: [email-masked], [email-masked]
Date: Sun, 14 Jun 2009 01:16:45 +1200
Sender: [email-masked]

Stefan Santesson <[email-masked]> writes:

>The way I read this is that 1.5 is handcrafted to mitigate known attacks
>while PSS use a more generic and provable secure approach. But neither of
>them are broken.
>
>Would that be a correct assessment?

Yes.  So 1.5 makes some cryptographers uneasy because it's not as rigorous as
PSS, but (barring buggy implementations, which affects PSS as much as 1.5)
there's currently no known attack against it that makes 1.5 worse than PSS.
9796-2, on the other hand, is a long series of patches to fix up weaknesses,
and there's no sign it's getting much better over time.

Peter.

Date: Sat, 13 Jun 2009 14:42:38 +0200
Subject: Re: RSA Signature Padding
From: Stefan Santesson <[email-masked]>
To: Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>
CC: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The way I read this is that 1.5 is handcrafted to mitigate known attacks
while PSS use a more generic and provable secure approach. But neither of
them are broken.

Would that be a correct assessment?

/Stefan

On 09-06-13 2:10 PM, "Peter Gutmann" <[email-masked]> wrote:

> 
> "Santosh Chokhani" <[email-masked]> writes:
> 
>> There is benefit to PSS over 1.5.  The paper points that out.
> 
> There is a purely theoretical benefit, but weighed against the *massive*
> practical downside of going to PSS I doubt it'll carry much weight...
> 
> Peter.
> 

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: RSA Signature Padding
Cc: [email-masked], [email-masked]
Date: Sun, 14 Jun 2009 00:10:22 +1200
Sender: [email-masked]

"Santosh Chokhani" <[email-masked]> writes:

>There is benefit to PSS over 1.5.  The paper points that out.

There is a purely theoretical benefit, but weighed against the *massive*
practical downside of going to PSS I doubt it'll carry much weight...

Peter.

Content-class: urn:content-classes:message
Subject: RE: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate and Certificate Revocation List (CRL) Profile) to Informational RFC
Date: Fri, 12 Jun 2009 16:07:40 -0400
From: "Zieglar, Lydia L." <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Solinas, Jerry" <[email-masked]>, "Rob Stradling" <[email-masked]>
Sender: [email-masked]

Here's the text from the response I just sent to Rob:

Sorry for the delayed response. Some of your questions I had to forward
to other parties here at NSA for an answer.=20

1) Regarding OCSP, OCSP has been identified as a topic we need to
address for Suite B. The question is whether we want to add something
quickly to the Suite B Certificate Profile, or wait to do a more
thorough treatment. I'll let you know what is decided.

2) We had this information in the .01 version of the Suite B Certificate
Profile, but decided to remove   it because such a list would be
incomplete. We have additional Suite B protocol specific RFCs under
development. Future Suite B protocol specific RFCs will most likely
contain a reference to the certificate profile, but those that are
already published don't simply because they were published before the
certificate profile was completed. =20

3) Regarding the IPR issues. Apparently, we've been inconsistent in how
we have handled this in our Suite B RFCs. I'm waiting for word on what
to do for the certificate profile. I suspect a statement will be added.

4) Regarding NSA's omission of P-521, P-256 and P-384 will satisfy all
of the U.S. Government's requirements so only these are included in
Suite B. We don't have a requirement that warrants the inclusion of
P-521.

5) I am not aware of any documents that cover Suite B for Code Signing
certificates or Time Stamping certificates or plans to develop such
documents.=20

Please do not hesitate to send me any additional questions you may have.

Thanks,
Lydia

=20

Lydia Zieglar
301-688-1028
[email-masked]

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]]=20
Sent: Tuesday, June 09, 2009 4:48 AM
To: [email-masked]; Zieglar, Lydia L.; Solinas, Jerry
Cc: [email-masked]
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=20
> >consider the following document:
> >
> >- 'Suite B Certificate and Certificate Revocation List (CRL) Profile
'
> >    <draft-solinas-suiteb-cert-profile-03.txt> as an Informational=20
> >RFC
<snip>

Since this I-D is now in Last Call, I'm forwarding a message I sent to
Lydia recently, to which I've not yet received any response...

----------  Forwarded Message  ----------

Subject: Re: NSA Suite B Certificate & CRL Profile
Date: Wednesday 03 June 2009
From: Rob Stradling <[email-masked]>
To: [email-masked]

Comodo are a global CA with Trusted Root Certificates present in all the
major browsers/OSes.  We are interested in your Suite B Certificate &
CRL Profile I-D because we're seriously looking at offering ECC
certificates to our customers in the near future.  We have already added
a P-384 Root Certificate to the Microsoft and Mozilla Root Certificate
Programs.

I have some questions/comments on your I-D and some other related
matters...

1. Why does your I-D not include a profile for OCSP requests/responses?
Perhaps you could add a section that references RFC 2560 and states that
OCSP request/response signatures should follow the same rules as
signatures for Suite B certificates?

2. What's the relationship between your I-D and the various Suite B
RFCs, such as RFC 5430 "Suite B Profile for Transport Layer Security
(TLS)"?
Would it make sense for your I-D to reference any of the Suite B RFCs
and/or for them to reference your I-D?

3. Some RFCs list IPR claims and/or advise the reader to consult
http://www.ietf.org/ipr.  Would it make sense to mention any IPR issues
in your I-D?  I am of course thinking about the large number of ECC
patents held by Certicom/RIM.

4. Why did the NSA include P-256 and P-384 in Suite B, but omit P-521?
I believe that Certicom defined P-521 before Suite B was specified, and
Microsoft and Mozilla have both chosen to support P-521 as well as P-256
and P-384.

5. RFC 5280 defines various standard Extended Key Usage OIDs.  I've seen
various documents that profile Suite B for Server Authentication
certificates, Client Authentication certificates and Secure Email
certificates, but I'm not aware of any documents that cover Suite B for
Code Signing certificates or Time Stamping certificates.
Are you aware of any such documents?
If not, do you know why no such documents exist?

Thanks in advance.

--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690 Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error please notify the sender by
replying to the e-mail containing this attachment. Replies to this email
may be monitored by Comodo for operational or business reasons. Whilst
every endeavour is taken to ensure that e-mails are free from viruses,
no liability can be accepted and the recipient is requested to use their
own virus checking software.

From: Daniel Brown <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 12 Jun 2009 11:35:40 -0400
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

------=_NextPart_000_00EB_01C9EB51.E98CB1C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Paul,

I propose the following text (sorry for the poor formatting).  A few
non-at-issue parts are left out, marked as "...".  I based the text on text
Quynh Dang prepared that was based on your shortened text.  I added some
SHOULDs and MUSTs based on my previous emails, and have below highlighted
these additions with *** above and below, as these are probably the
most-at-issue parts.

Best regards,

	Dan

...

Abstract
This document updates RFC 3279 [RFC 3279] to specify algorithm identifiers
and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and
Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when
using SHA-224, SHA-256, SHA-384 or SHA-512 as hashing algorithm. This
specification applies to the Internet X.509 Public Key infrastructure (PKI)
when digital signatures are used to sign certificates and certificate
revocation lists(CRLs).

1.	   Introduction
This specification defines the contents of the signatureAlgorithm,
signatureValue and signature fields within Internet X.509 certificates and
CRLs when these objects are signed using DSA or ECDSA with a SHA2 hash
algorithm. These fields are more fully described in RFC 5280 [RFC 5280].
This document profiles material presented in the "Secure Hash Standard"
[FIPS 180-3], "Public Key Cryptography for the Financial Services Industry:
The Elliptic Curve Digital Signature Standard (ECDSA)"[X9.62], and the
"Digital Signature Standard"[FIPS 186-3].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
 
2.    One-way Hash Functions
This section identifies four additional hash algorithms for use with DSA and
ECDSA in the Internet X.509 certificate and CRL profile [RFC 5280]. SHA-224,
SHA-256, SHA-384, and SHA-512 produce a 224-bit, 256-bit, 384-bit and
512-bit "hash" of the input respectively and are fully described in the
Federal Information Processing Standard 180-3 [FIPS 180-3].
The listed one-way hash functions are identified by the following object
identifiers (OIDs): 
id-sha224  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 }
id-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 }
id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 }
id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 }
When one of these OIDs appears in an AlgorithmIdentifier, all
implementations MUST accept both NULL and absent parameters as legal and
equivalent encodings.
***
Conforming CA implementations SHOULD use SHA-224, SHA-256, SHA-384 or
SHA-512 when generating certificates, but MAY use SHA-1.
***
3.    Signature Algorithms
This section identifies OIDs for DSA and ECDSA with SHA-224, SHA-256,
SHA-384, and SHA-512. The contents of the parameters    component for each
signature algorithm vary; details are provided for each algorithm.   
3.1	     DSA Signature Algorithm
The DSA is defined in the Digital Signature Standard (DSS) [FIPS 186-3]. DSA
was developed by the U.S. Government, and can be used in conjunction with a
SHA2 one-way hash function such as SHA-224 or SHA-256. DSA is fully
described in [FIPS 186-3].
   
When SHA-224 is used, the OID is:
id-dsa-with-sha224 OBJECT IDENTIFIER  ::=  { joint-iso-ccitt(2) country(16)
us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 1
}.
When SHA-256 is used, the OID is:
id-dsa-with-sha256 OBJECT IDENTIFIER  ::=  { joint-iso-citt(2)   country(16)
us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 2
}.
When the id-dsa-with-sha224 or id-dsa-with-sha256 algorithm identifier
appears in the algorithm field as an AlgorithmIdentifier, the encoding SHALL
omit the parameters field. That is, the AlgorithmIdentifier SHALL be a
SEQUENCE of one component, the OID id-dsa-with-sha224 or id-dsa-with-sha256.

Encoding rules for DSA signature values are specified in [RFC 3279]. 
***
Conforming CA implementations that generate DSA signatures for certificates
or CRLs MUST generate such DSA signature in accordance with all the
requirements in [FIPS 186-3].  Similarly, such DSA signatures SHOULD also be
generated in accordance with all the recommendations in [FIPS 186-3].
***
3.2	     ECDSA Signature Algorithm
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in,
"Public Key Cryptography for the Financial Services Industry: The Elliptic
Curve Digital Signature Standard (ECDSA)" [X9.62]. The ASN.1 OIDs used to
specify that an ECDSA signature was generated using SHA-224, SHA-256,
SHA-384 or SHA-512 are respectively:   

ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 }
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or
ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as an
AlgorithmIdentifier, the encoding MUST omit the parameters field. That is,
the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID
ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or
ecdsa-with-SHA512.  
Conforming CA implementations MUST specify the hash algorithm explicitly,
using the OIDs specified above, when encoding ECDSA/SHA2 signatures in
certificates and CRLs.
Conforming client implementations that process ECDSA signatures with any of
the SHA2 hash algorithms when processing certificates and CRLs MUST
recognize the corresponding OIDs specified above. 
Encoding rules for ECDSA signature values are specified in [RFC 3279].
***
Conforming CA implementations that generate ECDSA signatures in certificates
or CRLs MUST generate such ECDSA signatures in accordance with all the
requirements specified in [X9.62].  Similarly, such ECDSA signatures SHOULD
be generated in accordance with all the recommendations in [X9.62].
***

4.    ASN.1 Module 

...

5.    Security Considerations

NIST has defined appropriate use of the hash functions in terms of the
algorithm strengths and expected time frames for secure use in Special
Publications (SPs) 800-78-1 [SP 800-78-1], 800-57 [SP 800-57] and 800-107
[SP 800-107]. These documents can be used as guides to choose appropriate
key sizes for various security scenarios.

***
ANSI also provides security considerations for ECDSA in [X9.62]. These
security considerations may be used as a guide.
***    

6.    References

...

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, May 28, 2009 4:38 PM
To: Daniel Brown; [email-masked]
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

At 1:59 PM -0400 5/28/09, Daniel Brown wrote:
>Paul,
>
>Regarding your comment 3) below about validation requirements, I suggest
that this RFC 3279 update mandate SHA2 as a "SHOULD" (rather than a MUST as
it is in the WGLC draft). 
>
>Not making it a MUST avoids making existing implementations non-conformant.
Making it a SHOULD alerts implementers to the security issues and to the
NIST compliance/interoperability issues.

Please be more specific. What exact wording are you proposing? If you were
simply going to replace "MUST" with "SHOULD" in the last paragraph of
section 3, how would an implementer know when it is OK not to follow the
mandate?

As you can tell, this whole train of thought still bothers me. It is fine
for us to list the issues and to make recommendations about them; that is
quite different than invoking RFC 2119 language, particularly in a vague
fashion.

>Regarding your comment 2) below about key sizes and lifetimes, I suggest
this RFC 3279 update make the associated NIST recommendations a SHOULD.
Again, this is for security reasons and better NIST
compliance/interoperability issues. 

And I fully disagree for the same reasons. NIST makes it clear that their
recommendations are for one particular market, not the entire world. If we
want to make them world-wide, then we should help NIST come up with more
consistent and readable recommendations that match the new mandate; so far,
NIST has not asked for that type of help, and I would not expect them to do
so in the future.

>Generally, the DSA/ECDSA and SHA-1/2 algorithms come from NIST and ANSI,
and have some normative security requirements about key sizes.  Completely
dropping some of the normative security requirements should require strong
justification.

The IETF attempts to create standards that implementers can understand.
Mandating the NIST logic, which conflates different sizes and strengths for
reasons that make sense for NIST but not for us, does not lead to such
standards.

Again, it is a good idea to point to the NIST documents as guidance for
implementers. If there were competing documents with different guidance,
pointing to them would be good as well (I'm not aware of any such competing
documents). That's quite different than mandating compliance with the NIST
specs that were written for different purposes than we have.

I would still like comment on my greatly-shortened version of this document,
as well as on the other concerns expressed on this thread.

--Paul Hoffman, Director
--VPN Consortium

------=_NextPart_000_00EB_01C9EB51.E98CB1C0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_00EB_01C9EB51.E98CB1C0--

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: RSA Signature Padding
Date: Fri, 12 Jun 2009 14:57:50 +1200
Sender: [email-masked]

"Santosh Chokhani" <[email-masked]> writes:

>Any how did that go?
>
>I suspect fell on deaf ears?

Well, if you mean "after careful analysis the conclusion was that it was, at
best, going to be a pointless gesture", then I guess, yes.  My summary was:

-- Snip --

No matter how cool/interesting/useful/mandated in standards a new design is,
it won't be used if it requires redeployment of all existing hardware and
software for little apparent gain.  Two illustrative examples of this are
X9.42 DH and OAEP with AES.

An Internet standard RFC required that implementors support X9.42 DH key
agreement, and provided RSA as an option (in IETF terms, "MUST X9.42, MAY
RSA").  However, no existing software supported X9.42, no CAs would issue
certificates for it, even if they did no-one wanted to renew all of their
certificates ($$$) for an algorithm that provided no advantages over RSA, and
no hardware (either crypto accelerators or smart cards) supported it (there
was some token support after a few years, although even now there are problems
being found with the X9.42 test vectors which indicate that no-one has really
looked at them).  As a result, even though the standard mandated use of X9.42,
everyone treated it as if it said "MUST RSA, SHOULD NOT X9.42", pretending to
do X9.42 while running business as usual with RSA.

OAEP is in a similar situation.  In order to get it usefully deployed, it
would be necessary to issue certificates that would only work with OAEP
otherwise everyone would just keep using them with PKCS #1 v1.5.  This would
have exactly the same effect as X9.42.

An attempt was made to force OAEP through by tying it to AES.  In other words,
in order to use AES you also had to use OAEP.  Apart from the list of issues
already mentioned with X9.42 above, this was also going to be deployed in an
area where it was necessary to use crypto hardware for performance reasons
(this area is almost always glossed over in crypto designs).  Most crypto
hardware does RSA in hardware and either leaves the symmetric crypto for
software to do (cheaper hardware) or leaves further key management to software
and provides hardware acceleration for bulk data encryption once all further
key processing has been performed (more expensive hardware).  In addition a
few rather specialised crypto engines do everything in hardware.

In all cases except the most primitive accelerators that consist of nothing
but a bignum engine, moving to OAEP would require replacing the crypto
hardware.  Crypto hardware boxes typically cost $10,000-$20,000 each, assuming
you can find one that supports OAEP.  A server farm needs a great many of
these $20,000 boxes.  Smaller devices like smart cards may only cost $10-$20
each, but then you've got 100,000 of them to replace.  Some devices can upload
new firmware, but will zeroise their keys when this occurs for security
reasons, requiring a complete redeployment from scratch of all keys and
certificates ($$$).

As a result, a vendor would have two options: Supply a non-compliant solution
that uses AES with PKCS #1 v1.5, or supply a compliant solution that uses AES
with OAEP and requires rebuilding the entire infrastructure (hardware,
software, and certificates) from the ground up.

The standards group abandoned the idea of tying OAEP to AES ("It's X9.42 all
over again").

-- Snip --

Peter.

Date: Thu, 11 Jun 2009 18:21:28 -0400
To: Jean-Marc Desperrier <[email-masked]>
From: Michael StJohns <[email-masked]>
Subject: Re: CRLNumber definition and MAX
Cc: Peter Sylvester <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

I responded to his first email which seemed to be talking about the serialNumber field - he's since clarified he's talking about path length

Basically, you should probably just look at the integer and if its bigger than fits in a local 32 bit INT treat it as if its an unlimited length path value.  if the issuer is confused enough to issue something ridiculous you shouldn't worry about treating it in a ridiculous manner.

I'm not sure it needs any additional text here as any value > about 20 is effectively infinite... :-) 

Mike

At 05:40 AM 6/11/2009, Jean-Marc Desperrier wrote:
>Michael StJohns wrote:
>>I think you're confusing the ASN1 definition of "long integers" with
>>the C language definition of a long int.
>>
>>4.1.2.2 constrains the serial number INTEGER
>>(CertificateSerialNumber) into the range [0..2^159] - NOT [0..2^31].
>
>Peter is not confusing the two, it's *implementations* that did it by allowing themselves to store a pathLen value inside a C language integer.
>
>This being said, it's a reasonable assumption for applications to think it makes no sense to allow a path length to go over 2^31 and to not even try to handle values larger than that in pathLen, BaseDistance or SkipCerts.
>
>I'd go so far as adding text to say something like application MUST handle a path length up to 20, CA MUST NOT generate a path length longer than 20, and MUST NOT insert a value larger than that in any of those three values. CRLNumber and CRLNumber would, of course, still be allowed to up to 20 octets in length.

Content-class: urn:content-classes:message
Subject: RE: RSA Signature Padding
Date: Thu, 11 Jun 2009 17:23:49 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "pgut001" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

You may be right about the implementers.

There is benefit to PSS over 1.5.  The paper points that out. =20

> -----Original Message-----
> From: pgut001 [mailto:[email-masked]]=20
> Sent: Thursday, June 11, 2009 6:37 AM
> To: Santosh Chokhani; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: RSA Signature Padding
>=20
> Simon Josefsson <[email-masked]> writes:
> >"Santosh Chokhani" <[email-masked]> writes:
> >> I am asking because of the paper in the link below.
> >>
> >> http://eprint.iacr.org/2009/203
> >
> >Interesting.  What does that mean for PKCS#1 v1.5?
>=20
> Nothing whatsoever.
>=20
> Rob Stradling <[email-masked]> writes:
>=20
> >Should implementors wait until support for RSA-PSS is sufficiently=20
> >widespread for their needs before migrating from=20
> PKCS#1.5/SHA-1 to PKCS#2.1/SHA-2?
>=20
> Yes.  I'd recommend waiting until January 2038, on the basis=20
> that (a) there may be support for it in implementations by=20
> then and (b) people will be so busy fixing another problem=20
> that'll crop up around then that they won't notice this=20
> particular change.
>=20
> Peter.
>=20

Content-class: urn:content-classes:message
Subject: RE: RSA Signature Padding
Date: Thu, 11 Jun 2009 17:20:37 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "pgut001" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Any how did that go?

I suspect fell on deaf ears?=20

> -----Original Message-----
> From: pgut001 [mailto:[email-masked]]=20
> Sent: Thursday, June 11, 2009 6:33 AM
> To: [email-masked]; Santosh Chokhani
> Subject: Re: RSA Signature Padding
>=20
> "Santosh Chokhani" <[email-masked]> writes:
>=20
> >Should we encourage vendors to use RSA PSS as we transition=20
> to SHA-256=20
> >given the weakness in PKCS 1.5 padding?
>=20
> [Click]
>=20
> [Revind about five years to the thread discussing "Should we=20
> encourage vendors  to use RSA OEAP as we transition to AES=20
> given the weakness in PKCS 1.5  padding"]
>=20
> [Play]
>=20
> Peter.
>=20

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RSA Signature Padding
Cc: [email-masked], [email-masked]
Date: Thu, 11 Jun 2009 22:36:45 +1200
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:
>"Santosh Chokhani" <[email-masked]> writes:
>> I am asking because of the paper in the link below.
>>
>> http://eprint.iacr.org/2009/203
>
>Interesting.  What does that mean for PKCS#1 v1.5?

Nothing whatsoever.

Rob Stradling <[email-masked]> writes:

>Should implementors wait until support for RSA-PSS is sufficiently widespread
>for their needs before migrating from PKCS#1.5/SHA-1 to PKCS#2.1/SHA-2?

Yes.  I'd recommend waiting until January 2038, on the basis that (a) there
may be support for it in implementations by then and (b) people will be so
busy fixing another problem that'll crop up around then that they won't notice
this particular change.

Peter.

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RSA Signature Padding
Date: Thu, 11 Jun 2009 22:32:55 +1200
Sender: [email-masked]

"Santosh Chokhani" <[email-masked]> writes:

>Should we encourage vendors to use RSA PSS as we transition to SHA-256 given
>the weakness in PKCS 1.5 padding?

[Click]

[Revind about five years to the thread discussing "Should we encourage vendors
 to use RSA OEAP as we transition to AES given the weakness in PKCS 1.5
 padding"]

[Play]

Peter.

Date: Thu, 11 Jun 2009 12:15:50 +0200
From: Peter Sylvester <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>
Cc: Michael StJohns <[email-masked]>, pkix <[email-masked]>
Subject: Re: CRLNumber definition and MAX
Sender: [email-masked]

> 
> I'd go so far as adding text to say something like application MUST 
> handle a path length up to 20, CA MUST NOT generate a path length longer 
> than 20, and MUST NOT insert a value larger than that in any of those 
> three values. CRLNumber and CRLNumber would, of course, still be allowed 
> to up to 20 octets in length.

To be sure: you are saying "20", not "20 octets"? I would agree with 20 or 4711.

A path length of an "long" with 2**31-1 seems more than sufficient to me.
Putting a pathlen=20 or more is in practice the same as leaving out the field.

How long does it take to validate such a path, not even talking about
storing several tera octets of certificates. :-)

/P

Date: Thu, 11 Jun 2009 11:40:28 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: Michael StJohns <[email-masked]>
CC: Peter Sylvester <[email-masked]>, pkix <[email-masked]>
Subject: Re: CRLNumber definition and MAX
Sender: [email-masked]

Michael StJohns wrote:
> I think you're confusing the ASN1 definition of "long integers" with
> the C language definition of a long int.
>
> 4.1.2.2 constrains the serial number INTEGER
> (CertificateSerialNumber) into the range [0..2^159] - NOT [0..2^31].

Peter is not confusing the two, it's *implementations* that did it by 
allowing themselves to store a pathLen value inside a C language integer.

This being said, it's a reasonable assumption for applications to think 
it makes no sense to allow a path length to go over 2^31 and to not even 
try to handle values larger than that in pathLen, BaseDistance or SkipCerts.

I'd go so far as adding text to say something like application MUST 
handle a path length up to 20, CA MUST NOT generate a path length longer 
than 20, and MUST NOT insert a value larger than that in any of those 
three values. CRLNumber and CRLNumber would, of course, still be allowed 
to up to 20 octets in length.

Date: Tue, 09 Jun 2009 11:05:00 -0400
To: Peter Sylvester <[email-masked]>, pkix <[email-masked]>
From: Michael StJohns <[email-masked]>
Subject: Re: CRLNumber definition and MAX
Sender: [email-masked]

Peter - 

I think you're confusing the ASN1 definition of "long integers" with the C language definition of a long int.

4.1.2.2 constrains the serial number INTEGER (CertificateSerialNumber) into the range [0..2^159] - NOT [0..2^31].

Mike

At 07:19 AM 6/9/2009, Peter Sylvester wrote:

>Hi,
>
>RFC 5280 contains the following definitions for a CRLNumber
>
>CRLNumber ::= INTEGER (0..MAX)
>
>I think that as an analogy with CertficateSerialNumber the
>constraint (0..MAX) should be removed, cf also appendix B:
>
>  "As noted in Section 4.1.2.2, serial numbers can be expected to
>   contain long integers.  Certificate users MUST be able to handle
>   serialNumber values up to 20 octets in length.  Conforming CAs MUST
>   NOT use serialNumber values longer than 20 octets.
>
>   As noted in Section 5.2.3, CRL numbers can be expected to contain
>   long integers.  CRL validators MUST be able to handle cRLNumber
>   values up to 20 octets in length.  Conforming CRL issuers MUST NOT
>   use cRLNumber values longer than 20 octets."
>
>
>The ASN.1 appendix (B) also ontains
>
>   "The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
>   constructs.  A valid ASN.1 sequence will have zero or more entries.
>   The SIZE (1..MAX) construct constrains the sequence to have at least
>   one entry.  MAX indicates that the upper bound is unspecified.
>   Implementations are free to choose an upper bound that suits their
>   environment."
>
>but nothing similar concerning INTEGER (0..MAX)
>
>Is there someone who sees an important problem if we would require
>that MAX MUST be smaller that 2**31 in order to be conformant
>to the profile.
>
>The construct occurs in 4 types, the three others being
>  pathLenConstraints
>  BaseDistance
>  SkipCerts
>I haven't checked other Extensions defined in X.509.
>
>Peter Sylvester
>
>

Date: Tue, 09 Jun 2009 16:35:19 +0200
From: Peter Sylvester <[email-masked]>
To: "Kemp, David P." <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: CRLNumber definition and MAX
Sender: [email-masked]

I hit the send button too early.

Kemp, David P. wrote:
> I'm not sure I understand the rationale for removing the constraint on
> serial numbers - why would you want to encourage (or at least permit)
> negative serial numbers?  The explanation for a SIZE(1..MAX) constraint
> on SET/SEQUENCE is helpful but is not particularly relevant to range
> constraints on INTEGER values.
> 
> Does anyone see a problem with continuing to restrict CRLNumber (and
> CertificateSerialNumber) to being non-negative?
> 
> I believe there would be a problem with restricting serial number range
> to 0..2^^31-1, since (if I recall correctly) some currently-issued
> certificates have 16 octet serial number values (0..2^^127-1).
> 

Thanks for the answer. To be sure I was not asking to
restrict serialNumbers or CRlNumbers. in fact, the definition
of CRLNumber is ok. I massed up with the definition of MAX.
It requires positive values and no limit for the maximum
value (in the syntax). Sorry for the diversion.

The definitions of pathLen in the basicConstraints
extension indicates INTEGER (0..MAX) i.e. no maximum.
It seems that many implementations do not treat this correctly.
e.g. for the two hex values 01FF00FF00 or FF00000000

The second is not ok, but some implementations indicate 0
(the last 4 octets), the first is ridiculously high but correct
and some implementations indicate failure as a negative number.
Others indicate invalid values in both cases.

Peter

Date: Tue, 09 Jun 2009 16:24:47 +0200
From: Peter Sylvester <[email-masked]>
To: "Kemp, David P." <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: CRLNumber definition and MAX
Sender: [email-masked]

Kemp, David P. wrote:
> I'm not sure I understand the rationale for removing the constraint on
> serial numbers - why would you want to encourage (or at least permit)
> negative serial numbers?  The explanation for a SIZE(1..MAX) constraint
> on SET/SEQUENCE is helpful but is not particularly relevant to range
> constraints on INTEGER values.
> 
> Does anyone see a problem with continuing to restrict CRLNumber (and
> CertificateSerialNumber) to being non-negative?
> 
> I believe there would be a problem with restricting serial number range
> to 0..2^^31-1, since (if I recall correctly) some currently-issued
> certificates have 16 octet serial number values (0..2^^127-1).
> 

Thanks for the answer. To be sure I was not asking to
restrict serialNumbers or CRlNumbers. in fact, the definition
of CRLNumber is ok. It requires positive values and no limit
for the maximum value (in the syntax).

Content-class: urn:content-classes:message
Subject: RE: CRLNumber definition and MAX
Date: Tue, 9 Jun 2009 08:26:03 -0400
From: "Kemp, David P." <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

I'm not sure I understand the rationale for removing the constraint on
serial numbers - why would you want to encourage (or at least permit)
negative serial numbers?  The explanation for a SIZE(1..MAX) constraint
on SET/SEQUENCE is helpful but is not particularly relevant to range
constraints on INTEGER values.

Does anyone see a problem with continuing to restrict CRLNumber (and
CertificateSerialNumber) to being non-negative?

I believe there would be a problem with restricting serial number range
to 0..2^^31-1, since (if I recall correctly) some currently-issued
certificates have 16 octet serial number values (0..2^^127-1).

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Sylvester
Sent: Tuesday, June 09, 2009 7:20 AM
To: pkix
Subject: CRLNumber definition and MAX

Hi,

RFC 5280 contains the following definitions for a CRLNumber

CRLNumber ::=3D INTEGER (0..MAX)

I think that as an analogy with CertficateSerialNumber the
constraint (0..MAX) should be removed, cf also appendix B:

   "As noted in Section 4.1.2.2, serial numbers can be expected to
    contain long integers.  Certificate users MUST be able to handle
    serialNumber values up to 20 octets in length.  Conforming CAs MUST
    NOT use serialNumber values longer than 20 octets.

    As noted in Section 5.2.3, CRL numbers can be expected to contain
    long integers.  CRL validators MUST be able to handle cRLNumber
    values up to 20 octets in length.  Conforming CRL issuers MUST NOT
    use cRLNumber values longer than 20 octets."

The ASN.1 appendix (B) also ontains

    "The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
    constructs.  A valid ASN.1 sequence will have zero or more entries.
    The SIZE (1..MAX) construct constrains the sequence to have at least
    one entry.  MAX indicates that the upper bound is unspecified.
    Implementations are free to choose an upper bound that suits their
    environment."

but nothing similar concerning INTEGER (0..MAX)

Is there someone who sees an important problem if we would require
that MAX MUST be smaller that 2**31 in order to be conformant
to the profile.

The construct occurs in 4 types, the three others being
   pathLenConstraints
   BaseDistance
   SkipCerts
I haven't checked other Extensions defined in X.509.

Peter Sylvester

Date: Tue, 09 Jun 2009 13:19:54 +0200
From: Peter Sylvester <[email-masked]>
To: pkix <[email-masked]>
Subject: CRLNumber definition and MAX
Sender: [email-masked]

Hi,

RFC 5280 contains the following definitions for a CRLNumber

CRLNumber ::= INTEGER (0..MAX)

I think that as an analogy with CertficateSerialNumber the
constraint (0..MAX) should be removed, cf also appendix B:

   "As noted in Section 4.1.2.2, serial numbers can be expected to
    contain long integers.  Certificate users MUST be able to handle
    serialNumber values up to 20 octets in length.  Conforming CAs MUST
    NOT use serialNumber values longer than 20 octets.

    As noted in Section 5.2.3, CRL numbers can be expected to contain
    long integers.  CRL validators MUST be able to handle cRLNumber
    values up to 20 octets in length.  Conforming CRL issuers MUST NOT
    use cRLNumber values longer than 20 octets."

The ASN.1 appendix (B) also ontains

    "The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
    constructs.  A valid ASN.1 sequence will have zero or more entries.
    The SIZE (1..MAX) construct constrains the sequence to have at least
    one entry.  MAX indicates that the upper bound is unspecified.
    Implementations are free to choose an upper bound that suits their
    environment."

but nothing similar concerning INTEGER (0..MAX)

Is there someone who sees an important problem if we would require
that MAX MUST be smaller that 2**31 in order to be conformant
to the profile.

The construct occurs in 4 types, the three others being
   pathLenConstraints
   BaseDistance
   SkipCerts
I haven't checked other Extensions defined in X.509.

Peter Sylvester

From: Rob Stradling <[email-masked]>
Organization: COMODO CA Limited
To: "IETF-pkix" <[email-masked]>
Subject: Re: RSA Signature Padding
Date: Tue, 9 Jun 2009 10:15:48 +0100
Cc: "Santosh Chokhani" <[email-masked]>
Sender: [email-masked]

On Wednesday 03 June 2009 17:58:45 Santosh Chokhani wrote:
> I do not know if this is the right forum.
>
> Should we encourage vendors to use RSA PSS as we transition to SHA-256
> given the weakness in PKCS 1.5 padding?

Some widely used crypto libraries support SHA-2 but don't (yet) support 
RSA-PSS.  For example:
  - Microsoft Windows CryptoAPI: XP SP 3 and above support SHA-2, but I 
believe that RSA-PSS is only supported in Server 2008 and above.
  - Mozilla NSS: SHA-2 has been supported for a number of years, but RSA-PSS 
has not yet been implemented:
https://bugzilla.mozilla.org/show_bug.cgi?id=158750
  - OpenSSL: SHA-2 has been supported for a number of years, but it looks like 
RSA-PSS is only partly implemented at the moment.  e.g. 
http://www.mail-archive.com/[email-masked]/msg25994.html

Should implementors wait until support for RSA-PSS is sufficiently widespread 
for their needs before migrating from PKCS#1.5/SHA-1 to PKCS#2.1/SHA-2?

Or would an earlier transition from PKCS#1.5/SHA-1 to PKCS#1.5/SHA-2 be wiser 
for cases where RSA-PSS may not be sufficiently supported for some time to 
come?

> Santosh Chokhani
> CygnaCom Solutions
>
> "Questioning conventional wisdom is key to innovation"

-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

From: Rob Stradling <[email-masked]>
Organization: COMODO CA Limited
To: [email-masked], Lydia Zieglar <[email-masked]>, Jim Solinas <[email-masked]>
Subject: Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate and Certificate Revocation List (CRL) Profile) to Informational RFC
Date: Tue, 9 Jun 2009 09:47:32 +0100
Cc: [email-masked]
Sender: [email-masked]

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
<snip>

Since this I-D is now in Last Call, I'm forwarding a message I sent to Lydia 
recently, to which I've not yet received any response...

----------  Forwarded Message  ----------

Subject: Re: NSA Suite B Certificate & CRL Profile
Date: Wednesday 03 June 2009
From: Rob Stradling <[email-masked]>
To: [email-masked]

Comodo are a global CA with Trusted Root Certificates present in all the major 
browsers/OSes.  We are interested in your Suite B Certificate & CRL Profile 
I-D because we're seriously looking at offering ECC certificates to our 
customers in the near future.  We have already added a P-384 Root Certificate 
to the Microsoft and Mozilla Root Certificate Programs.

I have some questions/comments on your I-D and some other related matters...

1. Why does your I-D not include a profile for OCSP requests/responses?
Perhaps you could add a section that references RFC 2560 and states that OCSP 
request/response signatures should follow the same rules as signatures for 
Suite B certificates?

2. What's the relationship between your I-D and the various Suite B RFCs, such 
as RFC 5430 "Suite B Profile for Transport Layer Security (TLS)"?
Would it make sense for your I-D to reference any of the Suite B RFCs and/or 
for them to reference your I-D?

3. Some RFCs list IPR claims and/or advise the reader to consult 
http://www.ietf.org/ipr.  Would it make sense to mention any IPR issues in 
your I-D?  I am of course thinking about the large number of ECC patents held 
by Certicom/RIM.

4. Why did the NSA include P-256 and P-384 in Suite B, but omit P-521?
I believe that Certicom defined P-521 before Suite B was specified, and 
Microsoft and Mozilla have both chosen to support P-521 as well as P-256 and 
P-384.

5. RFC 5280 defines various standard Extended Key Usage OIDs.  I've seen 
various documents that profile Suite B for Server Authentication 
certificates, Client Authentication certificates and Secure Email 
certificates, but I'm not aware of any documents that cover Suite B for Code 
Signing certificates or Time Stamping certificates.
Are you aware of any such documents?
If not, do you know why no such documents exist?

Thanks in advance.

-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

Subject: RE: RSA Signature Padding
Content-class: urn:content-classes:message
Date: Mon, 8 Jun 2009 09:21:58 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "Tom Gindin" <[email-masked]>, "IETF-pkix" <[email-masked]>
Sender: [email-masked]

The thesis of the paper is that ad hoc encodings should be replaced with
Provably secure encodings, albeit the attack it describes may not apply
to PKCS 1 1.5.

One would think that we would want to use provable secure padding
specially as we use new OID.

> -----Original Message-----
> From: Simon Josefsson [mailto:[email-masked]]=20
> Sent: Monday, June 08, 2009 7:28 AM
> To: Santosh Chokhani
> Cc: Tom Gindin; IETF-pkix
> Subject: Re: RSA Signature Padding
>=20
> "Santosh Chokhani" <[email-masked]> writes:
>=20
> > Tom,
> >
> > I am asking because of the paper in the link below.
> >
> > http://eprint.iacr.org/2009/203
>=20
> Interesting.  What does that mean for PKCS#1 v1.5?
>=20
> /Simon
>=20
> >> -----Original Message-----
> >> From: Tom Gindin [mailto:[email-masked]]
> >> Sent: Sunday, June 07, 2009 8:54 PM
> >> To: Santosh Chokhani
> >> Cc: IETF-pkix
> >> Subject: Re: RSA Signature Padding
> >>=20
> >>         Is "we" the right term?  The latest TLS (RFC 5246 section=20
> >> 4.7) specifies RSA signatures but does not seem to permit=20
> PSS ones. =20
> >> PKIX at least has PSS in RFC 4055.  We could encourage vendors by=20
> >> producing a consolidated "algorithms" RFC which deprecates=20
> the use of=20
> >> MD2 and MD5 for new certificates, while suggesting that=20
> any RP vendor=20
> >> supporting sha1WithRSAEncryption as a signatureAlgorithm=20
> SHOULD also=20
> >> support id-RSASSA-PSS.  Are you suggesting that we should=20
> also tell=20
> >> people not to use sha256WithRSAEncryption,=20
> sha384WithRSAEncryption,=20
> >> or sha512WithRSAEncryption as signatureAlgorithm values but to use=20
> >> those hash algorithms as PSS parameters instead?
> >>         Should such an RFC be targeted for New Year's 2011?
> >>=20
> >>                 Tom Gindin
> >>=20
> >>=20
> >>=20
> >>=20
> >> "Santosh Chokhani" <[email-masked]> Sent by:=20
> >> [email-masked]
> >> 06/03/2009 12:58 PM
> >>=20
> >> To
> >> "IETF-pkix" <[email-masked]>
> >> cc
> >>=20
> >> Subject
> >> RSA Signature Padding
> >>=20
> >>=20
> >>=20
> >>=20
> >>=20
> >>=20
> >>=20
> >> I do not know if this is the right forum.
> >>=20
> >> Should we encourage vendors to use RSA PSS as we transition to=20
> >> SHA-256 given the weakness in PKCS 1.5 padding?
> >>=20
> >> Santosh Chokhani
> >> CygnaCom Solutions
> >>=20
> >> "Questioning conventional wisdom is key to innovation"
> >>=20
> >>=20
> >>=20
> >>=20
>=20

From: Simon Josefsson <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>
Cc: "Tom Gindin" <[email-masked]>, "IETF-pkix" <[email-masked]>
Subject: Re: RSA Signature Padding
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 08 Jun 2009 13:28:03 +0200
Sender: [email-masked]

"Santosh Chokhani" <[email-masked]> writes:

> Tom,
>
> I am asking because of the paper in the link below.
>
> http://eprint.iacr.org/2009/203 

Interesting.  What does that mean for PKCS#1 v1.5?

/Simon

>> -----Original Message-----
>> From: Tom Gindin [mailto:[email-masked]] 
>> Sent: Sunday, June 07, 2009 8:54 PM
>> To: Santosh Chokhani
>> Cc: IETF-pkix
>> Subject: Re: RSA Signature Padding
>> 
>>         Is "we" the right term?  The latest TLS (RFC 5246 
>> section 4.7) specifies RSA signatures but does not seem to 
>> permit PSS ones.  PKIX at least has PSS in RFC 4055.  We 
>> could encourage vendors by producing a consolidated 
>> "algorithms" RFC which deprecates the use of MD2 and MD5 for 
>> new certificates, while suggesting that any RP vendor 
>> supporting sha1WithRSAEncryption as a signatureAlgorithm 
>> SHOULD also support id-RSASSA-PSS.  Are you suggesting that 
>> we should also tell people not to use 
>> sha256WithRSAEncryption, sha384WithRSAEncryption, or 
>> sha512WithRSAEncryption as signatureAlgorithm values but to 
>> use those hash algorithms as PSS parameters instead?
>>         Should such an RFC be targeted for New Year's 2011?
>> 
>>                 Tom Gindin
>> 
>> 
>> 
>> 
>> "Santosh Chokhani" <[email-masked]> Sent by: 
>> [email-masked]
>> 06/03/2009 12:58 PM
>> 
>> To
>> "IETF-pkix" <[email-masked]>
>> cc
>> 
>> Subject
>> RSA Signature Padding
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> I do not know if this is the right forum.
>> 
>> Should we encourage vendors to use RSA PSS as we transition 
>> to SHA-256 given the weakness in PKCS 1.5 padding?
>> 
>> Santosh Chokhani
>> CygnaCom Solutions
>> 
>> "Questioning conventional wisdom is key to innovation"
>> 
>> 
>> 
>> 

Subject: RE: RSA Signature Padding
Date: Mon, 8 Jun 2009 06:43:11 -0400
Content-class: urn:content-classes:message
From: "Santosh Chokhani" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: "IETF-pkix" <[email-masked]>
Sender: [email-masked]

Tom,

I am asking because of the paper in the link below.

http://eprint.iacr.org/2009/203=20

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]=20
> Sent: Sunday, June 07, 2009 8:54 PM
> To: Santosh Chokhani
> Cc: IETF-pkix
> Subject: Re: RSA Signature Padding
>=20
>         Is "we" the right term?  The latest TLS (RFC 5246=20
> section 4.7) specifies RSA signatures but does not seem to=20
> permit PSS ones.  PKIX at least has PSS in RFC 4055.  We=20
> could encourage vendors by producing a consolidated=20
> "algorithms" RFC which deprecates the use of MD2 and MD5 for=20
> new certificates, while suggesting that any RP vendor=20
> supporting sha1WithRSAEncryption as a signatureAlgorithm=20
> SHOULD also support id-RSASSA-PSS.  Are you suggesting that=20
> we should also tell people not to use=20
> sha256WithRSAEncryption, sha384WithRSAEncryption, or=20
> sha512WithRSAEncryption as signatureAlgorithm values but to=20
> use those hash algorithms as PSS parameters instead?
>         Should such an RFC be targeted for New Year's 2011?
>=20
>                 Tom Gindin
>=20
>=20
>=20
>=20
> "Santosh Chokhani" <[email-masked]> Sent by:=20
> [email-masked]
> 06/03/2009 12:58 PM
>=20
> To
> "IETF-pkix" <[email-masked]>
> cc
>=20
> Subject
> RSA Signature Padding
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> I do not know if this is the right forum.
>=20
> Should we encourage vendors to use RSA PSS as we transition=20
> to SHA-256 given the weakness in PKCS 1.5 padding?
>=20
> Santosh Chokhani
> CygnaCom Solutions
>=20
> "Questioning conventional wisdom is key to innovation"
>=20
>=20
>=20
>=20

To: "Santosh Chokhani" <[email-masked]>
Cc: "IETF-pkix" <[email-masked]>
Subject: Re: RSA Signature Padding
From: Tom Gindin <[email-masked]>
Date: Sun, 7 Jun 2009 20:54:27 -0400
Sender: [email-masked]

        Is "we" the right term?  The latest TLS (RFC 5246 section 4.7) 
specifies RSA signatures but does not seem to permit PSS ones.  PKIX at 
least has PSS in RFC 4055.  We could encourage vendors by producing a 
consolidated "algorithms" RFC which deprecates the use of MD2 and MD5 for 
new certificates, while suggesting that any RP vendor supporting 
sha1WithRSAEncryption as a signatureAlgorithm SHOULD also support 
id-RSASSA-PSS.  Are you suggesting that we should also tell people not to 
use sha256WithRSAEncryption, sha384WithRSAEncryption, or 
sha512WithRSAEncryption as signatureAlgorithm values but to use those hash 
algorithms as PSS parameters instead?
        Should such an RFC be targeted for New Year's 2011?

                Tom Gindin

"Santosh Chokhani" <[email-masked]> 
Sent by: [email-masked]
06/03/2009 12:58 PM

To
"IETF-pkix" <[email-masked]>
cc

Subject
RSA Signature Padding

I do not know if this is the right forum.

Should we encourage vendors to use RSA PSS as we transition to SHA-256
given the weakness in PKCS 1.5 padding?

Santosh Chokhani
CygnaCom Solutions

"Questioning conventional wisdom is key to innovation"

Date: Fri, 5 Jun 2009 16:09:32 -0700
To: Sean Turner <[email-masked]>, [email-masked], Lydia Zieglar <[email-masked]>, Jerry Solinas <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate  and Certificate Revocation List (CRL) Profile) to Informational RFC
Cc: pkix <[email-masked]>
Sender: [email-masked]

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?
>
>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.

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.

>#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.
>

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

Date: Fri, 05 Jun 2009 12:39:09 -0400
From: Sean Turner <[email-masked]>
To: [email-masked], Lydia Zieglar <[email-masked]>, Jim Solinas <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B 	Certificate and Certificate Revocation List (CRL) Profile) to 	Informational RFC
Sender: [email-masked]

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

Date: Wed, 03 Jun 2009 13:19:57 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Fwd: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate and Certificate Revocation List (CRL) Profile) to Informational RFC 
Sender: [email-masked]

>To: IETF-Announce <[email-masked]>
>From: The IESG <[email-masked]>
>Subject: Last Call: draft-solinas-suiteb-cert-profile (Suite B
>         Certificate and Certificate Revocation List (CRL) Profile) to
>         Informational RFC
>Date: Wed,  3 Jun 2009 08:33:30 -0700 (PDT)
>
>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

Content-class: urn:content-classes:message
Subject: RSA Signature Padding
Date: Wed, 3 Jun 2009 12:58:45 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "IETF-pkix" <[email-masked]>
Sender: [email-masked]

I do not know if this is the right forum.

Should we encourage vendors to use RSA PSS as we transition to SHA-256
given the weakness in PKCS 1.5 padding?

Santosh Chokhani
CygnaCom Solutions

"Questioning conventional wisdom is key to innovation"