Re: Way forward - updating RFC 3161

[Adriano Santoni <[e-mail]>]

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 


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n616h3Df066183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 23:43:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n616h39H066182; Tue, 30 Jun 2009 23:43:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ascertia.com (www.ascertia.com [94.136.44.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n616gqPN066168 for <[e-mail]>; Tue, 30 Jun 2009 23:43:02 -0700 (MST) (envelope-from [e-mail])
Received: from ASCUK001 ([87.201.190.183]) by ascertia.com with MailEnable ESMTP; Wed, 1 Jul 2009 06:42:56 +0100
From: "Liaquat Khan" <[e-mail]>
To: "'Adriano Santoni'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Pope, Nick'" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: RE: Way forward - updating RFC 3161
Date: Wed, 1 Jul 2009 10:42:00 +0400
Message-ID: <294EC8B35280415F870168ED091DEEA4@ASCUK001>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
Thread-Index: Acn6CX3cJENwoJEnSC+anZrhew79LwADWuWw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-ME-Bayesian: 0.000000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes, me too.

Regards,
LK

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adriano Santoni
Sent: 01 July 2009 10:00
To: Stefan Santesson
Cc: [e-mail]; 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 







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n61608dq063180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 23:00:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n61608Kn063179; Tue, 30 Jun 2009 23:00:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from staff.aruba.it (staff.aruba.it [62.149.157.50] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n615xu4L063122 for <[e-mail]>; Tue, 30 Jun 2009 23:00:07 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 3104 invoked by uid 89); 1 Jul 2009 05:59:50 -0000
Received: by simscan 1.1.0 ppid: 3097, pid: 3100, t: 1.1362s scanners: spam: 3.1.0
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on staff1.fe.aruba.it
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=4.0 tests=BAYES_50,RDNS_NONE autolearn=no version=3.2.5
Received: from unknown (HELO ?156.54.188.117?) ([e-mail]@193.43.104.11) by staff1.fe.aruba.it with SMTP; 1 Jul 2009 05:59:49 -0000
Message-ID: <[e-mail]>
Date: Wed, 01 Jul 2009 07:59:52 +0200
From: Adriano Santoni <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: "[e-mail]" <[e-mail]>, Denis Pinkas <[e-mail]>, "Pope, Nick" <[e-mail]>
Subject: Re: Way forward - updating RFC 3161
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6110EOJ045512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 18:00:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6110EKo045511; Tue, 30 Jun 2009 18:00:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n610xxqQ045433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 30 Jun 2009 18:00:11 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 81722 invoked from network); 1 Jul 2009 01:00:08 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 1 Jul 2009 01:00:08 -0000
Received: (qmail 79283 invoked from network); 1 Jul 2009 00:59:57 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 1 Jul 2009 00:59:57 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Wed, 01 Jul 2009 02:59:56 +0200
Subject: Way forward - updating RFC 3161
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
CC: Denis Pinkas <[e-mail]>, "Pope, Nick" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Way forward - updating RFC 3161
Thread-Index: Acn55z/OUcUgq+DCekmtTP/TWhgO9Q==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3329261997_2958318"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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

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

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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5TJaJ7R026845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 12:36:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5TJaJ1e026844; Mon, 29 Jun 2009 12:36:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5TJa642026830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 29 Jun 2009 12:36:18 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10545 invoked from network); 29 Jun 2009 19:36:12 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 29 Jun 2009 19:36:12 -0000
Received: (qmail 99349 invoked from network); 29 Jun 2009 19:36:03 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 29 Jun 2009 19:36:03 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Mon, 29 Jun 2009 21:36:02 +0200
Subject: Request for PKIX agenda items - IETF 75
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Request for PKIX agenda items - IETF 75
Thread-Index: Acn48NXT7IibfD+IcUC82hGkpsHCGw==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3329156164_20567213"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5MDkuwO004746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2009 06:46:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5MDkuPG004745; Mon, 22 Jun 2009 06:46:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5MDkiCh004722 for <[e-mail]>; Mon, 22 Jun 2009 06:46:55 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id n5MDl2HP019409; Mon, 22 Jun 2009 13:47:03 GMT
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
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
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: draft-solinas-suiteb-cert-profile (Suite B 	Certificate and Certificate Revocation List (CRL) Profile) to 	Informational RFC
Thread-Index: AcnmBu+9Yb3XezsnQMmtCBQoYY/a7wNOGFOw
References: <[e-mail]> <[e-mail]>
From: "Zieglar, Lydia L." <[e-mail]>
To: "Sean Turner" <[e-mail]>, <[e-mail]>, "Solinas, Jerry" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sean Turner
Sent: Friday, June 05, 2009 12:39 PM
To: [e-mail]; Zieglar, Lydia L.; Solinas, Jerry
Cc: pkix
Subject: Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B
Certificate and Certificate Revocation List (CRL) Profile) to
Informational RFC


The IESG wrote:
> The IESG has received a request from an individual submitter to=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 [e-mail] mailing lists by 2009-07-01. Exceptionally, comments

> may be sent to [e-mail] 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5J5JtjZ057693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 22:19:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5J5Jtfw057689; Thu, 18 Jun 2009 22:19:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5J5JhsO057662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 18 Jun 2009 22:19:54 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5J5Ecjc025656 for <[e-mail]>; Fri, 19 Jun 2009 01:14:38 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5J5JgUc226604 for <[e-mail]>; Fri, 19 Jun 2009 01:19:42 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5J5JfXa018096 for <[e-mail]>; Fri, 19 Jun 2009 01:19:42 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n5J5Jfiv018091; Fri, 19 Jun 2009 01:19:41 -0400
In-Reply-To: <p062408fec66010ec0788@[10.20.30.158]>
To: Paul Hoffman <[e-mail]>
Cc: Daniel Brown <[e-mail]>, "[e-mail]" <[e-mail]>
MIME-Version: 1.0
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 19 Jun 2009 01:19:40 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 06/19/2009 01:19:41, Serialize complete at 06/19/2009 01:19:41
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        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 <[e-mail]> 
06/18/2009 11:43 AM

To
Tom Gindin/Watson/IBM@IBMUS, Daniel Brown <[e-mail]>
cc
"[e-mail]" <[e-mail]>
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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5IFhAMW013158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 08:43:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5IFhApd013157; Thu, 18 Jun 2009 08:43:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5IFh5S9013151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 08:43:06 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p062408fec66010ec0788@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 18 Jun 2009 08:43:04 -0700
To: Tom Gindin <[e-mail]>, Daniel Brown <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Cc: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5I1EHme055065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jun 2009 18:14:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5I1EHLp055064; Wed, 17 Jun 2009 18:14:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5I1E5NV055040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 17 Jun 2009 18:14:16 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5I19YP5017833 for <[e-mail]>; Wed, 17 Jun 2009 21:09:34 -0400
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5I1E3NN254202 for <[e-mail]>; Wed, 17 Jun 2009 21:14:03 -0400
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n5I1E2OI015532 for <[e-mail]>; Wed, 17 Jun 2009 21:14:02 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n5I1E2La015527; Wed, 17 Jun 2009 21:14:02 -0400
In-Reply-To: <[e-mail]>
To: Daniel Brown <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Paul Hoffman <[e-mail]>
MIME-Version: 1.0
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 17 Jun 2009 21:14:01 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 06/17/2009 21:14:02, Serialize complete at 06/17/2009 21:14:02
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        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 <[e-mail]> 
Sent by: [e-mail]
06/12/2009 11:35 AM

To
Paul Hoffman <[e-mail]>, "[e-mail]" 
<[e-mail]>
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:[e-mail]] 
Sent: Thursday, May 28, 2009 4:38 PM
To: Daniel Brown; [e-mail]
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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5H8LaO5084482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jun 2009 01:21:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5H8LaKb084481; Wed, 17 Jun 2009 01:21:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp823.mail.ird.yahoo.com (smtp823.mail.ird.yahoo.com [217.146.188.233]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n5H8LNHJ084452 for <[e-mail]>; Wed, 17 Jun 2009 01:21:34 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 40920 invoked from network); 17 Jun 2009 08:21:22 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=whtjOnvO+KllR9QjU80hQUvUMb7GgkC14Q2IaWFfVqeaSd3PeWKj9vDMJN67lsdIvFi+sP2HXfSpz6Zd/yBgw2O7XFiVpqqobWVM1Q0kPIbAE7ztn+5Cw07p+NShEpeq/1PfF8bUzB6sRatrBzoWFNefvNs07JsXhezwVOnkUl0=  ;
Received: from unknown (HELO ?192.168.1.67?) (j.larmouth@86.146.115.249 with plain) by smtp823.mail.ird.yahoo.com with SMTP; 17 Jun 2009 08:21:22 -0000
X-Yahoo-SMTP: wkRZlpKswBD4hYA5WOvxKyA0utS_ehUG.AZgJb2EFBo2v2XeQHg-
X-YMail-OSG: Uk1E6FQVM1lUcS4Phus9WRIeXS6LVCXeFi0p3TcdMIuTwMWLcekhIHQQpEEWZv4BHaNXsVgUkYCYFnKvB1SSfcIMMRN3wr2QcZhR0wMcIrEeco3AWxNNbbAiJDGxqKAJ_rXLF4suHgmGoX8TEHtxnbDjxaGdrFXHLiWXqVzEE7aURkH9bG6VcnBweRQ8iNDeBd7PMprJnlhKmWdqrn2fupezOBcpTvDL3vcV4MPBr0Mf4rv1HwjD47t2Cegli75g3Azs5zMSzOwxesJhmWgsU2HUlWLJKb2kqgtPJMcytEzfU.pLI8GliAhKybkhT0GEELcDZSpRWVQ.0hfUv6g-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Wed, 17 Jun 2009 09:21:17 +0100
From: John Larmouth <[e-mail]>
Reply-To:  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]> 
> Sent by: [e-mail]
> 12/22/2008 10:48 AM
> Please respond to
> [e-mail]
> 
> 
> To
> Alfred � <[e-mail]>
> cc
> [e-mail], [e-mail], [e-mail]
> 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                               [e-mail]
    Altrincham
    Cheshire
    WA14 3LS
    England
    Tel: [phone]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GNrLFn053242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 16:53:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GNrLEh053241; Tue, 16 Jun 2009 16:53:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GNrEfq053231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 16:53:15 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240806c65dc058ead3@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <p06240802c65c4d2ad6fb@[10.20.30.158]> <[e-mail]> <[e-mail]>
Date: Tue, 16 Jun 2009 14:57:34 -0700
To: Daniel Brown <[e-mail]>, Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GKLcKv041587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 13:21:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GKLcJl041586; Tue, 16 Jun 2009 13:21:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cx297.800onemail.com (CX297.800onemail.com [209.20.1.115]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GKLRUu041572 for <[e-mail]>; Tue, 16 Jun 2009 13:21:38 -0700 (MST) (envelope-from [e-mail])
Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx297.800onemail.com (8.13.8/8.13.8) with ESMTP id n5GKGm9M008105; Tue, 16 Jun 2009 16:16:48 -0400
Received: from EX41-2.exchserver.com ([169.254.4.162]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Tue, 16 Jun 2009 16:19:48 -0400
From: Daniel Brown <[e-mail]>
To: Stefan Santesson <[e-mail]>, Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 16 Jun 2009 16:19:46 -0400
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Topic: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Index: Acnup6dEosOi5p7yK0yQlLGgIUQWkQAEsLRA
Message-ID: <[e-mail]>
References: <p06240802c65c4d2ad6fb@[10.20.30.158]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A1_01C9EE9E.43D5AC50"
MIME-Version: 1.0
X-CRXEFW-Info: Please contact Ceryx for more information
X-CRXEFW-Virus: Clean
X-CRXEFW-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_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:[e-mail]] 
Sent: Tuesday, June 16, 2009 1:27 PM
To: Paul Hoffman; Daniel Brown; [e-mail]
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" <[e-mail]> 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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/zCCAvsw
ggHjoAMCAQICCCL9CV5x0J/QMA0GCSqGSIb3DQEBBQUAMBQxEjAQBgNVBAMMCURhbiBCcm93bjAe
Fw0wOTA2MDUxNjUzMzhaFw0xMDA2MDUxNjUzMzhaMBQxEjAQBgNVBAMMCURhbiBCcm93bjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMGip+SHMgE/IUnrzYH0tOGmt5t/i13O5YeITKy
aQjI1cS5ufbiffgujSpNASf4+pJGlchovcm6D/6C/7k1F80y+xWksYbzQQsm5BFJ3HBmMfp4kGe7
jYh4+K+LcLMIB6iseEqkrJU3dPcw60PFlrrZhaQvRV4T2A4KTndxu6f03PVF20CAWenp8DMELXBg
ehRjSskj4uQBhmI3MJbWPyH7TkqbcJh4TeZHf3QQuO8X58DrVnZflTHoW6LqgBDcKJiEyDy/eY+u
Pc3GmqHGyEaQ+GnM5MVZmWQZcjbAHsaayeYjiz9u0Dib5elPlv4bHavXs1YwxPFxappDDGfaZk8C
AwEAAaNRME8wDgYDVR0PAQH/BAQDAgXgMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMCUGA1UdEQQe
MByBBWVtYWlsgRNkYnJvd25AY2VydGljb20uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAJRYYuy7LW
H01CItbUsfobtL1XXSxOns33HUhW2hUwVpR6e1undIytIgYV/dxZTjdFbrUnzUp/bdpZ+TiNLd5c
eojJZywMKa1ds9QVNiwU94tu3i66/yr9bf54JEKK56mbfTaEzFb4sLOOKEQQweij9mgA3V7xAAdv
kfq+RcKNAnIPav95jlm62OYoZ8EX6pLFmBcwVfg7obSLBXgSi18/tRhViPFPNoULY5OmwHlk4DvY
m6LxNln+icCxvuicwwtxptyrZhNwgucKAVcPoRKZ+OY6/S5EFWo+bD4kGD+znSJiSGGX2L2xe6ap
NboJJXnWCWT/MniFIqqlE0dj52a7MYICwzCCAr8CAQEwIDAUMRIwEAYDVQQDDAlEYW4gQnJvd24C
CCL9CV5x0J/QMAkGBSsOAwIaBQCgggF4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTA5MDYxNjIwMTk0NlowIwYJKoZIhvcNAQkEMRYEFPoJzl6cw6+tZJeyOW4bCB4N
mdWmMC8GCSsGAQQBgjcQBDEiMCAwFDESMBAGA1UEAwwJRGFuIEJyb3duAggi/QlecdCf0DAxBgsq
hkiG9w0BCRACCzEioCAwFDESMBAGA1UEAwwJRGFuIEJyb3duAggi/QlecdCf0DBMBgsqhkiG9w0B
CRACATE9MDsEHQAAAAAQAAAAYvnJAkbUbUeDm1rC8zLxNQEAAAAAgAEAMBcwFYETZGJyb3duQGNl
cnRpY29tLmNvbTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0C
BTANBgkqhkiG9w0BAQEFAASCAQBehr7EM6p94NcJ9Jn3queH6aBnRoVBn2ePv4gx6yAcz+7JL/fF
2aGUsgOGkL/Mz6UtQNdl6dY1cY9f5qzYSC/kIQBYVtirsL2/hXjUhb85p43xy8/nrbkvZ7b/q7yt
gHTLpAr23X+ivjcAhydvBXql9oIJ0uFEFWGQNPeMdw3N9qhu6L0gEDIEbfriQuNCT9JaDdSuhXSn
cCtxP6erT01X1zcgeKNYzOjUhtCXw7CamIQlWENWt453tE6axov2L5SCYDpVe9fI9QFcuBb+Pc/7
rBqlhiFfRoKWU7Mw07LZdF91wpx1MYOQnxvpyC1Fztmb5d8/EyMArCYTROrdIXi3AAAAAAAA

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GJiopc038723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 12:44:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GJiobV038722; Tue, 16 Jun 2009 12:44:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GJik8s038705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 16 Jun 2009 12:44:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 88619 invoked from network); 16 Jun 2009 19:44:06 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 16 Jun 2009 19:44:06 -0000
Received: (qmail 98651 invoked from network); 16 Jun 2009 19:43:57 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 16 Jun 2009 19:43:57 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Tue, 16 Jun 2009 21:43:56 +0200
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
From: Stefan Santesson <[e-mail]>
To: Michael StJohns <[e-mail]>, Paul Hoffman <[e-mail]>, Daniel Brown <[e-mail]>, "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Index: Acnuusj7M8oS8QyxuUOKxgQxyh+hHA==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GI4ZBP031048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 11:04:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GI4ZCC031045; Tue, 16 Jun 2009 11:04:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GI4NYk031013 for <[e-mail]>; Tue, 16 Jun 2009 11:04:34 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 4eqF1c0010xGWP856i4QeP; Tue, 16 Jun 2009 18:04:24 +0000
Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA12.westchester.pa.mail.comcast.net with comcast id 4i4P1c00h4LCBKY3Yi4QUL; Tue, 16 Jun 2009 18:04:24 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 16 Jun 2009 14:04:22 -0400
To: Stefan Santesson <[e-mail]>, Paul Hoffman <[e-mail]>, Daniel Brown <[e-mail]>, "[e-mail]" <[e-mail]>
From: Michael StJohns <[e-mail]>
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
In-Reply-To: <[e-mail]>
References: <p06240802c65c4d2ad6fb@[10.20.30.158]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GHRGCa028401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 10:27:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GHRGEL028400; Tue, 16 Jun 2009 10:27:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GHR2ib028374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 16 Jun 2009 10:27:14 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 58493 invoked from network); 16 Jun 2009 17:27:08 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 16 Jun 2009 17:27:08 -0000
Received: (qmail 28558 invoked from network); 16 Jun 2009 17:27:01 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 16 Jun 2009 17:27:01 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Tue, 16 Jun 2009 19:26:59 +0200
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
From: Stefan Santesson <[e-mail]>
To: Paul Hoffman <[e-mail]>, Daniel Brown <[e-mail]>, "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Index: Acnup6dEosOi5p7yK0yQlLGgIUQWkQ==
In-Reply-To: <p06240802c65c4d2ad6fb@[10.20.30.158]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GDjCAM009894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 06:45:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5GDjC8Q009893; Tue, 16 Jun 2009 06:45:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5GDjCki009886 for <[e-mail]>; Tue, 16 Jun 2009 06:45:12 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 6B9E33A69EE; Tue, 16 Jun 2009 06:45:00 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-pkix-tac (Traceable Anonymous Certificate)  to Experimental RFC 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 16 Jun 2009 06:45:00 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
[e-mail] mailing lists by 2009-06-30. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5FJSK76037819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2009 12:28:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5FJSKL9037818; Mon, 15 Jun 2009 12:28:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5FJSDA5037809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2009 12:28:14 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240802c65c4d2ad6fb@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <p06240814c6275b402200@[193.0.26.228]> <p0624084fc62b5793d201@[10.20.30.249]> <[e-mail]> <p06240843c644a2c3dc78@[10.20.30.158]> <[e-mail]>
Date: Mon, 15 Jun 2009 12:28:11 -0700
To: Daniel Brown <[e-mail]>, "[e-mail]"	<[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5DDGssX070605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jun 2009 06:16:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5DDGrVo070601; Sat, 13 Jun 2009 06:16:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5DDGq89070589 for <[e-mail]>; Sat, 13 Jun 2009 06:16:52 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id AABE466AFD6; Sun, 14 Jun 2009 01:16:51 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifmF37u6NbNR; Sun, 14 Jun 2009 01:16:51 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EA8C066AFC6; Sun, 14 Jun 2009 01:16:46 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 41F2219EC0BA; Sun, 14 Jun 2009 01:16:45 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MFT6D-0001EZ-3k; Sun, 14 Jun 2009 01:16:45 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: RSA Signature Padding
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sun, 14 Jun 2009 01:16:45 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5DCgtbm067816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jun 2009 05:42:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5DCgtRe067815; Sat, 13 Jun 2009 05:42:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5DCggWu067801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 13 Jun 2009 05:42:54 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 99019 invoked from network); 13 Jun 2009 12:42:45 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 13 Jun 2009 12:42:45 -0000
Received: (qmail 99148 invoked from network); 13 Jun 2009 12:42:39 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) ([e-mail]@[213.64.142.21]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 13 Jun 2009 12:42:39 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Sat, 13 Jun 2009 14:42:38 +0200
Subject: Re: RSA Signature Padding
From: Stefan Santesson <[e-mail]>
To: Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>
CC: <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: RSA Signature Padding
Thread-Index: AcnsJG7hXslbaKBfNkS3GlzyxJIk4A==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

> 
> "Santosh Chokhani" <[e-mail]> 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.
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5DCApds065826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jun 2009 05:10:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5DCApUj065825; Sat, 13 Jun 2009 05:10:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5DCAdsO065794 for <[e-mail]>; Sat, 13 Jun 2009 05:10:49 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4921B671113; Sun, 14 Jun 2009 00:10:37 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzVCQb9JkmPq; Sun, 14 Jun 2009 00:10:37 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F3A1167110B; Sun, 14 Jun 2009 00:10:29 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 23A9519EC0BA; Sun, 14 Jun 2009 00:10:23 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MFS3y-0006Rf-Vq; Sun, 14 Jun 2009 00:10:23 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: RSA Signature Padding
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sun, 14 Jun 2009 00:10:22 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CK7oDv022447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 13:07:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5CK7o0q022446; Fri, 12 Jun 2009 13:07:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.67.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CK7lgA022439 for <[e-mail]>; Fri, 12 Jun 2009 13:07:48 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id n5CK7TgW008660; Fri, 12 Jun 2009 20:07:29 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
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
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate and Certificate Revocation List (CRL) Profile) to Informational RFC
Thread-Index: Acno3v1fu/LQH5uxS160wNLRIY70swCuishg
References: <[e-mail]> <[e-mail]>
From: "Zieglar, Lydia L." <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Solinas, Jerry" <[e-mail]>, "Rob Stradling" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

-----Original Message-----
From: Rob Stradling [mailto:[e-mail]]=20
Sent: Tuesday, June 09, 2009 4:48 AM
To: [e-mail]; Zieglar, Lydia L.; Solinas, Jerry
Cc: [e-mail]
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 <[e-mail]>
To: [e-mail]

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: [phone]
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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CFajZa005628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 08:36:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5CFajxD005627; Fri, 12 Jun 2009 08:36:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CFaY1K005614 for <[e-mail]>; Fri, 12 Jun 2009 08:36:44 -0700 (MST) (envelope-from [e-mail])
Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n5CFZrmX023653; Fri, 12 Jun 2009 11:35:53 -0400
Received: from EX41-2.exchserver.com ([169.254.4.162]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Fri, 12 Jun 2009 11:35:53 -0400
From: Daniel Brown <[e-mail]>
To: Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 12 Jun 2009 11:35:40 -0400
Subject: RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Topic: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
Thread-Index: Acnf1R4sR3VIDqiVTK2okgHSpgx6kwLnInKg
Message-ID: <[e-mail]>
References: <p06240814c6275b402200@[193.0.26.228]> <p0624084fc62b5793d201@[10.20.30.249]> <[e-mail]> <p06240843c644a2c3dc78@[10.20.30.158]>
In-Reply-To: <p06240843c644a2c3dc78@[10.20.30.158]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00EB_01C9EB51.E98CB1C0"
MIME-Version: 1.0
X-CRXEFW-Info: Please contact Ceryx for more information
X-CRXEFW-Virus: Clean
X-CRXEFW-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_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:[e-mail]] 
Sent: Thursday, May 28, 2009 4:38 PM
To: Daniel Brown; [e-mail]
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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/zCCAvsw
ggHjoAMCAQICCCL9CV5x0J/QMA0GCSqGSIb3DQEBBQUAMBQxEjAQBgNVBAMMCURhbiBCcm93bjAe
Fw0wOTA2MDUxNjUzMzhaFw0xMDA2MDUxNjUzMzhaMBQxEjAQBgNVBAMMCURhbiBCcm93bjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMGip+SHMgE/IUnrzYH0tOGmt5t/i13O5YeITKy
aQjI1cS5ufbiffgujSpNASf4+pJGlchovcm6D/6C/7k1F80y+xWksYbzQQsm5BFJ3HBmMfp4kGe7
jYh4+K+LcLMIB6iseEqkrJU3dPcw60PFlrrZhaQvRV4T2A4KTndxu6f03PVF20CAWenp8DMELXBg
ehRjSskj4uQBhmI3MJbWPyH7TkqbcJh4TeZHf3QQuO8X58DrVnZflTHoW6LqgBDcKJiEyDy/eY+u
Pc3GmqHGyEaQ+GnM5MVZmWQZcjbAHsaayeYjiz9u0Dib5elPlv4bHavXs1YwxPFxappDDGfaZk8C
AwEAAaNRME8wDgYDVR0PAQH/BAQDAgXgMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMCUGA1UdEQQe
MByBBWVtYWlsgRNkYnJvd25AY2VydGljb20uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAJRYYuy7LW
H01CItbUsfobtL1XXSxOns33HUhW2hUwVpR6e1undIytIgYV/dxZTjdFbrUnzUp/bdpZ+TiNLd5c
eojJZywMKa1ds9QVNiwU94tu3i66/yr9bf54JEKK56mbfTaEzFb4sLOOKEQQweij9mgA3V7xAAdv
kfq+RcKNAnIPav95jlm62OYoZ8EX6pLFmBcwVfg7obSLBXgSi18/tRhViPFPNoULY5OmwHlk4DvY
m6LxNln+icCxvuicwwtxptyrZhNwgucKAVcPoRKZ+OY6/S5EFWo+bD4kGD+znSJiSGGX2L2xe6ap
NboJJXnWCWT/MniFIqqlE0dj52a7MYICwzCCAr8CAQEwIDAUMRIwEAYDVQQDDAlEYW4gQnJvd24C
CCL9CV5x0J/QMAkGBSsOAwIaBQCgggF4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTA5MDYxMjE1MzUzOVowIwYJKoZIhvcNAQkEMRYEFIP0WR6jsRMEmPAzJh/K1zgg
FOc6MC8GCSsGAQQBgjcQBDEiMCAwFDESMBAGA1UEAwwJRGFuIEJyb3duAggi/QlecdCf0DAxBgsq
hkiG9w0BCRACCzEioCAwFDESMBAGA1UEAwwJRGFuIEJyb3duAggi/QlecdCf0DBMBgsqhkiG9w0B
CRACATE9MDsEHQAAAAAQAAAA2adjf30t30qf/CGhBzA5vgEAAAAAgAEAMBcwFYETZGJyb3duQGNl
cnRpY29tLmNvbTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0C
BTANBgkqhkiG9w0BAQEFAASCAQAwhOWi7PRomf2/ji+TcvIPY3iEZMscxWxRfD27tGGUJ5Oz+RtR
XfHMXhVpUF3gBjY+YcINdkEp1nStqTR9asi/5LIur7/tv9yIdDD+zuAWOYcR+rVAT20XzosROO4Q
YdhceO3IfvSWqRWCMbrZ9LAW26BWzloOX0VbRDmvDkquLCAyWnfJj7jouR/ftM6nK0IIgiVDrjka
Nx6kDAfaLPXiMWbqI0lEHLHUqXP8LSI+UOx/5GWyAkjoVwP4V7HEoYdj7VPT+WploQEhhoTemXT2
/o30noUETzDYJ/XhG5nZC0qWIKc3e3J9dgzUcpckO4mt/CEqWuWPda1fnLZRAIwyAAAAAAAA

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C2w5vs064772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 19:58:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C2w563064771; Thu, 11 Jun 2009 19:58:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C2vsLJ064761 for <[e-mail]>; Thu, 11 Jun 2009 19:58:04 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8431B170980; Fri, 12 Jun 2009 14:57:53 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaKLpbr-JbNC; Fri, 12 Jun 2009 14:57:53 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1681A1707E1; Fri, 12 Jun 2009 14:57:50 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4BA7719EC0BA; Fri, 12 Jun 2009 14:57:50 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MEwxi-0008JC-4k; Fri, 12 Jun 2009 14:57:50 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: RSA Signature Padding
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 12 Jun 2009 14:57:50 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BMMJ4Z051939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 15:22:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BMMJBc051938; Thu, 11 Jun 2009 15:22:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BMM8rL051929 for <[e-mail]>; Thu, 11 Jun 2009 15:22:18 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 2mK81c0040mlR8UA2mN93V; Thu, 11 Jun 2009 22:22:09 +0000
Received: from MIKES-LAPTOM.comcast.net ([216.129.123.44]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id 2mMV1c0020xb3EY8XmMjpB; Thu, 11 Jun 2009 22:22:04 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 11 Jun 2009 18:21:28 -0400
To: Jean-Marc Desperrier <[e-mail]>
From: Michael StJohns <[e-mail]>
Subject: Re: CRLNumber definition and MAX
Cc: Peter Sylvester <[e-mail]>, pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BLOt6R048469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 14:24:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BLOtgM048468; Thu, 11 Jun 2009 14:24:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BLOiB6048455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 11 Jun 2009 14:24:54 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 626713a4.2326637488.11478.00-005.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Thu, 11 Jun 2009 15:24:54 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: RSA Signature Padding
Date: Thu, 11 Jun 2009 17:23:49 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RSA Signature Padding
thread-index: AcnqgIY6Jrx80UIcSOeDI2+Zc9c0HgAWgcDQ
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "pgut001" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009052001)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]=20
> Sent: Thursday, June 11, 2009 6:37 AM
> To: Santosh Chokhani; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: RSA Signature Padding
>=20
> Simon Josefsson <[e-mail]> writes:
> >"Santosh Chokhani" <[e-mail]> 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 <[e-mail]> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BLMhpk048377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 14:22:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BLMhDZ048376; Thu, 11 Jun 2009 14:22:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BLMU9I048364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 11 Jun 2009 14:22:41 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 2a5713a4.2255326128.149526.00-001.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Thu, 11 Jun 2009 15:22:42 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: RSA Signature Padding
Date: Thu, 11 Jun 2009 17:20:37 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RSA Signature Padding
thread-index: Acnqf//estqAIfHHR/+P9PDMbf9n+gAWmhKg
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "pgut001" <[e-mail]>, <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009052001)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Any how did that go?

I suspect fell on deaf ears?=20

> -----Original Message-----
> From: pgut001 [mailto:[e-mail]]=20
> Sent: Thursday, June 11, 2009 6:33 AM
> To: [e-mail]; Santosh Chokhani
> Subject: Re: RSA Signature Padding
>=20
> "Santosh Chokhani" <[e-mail]> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BAaxj5009191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 03:37:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BAaxMl009190; Thu, 11 Jun 2009 03:36:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BAalF1009172 for <[e-mail]>; Thu, 11 Jun 2009 03:36:58 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 322591704FF; Thu, 11 Jun 2009 22:36:47 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhlhvwsZHWG6; Thu, 11 Jun 2009 22:36:47 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5C68F170610; Thu, 11 Jun 2009 22:36:46 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D687519EC0BA; Thu, 11 Jun 2009 22:36:45 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MEheH-00070e-NL; Thu, 11 Jun 2009 22:36:45 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: RSA Signature Padding
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 11 Jun 2009 22:36:45 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson <[e-mail]> writes:
>"Santosh Chokhani" <[e-mail]> 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 <[e-mail]> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BAXDCx009042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 03:33:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BAXDJ2009041; Thu, 11 Jun 2009 03:33:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BAX1aa009004 for <[e-mail]>; Thu, 11 Jun 2009 03:33:12 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 29CF841792A; Thu, 11 Jun 2009 22:33:01 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSvwHUzNpEJF; Thu, 11 Jun 2009 22:33:01 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id AAA27417922; Thu, 11 Jun 2009 22:32:56 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4F23019EC0BA; Thu, 11 Jun 2009 22:32:55 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1MEhaZ-0006lK-53; Thu, 11 Jun 2009 22:32:55 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: RSA Signature Padding
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 11 Jun 2009 22:32:55 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BAG7xh007952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 03:16:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5BAG75d007951; Thu, 11 Jun 2009 03:16:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5BAFucp007941 for <[e-mail]>; Thu, 11 Jun 2009 03:16:06 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 19BFD9E; Thu, 11 Jun 2009 12:15:54 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2009061112155029:25021 ; Thu, 11 Jun 2009 12:15:50 +0200 
Message-ID: <[e-mail]>
Date: Thu, 11 Jun 2009 12:15:50 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
Cc: Michael StJohns <[e-mail]>, pkix <[e-mail]>
Subject: Re: CRLNumber definition and MAX
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 06/11/2009 12:15:50 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 06/11/2009 12:15:53 PM, Serialize complete at 06/11/2009 12:15:53 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B9fVNF005573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 02:41:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5B9fVXQ005572; Thu, 11 Jun 2009 02:41:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5B9fDni005546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 11 Jun 2009 02:41:30 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-ex5.fr.colt.net (smtp-ex5.fr.colt.net [213.41.78.121]) by smtp-ft5.fr.colt.net (8.13.8/8.13.8/Debian-3) with ESMTP id n5B9ei8N008542; Thu, 11 Jun 2009 11:40:44 +0200
Received: from host.104.92.68.195.rev.coltfrance.com ([195.68.92.104] helo=[172.30.24.37]) by smtp-ex5.fr.colt.net with esmtp (Exim) (envelope-from <[e-mail]>) id 1MEgm5-00075C-0l; Thu, 11 Jun 2009 11:40:45 +0200
Message-ID: <[e-mail]>
Date: Thu, 11 Jun 2009 11:40:28 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090606 SeaMonkey/2.0b1pre
MIME-Version: 1.0
To: Michael StJohns <[e-mail]>
CC: Peter Sylvester <[e-mail]>, pkix <[e-mail]>
Subject: Re: CRLNumber definition and MAX
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ACL-Warn: 3/3 recipients OK.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59F5DdH073974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 08:05:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59F5Duv073972; Tue, 9 Jun 2009 08:05:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59F51JN073964 for <[e-mail]>; Tue, 9 Jun 2009 08:05:11 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 1mJc1c0030Fqzac52r51Xg; Tue, 09 Jun 2009 15:05:01 +0000
Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 1r511c00M4LCBKY3Ur51GT; Tue, 09 Jun 2009 15:05:01 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 09 Jun 2009 11:05:00 -0400
To: Peter Sylvester <[e-mail]>, pkix <[e-mail]>
From: Michael StJohns <[e-mail]>
Subject: Re: CRLNumber definition and MAX
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59EZhH9072471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 07:35:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59EZhrU072470; Tue, 9 Jun 2009 07:35:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59EZgPN072463 for <[e-mail]>; Tue, 9 Jun 2009 07:35:43 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id D68C070; Tue,  9 Jun 2009 16:35:20 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2009060916351901:21412 ; Tue, 9 Jun 2009 16:35:19 +0200 
Message-ID: <[e-mail]>
Date: Tue, 09 Jun 2009 16:35:19 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: "Kemp, David P." <[e-mail]>
Cc: pkix <[e-mail]>
Subject: Re: CRLNumber definition and MAX
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 06/09/2009 04:35:19 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 06/09/2009 04:35:40 PM, Serialize complete at 06/09/2009 04:35:40 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59EP0EK071895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 07:25:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59EP0c3071894; Tue, 9 Jun 2009 07:25:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59EOnvL071855 for <[e-mail]>; Tue, 9 Jun 2009 07:25:00 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id F180E7F; Tue,  9 Jun 2009 16:24:47 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2009060916244744:21371 ; Tue, 9 Jun 2009 16:24:47 +0200 
Message-ID: <[e-mail]>
Date: Tue, 09 Jun 2009 16:24:47 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: "Kemp, David P." <[e-mail]>
Cc: pkix <[e-mail]>
Subject: Re: CRLNumber definition and MAX
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 06/09/2009 04:24:47 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 06/09/2009 04:24:47 PM, Serialize complete at 06/09/2009 04:24:47 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59CVGvV064979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 05:31:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59CVGsZ064978; Tue, 9 Jun 2009 05:31:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59CV4nf064963 for <[e-mail]>; Tue, 9 Jun 2009 05:31:15 -0700 (MST) (envelope-from [e-mail])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: CRLNumber definition and MAX
Date: Tue, 9 Jun 2009 08:26:03 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: CRLNumber definition and MAX
Thread-Index: Acno+j+hr6Kl8f8BTVuhiJu+i6T/ZgAAcB9g
References: <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 09 Jun 2009 12:19:35.0031 (UTC) FILETIME=[8CE9E070:01C9E8FC]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59BK9bJ060506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 04:20:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n59BK95m060505; Tue, 9 Jun 2009 04:20:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59BJvFp060479 for <[e-mail]>; Tue, 9 Jun 2009 04:20:08 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 086D170 for <[e-mail]>; Tue,  9 Jun 2009 13:19:56 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2009060913195485:20858 ; Tue, 9 Jun 2009 13:19:54 +0200 
Message-ID: <[e-mail]>
Date: Tue, 09 Jun 2009 13:19:54 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: CRLNumber definition and MAX
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 06/09/2009 01:19:54 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 06/09/2009 01:19:55 PM, Serialize complete at 06/09/2009 01:19:55 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n599FvDV053541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 02:15:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n599FvUh053540; Tue, 9 Jun 2009 02:15:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brendan.brad.office.comodo.net (brad.comodogroup.com [82.109.38.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n599FsWd053534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 9 Jun 2009 02:15:56 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 2636 invoked by uid 1000); 9 Jun 2009 09:15:54 -0000
Received: from nigel.brad.office.comodo.net (HELO nigel.brad.office.comodo.net) (192.168.0.58) (smtp-auth username rob, mechanism login) by brendan.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Tue, 09 Jun 2009 10:15:54 +0100
From: Rob Stradling <[e-mail]>
Organization: COMODO CA Limited
To: "IETF-pkix" <[e-mail]>
Subject: Re: RSA Signature Padding
Date: Tue, 9 Jun 2009 10:15:48 +0100
User-Agent: KMail/1.9.9
Cc: "Santosh Chokhani" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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/[e-mail]/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: [phone]
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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n598lvkq051958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 01:47:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n598lvQL051957; Tue, 9 Jun 2009 01:47:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brendan.brad.office.comodo.net (brad.comodogroup.com [82.109.38.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n598lgF9051948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 9 Jun 2009 01:47:55 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 28851 invoked by uid 1000); 9 Jun 2009 08:47:41 -0000
Received: from nigel.brad.office.comodo.net (HELO nigel.brad.office.comodo.net) (192.168.0.58) (smtp-auth username rob, mechanism login) by brendan.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Tue, 09 Jun 2009 09:47:41 +0100
From: Rob Stradling <[e-mail]>
Organization: COMODO CA Limited
To: [e-mail], Lydia Zieglar <[e-mail]>, Jim Solinas <[e-mail]>
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
User-Agent: KMail/1.9.9
Cc: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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: [phone]
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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58DMBdq000799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 06:22:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58DMBUd000798; Mon, 8 Jun 2009 06:22:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58DLxMU000767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Jun 2009 06:22:10 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 2801d2a4.2926185392.136328.00-017.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Mon, 08 Jun 2009 07:22:10 -0600 (MDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RSA Signature Padding
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 8 Jun 2009 09:21:58 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RSA Signature Padding
thread-index: AcnoLDQJKvMLt1XNR8GL1Dklc0U5swAD0avw
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Simon Josefsson" <[e-mail]>
Cc: "Tom Gindin" <[e-mail]>, "IETF-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009052001)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]=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" <[e-mail]> 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:[e-mail]]
> >> 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" <[e-mail]> Sent by:=20
> >> [e-mail]
> >> 06/03/2009 12:58 PM
> >>=20
> >> To
> >> "IETF-pkix" <[e-mail]>
> >> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58BSOg1094766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 04:28:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58BSOGY094765; Mon, 8 Jun 2009 04:28:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58BSBr0094743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 8 Jun 2009 04:28:23 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n58BS25g003542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Jun 2009 13:28:04 +0200
From: Simon Josefsson <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: "Tom Gindin" <[e-mail]>, "IETF-pkix" <[e-mail]>
Subject: Re: RSA Signature Padding
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090608:[e-mail]::8QYg5VI2Rowow4F5:Le/Q
X-Hashcash: 1:22:090608:[e-mail]::AUwzyAaWC3sJ/Apx:xmjr
X-Hashcash: 1:22:090608:[e-mail]::KZNIvgzasLQZ/D99:SoXc
Date: Mon, 08 Jun 2009 13:28:03 +0200
In-Reply-To: <[e-mail]> (Santosh Chokhani's message of "Mon, 8 Jun 2009 06:43:11 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> 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:[e-mail]] 
>> 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" <[e-mail]> Sent by: 
>> [e-mail]
>> 06/03/2009 12:58 PM
>> 
>> To
>> "IETF-pkix" <[e-mail]>
>> 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"
>> 
>> 
>> 
>> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58AhO6R092323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 03:43:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58AhO9x092322; Mon, 8 Jun 2009 03:43:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58AhCuF092315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 8 Jun 2009 03:43:23 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id b4bec2a4.1901063088.76902.00-002.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Mon, 08 Jun 2009 04:43:23 -0600 (MDT)
Subject: RE: RSA Signature Padding
Date: Mon, 8 Jun 2009 06:43:11 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-TNEF-Correlator: 
Thread-Topic: RSA Signature Padding
thread-index: Acnn067x/v/+nYocS4GQ7/KYCfRBmQAUf9+w
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: "IETF-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009052001)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]=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" <[e-mail]> Sent by:=20
> [e-mail]
> 06/03/2009 12:58 PM
>=20
> To
> "IETF-pkix" <[e-mail]>
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n580sfrQ068845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jun 2009 17:54:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n580sfR2068844; Sun, 7 Jun 2009 17:54:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n580sS5D068833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 7 Jun 2009 17:54:39 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e7.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n580gTvM019405 for <[e-mail]>; Sun, 7 Jun 2009 20:42:29 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n580sROj150102 for <[e-mail]>; Sun, 7 Jun 2009 20:54:27 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n580sRqI006411 for <[e-mail]>; Sun, 7 Jun 2009 20:54:27 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n580sRNE006360; Sun, 7 Jun 2009 20:54:27 -0400
In-Reply-To: <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: "IETF-pkix" <[e-mail]>
MIME-Version: 1.0
Subject: Re: RSA Signature Padding
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Sun, 7 Jun 2009 20:54:27 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 06/07/2009 20:54:27, Serialize complete at 06/07/2009 20:54:27
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        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" <[e-mail]> 
Sent by: [e-mail]
06/03/2009 12:58 PM

To
"IETF-pkix" <[e-mail]>
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"





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55N9gYp060066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 16:09:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n55N9guE060065; Fri, 5 Jun 2009 16:09:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55N9Y1r060053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 16:09:35 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624080ec64f538fe0bb@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 5 Jun 2009 16:09:32 -0700
To: Sean Turner <[e-mail]>, [e-mail], Lydia Zieglar <[e-mail]>, Jerry Solinas <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate  and Certificate Revocation List (CRL) Profile) to Informational RFC
Cc: pkix <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55GdMQf041097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 09:39:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n55GdMBJ041096; Fri, 5 Jun 2009 09:39:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n55GdA8O041087 for <[e-mail]>; Fri, 5 Jun 2009 09:39:20 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 14158 invoked from network); 5 Jun 2009 16:39:10 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.241.12.137 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 5 Jun 2009 16:39:09 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: 7_8ARlwVM1kLySLVhnUB9dqo1TH.24kChSM7eW5snyVSApVQvbsgv0a2OvYvnxp4GDG1HKUoccCT_fFs6.CJi_0AwRTOR4pFpZ4xMGZXyXwv_jZieDqTnn6tBL8jWqGdrIij3PCl6uCaa8d04vWZhtBqaHNtUDoETtEKgcSTOce_xYPtBr3LO2G.SR5s500F6Va8mnecKoejPhYIyUw6wv5_fU_1s9BZ5eOvJfaFfOnetUYUvSky2tu73HWZUmhZ9XwxSEbr6yc9ALUH0tWVx_ePG9G.j1JA1pOT6jRWb.L6suyYqSdIyH5ghJAXOR_AVcNwO45qkC6mAPtljHqPDfRejVkgMik0HFno
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Fri, 05 Jun 2009 12:39:09 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: [e-mail], Lydia Zieglar <[e-mail]>, Jim Solinas <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B 	Certificate and Certificate Revocation List (CRL) Profile) to 	Informational RFC
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> 
> - 'Suite B Certificate and Certificate Revocation List (CRL) Profile '
>    <draft-solinas-suiteb-cert-profile-03.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [e-mail] mailing lists by 2009-07-01. Exceptionally, 
> comments may be sent to [e-mail] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-03.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18056&rfc_flag=0
> 

Lydia and Jim,

Here are some comments.

#1 Non-repudiation bit

During the development of other profiles where the NR bit wasn't set, 
sometime after the profile gets developed I've usually gotten questions 
like "so you're not setting N-R can I use it for non-repudiation 
services?"  To answer this question, I sometimes put text in that said 
yes you can (below).  Maybe we should add something like this maybe in 
the security considerations?

Note that setting keyCertSign, cRLSign, and digitialSignature also means
that the certificate could be used by applications that require
non-repudiation services for certificate, CRL, and content signing,
respectively.

#2 Section 3.1 (add dashes)

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

#3 Section 3.2 (add a new line):

OLD:

       certicom-arc OBJECT IDENTIFIER ::= {
          iso(1) identified-organization(3) certicom(132) }
       id-ecPublicKey OBJECT IDENTIFIER ::= {
          ansi-X9-62 keyType(2) 1 }

NEW:

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

       id-ecPublicKey OBJECT IDENTIFIER ::= {
          ansi-X9-62 keyType(2) 1 }

#4 Section 4.2 (add reference to 5480 and ECDSA-Sig-Value)

I sometimes think it's easier to understand that we've defined an ASN.1
structure for the r/s combo:

  ECDSA-Sig-Value ::= SEQUENCE {
      r  INTEGER,
      s  INTEGER
    }

It's in RFC 3279 and in RFC 5480.  Don't point to X9.62 they did some
odd things to this structure.  Maybe the 2nd para in 4.2 could be
changed as follows:

OLD:

The ECDSA signatureValue in an X.509 certificate is encoded as a BIT
STRING value of a DER encoded SEQUENCE of the two INTEGERS.  For
example, in a signature using P-256 and hex notation:

NEW:

The ECDSA signatureValue in an X.509 certificate is encoded as a BIT
STRING value of a DER encoded SEQUENCE of the two INTEGERS.  As per
[RFC5480], the structure, included for convenience, is as follows:

  ECDSA-Sig-Value ::= SEQUENCE {
      r  INTEGER,
      s  INTEGER
    }

For example, in a signature using P-256 and hex notation:

#5 Question: 4.2 Conversion Routine

Aren't the conversion routines in SEC1 and ANSI X9.62 the same?  5480
pointed to SEC1 because it was more readily available (online and free
versus online and not free for ANSI).  Curious why you chose to point to
3279 and not 5480?  2.3.5 of 3279 points to 4.3.3 and 4.3.6 of ANSI
X9.62.  2.2 of 5480 points to 2.3.1 and 2.3.2 of SEC1G. If we don't
point to 3279 here and the next one, you could delete it as a reference.

#6 Section 4.2 5th para: r/RFC3279/RFC5480  (the same routine is in 5480
section 2.2)

#7 Section 4.5.2: r/[5280]/[RFC5280]

Cheers,

spt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n53HKGpZ051972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 10:20:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n53HKGWV051971; Wed, 3 Jun 2009 10:20:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n53HK5KO051953 for <[e-mail]>; Wed, 3 Jun 2009 10:20:15 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7D3389A4726 for <[e-mail]>; Wed,  3 Jun 2009 13:20:09 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id Ax5VAm1J-47k for <[e-mail]>; Wed,  3 Jun 2009 13:20:03 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (pool-96-255-70-130.washdc.fios.verizon.net [96.255.70.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 56D03F24008 for <[e-mail]>; Wed,  3 Jun 2009 13:20:08 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 03 Jun 2009 13:19:57 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Fwd: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate and Certificate Revocation List (CRL) Profile) to Informational RFC 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>To: IETF-Announce <[e-mail]>
>From: The IESG <[e-mail]>
>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
>[e-mail] mailing lists by 2009-07-01. Exceptionally,
>comments may be sent to [e-mail] instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-03.txt
>
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18056&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n53GwwmI049266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 09:58:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n53Gww5C049264; Wed, 3 Jun 2009 09:58:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n53Gwkq6049246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 3 Jun 2009 09:58:57 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 1dba62a4.2180758448.140358.00-021.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Wed, 03 Jun 2009 10:58:57 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RSA Signature Padding
Date: Wed, 3 Jun 2009 12:58:45 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RSA Signature Padding
Thread-Index: AcnkbI6Azla2DhYqRqKN/ve9UCBQrg==
From: "Santosh Chokhani" <[e-mail]>
To: "IETF-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009052001)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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"