Subject: scottano

From: "shoaib Heshiki" <[email-masked]>
Date: Wed, 31 Oct 2007 23:00:44 +0100

hello mom pkix-archive
she said she was impossible to please, may be you can with 3 inches more
http://www.chayzy.com/

shoaib Heshiki

Date: Wed, 31 Oct 2007 15:55:58 -0500
From: "Akil DeOliveira" <[email-masked]>
Reply-To: "Akil DeOliveira" <[email-masked]>
To: <[email-masked]>
Subject: atiot

hey you ietf-pkix-archive
as far as everyone can see, your dick needs some serious improvement
http://babaztag.com/

Akil DeOliveira

From: Stefan Santesson <[email-masked]>
To: Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 29 Oct 2007 09:35:07 +0000
Subject: RE: Call for agenda items - Vancouver IETF
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Just a friendly reminder.

So far the number of received requests is 0.
Thanks.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Stefan Santesson
Sent: den 22 oktober 2007 19:36
To: [email-masked]
Subject: Call for agenda items - Vancouver IETF

Vancouver IETF is coming up.

Please send me requests for agenda slots.
As usual I would appreciate if editors of current documents let me know if =
they want a slot and their assessment of the current status.

I would appreciate requests to be sent to me as soon as possible and at lat=
est Friday November 2nd.

Thank you.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

--_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.w3.org/TR/REC-html40" xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope=
/" xmlns:D=3D"DAV:" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sps=3D"http://schemas=
.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSch=
ema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile"=
 xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:=
mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:=
m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http:=
//schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"http=
://schemas.microsoft.com/exchange/services/2006/messages" xmlns=3D"http://w=
ww.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span style=3D'color:#1F49=
7D'>Just a
friendly reminder.<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>So far the =
number of
received requests is 0.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Thanks.<o:p=
></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stefan Santesson<=
br>
<b>Sent:</b> den 22 oktober 2007 19:36<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Call for agenda items - Vancouver IETF<o:p></o:p></span></p=

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US>Vancouver IETF is coming up.<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Please send me requests for agenda =
slots.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I would appreciate if edit=
ors of current
documents let me know if they want a slot and their assessment of the curre=
nt
status.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I would appreciate requests to be s=
ent to
me as soon as possible and at latest Friday November 2<sup>nd</sup>.<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Thank you.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</div>

</body>

</html>

--_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_--

Date: Fri, 26 Oct 2007 22:51:47 -0400
From: "Rosalie Monroe" <[email-masked]>
To: [email-masked]
Subject: Good clothes open all doors.

If your "prick-horse" is not glad for you and give brake for you come to us.
You'll feel that curb "it" is impossible.
You must come to us now and you'll be a real cowboy legend.
We wait you today, because the hot week of discounts is now.
Don't miss your chance. http://ovloxq.partywill.cn/?808817644044

From: "Erik Andersen" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "'Hoyt L Kesterson II'" <[email-masked]>, <[email-masked]>
Subject: RE: Upper Bounds for X.509
Date: Fri, 26 Oct 2007 11:28:41 +0200
Importance: Normal
Sender: [email-masked]

PKIX could impose upper bounds on anything they want without this being
reflected in the ASN.1, but in English text.

Erik Andersen
Andersen's L-Service
Mobile: +45 20 97 14 90
e-mail: [email-masked]
http://www.x500standard.com/
http://home20.inet.tele.dk/era/me

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Russ Housley
> Sent: 22. oktober 2007 11:34
> To: Hoyt L Kesterson II; [email-masked]
> Subject: Re: Upper Bounds for X.509
> 
> 
> Hoyt:
> 
> One never knows which non-critical extensions might be put in a
> certificate.  Remember when Bob Jueneman was advocating pictures in
> certificates....
> 
> Russ
> 
> 
> At 04:30 AM 10/22/2007, Hoyt L Kesterson II wrote:
> 
> >Steven, I didn't say it was an attractive option. I have always been
> >against these limits.
> >
> >Peter Gutmann recommended that "reasonable" upper bounds be set,
> >e.g. thousand characters for a common name. But it appears his
> >concern is about erratic operation when the certificate itself it huge.
> >
> >It may be more reasonable to set a max size on the entire
> >certificate than on the individual components that comprise it.
> >
> >    hoyt
> >
> > >Hoyt,
> > >
> > >Hoyt L Kesterson II wrote:
> > >>Another option is to keep the bounds as we have them and have the
> > IETF standard mandate the bounds, choosing any values you like.
> > >
> > >Then directory deployments would have to choose between being nice
> > >to PKIX applications by imposing PKIX's upper bounds, or being
> > >nice to other LDAP applications by not imposing upper bounds.
> > >
> > >Regards,
> > >Steven

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Date: Thu, 25 Oct 2007 05:50:10 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Julien,

It is very simple.  Point to me to the specific post or e-mail me (not
the entire mail list) your protection approach.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Stern
Sent: Thursday, October 25, 2007 4:44 AM
To: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution
of DR320"

Santosh,

I think you are being a bit unfair, as I did explain on the list
as clearly as I could the attack and the protection (early Nov 2004).

Anyway, I do not feel like boring other readers to death by starting
the whole discussion once again.

Maybe we can sit down at a table and chat if we happen to meet at a
conference someday :)

Regards,

--
Julien

On Mon, Oct 22, 2007 at 10:41:10AM -0700, Santosh Chokhani wrote:
> Julien,
> 
> What I recall is that your attack was a CA trusted to issue CA
> certificates by the relying party going rogue.  X.509 does not protect
> against that.
> 
> You also mentioned that you had protection against it, you were
> unwilling to share it, and you said that you will share it after you
> publish your work.
> 
> I have yet to see your proposal.
> 
> As a matter of fact on PKIX or X.500 forum within last year again I
> asked you to share your proposal and you never replied.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Julien Stern
> Sent: Monday, October 22, 2007 10:34 AM
> To: [email-masked]
> Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution
> of DR320"
> 
> 
> On Mon, Oct 22, 2007 at 06:18:22AM -0700, Santosh Chokhani wrote:
> > 
> > We have been down this route before.
> 
> Oooooh Yes. Lots of fun and (gentle) arguments...
> 
> > See my presentation to PKIX in Fall 2004 IETF meeting in Washington
> DC.
> > 
> > My understanding from 2004 presentation was that Russ Housley
proposed
> instead of ensuring certificate certification path and CRL
certification
> path matching, we make sure that we ensure that the paths begin at the
> same trust anchor.  It was felt by the group (not I) that coupled with
> name constraints in cross certified environment is sufficient to
> mitigate the risk to an acceptably low level.  Of course, my argument
> always has been that using the certificate certification path to
> constrain the CRL certification path provides you both with security
and
> efficiency, something you do not always get.  The primary reason to
not
> adopt my suggestion is that it requires change to client software.
> 
> I did not feel either that trust anchor matching was sufficient
enough.
> 
> As you may remember, I also felt that your proposed solution, while
> improving the situation, did not close every possible attacks, and I
> proposed an alternative that was (in my humble opinion) even more
secure
> but with even more changes on the client software.
> 
> Anyway, my current take on the subject would be roughly the following.
> RFC3280bis could include something in the line of:
> 
> "The uniqueness of DN of all entities in all the Trust Anchors
> hierarchies SHOULD be enforced. If the uniqueness cannot be guaranteed
> in some circonstances, client software MAY implement additional checks
> in order to lower the risk of outputing an incorrect revocation value
> during
> path validation. [We could give example of additional checks here:
> checking the trust anchor matching, check the full path matching,
> checking the AuthorityKeyIdentifier hash matching, etc]. Client
> implementors should however be aware that these additional checks may
> hinder interoperability in the general case."
> 
> --
> Julien
> 
> 

From: "Julien Stern" <[email-masked]>
Date: Thu, 25 Oct 2007 10:43:58 +0200
To: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

Santosh,

I think you are being a bit unfair, as I did explain on the list
as clearly as I could the attack and the protection (early Nov 2004).

Anyway, I do not feel like boring other readers to death by starting
the whole discussion once again.

Maybe we can sit down at a table and chat if we happen to meet at a
conference someday :)

Regards,

--
Julien

On Mon, Oct 22, 2007 at 10:41:10AM -0700, Santosh Chokhani wrote:
> Julien,
> 
> What I recall is that your attack was a CA trusted to issue CA
> certificates by the relying party going rogue.  X.509 does not protect
> against that.
> 
> You also mentioned that you had protection against it, you were
> unwilling to share it, and you said that you will share it after you
> publish your work.
> 
> I have yet to see your proposal.
> 
> As a matter of fact on PKIX or X.500 forum within last year again I
> asked you to share your proposal and you never replied.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Julien Stern
> Sent: Monday, October 22, 2007 10:34 AM
> To: [email-masked]
> Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution
> of DR320"
> 
> 
> On Mon, Oct 22, 2007 at 06:18:22AM -0700, Santosh Chokhani wrote:
> > 
> > We have been down this route before.
> 
> Oooooh Yes. Lots of fun and (gentle) arguments...
> 
> > See my presentation to PKIX in Fall 2004 IETF meeting in Washington
> DC.
> > 
> > My understanding from 2004 presentation was that Russ Housley proposed
> instead of ensuring certificate certification path and CRL certification
> path matching, we make sure that we ensure that the paths begin at the
> same trust anchor.  It was felt by the group (not I) that coupled with
> name constraints in cross certified environment is sufficient to
> mitigate the risk to an acceptably low level.  Of course, my argument
> always has been that using the certificate certification path to
> constrain the CRL certification path provides you both with security and
> efficiency, something you do not always get.  The primary reason to not
> adopt my suggestion is that it requires change to client software.
> 
> I did not feel either that trust anchor matching was sufficient enough.
> 
> As you may remember, I also felt that your proposed solution, while
> improving the situation, did not close every possible attacks, and I
> proposed an alternative that was (in my humble opinion) even more secure
> but with even more changes on the client software.
> 
> Anyway, my current take on the subject would be roughly the following.
> RFC3280bis could include something in the line of:
> 
> "The uniqueness of DN of all entities in all the Trust Anchors
> hierarchies SHOULD be enforced. If the uniqueness cannot be guaranteed
> in some circonstances, client software MAY implement additional checks
> in order to lower the risk of outputing an incorrect revocation value
> during
> path validation. [We could give example of additional checks here:
> checking the trust anchor matching, check the full path matching,
> checking the AuthorityKeyIdentifier hash matching, etc]. Client
> implementors should however be aware that these additional checks may
> hinder interoperability in the general case."
> 
> --
> Julien
> 
> 

From: "Marika" <[email-masked]>
To: "Tim" <[email-masked]>
Subject: i want to know you!
Date: Tue, 23 Oct 2007 20:32:33 +0300

Aloha, my gentleman!

Please, open windows into your heart. I know that you are embarrassed, what
you can have common with woman from far Ukraine, the country which is
situated at the another part of the world. Before writing to you this
letter, I was puzzled by this question too till I have not found  the answer
and you here. We are both lonely and want the same: to find love and to be
happy. Am I right?
I am not risky person, but I want to risk this time, because it is the one
chance to get acquainted with you and to create couple with you.
I am kind-hearted, pretty woman who is able to love and take care.
If my words touched your heart and you want to find your love, write me here
http://russobride.info/?idAff=101

Yourth faithfully

Marinochka

From: "manju DeBenedictis" <[email-masked]>
To: <[email-masked]>
Subject: 0tnuah
Date: Tue, 23 Oct 2007 14:44:18 +0100

------=_NextPart_000_0006_01C81583.30C8E370
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Watcha! ietf-pkix-archive
is she faking it? take care of that and make your dick big
http://www.parsno.com/

manju DeBenedictis
------=_NextPart_000_0006_01C81583.30C8E370
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT Arial size=3D2>Watcha! ietf-pkix-archive</FONT></DIV>
<DIV><FONT Arial size=3D2>is she faking it? take care of that and make =
your dick=20
big</FONT></DIV>
<DIV><FONT Arial size=3D2><A=20
HREF=3D"http://www.parsno.com/">http://www.parsno.com/</A></FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>manju DeBenedictis</FONT></DIV></BODY></HTML>

------=_NextPart_000_0006_01C81583.30C8E370--

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement,      "Liaison to IETF on the resolution  of  DR320"
Date: Tue, 23 Oct 2007 04:14:56 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

It is a bit worse than that.  This has become our Autumn Ritual since
2004.  May be we should make a movie on this "Same Time, Same Place,
Same Debate Next Year"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Tuesday, October 23, 2007 5:43 AM
To: Santosh Chokhani
Cc: Denis Pinkas; [email-masked]
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution
of DR320"

As pointed out, we discussed this some time ago and ended
up with the current 3280bis text. Repeating the arguments
will only consume cycles.

Stephen.

Date: Tue, 23 Oct 2007 10:42:59 +0100 (IST)
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
From: [email-masked]
To: "Santosh Chokhani" <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Importance: Normal
Sender: [email-masked]

As pointed out, we discussed this some time ago and ended
up with the current 3280bis text. Repeating the arguments
will only consume cycles.

Stephen.

Date: Mon, 22 Oct 2007 20:11:49 -0400 (EDT)
From: Hoyt L Kesterson II <[email-masked]>
Reply-To: Hoyt L Kesterson II <[email-masked]>
To: [email-masked]
Subject: Re: New Liaison Statement,
Sender: [email-masked]

The ITU is not in disagreement. Its Study Group Plenary sent the IETF (not just PKIX) a liaison stating that it had rejected DR 320. It believes that the problems described by DR 320 would not exist if the concept of unambiguous naming is followed as described in the standard.

It believes that if such a problem exists, those environments that permit such duplicate naming should address the problem. If the IETF feels that the problem need not be addressed for whatever reason, then the IETF can respond with that position.

I only advise that "words fail me" would not be an understandable response to the folks back in Geneva.

   hoyt

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Oct 22, 2007 7:16 PM
>To: Denis Pinkas <[email-masked]>, "[email-masked]" <[email-masked]>
>Cc: Russ Housley <[email-masked]>
>Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"
>
>
>At 1:52 PM +0200 10/22/07, Denis Pinkas wrote:
>>I agree with what you say. However", Words fail me" may have 
>>multiple interpretations.
>>We are going to invent a mechanism to prevent conflict, e.g. a list 
>>of existing CA
>>names that deployers of new CAs could check for naming conflicts.
>
>When you say "We", if you mean the IETF, then, yes, you have indeed 
>gotten the wrong sense of my statement.
>
>>The implications are that DR 320 has been rejected by the directory 
>>group on a wrong basis.
>
>It would be unwise for the PKIX WG to get embroiled in the ITU's 
>disagreements here. We should wait for a clear statement from them 
>about what they believe is their response to the issue, then we can 
>work with that.
>
>--Paul Hoffman, Director
>--VPN Consortium
>

Date: Mon, 22 Oct 2007 16:16:09 -0700
To: "Denis Pinkas" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"
Cc: "Russ Housley" <[email-masked]>
Sender: [email-masked]

At 1:52 PM +0200 10/22/07, Denis Pinkas wrote:
>I agree with what you say. However", Words fail me" may have 
>multiple interpretations.
>We are going to invent a mechanism to prevent conflict, e.g. a list 
>of existing CA
>names that deployers of new CAs could check for naming conflicts.

When you say "We", if you mean the IETF, then, yes, you have indeed 
gotten the wrong sense of my statement.

>The implications are that DR 320 has been rejected by the directory 
>group on a wrong basis.

It would be unwise for the PKIX WG to get embroiled in the ITU's 
disagreements here. We should wait for a clear statement from them 
about what they believe is their response to the issue, then we can 
work with that.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Date: Mon, 22 Oct 2007 14:43:39 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Denis,

I am not sure you and I should be discussing this on the mail list, if the goal of our effort is to facilitate consensus.  Last time we did that, we put people to sleep.  It is time for others to comment on the topic.  I know we are trying to fill a security hole using technical means as opposed to assuming that there are no CA name collisions.

As to my proposal, it calls for an exact match of DNs in the certification path, but accounts for self-issued certificates due to CA re-key.  I encourage you to look at the detailed briefing presented at PKIX Fall 2004.  I assume it is still available via IETF.

As to the paper presented at NIST 2005 Research Conference, it is actually NIST 2006 Research Conference.  The URL is provided below.  This also has been posted on PKIX before.

The briefing (NIST workshop, not IETF) is at:
http://middleware.internet2.edu/pki06/proceedings/

The full paper is at:
http://csrc.nist.gov/publications/nistir/ir-7313/NIST-IR-7313_Final.pdf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, October 22, 2007 9:37 AM
To: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"

Santosh,

>We have been down this route before.

>See my presentation to PKIX in Fall 2004 IETF meeting in Washington DC.

> My understanding from 2004 presentation was that Russ Housley proposed instead of 
> ensuring certificate certification path and CRL certification path matching, 

Unless the client software knows by "other means" what to do, this is the default way 
to make the whole system secure.
 
> we make sure that we ensure that the paths begin at the same trust anchor.  

This helps, but it is fra from sufficient.

> It was felt by the group (not I) that coupled with name constraints in cross certified 
> environment is sufficient to mitigate the risk to an acceptably low level.  

Reducing the risk does not suppress it.

> Of course, my argument always has been that using the certificate 
> certification path to constrain the CRL certification path provides you both with security and 
> efficiency, something you do not always get.  

"Constraining" does not mean "identical". Would you be more precise ?

> The primary reason to not adopt my suggestion is that it requires change to client software.

Since most of the clients are insecure today in case of a DN name collision, it is time to fix it.

>Also see our paper in NIST PKI Research Workshop in 2005 for a discussion of this.

Would you have a link ?

Denis

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Monday, October 22, 2007 7:58 AM
>To: [email-masked]
>Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
>
>
>Russ said:
>
>>It seems to me that this is a trust anchor configuration concern.  
>
>Not only.
>
>> If two CAs adopt the same name and a user accepts both of these CAs as 
>>trust anchors, then there could be a problem.  Just don't do it.
>
>This is correct, but insufficient. This does not prevent two CAs somewhere 
>under this trust anchor to use the same name in different branches.
>
>>RFC 3280bis says:
>
>>    While X.509 mandates that names be unambiguous, there is a risk that
>>    two unrelated authorities will issue certificates and/or CRLs under
>>    the same issuer name.  
>
>This is correct. This sentence contradicts the response to DR 320.
>
>>    As a means of reducing problems and security
>>    issues related to issuer name collisions, CA and CRL issuer names
>>    SHOULD be formed in a way that reduces the likelihood of name
>>    collisions.  
>
>This recommandation does not *prevent* "problems and security issues".
>This sentence should be deleted or changed. 
>
>>    Implementers should take into account the possible
>>    existence of multiple unrelated CAs and CRL issuers with the same
>>    name.  
>
>This is fully correct.
>
>>    At a minimum, implementations validating CRLs MUST ensure that
>>    the certification path of a certificate and the CRL issuer
>>    certification path used to validate the certificate terminate at the
>>    same trust anchor.
>
>This "minimum" clause is both insufficient and insecure. 
>This sentence gives a false sense of security.
>
>This means that RFC3280bis currently provides no coorect guidance 
>on how implementers should address this issue. 
>
>The following text is an attempt to address this issue:
>
>"Implementations validating indirect CRLs MUST make sure that the 
>certificate of the CRL Issuer is indeed issued by the CA that issued 
>the certificate to be verified, which means that the sequence of DNs 
>of the certification path of the CRL issuer, up to the DN of a trust anchor, 
>must be identical to the the sequence of DNs of the certification path 
>of the certificate to be verified, up to the DN of the same trust anchor".
>
>Denis
>
>>Russ
>>
>>At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
>>
>>>Title: Liaison to IETF on the resolution of DR320
>>>Submission Date: 2007-10-05
>>>URL of the IETF Web page: 
>>>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>>>Please reply by 2008-03-01
>>>
>>>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>>>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
>>><[email-masked]>)
>>>Cc: Herbert Bertine <[email-masked]>
>>><[email-masked]>
>>><[email-masked]>
>>><[email-masked]>
>>>Reponse Contact: Xiaoya YANG <[email-masked]>
>>><[email-masked]>
>>>Technical Contact: <[email-masked]>
>>><[email-masked]>
>>>Purpose: For action
>>>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>>>rejected Defect Report 320 
>>>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>>>AFNOR.  This DR advanced an argument that Distinguished Names may 
>>>not be unique and as such, the DN of the Certificate User may not be unique.
>>>The directory group believes that Distinguished Name values must be 
>>>unique and unambiguously identify a single entity, hence the use of 
>>>the term Distinguished.
>>>The DR states Ã¢â‚¬Å“the DN of the issuer name cannot be guaranteed to 
>>>be uniqueÃ¢â‚¬Â.  X.509 takes its definition of DN from X.501.  Clause 
>>>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>>>clause states A name shall be unambiguous, that is, denotes just one object.
>>>Clause 9 goes on to state: It is the responsibility of the relevant 
>>>naming authority for an entry to ensure that this is so by 
>>>appropriately assigning distinguished attribute values.  Allocation 
>>>of RDNs is considered an administrative undertaking that may or may 
>>>not require some negotiation between involved organizations or 
>>>administrations.  This Directory Specification does not provide such 
>>>a negotiation mechanism, and makes no assumption as to how it is performed.
>>>The standard takes an axiomatic view of the concept that a 
>>>distinguished name unambiguously identifies a single entity.  Things 
>>>break if two entities identify themselves using the same name.  We 
>>>don't let two entities have the same domain name or the same email 
>>>address.  Why? - because things wouldn't work.
>>>The directory group does not accept the DRÃ¢â‚¬â„¢s basic argument.  We 
>>>believe that if two entities present the same name and a CA issues a 
>>>certificate to each, that CA made a mistake - not a naming authority 
>>>mistake, since a CA is not an naming authority (although one entity 
>>>can be both), but an entity to key binding mistake that leads to 
>>>confusion and even worse, a security risk.
>>>We believe that if two entities claim the same name as top level 
>>>CAs, there is a political/procedural breakdown much like the domain 
>>>ownership arguments we have seen.  No one argues that the Internet 
>>>protocols should be modified to solve that problem.  The conflict is 
>>>resolved and one entity is assigned the name.  The group believes 
>>>that this is the only reasonable solution for Distinguished 
>>>Naming.  One votes for the CA of choice by configuring it as an anchor.
>>>One of the participants in the directory meeting stated that 
>>>Certification Authorities are being deployed with names not acquired 
>>>from naming authorities but with names arbitrarily chosen assuming 
>>>that no other CA is or will be operating under that name.  That 
>>>participant further stated that the IETF provides no guidelines on 
>>>ensuring that the names of CAs are unambiguous.
>>>The directory group requests the IETF PKIX group to comment on this 
>>>statement.  If the statement is correct, we ask the IETF to consider 
>>>putting a mechanism in place to prevent conflict, e.g. a list of 
>>>existing CA names that deployers of new CAs could check for naming conflicts.
>>>Attachment(s):
>>>No document has been attached
>>
>
>Regards,
>
>Denis Pinkas
>
>

Regards,

Denis Pinkas

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Date: Mon, 22 Oct 2007 10:41:10 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Julien,

What I recall is that your attack was a CA trusted to issue CA
certificates by the relying party going rogue.  X.509 does not protect
against that.

You also mentioned that you had protection against it, you were
unwilling to share it, and you said that you will share it after you
publish your work.

I have yet to see your proposal.

As a matter of fact on PKIX or X.500 forum within last year again I
asked you to share your proposal and you never replied.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Stern
Sent: Monday, October 22, 2007 10:34 AM
To: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution
of DR320"

On Mon, Oct 22, 2007 at 06:18:22AM -0700, Santosh Chokhani wrote:
> 
> We have been down this route before.

Oooooh Yes. Lots of fun and (gentle) arguments...

> See my presentation to PKIX in Fall 2004 IETF meeting in Washington
DC.
> 
> My understanding from 2004 presentation was that Russ Housley proposed
instead of ensuring certificate certification path and CRL certification
path matching, we make sure that we ensure that the paths begin at the
same trust anchor.  It was felt by the group (not I) that coupled with
name constraints in cross certified environment is sufficient to
mitigate the risk to an acceptably low level.  Of course, my argument
always has been that using the certificate certification path to
constrain the CRL certification path provides you both with security and
efficiency, something you do not always get.  The primary reason to not
adopt my suggestion is that it requires change to client software.

I did not feel either that trust anchor matching was sufficient enough.

As you may remember, I also felt that your proposed solution, while
improving the situation, did not close every possible attacks, and I
proposed an alternative that was (in my humble opinion) even more secure
but with even more changes on the client software.

Anyway, my current take on the subject would be roughly the following.
RFC3280bis could include something in the line of:

"The uniqueness of DN of all entities in all the Trust Anchors
hierarchies SHOULD be enforced. If the uniqueness cannot be guaranteed
in some circonstances, client software MAY implement additional checks
in order to lower the risk of outputing an incorrect revocation value
during
path validation. [We could give example of additional checks here:
checking the trust anchor matching, check the full path matching,
checking the AuthorityKeyIdentifier hash matching, etc]. Client
implementors should however be aware that these additional checks may
hinder interoperability in the general case."

--
Julien

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 22 Oct 2007 18:36:23 +0100
Subject: Call for agenda items - Vancouver IETF
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_E75F200AF1718F45B2024A88C3141A1D0647534474EAEXMSGC320eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Vancouver IETF is coming up.

Please send me requests for agenda slots.
As usual I would appreciate if editors of current documents let me know if =
they want a slot and their assessment of the current status.

I would appreciate requests to be sent to me as soon as possible and at lat=
est Friday November 2nd.

Thank you.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

--_000_E75F200AF1718F45B2024A88C3141A1D0647534474EAEXMSGC320eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m=3D"http://sc=
hemas.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>Vancouver IETF is coming up.<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Please send me requests for agenda =
slots.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I would appreciate if edit=
ors of
current documents let me know if they want a slot and their assessment of t=
he
current status.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I would appreciate requests to be s=
ent to
me as soon as possible and at latest Friday November 2<sup>nd</sup>.<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Thank you.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_E75F200AF1718F45B2024A88C3141A1D0647534474EAEXMSGC320eu_--

Date: Mon, 22 Oct 2007 16:55:12 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Sender: [email-masked]

>Denis,
>
>As you might have seen from some of my old posting on the list,
>I initially believed that there was a true "security flaw" in X.509
>regarding revocation.
>
>Now, my understanding is that the fact there is no name
>collision is an _assumption_ in X.509.

No name collision is simply an invalid assumption.

>If one wants to cope with name collisions there are several
>routes one can take depending on what the "adversary" is and
>the constraint one wants to put on the PKI topology.
>
>1) The first one is simply to assume that it can be detected
>and fixed.

It can't.

>2) One can cope with "accidental" name collision: I believe that is
>the route currently taken by PKIX by mandating trust anchor matching.

Same trust anchor is insufiicient.

>3) Your proposed wording copes with less accidental and more malicious
>attacks. 

It addresses the general case.

> I believe this is in the same spirit as Santosh Chokani
>proposal in 2004, (isn't it ?). 

No. Santosh was certainly mandating the same trust anchor, but this is not sufficient.
But I let Santosh explains. 

> However, it restricts the PKI topology and

It does not.

>I believe it is still open to some exotic attacts (see my posting from
>early November 2004).

I do not recall that you have explained an attack on that scheme.

>4) One can put even more restrictions on the PKI topology by mandating
>that a CA signs the CRL issuer keys with an explicit "CRL issuer" extension
>(similar to OCSP) and that the AuthorityKeyExtension (containing the
>hash of the key) be explicitely checked during the path building.

The AuthorityKeyExtension is not done for this.

>All in all, I believe it is close to impossible to define a general rule
>in the standard because some core assumptions regarding the uniqueness
>of the DNs and the adversarial model may not be the same between
>different PKIs.

It is possible to define a default rule.

Remember:

A DN issued by one CA is unique for that CA, but for that CA only.
Only a chain of DNs may be unique, starting from a trust anchor.

which means, as Russ noticed, that it is not allowed to have two different roots 
in a validation policy (or a signature policy) with the same DN.

Denis

>Regards,
>
>--
>Julien
>
>On Mon, Oct 22, 2007 at 03:16:32PM +0200, Denis Pinkas wrote:
>> 
>> Julien,
>> 
>> >On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote:
>> >>
>> >> [snip]
>> >
>> >Hi Denis,
>> >
>> >> This means that RFC3280bis currently provides no coorect guidance 
>> >> on how implementers should address this issue. 
>> >
>> >Agreed. There is a somewhat "matter of local policy-ish" issue here.
>> >
>> >> The following text is an attempt to address this issue:
>> >> 
>> >> "Implementations validating indirect CRLs MUST make sure that the 
>> >> certificate of the CRL Issuer is indeed issued by the CA that issued 
>> >> the certificate to be verified, which means that the sequence of DNs 
>> >> of the certification path of the CRL issuer, up to the DN of a trust anchor, 
>> >> must be identical to the the sequence of DNs of the certification path 
>> >> of the certificate to be verified, up to the DN of the same trust anchor".
>> >
>> >Forcing the CA to directly issue the CRL issuer certificate is way too
>> >restrictive in my humble opinion. I have an example of a PKI where there
>> >is a single (indirect) CRL issuer for about 20 CAs.
>> >
>> >The CRL issuer certificate is issued by the (Root) CA that issued
>> >those 20 CA certificates.
>> 
>> What about:
>> 
>> Unless a local policy states otherwise, implementations validating indirect CRLs 
>> MUST make sure that the certificate of the CRL Issuer is indeed issued by the CA 
>> that issued  the certificate to be verified, which means that the sequence of DNs 
>> of the certification path of the CRL issuer, up to the DN of a trust anchor, 
>> must be identical to the the sequence of DNs of the certification path 
>> of the certificate to be verified, up to the DN of the same trust anchor".
>> 
>> Denis
>> 
>> >Regards,
>> >
>> >--
>> >Julien
>> >
>> >> Denis
>> >> 
>> >> >Russ
>> >> >
>> >> >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
>> >> >
>> >> >>Title: Liaison to IETF on the resolution of DR320
>> >> >>Submission Date: 2007-10-05
>> >> >>URL of the IETF Web page: 
>> >> >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>> >> >>Please reply by 2008-03-01
>> >> >>
>> >> >>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>> >> >>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
>> >> >><[email-masked]>)
>> >> >>Cc: Herbert Bertine <[email-masked]>
>> >> >><[email-masked]>
>> >> >><[email-masked]>
>> >> >><[email-masked]>
>> >> >>Reponse Contact: Xiaoya YANG <[email-masked]>
>> >> >><[email-masked]>
>> >> >>Technical Contact: <[email-masked]>
>> >> >><[email-masked]>
>> >> >>Purpose: For action
>> >> >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>> >> >>rejected Defect Report 320 
>> >> >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>> >> >>AFNOR.  This DR advanced an argument that Distinguished Names may 
>> >> >>not be unique and as such, the DN of the Certificate User may not be unique.
>> >> >>The directory group believes that Distinguished Name values must be 
>> >> >>unique and unambiguously identify a single entity, hence the use of 
>> >> >>the term Distinguished.
>> >> >>The DR states â€œthe DN of the issuer name cannot be guaranteed to 
>> >> >>be uniqueâ€.  X.509 takes its definition of DN from X.501.  Clause 
>> >> >>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>> >> >>clause states A name shall be unambiguous, that is, denotes just one object.
>> >> >>Clause 9 goes on to state: It is the responsibility of the relevant 
>> >> >>naming authority for an entry to ensure that this is so by 
>> >> >>appropriately assigning distinguished attribute values.  Allocation 
>> >> >>of RDNs is considered an administrative undertaking that may or may 
>> >> >>not require some negotiation between involved organizations or 
>> >> >>administrations.  This Directory Specification does not provide such 
>> >> >>a negotiation mechanism, and makes no assumption as to how it is performed.
>> >> >>The standard takes an axiomatic view of the concept that a 
>> >> >>distinguished name unambiguously identifies a single entity.  Things 
>> >> >>break if two entities identify themselves using the same name.  We 
>> >> >>don't let two entities have the same domain name or the same email 
>> >> >>address.  Why? - because things wouldn't work.
>> >> >>The directory group does not accept the DRâ€™s basic argument.  We 
>> >> >>believe that if two entities present the same name and a CA issues a 
>> >> >>certificate to each, that CA made a mistake - not a naming authority 
>> >> >>mistake, since a CA is not an naming authority (although one entity 
>> >> >>can be both), but an entity to key binding mistake that leads to 
>> >> >>confusion and even worse, a security risk.
>> >> >>We believe that if two entities claim the same name as top level 
>> >> >>CAs, there is a political/procedural breakdown much like the domain 
>> >> >>ownership arguments we have seen.  No one argues that the Internet 
>> >> >>protocols should be modified to solve that problem.  The conflict is 
>> >> >>resolved and one entity is assigned the name.  The group believes 
>> >> >>that this is the only reasonable solution for Distinguished 
>> >> >>Naming.  One votes for the CA of choice by configuring it as an anchor.
>> >> >>One of the participants in the directory meeting stated that 
>> >> >>Certification Authorities are being deployed with names not acquired 
>> >> >>from naming authorities but with names arbitrarily chosen assuming 
>> >> >>that no other CA is or will be operating under that name.  That 
>> >> >>participant further stated that the IETF provides no guidelines on 
>> >> >>ensuring that the names of CAs are unambiguous.
>> >> >>The directory group requests the IETF PKIX group to comment on this 
>> >> >>statement.  If the statement is correct, we ask the IETF to consider 
>> >> >>putting a mechanism in place to prevent conflict, e.g. a list of 
>> >> >>existing CA names that deployers of new CAs could check for naming conflicts.
>> >> >>Attachment(s):
>> >> >>No document has been attached
>> 
>> 
>

Regards,

Denis Pinkas

From: "Julien Stern" <[email-masked]>
Date: Mon, 22 Oct 2007 16:33:30 +0200
To: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Oct 22, 2007 at 06:18:22AM -0700, Santosh Chokhani wrote:
> 
> We have been down this route before.

Oooooh Yes. Lots of fun and (gentle) arguments...

> See my presentation to PKIX in Fall 2004 IETF meeting in Washington DC.
> 
> My understanding from 2004 presentation was that Russ Housley proposed instead of ensuring certificate certification path and CRL certification path matching, we make sure that we ensure that the paths begin at the same trust anchor.  It was felt by the group (not I) that coupled with name constraints in cross certified environment is sufficient to mitigate the risk to an acceptably low level.  Of course, my argument always has been that using the certificate certification path to constrain the CRL certification path provides you both with security and efficiency, something you do not always get.  The primary reason to not adopt my suggestion is that it requires change to client software.

I did not feel either that trust anchor matching was sufficient enough.

As you may remember, I also felt that your proposed solution, while
improving the situation, did not close every possible attacks, and I
proposed an alternative that was (in my humble opinion) even more secure
but with even more changes on the client software.

Anyway, my current take on the subject would be roughly the following.
RFC3280bis could include something in the line of:

"The uniqueness of DN of all entities in all the Trust Anchors
hierarchies SHOULD be enforced. If the uniqueness cannot be guaranteed
in some circonstances, client software MAY implement additional checks
in order to lower the risk of outputing an incorrect revocation value during
path validation. [We could give example of additional checks here:
checking the trust anchor matching, check the full path matching,
checking the AuthorityKeyIdentifier hash matching, etc]. Client
implementors should however be aware that these additional checks may
hinder interoperability in the general case."

--
Julien

From: "Julien Stern" <[email-masked]>
Date: Mon, 22 Oct 2007 16:21:22 +0200
To: "[email-masked]" <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Mail-Followup-To: Julien Stern <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Denis,

As you might have seen from some of my old posting on the list,
I initially believed that there was a true "security flaw" in X.509
regarding revocation.

Now, my understanding is that the fact there is no name
collision is an _assumption_ in X.509.

If one wants to cope with name collisions there are several
routes one can take depending on what the "adversary" is and
the constraint one wants to put on the PKI topology.

1) The first one is simply to assume that it can be detected
and fixed.

2) One can cope with "accidental" name collision: I believe that is
the route currently taken by PKIX by mandating trust anchor matching.

3) Your proposed wording copes with less accidental and more malicious
attacks. I believe this is in the same spirit as Santosh Chokani
proposal in 2004, (isn't it ?). However, it restricts the PKI topology and
I believe it is still open to some exotic attacts (see my posting from
early November 2004).

4) One can put even more restrictions on the PKI topology by mandating
that a CA signs the CRL issuer keys with an explicit "CRL issuer" extension
(similar to OCSP) and that the AuthorityKeyExtension (containing the
hash of the key) be explicitely checked during the path building.

All in all, I believe it is close to impossible to define a general rule
in the standard because some core assumptions regarding the uniqueness
of the DNs and the adversarial model may not be the same between
different PKIs.

Regards,

--
Julien

On Mon, Oct 22, 2007 at 03:16:32PM +0200, Denis Pinkas wrote:
> 
> Julien,
> 
> >On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote:
> >>
> >> [snip]
> >
> >Hi Denis,
> >
> >> This means that RFC3280bis currently provides no coorect guidance 
> >> on how implementers should address this issue. 
> >
> >Agreed. There is a somewhat "matter of local policy-ish" issue here.
> >
> >> The following text is an attempt to address this issue:
> >> 
> >> "Implementations validating indirect CRLs MUST make sure that the 
> >> certificate of the CRL Issuer is indeed issued by the CA that issued 
> >> the certificate to be verified, which means that the sequence of DNs 
> >> of the certification path of the CRL issuer, up to the DN of a trust anchor, 
> >> must be identical to the the sequence of DNs of the certification path 
> >> of the certificate to be verified, up to the DN of the same trust anchor".
> >
> >Forcing the CA to directly issue the CRL issuer certificate is way too
> >restrictive in my humble opinion. I have an example of a PKI where there
> >is a single (indirect) CRL issuer for about 20 CAs.
> >
> >The CRL issuer certificate is issued by the (Root) CA that issued
> >those 20 CA certificates.
> 
> What about:
> 
> Unless a local policy states otherwise, implementations validating indirect CRLs 
> MUST make sure that the certificate of the CRL Issuer is indeed issued by the CA 
> that issued  the certificate to be verified, which means that the sequence of DNs 
> of the certification path of the CRL issuer, up to the DN of a trust anchor, 
> must be identical to the the sequence of DNs of the certification path 
> of the certificate to be verified, up to the DN of the same trust anchor".
> 
> Denis
> 
> >Regards,
> >
> >--
> >Julien
> >
> >> Denis
> >> 
> >> >Russ
> >> >
> >> >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
> >> >
> >> >>Title: Liaison to IETF on the resolution of DR320
> >> >>Submission Date: 2007-10-05
> >> >>URL of the IETF Web page: 
> >> >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
> >> >>Please reply by 2008-03-01
> >> >>
> >> >>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
> >> >>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
> >> >><[email-masked]>)
> >> >>Cc: Herbert Bertine <[email-masked]>
> >> >><[email-masked]>
> >> >><[email-masked]>
> >> >><[email-masked]>
> >> >>Reponse Contact: Xiaoya YANG <[email-masked]>
> >> >><[email-masked]>
> >> >>Technical Contact: <[email-masked]>
> >> >><[email-masked]>
> >> >>Purpose: For action
> >> >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
> >> >>rejected Defect Report 320 
> >> >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
> >> >>AFNOR.  This DR advanced an argument that Distinguished Names may 
> >> >>not be unique and as such, the DN of the Certificate User may not be unique.
> >> >>The directory group believes that Distinguished Name values must be 
> >> >>unique and unambiguously identify a single entity, hence the use of 
> >> >>the term Distinguished.
> >> >>The DR states â€œthe DN of the issuer name cannot be guaranteed to 
> >> >>be uniqueâ€.  X.509 takes its definition of DN from X.501.  Clause 
> >> >>9.2 of X.501 specifies the definition of DistinguishedName.  This 
> >> >>clause states A name shall be unambiguous, that is, denotes just one object.
> >> >>Clause 9 goes on to state: It is the responsibility of the relevant 
> >> >>naming authority for an entry to ensure that this is so by 
> >> >>appropriately assigning distinguished attribute values.  Allocation 
> >> >>of RDNs is considered an administrative undertaking that may or may 
> >> >>not require some negotiation between involved organizations or 
> >> >>administrations.  This Directory Specification does not provide such 
> >> >>a negotiation mechanism, and makes no assumption as to how it is performed.
> >> >>The standard takes an axiomatic view of the concept that a 
> >> >>distinguished name unambiguously identifies a single entity.  Things 
> >> >>break if two entities identify themselves using the same name.  We 
> >> >>don't let two entities have the same domain name or the same email 
> >> >>address.  Why? - because things wouldn't work.
> >> >>The directory group does not accept the DRâ€™s basic argument.  We 
> >> >>believe that if two entities present the same name and a CA issues a 
> >> >>certificate to each, that CA made a mistake - not a naming authority 
> >> >>mistake, since a CA is not an naming authority (although one entity 
> >> >>can be both), but an entity to key binding mistake that leads to 
> >> >>confusion and even worse, a security risk.
> >> >>We believe that if two entities claim the same name as top level 
> >> >>CAs, there is a political/procedural breakdown much like the domain 
> >> >>ownership arguments we have seen.  No one argues that the Internet 
> >> >>protocols should be modified to solve that problem.  The conflict is 
> >> >>resolved and one entity is assigned the name.  The group believes 
> >> >>that this is the only reasonable solution for Distinguished 
> >> >>Naming.  One votes for the CA of choice by configuring it as an anchor.
> >> >>One of the participants in the directory meeting stated that 
> >> >>Certification Authorities are being deployed with names not acquired 
> >> >>from naming authorities but with names arbitrarily chosen assuming 
> >> >>that no other CA is or will be operating under that name.  That 
> >> >>participant further stated that the IETF provides no guidelines on 
> >> >>ensuring that the names of CAs are unambiguous.
> >> >>The directory group requests the IETF PKIX group to comment on this 
> >> >>statement.  If the statement is correct, we ask the IETF to consider 
> >> >>putting a mechanism in place to prevent conflict, e.g. a list of 
> >> >>existing CA names that deployers of new CAs could check for naming conflicts.
> >> >>Attachment(s):
> >> >>No document has been attached
> 
> 

Date: Mon, 22 Oct 2007 15:37:09 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Sender: [email-masked]

Santosh,

>We have been down this route before.

>See my presentation to PKIX in Fall 2004 IETF meeting in Washington DC.

> My understanding from 2004 presentation was that Russ Housley proposed instead of 
> ensuring certificate certification path and CRL certification path matching, 

Unless the client software knows by "other means" what to do, this is the default way 
to make the whole system secure.
 
> we make sure that we ensure that the paths begin at the same trust anchor.  

This helps, but it is fra from sufficient.

> It was felt by the group (not I) that coupled with name constraints in cross certified 
> environment is sufficient to mitigate the risk to an acceptably low level.  

Reducing the risk does not suppress it.

> Of course, my argument always has been that using the certificate 
> certification path to constrain the CRL certification path provides you both with security and 
> efficiency, something you do not always get.  

"Constraining" does not mean "identical". Would you be more precise ?

> The primary reason to not adopt my suggestion is that it requires change to client software.

Since most of the clients are insecure today in case of a DN name collision, it is time to fix it.

>Also see our paper in NIST PKI Research Workshop in 2005 for a discussion of this.

Would you have a link ?

Denis

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Monday, October 22, 2007 7:58 AM
>To: [email-masked]
>Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
>
>
>Russ said:
>
>>It seems to me that this is a trust anchor configuration concern.  
>
>Not only.
>
>> If two CAs adopt the same name and a user accepts both of these CAs as 
>>trust anchors, then there could be a problem.  Just don't do it.
>
>This is correct, but insufficient. This does not prevent two CAs somewhere 
>under this trust anchor to use the same name in different branches.
>
>>RFC 3280bis says:
>
>>    While X.509 mandates that names be unambiguous, there is a risk that
>>    two unrelated authorities will issue certificates and/or CRLs under
>>    the same issuer name.  
>
>This is correct. This sentence contradicts the response to DR 320.
>
>>    As a means of reducing problems and security
>>    issues related to issuer name collisions, CA and CRL issuer names
>>    SHOULD be formed in a way that reduces the likelihood of name
>>    collisions.  
>
>This recommandation does not *prevent* "problems and security issues".
>This sentence should be deleted or changed. 
>
>>    Implementers should take into account the possible
>>    existence of multiple unrelated CAs and CRL issuers with the same
>>    name.  
>
>This is fully correct.
>
>>    At a minimum, implementations validating CRLs MUST ensure that
>>    the certification path of a certificate and the CRL issuer
>>    certification path used to validate the certificate terminate at the
>>    same trust anchor.
>
>This "minimum" clause is both insufficient and insecure. 
>This sentence gives a false sense of security.
>
>This means that RFC3280bis currently provides no coorect guidance 
>on how implementers should address this issue. 
>
>The following text is an attempt to address this issue:
>
>"Implementations validating indirect CRLs MUST make sure that the 
>certificate of the CRL Issuer is indeed issued by the CA that issued 
>the certificate to be verified, which means that the sequence of DNs 
>of the certification path of the CRL issuer, up to the DN of a trust anchor, 
>must be identical to the the sequence of DNs of the certification path 
>of the certificate to be verified, up to the DN of the same trust anchor".
>
>Denis
>
>>Russ
>>
>>At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
>>
>>>Title: Liaison to IETF on the resolution of DR320
>>>Submission Date: 2007-10-05
>>>URL of the IETF Web page: 
>>>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>>>Please reply by 2008-03-01
>>>
>>>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>>>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
>>><[email-masked]>)
>>>Cc: Herbert Bertine <[email-masked]>
>>><[email-masked]>
>>><[email-masked]>
>>><[email-masked]>
>>>Reponse Contact: Xiaoya YANG <[email-masked]>
>>><[email-masked]>
>>>Technical Contact: <[email-masked]>
>>><[email-masked]>
>>>Purpose: For action
>>>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>>>rejected Defect Report 320 
>>>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>>>AFNOR.  This DR advanced an argument that Distinguished Names may 
>>>not be unique and as such, the DN of the Certificate User may not be unique.
>>>The directory group believes that Distinguished Name values must be 
>>>unique and unambiguously identify a single entity, hence the use of 
>>>the term Distinguished.
>>>The DR states â€œthe DN of the issuer name cannot be guaranteed to 
>>>be uniqueâ€.  X.509 takes its definition of DN from X.501.  Clause 
>>>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>>>clause states A name shall be unambiguous, that is, denotes just one object.
>>>Clause 9 goes on to state: It is the responsibility of the relevant 
>>>naming authority for an entry to ensure that this is so by 
>>>appropriately assigning distinguished attribute values.  Allocation 
>>>of RDNs is considered an administrative undertaking that may or may 
>>>not require some negotiation between involved organizations or 
>>>administrations.  This Directory Specification does not provide such 
>>>a negotiation mechanism, and makes no assumption as to how it is performed.
>>>The standard takes an axiomatic view of the concept that a 
>>>distinguished name unambiguously identifies a single entity.  Things 
>>>break if two entities identify themselves using the same name.  We 
>>>don't let two entities have the same domain name or the same email 
>>>address.  Why? - because things wouldn't work.
>>>The directory group does not accept the DRâ€™s basic argument.  We 
>>>believe that if two entities present the same name and a CA issues a 
>>>certificate to each, that CA made a mistake - not a naming authority 
>>>mistake, since a CA is not an naming authority (although one entity 
>>>can be both), but an entity to key binding mistake that leads to 
>>>confusion and even worse, a security risk.
>>>We believe that if two entities claim the same name as top level 
>>>CAs, there is a political/procedural breakdown much like the domain 
>>>ownership arguments we have seen.  No one argues that the Internet 
>>>protocols should be modified to solve that problem.  The conflict is 
>>>resolved and one entity is assigned the name.  The group believes 
>>>that this is the only reasonable solution for Distinguished 
>>>Naming.  One votes for the CA of choice by configuring it as an anchor.
>>>One of the participants in the directory meeting stated that 
>>>Certification Authorities are being deployed with names not acquired 
>>>from naming authorities but with names arbitrarily chosen assuming 
>>>that no other CA is or will be operating under that name.  That 
>>>participant further stated that the IETF provides no guidelines on 
>>>ensuring that the names of CAs are unambiguous.
>>>The directory group requests the IETF PKIX group to comment on this 
>>>statement.  If the statement is correct, we ask the IETF to consider 
>>>putting a mechanism in place to prevent conflict, e.g. a list of 
>>>existing CA names that deployers of new CAs could check for naming conflicts.
>>>Attachment(s):
>>>No document has been attached
>>
>
>Regards,
>
>Denis Pinkas
>
>

Regards,

Denis Pinkas

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Date: Mon, 22 Oct 2007 06:18:22 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

We have been down this route before.

See my presentation to PKIX in Fall 2004 IETF meeting in Washington DC.

My understanding from 2004 presentation was that Russ Housley proposed instead of ensuring certificate certification path and CRL certification path matching, we make sure that we ensure that the paths begin at the same trust anchor.  It was felt by the group (not I) that coupled with name constraints in cross certified environment is sufficient to mitigate the risk to an acceptably low level.  Of course, my argument always has been that using the certificate certification path to constrain the CRL certification path provides you both with security and efficiency, something you do not always get.  The primary reason to not adopt my suggestion is that it requires change to client software.

Also see our paper in NIST PKI Research Workshop in 2005 for a discussion of this.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, October 22, 2007 7:58 AM
To: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"

Russ said:

>It seems to me that this is a trust anchor configuration concern.  

Not only.

> If two CAs adopt the same name and a user accepts both of these CAs as 
>trust anchors, then there could be a problem.  Just don't do it.

This is correct, but insufficient. This does not prevent two CAs somewhere 
under this trust anchor to use the same name in different branches.

>RFC 3280bis says:

>    While X.509 mandates that names be unambiguous, there is a risk that
>    two unrelated authorities will issue certificates and/or CRLs under
>    the same issuer name.  

This is correct. This sentence contradicts the response to DR 320.

>    As a means of reducing problems and security
>    issues related to issuer name collisions, CA and CRL issuer names
>    SHOULD be formed in a way that reduces the likelihood of name
>    collisions.  

This recommandation does not *prevent* "problems and security issues".
This sentence should be deleted or changed. 

>    Implementers should take into account the possible
>    existence of multiple unrelated CAs and CRL issuers with the same
>    name.  

This is fully correct.

>    At a minimum, implementations validating CRLs MUST ensure that
>    the certification path of a certificate and the CRL issuer
>    certification path used to validate the certificate terminate at the
>    same trust anchor.

This "minimum" clause is both insufficient and insecure. 
This sentence gives a false sense of security.

This means that RFC3280bis currently provides no coorect guidance 
on how implementers should address this issue. 

The following text is an attempt to address this issue:

"Implementations validating indirect CRLs MUST make sure that the 
certificate of the CRL Issuer is indeed issued by the CA that issued 
the certificate to be verified, which means that the sequence of DNs 
of the certification path of the CRL issuer, up to the DN of a trust anchor, 
must be identical to the the sequence of DNs of the certification path 
of the certificate to be verified, up to the DN of the same trust anchor".

Denis

>Russ
>
>At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
>
>>Title: Liaison to IETF on the resolution of DR320
>>Submission Date: 2007-10-05
>>URL of the IETF Web page: 
>>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>>Please reply by 2008-03-01
>>
>>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
>><[email-masked]>)
>>Cc: Herbert Bertine <[email-masked]>
>><[email-masked]>
>><[email-masked]>
>><[email-masked]>
>>Reponse Contact: Xiaoya YANG <[email-masked]>
>><[email-masked]>
>>Technical Contact: <[email-masked]>
>><[email-masked]>
>>Purpose: For action
>>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>>rejected Defect Report 320 
>>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>>AFNOR.  This DR advanced an argument that Distinguished Names may 
>>not be unique and as such, the DN of the Certificate User may not be unique.
>>The directory group believes that Distinguished Name values must be 
>>unique and unambiguously identify a single entity, hence the use of 
>>the term Distinguished.
>>The DR states Ã¢â‚¬Å“the DN of the issuer name cannot be guaranteed to 
>>be uniqueÃ¢â‚¬Â.  X.509 takes its definition of DN from X.501.  Clause 
>>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>>clause states A name shall be unambiguous, that is, denotes just one object.
>>Clause 9 goes on to state: It is the responsibility of the relevant 
>>naming authority for an entry to ensure that this is so by 
>>appropriately assigning distinguished attribute values.  Allocation 
>>of RDNs is considered an administrative undertaking that may or may 
>>not require some negotiation between involved organizations or 
>>administrations.  This Directory Specification does not provide such 
>>a negotiation mechanism, and makes no assumption as to how it is performed.
>>The standard takes an axiomatic view of the concept that a 
>>distinguished name unambiguously identifies a single entity.  Things 
>>break if two entities identify themselves using the same name.  We 
>>don't let two entities have the same domain name or the same email 
>>address.  Why? - because things wouldn't work.
>>The directory group does not accept the DRÃ¢â‚¬â„¢s basic argument.  We 
>>believe that if two entities present the same name and a CA issues a 
>>certificate to each, that CA made a mistake - not a naming authority 
>>mistake, since a CA is not an naming authority (although one entity 
>>can be both), but an entity to key binding mistake that leads to 
>>confusion and even worse, a security risk.
>>We believe that if two entities claim the same name as top level 
>>CAs, there is a political/procedural breakdown much like the domain 
>>ownership arguments we have seen.  No one argues that the Internet 
>>protocols should be modified to solve that problem.  The conflict is 
>>resolved and one entity is assigned the name.  The group believes 
>>that this is the only reasonable solution for Distinguished 
>>Naming.  One votes for the CA of choice by configuring it as an anchor.
>>One of the participants in the directory meeting stated that 
>>Certification Authorities are being deployed with names not acquired 
>>from naming authorities but with names arbitrarily chosen assuming 
>>that no other CA is or will be operating under that name.  That 
>>participant further stated that the IETF provides no guidelines on 
>>ensuring that the names of CAs are unambiguous.
>>The directory group requests the IETF PKIX group to comment on this 
>>statement.  If the statement is correct, we ask the IETF to consider 
>>putting a mechanism in place to prevent conflict, e.g. a list of 
>>existing CA names that deployers of new CAs could check for naming conflicts.
>>Attachment(s):
>>No document has been attached
>

Regards,

Denis Pinkas

Date: Mon, 22 Oct 2007 15:16:32 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Sender: [email-masked]

Julien,

>On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote:
>>
>> [snip]
>
>Hi Denis,
>
>> This means that RFC3280bis currently provides no coorect guidance 
>> on how implementers should address this issue. 
>
>Agreed. There is a somewhat "matter of local policy-ish" issue here.
>
>> The following text is an attempt to address this issue:
>> 
>> "Implementations validating indirect CRLs MUST make sure that the 
>> certificate of the CRL Issuer is indeed issued by the CA that issued 
>> the certificate to be verified, which means that the sequence of DNs 
>> of the certification path of the CRL issuer, up to the DN of a trust anchor, 
>> must be identical to the the sequence of DNs of the certification path 
>> of the certificate to be verified, up to the DN of the same trust anchor".
>
>Forcing the CA to directly issue the CRL issuer certificate is way too
>restrictive in my humble opinion. I have an example of a PKI where there
>is a single (indirect) CRL issuer for about 20 CAs.
>
>The CRL issuer certificate is issued by the (Root) CA that issued
>those 20 CA certificates.

What about:

Unless a local policy states otherwise, implementations validating indirect CRLs 
MUST make sure that the certificate of the CRL Issuer is indeed issued by the CA 
that issued  the certificate to be verified, which means that the sequence of DNs 
of the certification path of the CRL issuer, up to the DN of a trust anchor, 
must be identical to the the sequence of DNs of the certification path 
of the certificate to be verified, up to the DN of the same trust anchor".

Denis

>Regards,
>
>--
>Julien
>
>> Denis
>> 
>> >Russ
>> >
>> >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
>> >
>> >>Title: Liaison to IETF on the resolution of DR320
>> >>Submission Date: 2007-10-05
>> >>URL of the IETF Web page: 
>> >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>> >>Please reply by 2008-03-01
>> >>
>> >>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>> >>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
>> >><[email-masked]>)
>> >>Cc: Herbert Bertine <[email-masked]>
>> >><[email-masked]>
>> >><[email-masked]>
>> >><[email-masked]>
>> >>Reponse Contact: Xiaoya YANG <[email-masked]>
>> >><[email-masked]>
>> >>Technical Contact: <[email-masked]>
>> >><[email-masked]>
>> >>Purpose: For action
>> >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>> >>rejected Defect Report 320 
>> >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>> >>AFNOR.  This DR advanced an argument that Distinguished Names may 
>> >>not be unique and as such, the DN of the Certificate User may not be unique.
>> >>The directory group believes that Distinguished Name values must be 
>> >>unique and unambiguously identify a single entity, hence the use of 
>> >>the term Distinguished.
>> >>The DR states â€œthe DN of the issuer name cannot be guaranteed to 
>> >>be uniqueâ€.  X.509 takes its definition of DN from X.501.  Clause 
>> >>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>> >>clause states A name shall be unambiguous, that is, denotes just one object.
>> >>Clause 9 goes on to state: It is the responsibility of the relevant 
>> >>naming authority for an entry to ensure that this is so by 
>> >>appropriately assigning distinguished attribute values.  Allocation 
>> >>of RDNs is considered an administrative undertaking that may or may 
>> >>not require some negotiation between involved organizations or 
>> >>administrations.  This Directory Specification does not provide such 
>> >>a negotiation mechanism, and makes no assumption as to how it is performed.
>> >>The standard takes an axiomatic view of the concept that a 
>> >>distinguished name unambiguously identifies a single entity.  Things 
>> >>break if two entities identify themselves using the same name.  We 
>> >>don't let two entities have the same domain name or the same email 
>> >>address.  Why? - because things wouldn't work.
>> >>The directory group does not accept the DRâ€™s basic argument.  We 
>> >>believe that if two entities present the same name and a CA issues a 
>> >>certificate to each, that CA made a mistake - not a naming authority 
>> >>mistake, since a CA is not an naming authority (although one entity 
>> >>can be both), but an entity to key binding mistake that leads to 
>> >>confusion and even worse, a security risk.
>> >>We believe that if two entities claim the same name as top level 
>> >>CAs, there is a political/procedural breakdown much like the domain 
>> >>ownership arguments we have seen.  No one argues that the Internet 
>> >>protocols should be modified to solve that problem.  The conflict is 
>> >>resolved and one entity is assigned the name.  The group believes 
>> >>that this is the only reasonable solution for Distinguished 
>> >>Naming.  One votes for the CA of choice by configuring it as an anchor.
>> >>One of the participants in the directory meeting stated that 
>> >>Certification Authorities are being deployed with names not acquired 
>> >>from naming authorities but with names arbitrarily chosen assuming 
>> >>that no other CA is or will be operating under that name.  That 
>> >>participant further stated that the IETF provides no guidelines on 
>> >>ensuring that the names of CAs are unambiguous.
>> >>The directory group requests the IETF PKIX group to comment on this 
>> >>statement.  If the statement is correct, we ask the IETF to consider 
>> >>putting a mechanism in place to prevent conflict, e.g. a list of 
>> >>existing CA names that deployers of new CAs could check for naming conflicts.
>> >>Attachment(s):
>> >>No document has been attached

From: "Julien Stern" <[email-masked]>
Date: Mon, 22 Oct 2007 14:53:53 +0200
To: "[email-masked]" <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Mail-Followup-To: Julien Stern <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote:
> [snip]

Hi Denis,

> This means that RFC3280bis currently provides no coorect guidance 
> on how implementers should address this issue. 

Agreed. There is a somewhat "matter of local policy-ish" issue here.

> The following text is an attempt to address this issue:
> 
> "Implementations validating indirect CRLs MUST make sure that the 
> certificate of the CRL Issuer is indeed issued by the CA that issued 
> the certificate to be verified, which means that the sequence of DNs 
> of the certification path of the CRL issuer, up to the DN of a trust anchor, 
> must be identical to the the sequence of DNs of the certification path 
> of the certificate to be verified, up to the DN of the same trust anchor".

Forcing the CA to directly issue the CRL issuer certificate is way too
restrictive in my humble opinion. I have an example of a PKI where there
is a single (indirect) CRL issuer for about 20 CAs.

The CRL issuer certificate is issued by the (Root) CA that issued
those 20 CA certificates.

Regards,

--
Julien

> Denis
> 
> >Russ
> >
> >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
> >
> >>Title: Liaison to IETF on the resolution of DR320
> >>Submission Date: 2007-10-05
> >>URL of the IETF Web page: 
> >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
> >>Please reply by 2008-03-01
> >>
> >>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
> >>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
> >><[email-masked]>)
> >>Cc: Herbert Bertine <[email-masked]>
> >><[email-masked]>
> >><[email-masked]>
> >><[email-masked]>
> >>Reponse Contact: Xiaoya YANG <[email-masked]>
> >><[email-masked]>
> >>Technical Contact: <[email-masked]>
> >><[email-masked]>
> >>Purpose: For action
> >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
> >>rejected Defect Report 320 
> >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
> >>AFNOR.  This DR advanced an argument that Distinguished Names may 
> >>not be unique and as such, the DN of the Certificate User may not be unique.
> >>The directory group believes that Distinguished Name values must be 
> >>unique and unambiguously identify a single entity, hence the use of 
> >>the term Distinguished.
> >>The DR states â€œthe DN of the issuer name cannot be guaranteed to 
> >>be uniqueâ€.  X.509 takes its definition of DN from X.501.  Clause 
> >>9.2 of X.501 specifies the definition of DistinguishedName.  This 
> >>clause states A name shall be unambiguous, that is, denotes just one object.
> >>Clause 9 goes on to state: It is the responsibility of the relevant 
> >>naming authority for an entry to ensure that this is so by 
> >>appropriately assigning distinguished attribute values.  Allocation 
> >>of RDNs is considered an administrative undertaking that may or may 
> >>not require some negotiation between involved organizations or 
> >>administrations.  This Directory Specification does not provide such 
> >>a negotiation mechanism, and makes no assumption as to how it is performed.
> >>The standard takes an axiomatic view of the concept that a 
> >>distinguished name unambiguously identifies a single entity.  Things 
> >>break if two entities identify themselves using the same name.  We 
> >>don't let two entities have the same domain name or the same email 
> >>address.  Why? - because things wouldn't work.
> >>The directory group does not accept the DRâ€™s basic argument.  We 
> >>believe that if two entities present the same name and a CA issues a 
> >>certificate to each, that CA made a mistake - not a naming authority 
> >>mistake, since a CA is not an naming authority (although one entity 
> >>can be both), but an entity to key binding mistake that leads to 
> >>confusion and even worse, a security risk.
> >>We believe that if two entities claim the same name as top level 
> >>CAs, there is a political/procedural breakdown much like the domain 
> >>ownership arguments we have seen.  No one argues that the Internet 
> >>protocols should be modified to solve that problem.  The conflict is 
> >>resolved and one entity is assigned the name.  The group believes 
> >>that this is the only reasonable solution for Distinguished 
> >>Naming.  One votes for the CA of choice by configuring it as an anchor.
> >>One of the participants in the directory meeting stated that 
> >>Certification Authorities are being deployed with names not acquired 
> >>from naming authorities but with names arbitrarily chosen assuming 
> >>that no other CA is or will be operating under that name.  That 
> >>participant further stated that the IETF provides no guidelines on 
> >>ensuring that the names of CAs are unambiguous.
> >>The directory group requests the IETF PKIX group to comment on this 
> >>statement.  If the statement is correct, we ask the IETF to consider 
> >>putting a mechanism in place to prevent conflict, e.g. a list of 
> >>existing CA names that deployers of new CAs could check for naming conflicts.
> >>Attachment(s):
> >>No document has been attached
> >
> 
> Regards,
> 
> Denis Pinkas
> 
> 

Date: Mon, 22 Oct 2007 13:57:33 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution  of  DR320"
Sender: [email-masked]

Russ said:

>It seems to me that this is a trust anchor configuration concern.  

Not only.

> If two CAs adopt the same name and a user accepts both of these CAs as 
>trust anchors, then there could be a problem.  Just don't do it.

This is correct, but insufficient. This does not prevent two CAs somewhere 
under this trust anchor to use the same name in different branches.

>RFC 3280bis says:

>    While X.509 mandates that names be unambiguous, there is a risk that
>    two unrelated authorities will issue certificates and/or CRLs under
>    the same issuer name.  

This is correct. This sentence contradicts the response to DR 320.

>    As a means of reducing problems and security
>    issues related to issuer name collisions, CA and CRL issuer names
>    SHOULD be formed in a way that reduces the likelihood of name
>    collisions.  

This recommandation does not *prevent* "problems and security issues".
This sentence should be deleted or changed. 

>    Implementers should take into account the possible
>    existence of multiple unrelated CAs and CRL issuers with the same
>    name.  

This is fully correct.

>    At a minimum, implementations validating CRLs MUST ensure that
>    the certification path of a certificate and the CRL issuer
>    certification path used to validate the certificate terminate at the
>    same trust anchor.

This "minimum" clause is both insufficient and insecure. 
This sentence gives a false sense of security.

This means that RFC3280bis currently provides no coorect guidance 
on how implementers should address this issue. 

The following text is an attempt to address this issue:

"Implementations validating indirect CRLs MUST make sure that the 
certificate of the CRL Issuer is indeed issued by the CA that issued 
the certificate to be verified, which means that the sequence of DNs 
of the certification path of the CRL issuer, up to the DN of a trust anchor, 
must be identical to the the sequence of DNs of the certification path 
of the certificate to be verified, up to the DN of the same trust anchor".

Denis

>Russ
>
>At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
>
>>Title: Liaison to IETF on the resolution of DR320
>>Submission Date: 2007-10-05
>>URL of the IETF Web page: 
>>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>>Please reply by 2008-03-01
>>
>>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
>><[email-masked]>)
>>Cc: Herbert Bertine <[email-masked]>
>><[email-masked]>
>><[email-masked]>
>><[email-masked]>
>>Reponse Contact: Xiaoya YANG <[email-masked]>
>><[email-masked]>
>>Technical Contact: <[email-masked]>
>><[email-masked]>
>>Purpose: For action
>>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>>rejected Defect Report 320 
>>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>>AFNOR.  This DR advanced an argument that Distinguished Names may 
>>not be unique and as such, the DN of the Certificate User may not be unique.
>>The directory group believes that Distinguished Name values must be 
>>unique and unambiguously identify a single entity, hence the use of 
>>the term Distinguished.
>>The DR states â€œthe DN of the issuer name cannot be guaranteed to 
>>be uniqueâ€.  X.509 takes its definition of DN from X.501.  Clause 
>>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>>clause states A name shall be unambiguous, that is, denotes just one object.
>>Clause 9 goes on to state: It is the responsibility of the relevant 
>>naming authority for an entry to ensure that this is so by 
>>appropriately assigning distinguished attribute values.  Allocation 
>>of RDNs is considered an administrative undertaking that may or may 
>>not require some negotiation between involved organizations or 
>>administrations.  This Directory Specification does not provide such 
>>a negotiation mechanism, and makes no assumption as to how it is performed.
>>The standard takes an axiomatic view of the concept that a 
>>distinguished name unambiguously identifies a single entity.  Things 
>>break if two entities identify themselves using the same name.  We 
>>don't let two entities have the same domain name or the same email 
>>address.  Why? - because things wouldn't work.
>>The directory group does not accept the DRâ€™s basic argument.  We 
>>believe that if two entities present the same name and a CA issues a 
>>certificate to each, that CA made a mistake - not a naming authority 
>>mistake, since a CA is not an naming authority (although one entity 
>>can be both), but an entity to key binding mistake that leads to 
>>confusion and even worse, a security risk.
>>We believe that if two entities claim the same name as top level 
>>CAs, there is a political/procedural breakdown much like the domain 
>>ownership arguments we have seen.  No one argues that the Internet 
>>protocols should be modified to solve that problem.  The conflict is 
>>resolved and one entity is assigned the name.  The group believes 
>>that this is the only reasonable solution for Distinguished 
>>Naming.  One votes for the CA of choice by configuring it as an anchor.
>>One of the participants in the directory meeting stated that 
>>Certification Authorities are being deployed with names not acquired 
>>from naming authorities but with names arbitrarily chosen assuming 
>>that no other CA is or will be operating under that name.  That 
>>participant further stated that the IETF provides no guidelines on 
>>ensuring that the names of CAs are unambiguous.
>>The directory group requests the IETF PKIX group to comment on this 
>>statement.  If the statement is correct, we ask the IETF to consider 
>>putting a mechanism in place to prevent conflict, e.g. a list of 
>>existing CA names that deployers of new CAs could check for naming conflicts.
>>Attachment(s):
>>No document has been attached
>

Regards,

Denis Pinkas

Date: Mon, 22 Oct 2007 13:52:42 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"
Sender: [email-masked]

Paul,

I agree with what you say. However", Words fail me" may have multiple interpretations.

We are going to invent a mechanism to prevent conflict, e.g. a list of existing CA 
names that deployers of new CAs could check for naming conflicts.

We are not going either to mandate the use of the DC naming attribute to guarantee
DN uniqueness.

The text from DR 320 is:

On page 12, the current text states “serialNumber is an integer assigned 
by the CA to each certificate. The value of serialNumber shall be unique 
for each certificate issued by a given CA (i.e., the issuer name and serial number 
identify a unique certificate).”
 
The text inside the parenthesis should be deleted: the DN of the issuer name 
cannot be guaranteed to be unique (the collision may be deliberate or accidental) 
and therefore the issuer name and serial number cannot uniquely identify a certificate.

The text of the answer to DR 320 states:

"This DR advanced an argument that Distinguished Names may 
not be unique and as such, the DN of the Certificate User may not be unique.

The directory group believes that Distinguished Name values must be 
unique and unambiguously identify a single entity, hence the use of 
the term Distinguished".

The implications are that DR 320 has been rejected by the directory group on a wrong basis.

Denis

>The ITU statement says the following:

>>>One of the participants in the directory meeting stated that 
>>>Certification Authorities are being deployed with names not 
>>>acquired from naming authorities but with names arbitrarily chosen 
>>>assuming that no other CA is or will be operating under that name.

>That is, of course, true. There is no central repository for CA names 
>because there is no central authority for CAs.

>>>That participant further stated that the IETF provides no 
>>>guidelines on ensuring that the names of CAs are unambiguous.

>That is true.

>>>The directory group requests the IETF PKIX group to comment on this 
>>>statement.

>Should we make a consensus call on "that is true"?

>>>If the statement is correct, we ask the IETF to consider putting a 
>>>mechanism in place to prevent conflict, e.g. a list of existing CA 
>>>names that deployers of new CAs could check for naming conflicts.

>Words fail me.

>--Paul Hoffman, Director
>--VPN Consortium

Date: Mon, 22 Oct 2007 06:33:38 -0400
To: Hoyt L Kesterson II <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Upper Bounds for X.509
Sender: [email-masked]

Hoyt:

One never knows which non-critical extensions might be put in a 
certificate.  Remember when Bob Jueneman was advocating pictures in 
certificates....

Russ

At 04:30 AM 10/22/2007, Hoyt L Kesterson II wrote:

>Steven, I didn't say it was an attractive option. I have always been 
>against these limits.
>
>Peter Gutmann recommended that "reasonable" upper bounds be set, 
>e.g. thousand characters for a common name. But it appears his 
>concern is about erratic operation when the certificate itself it huge.
>
>It may be more reasonable to set a max size on the entire 
>certificate than on the individual components that comprise it.
>
>    hoyt
>
> >Hoyt,
> >
> >Hoyt L Kesterson II wrote:
> >>Another option is to keep the bounds as we have them and have the 
> IETF standard mandate the bounds, choosing any values you like.
> >
> >Then directory deployments would have to choose between being nice
> >to PKIX applications by imposing PKIX's upper bounds, or being
> >nice to other LDAP applications by not imposing upper bounds.
> >
> >Regards,
> >Steven

Date: Mon, 22 Oct 2007 01:30:50 -0700
To: [email-masked]
From: Hoyt L Kesterson II <[email-masked]>
Subject: Re: Upper Bounds for X.509
Sender: [email-masked]

Steven, I didn't say it was an attractive option. I have always been against these limits.

Peter Gutmann recommended that "reasonable" upper bounds be set, e.g. thousand characters for a common name. But it appears his concern is about erratic operation when the certificate itself it huge.

It may be more reasonable to set a max size on the entire certificate than on the individual components that comprise it.

   hoyt

>Hoyt,
>
>Hoyt L Kesterson II wrote:
>>Another option is to keep the bounds as we have them and have the IETF standard mandate the bounds, choosing any values you like.
>
>Then directory deployments would have to choose between being nice
>to PKIX applications by imposing PKIX's upper bounds, or being
>nice to other LDAP applications by not imposing upper bounds.
>
>Regards,
>Steven

Date: Mon, 22 Oct 2007 13:45:57 +1000
From: Steven Legg <[email-masked]>
To: Hoyt L Kesterson II <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: Upper Bounds for X.509
Sender: [email-masked]

Hoyt,

Hoyt L Kesterson II wrote:
> Another option is to keep the bounds as we have them and have the IETF standard mandate the bounds, choosing any values you like.

Then directory deployments would have to choose between being nice
to PKIX applications by imposing PKIX's upper bounds, or being
nice to other LDAP applications by not imposing upper bounds.

Regards,
Steven

Date: Mon, 22 Oct 2007 13:32:21 +1000
From: Steven Legg <[email-masked]>
To: Russ Housley <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: Upper Bounds for X.509
Sender: [email-masked]

Russ,

Russ Housley wrote:
> I understand that an unbounded directory string may be useful in many 
> contexts, but is it going to help interoperability to remove the bounds 
> on naming attributes?

As I recall, it was an upper bound on a naming attribute that we first
bumped up against, and which prompted us to ignore all the upper bounds.
Ignoring the upper bounds also allows us to claim conformance with LDAP,
which imposes no upper bounds. Clearly there is the potential for
interoperability problems if we interwork with an implementation that
imposes upper bounds. To the best of my knowledge such problems haven't
arisen with respect to our implementation. I assume that in each instance
of interworking the other system also ignores the upper bounds, or else
the shared data happen to be within that other system's upper bounds.
Nonetheless, the potential for interoperability problems diminishes if
the upper bounds are discarded.

Regards,
Steven

> 
> Russ
> 
> At 10:19 AM 10/19/2007, Erik Andersen wrote:
>> Hi Folks,
>>  
>> As mentioned in a liaison statement from the directory meeting, 
>> September 2007 in Geneva, we have decided to remove the Upper Bounds 
>> from any occurrence. A majority of those are on DirectoryString, which 
>> is also specified for many attribute types.
>>  
>> At one type we were considering removing the Upper Bound by the Defect 
>> Report procedure, but found the change to heavy for that procedure. By 
>> the Defect Report procedure we corrected a inconsistency in the Upper 
>> Bounds and expressed that Upper Bounds are only provided as examples.
>>  
>> It is our intention to remove the Upper Bound from the sixth edition 
>> of the Directory Specification. We gave a possible approach in the 
>> liaison statement, but that may not be the final solution. Be assured 
>> that whatever we do, it will be valid ASN.1. The example we came up 
>> with is actual valid ASN.1 by using parameterized specification. 
>> However, we are faced with the problem that directory object class 
>> definitions will be parameterized. This does not change the definition 
>> as such, but only the ASN.1 appearance. This could be a problem for 
>> implementations parsing such object class definitions to set-up the 
>> directory schema.
>>  
>> Our fall-back solution is to define a new variant of DirectoryString 
>> that is unbounded.
>>  
>> Erik Andersen
>> Andersen's L-Service
>> Mobile: +45 20 97 14 90
>> e-mail: [email-masked] <mailto:[email-masked]>
>> http://www.x500standard.com/
>> http://home20.inet.tele.dk/era/me
>>  

Date: Mon, 22 Oct 2007 11:51:27 +1000
From: Steven Legg <[email-masked]>
To: Tom Gindin <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution   of DR320"
Sender: [email-masked]

Tom Gindin wrote:
>         I know this response is a little late, but the main reason that 
> there is no central repository for CA names is that there is no world-wide 
> directory using X.500 names.  For reasons which have been discussed many 
> times on this list, there probably never will be.  Of course,  the IETF 
> knows of an existing registry which could be used to avoid conflicts 
> between CA names.
>         How about the following wording: "Certificate Authorities SHOULD 
> NOT use a value in the Organization or Common Name attribute of their 
> Distinguished Name which is syntactically legal as a dNSName (i.e. an IA5 
> string containing one or more periods but no spaces) unless they are 
> operated by an organization which has registered the domain name 
> controlling that dNSName.  Certificate Authorities wishing to ensure a 
> globally unique issuer name MAY use an IA5 FQDN controlled by their 
> organization in either the Organization or the Common Name attribute."

... or use the dc naming attribute defined in RFC 4519.

Regards,
Steven

> Does anybody want to add Organizational Unit into the mix, and possibly 
> even make it a SHOULD for newly allocated CA's?
>         Given my unfamiliarity with non-alphabetic scripts, I hesitate to 
> discuss internationalized DNS names in this connection unless Punycode is 
> relevant.  However, even without considering DR 320, using somebody else's 
> domain name as your CN or O attribute is misleading.
> 
>                 Tom Gindin
> 
> P.S. -  The opinions above are mine, and not necessarily those of my 
> employer
> 
> 
> 
> Ryan Hurst <[email-masked]> 
> Sent by: [email-masked]
> 10/09/2007 08:47 PM
> 
> To
> Paul Hoffman <[email-masked]>, Russ Housley <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> cc
> 
> Subject
> RE: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"
> 
> 
> 
> 
> 
> 
> 
> All of these statements are true.
> 
> Words fail me is as fine a response to that as any...
> 
> ________________________________________
> From: [email-masked] [[email-masked]] On 
> Behalf Of Paul Hoffman [[email-masked]]
> Sent: Tuesday, October 09, 2007 3:25 PM
> To: Russ Housley; [email-masked]
> Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of 
> DR320"
> 
> The ITU statement says the following:
> 
>>> One of the participants in the directory meeting stated that
>>> Certification Authorities are being deployed with names not
>>> acquired from naming authorities but with names arbitrarily chosen
>>> assuming that no other CA is or will be operating under that name.
> 
> That is, of course, true. There is no central repository for CA names
> because there is no central authority for CAs.
> 
>>> That participant further stated that the IETF provides no
>>> guidelines on ensuring that the names of CAs are unambiguous.
> 
> That is true.
> 
>>> The directory group requests the IETF PKIX group to comment on this
>>> statement.
> 
> Should we make a consensus call on "that is true"?
> 
>>> If the statement is correct, we ask the IETF to consider putting a
>>> mechanism in place to prevent conflict, e.g. a list of existing CA
>>> names that deployers of new CAs could check for naming conflicts.
> 
> Words fail me.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Upper Bounds for X.509
Cc: [email-masked]
Date: Sun, 21 Oct 2007 01:11:46 +1300
Sender: [email-masked]

Hoyt L Kesterson II <[email-masked]> writes:

>Does certificate generating software enforce the bounds?
>
>Does relying party software validate the bounds in received certificate?

Yes.  I think there should be some reasonable upper bound (1K perhaps) as a
safety feature to prevent MPEG-of-cat certificates.  People are going to stuff
anything they feel like into certs, aided and abetted by software that hides
the details of what they're doing (dragging an icon to a drop target doesn't
convey the fact that adding a 20MB Flash animation at that location isn't very
sensible).  So making it unbounded is asking for trouble.  Setting a
reasonable upper bound (does anyone really have a common name more than a
thousand characters long?) is a good safety setting.

(Oh, and an aside: When I created the MPEG-of-cat cert, with a (by current
standards) relatively small ~1MB MPEG in there, neither Windows nor Netscape
(the two main cert apps at the time) complained about finding over a million
characters in what should be a short field.  However, both of them performed
very erratically, and in the case of Netscape I had to delete the browser cert
database after a couple of days to restore proper operation to the browser.
So current apps will quite readily accept stupid sizes for these fields, and
nicely DoS themselves in the process.  Another argument for setting upper
limits).

Peter.

Date: Fri, 19 Oct 2007 10:49:39 -0700 (GMT-07:00)
From: Hoyt L Kesterson II <[email-masked]>
Reply-To: Hoyt L Kesterson II <[email-masked]>
To: PKIX <[email-masked]>, Erik Andersen <[email-masked]>, PKIX <[email-masked]>
Subject: Re: Upper Bounds for X.509
Sender: [email-masked]

I had hoped that the LDAP people would join this conversation. Unless I misunderstood, I was told that LDAP never utilized these bounds and that it did not cause interoperability problems.

Another option is to keep the bounds as we have them and have the IETF standard mandate the bounds, choosing any values you like.

Does anyone out there test conformance to these limits? If exceeded, what error is generated? Does certificate generating software enforce the bounds? Does relying party software validate the bounds in received certificate?

    hoyt

-----Original Message-----
>From: Russ Housley <[email-masked]>
>Sent: Oct 19, 2007 10:06 AM
>To: Erik Andersen <[email-masked]>, PKIX <[email-masked]>
>Subject: Re: Upper Bounds for X.509
>
>I understand that an unbounded directory string may be useful in manycontexts, but is it going to help interoperability to remove the boundson naming attributes?
>
>Russ
>
>At 10:19 AM 10/19/2007, Erik Andersen wrote:
>Hi Folks,
>Â 
>As mentioned in a liaison statement from the directory meeting, September2007 in Geneva, we have decided to remove the Upper Bounds from anyoccurrence. A majority of those are on DirectoryString, which is alsospecified for many attribute types.
>Â 
>At one type we were considering removing the Upper Bound by the DefectReport procedure, but found the change to heavy for that procedure. Bythe Defect Report procedure we corrected a inconsistency in the UpperBounds and expressed that Upper Bounds are only provided asexamples.
>Â 
>It is our intention to remove the Upper Bound from the sixth edition ofthe Directory Specification. We gave a possible approach in the liaisonstatement, but that may not be the final solution. Be assured thatwhatever we do, it will be valid ASN.1. The example we came up with isactual valid ASN.1 by using parameterized specification. However, we arefaced with the problem that directory object class definitions will beparameterized. This does not change the definition as such, but only theASN.1 appearance. This could be a problem for implementations parsingsuch object class definitions to set-up the directory schema.
>Â 
>Our fall-back solution is to define a new variant of DirectoryString thatis unbounded.
>Â 
>Erik Andersen
>Andersen's L-Service
>Mobile: +45 20 97 14 90
>e-mail: [email-masked]
>http://www.x500standard.com/
>http://home20.inet.tele.dk/era/me
>Â 

Date: Fri, 19 Oct 2007 10:40:33 -0700 (GMT-07:00)
From: Hoyt L Kesterson II <[email-masked]>
Reply-To: Hoyt L Kesterson II <[email-masked]>
To: Erik Andersen <[email-masked]>, PKIX <[email-masked]>
Subject: Re: Upper Bounds for X.509
Sender: [email-masked]

One minor clarification. Only the blue book (the original CCITT X.520 specification) identified the Bounds annex as normative. That was in error. When the corresponding ISO version was published (the first edition was not done as common text) in 1990 the Bounds annex was correctly identified as informative.

All subsequent publications (done as common text) contained the following line under the annex title â€” "This annex does not form an integral part of this Recommendation | International Standard"

The Foreword clause also contained this paragraph

"Annex C, which is not an integral part of this Recommendation | International Standard, provides suggested upper bounds value constraints used in these Directory Specifications."

Erik's phrase "expressed that Upper Bounds are only provided as examples" means that we have further emphasized that the values are not mandated by the standard. Next we will try blinking red text.

    hoyt

-----Original Message-----
>From: Erik Andersen <[email-masked]>
>Sent: Oct 19, 2007 7:19 AM
>To: PKIX <[email-masked]>
>Subject: Upper Bounds for X.509
>
>Hi Folks,
>
> 
>
>As mentioned in a liaison statement from the directory meeting, September
>2007 in Geneva, we have decided to remove the Upper Bounds from any
>occurrence. A majority of those are on DirectoryString, which is also
>specified for many attribute types.
>
> 
>
>At one type we were considering removing the Upper Bound by the Defect
>Report procedure, but found the change to heavy for that procedure. By the
>Defect Report procedure we corrected a inconsistency in the Upper Bounds and
>expressed that Upper Bounds are only provided as examples.
>
> 
>
>It is our intention to remove the Upper Bound from the sixth edition of the
>Directory Specification. We gave a possible approach in the liaison
>statement, but that may not be the final solution. Be assured that whatever
>we do, it will be valid ASN.1. The example we came up with is actual valid
>ASN.1 by using parameterized specification. However, we are faced with the
>problem that directory object class definitions will be parameterized. This
>does not change the definition as such, but only the ASN.1 appearance. This
>could be a problem for implementations parsing such object class definitions
>to set-up the directory schema.
>
> 
>
>Our fall-back solution is to define a new variant of DirectoryString that is
>unbounded.
>
> 
>
>Erik Andersen
>
>Andersen's L-Service
>
>Mobile: +45 20 97 14 90
>
>e-mail: [email-masked]
>
>http://www.x500standard.com/
>
>http://home20.inet.tele.dk/era/me
>
> 
>

Date: Fri, 19 Oct 2007 10:21:22 -0700
To: Tom Gindin <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"
Cc: <[email-masked]>
Sender: [email-masked]

At 12:37 PM -0400 10/19/07, Tom Gindin wrote:
>         I know this response is a little late, but the main reason that
>there is no central repository for CA names is that there is no world-wide
>directory using X.500 names.

While the latter is obviously true, it is not the "main reason". The 
"main reason" is that many (most?) CAs could get no real value out of 
a "world-wide directory using X.500 names". For example, when an 
organization becomes a CA by making its own trust anchor for internal 
use, having to register in a "world-wide directory" is  a hindrance, 
not a feature.

>For reasons which have been discussed many
>times on this list, there probably never will be.

"Probably" may be understating the likelihood.

>Of course,  the IETF
>knows of an existing registry which could be used to avoid conflicts
>between CA names.

We do?

>         How about the following wording: "Certificate Authorities SHOULD
>NOT use a value in the Organization or Common Name attribute of their
>Distinguished Name which is syntactically legal as a dNSName (i.e. an IA5
>string containing one or more periods but no spaces) unless they are
>operated by an organization which has registered the domain name
>controlling that dNSName.  Certificate Authorities wishing to ensure a
>globally unique issuer name MAY use an IA5 FQDN controlled by their
>organization in either the Organization or the Common Name attribute."

This might be appropriate in an ITU document, but is it really 
appropriate for a standards-track IETF document? In specific, the 
latter makes it sound like using your domain name is safe. Might be, 
might not be.

>Does anybody want to add Organizational Unit into the mix, and possibly
>even make it a SHOULD for newly allocated CA's?

I don't see how this would help. If you look at the OUs in 
IssuerNames of certificates flying around the net, you can see that 
few people understand OUs,

>         Given my unfamiliarity with non-alphabetic scripts, I hesitate to
>discuss internationalized DNS names in this connection unless Punycode is
>relevant.  However, even without considering DR 320, using somebody else's
>domain name as your CN or O attribute is misleading.

True, but I do not think that it is the place of IETF documents to 
say what is or is not "misleading".

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 19 Oct 2007 13:06:46 -0400
To: "Erik Andersen" <[email-masked]>, "PKIX" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Upper Bounds for X.509
Sender: [email-masked]

<html>
<body>
I understand that an unbounded directory string may be useful in many
contexts, but is it going to help interoperability to remove the bounds
on naming attributes?<br><br>
Russ<br><br>
At 10:19 AM 10/19/2007, Erik Andersen wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2>Hi Folks,<br>
&nbsp;<br>
As mentioned in a liaison statement from the directory meeting, September
2007 in Geneva, we have decided to remove the Upper Bounds from any
occurrence. A majority of those are on DirectoryString, which is also
specified for many attribute types.<br>
&nbsp;<br>
At one type we were considering removing the Upper Bound by the Defect
Report procedure, but found the change to heavy for that procedure. By
the Defect Report procedure we corrected a inconsistency in the Upper
Bounds and expressed that Upper Bounds are only provided as
examples.<br>
&nbsp;<br>
It is our intention to remove the Upper Bound from the sixth edition of
the Directory Specification. We gave a possible approach in the liaison
statement, but that may not be the final solution. Be assured that
whatever we do, it will be valid ASN.1. The example we came up with is
actual valid ASN.1 by using parameterized specification. However, we are
faced with the problem that directory object class definitions will be
parameterized. This does not change the definition as such, but only the
ASN.1 appearance. This could be a problem for implementations parsing
such object class definitions to set-up the directory schema.<br>
&nbsp;<br>
Our fall-back solution is to define a new variant of DirectoryString that
is unbounded.<br>
&nbsp;<br>
Erik Andersen<br>
Andersen's L-Service<br>
Mobile: +45 20 97 14 90<br>
e-mail: <a href="mailto:[email-masked]">[email-masked]</a><br>
</font><font face="Times New Roman, Times">
<a href="http://www.x500standard.com/" eudora="autourl">
http://www.x500standard.com/</a><br>
</font><font size=2><a href="http://home20.inet.tele.dk/era/me">
http://home20.inet.tele.dk/era/me</a><br>
</font><font face="Times New Roman, Times">&nbsp;</font></blockquote>
</body>
</html>

To: Ryan Hurst <[email-masked]>
Cc: Russ Housley <[email-masked]>, "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"
From: Tom Gindin <[email-masked]>
Date: Fri, 19 Oct 2007 12:37:41 -0400
Sender: [email-masked]

        I know this response is a little late, but the main reason that 
there is no central repository for CA names is that there is no world-wide 
directory using X.500 names.  For reasons which have been discussed many 
times on this list, there probably never will be.  Of course,  the IETF 
knows of an existing registry which could be used to avoid conflicts 
between CA names.
        How about the following wording: "Certificate Authorities SHOULD 
NOT use a value in the Organization or Common Name attribute of their 
Distinguished Name which is syntactically legal as a dNSName (i.e. an IA5 
string containing one or more periods but no spaces) unless they are 
operated by an organization which has registered the domain name 
controlling that dNSName.  Certificate Authorities wishing to ensure a 
globally unique issuer name MAY use an IA5 FQDN controlled by their 
organization in either the Organization or the Common Name attribute." 
Does anybody want to add Organizational Unit into the mix, and possibly 
even make it a SHOULD for newly allocated CA's?
        Given my unfamiliarity with non-alphabetic scripts, I hesitate to 
discuss internationalized DNS names in this connection unless Punycode is 
relevant.  However, even without considering DR 320, using somebody else's 
domain name as your CN or O attribute is misleading.

                Tom Gindin

P.S. -  The opinions above are mine, and not necessarily those of my 
employer

Ryan Hurst <[email-masked]> 
Sent by: [email-masked]
10/09/2007 08:47 PM

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

Subject
RE: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"

All of these statements are true.

Words fail me is as fine a response to that as any...

________________________________________
From: [email-masked] [[email-masked]] On 
Behalf Of Paul Hoffman [[email-masked]]
Sent: Tuesday, October 09, 2007 3:25 PM
To: Russ Housley; [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of 
DR320"

The ITU statement says the following:

>>One of the participants in the directory meeting stated that
>>Certification Authorities are being deployed with names not
>>acquired from naming authorities but with names arbitrarily chosen
>>assuming that no other CA is or will be operating under that name.

That is, of course, true. There is no central repository for CA names
because there is no central authority for CAs.

>>That participant further stated that the IETF provides no
>>guidelines on ensuring that the names of CAs are unambiguous.

That is true.

>>The directory group requests the IETF PKIX group to comment on this
>>statement.

Should we make a consensus call on "that is true"?

>>If the statement is correct, we ask the IETF to consider putting a
>>mechanism in place to prevent conflict, e.g. a list of existing CA
>>names that deployers of new CAs could check for naming conflicts.

Words fail me.

--Paul Hoffman, Director
--VPN Consortium

From: "Erik Andersen" <[email-masked]>
To: "PKIX" <[email-masked]>
Subject: Upper Bounds for X.509
Date: Fri, 19 Oct 2007 16:19:41 +0200
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C8126B.DB523E60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Folks,

=20

As mentioned in a liaison statement from the directory meeting, =
September
2007 in Geneva, we have decided to remove the Upper Bounds from any
occurrence. A majority of those are on DirectoryString, which is also
specified for many attribute types.

=20

At one type we were considering removing the Upper Bound by the Defect
Report procedure, but found the change to heavy for that procedure. By =
the
Defect Report procedure we corrected a inconsistency in the Upper Bounds =
and
expressed that Upper Bounds are only provided as examples.

=20

It is our intention to remove the Upper Bound from the sixth edition of =
the
Directory Specification. We gave a possible approach in the liaison
statement, but that may not be the final solution. Be assured that =
whatever
we do, it will be valid ASN.1. The example we came up with is actual =
valid
ASN.1 by using parameterized specification. However, we are faced with =
the
problem that directory object class definitions will be parameterized. =
This
does not change the definition as such, but only the ASN.1 appearance. =
This
could be a problem for implementations parsing such object class =
definitions
to set-up the directory schema.

=20

Our fall-back solution is to define a new variant of DirectoryString =
that is
unbounded.

=20

Erik Andersen

Andersen's L-Service

Mobile: +45 20 97 14 90

e-mail: [email-masked]

http://www.x500standard.com/

http://home20.inet.tele.dk/era/me

=20

------=_NextPart_000_0015_01C8126B.DB523E60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h3
	{margin-top:9.05pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:0cm;
	text-align:justify;
	page-break-after:avoid;
	font-size:10.0pt;
	font-family:Times;}
p.MsoToc4, li.MsoToc4, div.MsoToc4
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:87.9pt;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:-45.35pt;
	font-size:10.0pt;
	font-family:"Times New Roman";}
p.MsoToc5, li.MsoToc5, div.MsoToc5
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:48.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.ASN1, li.ASN1, div.ASN1
	{margin-top:6.8pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:0cm;
	margin-bottom:.0001pt;
	punctuation-wrap:simple;
	text-autospace:none;
	font-size:9.0pt;
	font-family:Helvetica;
	font-weight:bold;}
span.EmailStyle20
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Hi Folks,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>As mentioned in a liaison statement from the
directory meeting, September 2007 in </span></font><font size=3D2 =
face=3DArial><span
  lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Geneva</span></font><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>,
we have decided to remove the Upper Bounds from any occurrence. A =
majority of
those are on DirectoryString, which is also specified for many attribute =
types.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>At one type we were considering removing the =
Upper
Bound by the Defect Report procedure, but found the change to heavy for =
that
procedure. By the Defect Report procedure we corrected a inconsistency =
in the
Upper Bounds and expressed that Upper Bounds are only provided as =
examples.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It is our intention to remove the Upper Bound =
from
the sixth edition of the Directory Specification. We gave a possible =
approach
in the liaison statement, but that may not be the final solution. Be =
assured
that whatever we do, it will be valid ASN.1. The example we came up with =
is
actual valid ASN.1 by using parameterized specification. However, we are =
faced
with the problem that directory object class definitions will be =
parameterized.
This does not change the definition as such, but only the ASN.1 =
appearance. This
could be a problem for implementations parsing such object class =
definitions to
set-up the directory schema.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Our fall-back solution is to define a new =
variant of
DirectoryString that is unbounded.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Erik Andersen</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Andersen's L-Service</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
  10.0pt;font-family:Arial'>Mobile</span></font><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>: +45 20 97 14 =
90</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>e-mail: <a =
href=3D"mailto:[email-masked]">[email-masked]</a></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'><a =
href=3D"http://www.x500standard.com/">http://www.x500standard.com/</a></s=
pan></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><a =
href=3D"http://home20.inet.tele.dk/era/me">http://home20.inet.tele.dk/era=
/me</a></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0015_01C8126B.DB523E60--

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Tue, 16 Oct 2007 12:11:03 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "Seth Hitchings" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C81028.83DBBE2C
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I agree that the RFC 2560 should be revised for a variety of reasons.

=20

It would be nice to have a set of client side request composition and
response processing rules (a la Section 6 of RFC 3290).

=20

We probably can not mandate that in delegated model certificate in
question and OCSP Responder should be signed by the same CA key, but we
can recommend it and add some language in the Security Considerations
section the residual risk of not doing that.

=20

For hashing algorithm, certID should be sufficient and should be the
same the as the hashing algorithm, used for the certificate.  We of
course will need to spell this out in the revision.

=20

For signature, we can add an extension, but this should state the
algorithm used for the certificate.  We of course will need to spell
this out also in the revision.

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, October 15, 2007 11:36 PM
To: Seth Hitchings; Santosh Chokhani; [email-masked]
Subject: RE: OCSP Algorithm Agility

=20

Whether a server could make a sensible choice is beside the point.

=20

For a specification to provide an interoperable standard we must have a
definitive statement. Otherwise interoperability ends up depending on
heuristics and undocumented assumptions.

=20

Unless I missed the section in the RFC that describes the algorithm
agility strategy it seems to me we must either:

=20

1) Document the server algorithm selection as proposed by Santosh

2) Doucment the server algorithm selection as proposed by Santosh with
an optional extension to allow the client to specify the choices it
supports.

=20

Either way we need a draft if we are going to meet the algorithm agility
requirement.

=20

________________________________

From: [email-masked] on behalf of Seth Hitchings
Sent: Wed 10/10/2007 3:25 PM
To: Santosh Chokhani; Hallam-Baker, Phillip; [email-masked]
Subject: RE: OCSP Algorithm Agility

I'm generally in favor of simpler approaches, such as those suggested by
Santosh, as they favor interoperability. Updating deployed applications
to
understand new elements of the protocol could take just as long to roll
out
as the new algorithm support that's purportedly lacking.

I can see a situation in which the CA cannot assume that the entire user
population understands a new algorithm such as SHA-256, and thus has to
continue using SHA-1 with RSA when signing certificates. Individual
clients
that do understand SHA-256 may wish to receive OCSP responses signed
using
SHA-256 with RSA, and would need a way to signal their desires to the
OCSP
responder.

The question is, then, is there any security benefit to having the
signature
algorithm on the OCSP response stronger than the signature algorithm on
the
certificate? If you can break the algorithm and cause me to accept a
contrived OCSP response, could you not do the same thing with a
certificate?

Seth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of Santosh Chokhani
Sent: Wednesday, October 10, 2007 2:28 PM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: OCSP Algorithm Agility

See responses in-line below.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]]
Sent: Tuesday, October 09, 2007 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: OCSP Algorithm Agility

Not if they don't know that the client can understand them they can't.
[Santosh Chokhani] The Responder has two ways to know what the client
understands.  From certID or from CA.  If the client does not understand
the algorithm used in certificate signing, revocation information is
useless.

And the issue is not just hashing algorithms, it is signature
algorithms.
Like your previous posts you continue to assume that cipher strength is
a linear quantity with only one dimension and that any client which
supports strength 2X must automatically support strength X.
[Santosh Chokhani] I am making no such assumptions.  I am saying that if
an algorithm is good enough for a certificate, it is good enough for
revocation notification for that certificate.

That is not the case if you consider the practicalities of deploying ECC
in an RSA world.

To give a practical example, VeriSign issues a cert for an ECC key
signed with an ECC key. The email program on Alice's machine in the DHS
supports ECC but not the DHS SCVP server or OCSP relay.
[Santosh Chokhani] And what is the problem with that?  They have no
choice but to use RSA.

In the real world the OCSP service does not have a necessary connection
to the CA. There are plenty of commercial OCSP offerings that report on
certificates issued by other CAs.
[Santosh Chokhani] And how does this relate to algorithm agility?  If
the OCSP does not do ECDSA it won't.  If OCSP supports both RSA and
ECDSA, it can take the cue from the CA CRL to determine what algorithm
to use for signing OCSP responses.  If the OCSP does not consume CRL,
the mechanism that tells it revocation information can also tell it the
signature algorithm to use.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Tuesday, October 09, 2007 11:16 AM
> To: Hallam-Baker, Phillip; [email-masked]
> Subject: RE: OCSP Algorithm Agility
>
>
> The OCSP and SCVP can transition to stronger algorithms any
> time they want.
>
> The OCSP can take their clue from the CA or the certID field
> to decide the hashing algorithm.  When multiple certID is
> present, OCSP can take low water mark of these.
>
> SCVP is no different than a client in terms of validating a
> path.  In terms of signing a response, it can take the low
> water mark of the hashing algorithms in the certificate chain.
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of Hallam-Baker, Phillip
> Sent: Monday, October 08, 2007 7:27 PM
> To: Santosh Chokhani; Andrews, Rick; [email-masked]
> Subject: RE: OCSP Algorithm Agility
>
>
> The objective here is to overcome a real deployment obstacle
> that creates a lockstep issue when use of stronger algorithms
> is attempted.
>
> The CA cannot issue a certificate that employs a new
> algorithm until it is known that all clients that might rely
> on the certificate are capable of processing the new
> certificate. Requiring lockstep updates to the OCSP and SCVP
> infrastructure to be made at the same time renders transition
> to stronger algorithms a much lengthier and much less
> practical proposition.
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Saturday, October 06, 2007 4:12 PM
> > To: Andrews, Rick; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> >
> >
> > Rick,
> >
> > SCVP or other intermediaries are red herring.  Whoever
> processes the
> > certificate processes the revocation information for that
> certificate.
> > It does not change the following:
> >
> > 1.  There is no security benefit in using a stronger algorithm for
> > OCSP
> > response than for the certificate in question.   Neither,
> there is any
> > benefit from interoperability viewpoint for these two to be
> different.
> >
> > 2.  If the OCSP Responder does not get a CRL, it can use the same
> > mechanism to get the hashing algorithm used as it uses to get the
> > revocation information.
> >
> > -----Original Message-----
> > From: Andrews, Rick [mailto:[email-masked]]
> > Sent: Wednesday, October 03, 2007 3:29 PM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> >
> > Santosh,
> >
> > Sorry for the long delay in responding - travel and vacation.
> >=20
> > Not all OCSP responders work from CRLs, so they won't take
> their cue
> > from the CRL. Nor should they take their cue from the
> signature on the
> > cert in question, I believe. Let me try to restate my argument in a
> > different way.
> >=20
> > With SCVP delegated path validation, the client requesting a cert's
> > status from an OCSP responder will be different from the
> client at the
> > other end of the SSL connection. Those two clients may have very
> > different capabilities in terms of supported signature and hash
> > algorithms. It's not realistic to expect that all SSL clients, all
> > SCVP servers, and all CAs will be able to upgrade in
> lockstep to new
> > algorithms as they are developed. Allowing the OCSP client
> and server
> > to negotiate a mutually-acceptable set of algorithms is
> essential to
> > the deployment of newer, stronger algorithms.
> >=20
> > Likewise, companies that run large OCSP responders may wish to
> > gradually move to ECC-based signatures for all their OCSP
> responses,
> > even those for certs with RSA or DSA keys, because ECC
> signatures are
> > cheaper to produce. If algorithm agility is added to OCSP, those
> > companies can gradually achieve the move to ECC without
> disrupting the
> > installed base of OCSP clients that don't support ECC.
> >=20
> > -Rick Andrews
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of
> Santosh Chokhani
> > > Sent: Friday, September 21, 2007 2:45 PM
> > > To: Paul Hoffman; Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > >
> > >
> > > Paul,
> > >
> > > Here are my views on this.
> > >
> > > The client should be first asking for the algorithm suite
> > that signed
> > > the certificate in question.  There is no need for the
> > client to ask
> > > for anything stronger.  The client can ask for stronger suites as
> > > secondary, if client has them.
> > >
> > > In the scenario you cite, the Responder certificate will
> > not include
> > > RSA with SHA 1 any longer.  So, client will know that
> > Responder only
> > > supported his second choice and he should be ok with it.
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > On Behalf Of Paul Hoffman
> > > Sent: Friday, September 21, 2007 4:39 PM
> > > To: Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > >
> > >
> > > At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> > > >How about defining an extension to be included in the cert
> > > issued to an
> > > >OCSP responder by a CA.  The extension would have an
> > ordered list of
> > > >algorithms (hash and signature if we want to address more
> > > than the hash
> > > >agility issue) accepted by the OCSP responder.  An OCSP
> > > client can use
> > > >this info to determine what is the "best" algorithm (or alg
> > > pair) that
> > > >it and the responder share. The combination of this
> > extension and an
> > > >OCSP negotiation procedure will allow the client to detect MITM
> > > >downgrade attacks. In fact, if the client acquires the
> > > responder's cert
> > > >prior to making a request, there would not even be a
> need for real
> > > >negotiation, since the client would know what alg to
> request in a
> > > >response.
> > >
> > > Imagine the list of algorithms is RSA-with-SHA1 first and
> > > DSA-with-SHA1 second. How does your negotiation work? The
> > client asks
> > > for this message to be signed with RSA-with-SHA1.
> > > But the server knows that RSA-with-SHA1 has been
> > compromised since it
> > > got that certificate from the CA. What does the server say to the
> > > client to indicate that it only wants to sign with
> > DSA-with-SHA1? What
> > > prevents Mallory from saying the same thing to the client?
> > >
> > > --Paul Hoffman, Director
> > > --VPN Consortium
> > >
> > >
> > >
> >
> >
>
>
>

------_=_NextPart_001_01C81028.83DBBE2C
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: OCSP Algorithm Agility</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree that the RFC 2560 should be
revised for a variety of reasons.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It would be nice to have a set of =
client
side request composition and response processing rules (a la Section 6 =
of RFC
3290).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>We probably can not mandate that in
delegated model certificate in question and OCSP Responder should be =
signed by
the same CA key, but we can recommend it and add some language in the =
Security
Considerations section the residual risk of not doing =
that.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>For hashing algorithm, certID =
should be
sufficient and should be the same the as the hashing algorithm, used for =
the certificate.
&nbsp;We of course will need to spell this out in the =
revision.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>For signature, we can add an =
extension,
but this should state the algorithm used for the certificate.&nbsp; We =
of course
will need to spell this out also in the =
revision.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Hallam-Baker, =
Phillip<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 15, =
2007
11:36 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Seth Hitchings; =
<st1:PersonName
w:st=3D"on">Santosh Chokhani</st1:PersonName>; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: OCSP =
Algorithm
Agility</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div id=3DidOWAReplyText70118>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black'>Whether a server could make a =
sensible
choice is beside the point.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>For a specification to provide an interoperable =
standard we
must have a definitive statement. Otherwise interoperability ends up =
depending
on heuristics and undocumented assumptions.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Unless I missed the section in the RFC that describes =
the
algorithm agility strategy it seems to me we must =
either:</span></font><o:p></o:p></p>

</div>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>1) Document the&nbsp;server&nbsp;algorithm selection as proposed =
by
Santosh<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>2) Doucment&nbsp;the server algorithm selection as proposed by =
Santosh
with an optional extension to allow the client to specify the choices it =
supports.<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Either way we need a draft if we are going to meet the algorithm
agility requirement.<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] on behalf of Seth Hitchings<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wed 10/10/2007 3:25 =
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Santosh
 Chokhani</st1:PersonName>; Hallam-Baker, Phillip; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: OCSP =
Algorithm
Agility</span></font><o:p></o:p></p>

</div>

<div>

<p style=3D'margin-bottom:12.0pt'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I'm generally in favor of simpler approaches, =
such as
those suggested by<br>
Santosh, as they favor interoperability. Updating deployed applications =
to<br>
understand new elements of the protocol could take just as long to roll =
out<br>
as the new algorithm support that's purportedly lacking.<br>
<br>
I can see a situation in which the CA cannot assume that the entire =
user<br>
population understands a new algorithm such as SHA-256, and thus has =
to<br>
continue using SHA-1 with RSA when signing certificates. Individual =
clients<br>
that do understand SHA-256 may wish to receive OCSP responses signed =
using<br>
SHA-256 with RSA, and would need a way to signal their desires to the =
OCSP<br>
responder.<br>
<br>
The question is, then, is there any security benefit to having the =
signature<br>
algorithm on the OCSP response stronger than the signature algorithm on =
the<br>
certificate? If you can break the algorithm and cause me to accept a<br>
contrived OCSP response, could you not do the same thing with a =
certificate?<br>
<br>
Seth<br>
<br>
-----Original Message-----<br>
From: [email-masked] [<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
On<br>
Behalf Of <st1:PersonName w:st=3D"on">Santosh =
Chokhani</st1:PersonName><br>
Sent: Wednesday, October 10, 2007 2:28 PM<br>
To: Hallam-Baker, Phillip; [email-masked]<br>
Subject: RE: OCSP Algorithm Agility<br>
<br>
<br>
See responses in-line below.<br>
<br>
-----Original Message-----<br>
From: Hallam-Baker, Phillip [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<br>
Sent: Tuesday, October 09, 2007 2:07 PM<br>
To: <st1:PersonName w:st=3D"on">Santosh Chokhani</st1:PersonName>; =
[email-masked]<br>
Subject: RE: OCSP Algorithm Agility<br>
<br>
Not if they don't know that the client can understand them they =
can't.<br>
[<st1:PersonName w:st=3D"on">Santosh Chokhani</st1:PersonName>] The =
Responder has
two ways to know what the client<br>
understands.&nbsp; From certID or from CA.&nbsp; If the client does not =
understand<br>
the algorithm used in certificate signing, revocation information is<br>
useless.<br>
<br>
And the issue is not just hashing algorithms, it is signature<br>
algorithms.<br>
Like your previous posts you continue to assume that cipher strength =
is<br>
a linear quantity with only one dimension and that any client which<br>
supports strength 2X must automatically support strength X.<br>
[<st1:PersonName w:st=3D"on">Santosh Chokhani</st1:PersonName>] I am =
making no
such assumptions.&nbsp; I am saying that if<br>
an algorithm is good enough for a certificate, it is good enough for<br>
revocation notification for that certificate.<br>
<br>
That is not the case if you consider the practicalities of deploying =
ECC<br>
in an RSA world.<br>
<br>
To give a practical example, VeriSign issues a cert for an ECC key<br>
signed with an ECC key. The email program on <st1:City =
w:st=3D"on"><st1:place
 w:st=3D"on">Alice</st1:place></st1:City>'s machine in the DHS<br>
supports ECC but not the DHS SCVP server or OCSP relay.<br>
[<st1:PersonName w:st=3D"on">Santosh Chokhani</st1:PersonName>] And what =
is the
problem with that?&nbsp; They have no<br>
choice but to use RSA.<br>
<br>
In the real world the OCSP service does not have a necessary =
connection<br>
to the CA. There are plenty of commercial OCSP offerings that report =
on<br>
certificates issued by other CAs.<br>
[<st1:PersonName w:st=3D"on">Santosh Chokhani</st1:PersonName>] And how =
does this
relate to algorithm agility?&nbsp; If<br>
the OCSP does not do ECDSA it won't.&nbsp; If OCSP supports both RSA =
and<br>
ECDSA, it can take the cue from the CA CRL to determine what =
algorithm<br>
to use for signing OCSP responses.&nbsp; If the OCSP does not consume =
CRL,<br>
the mechanism that tells it revocation information can also tell it =
the<br>
signature algorithm to use.<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: [email-masked]<br>
&gt; [<a =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
On Behalf Of <st1:PersonName w:st=3D"on">Santosh =
Chokhani</st1:PersonName><br>
&gt; Sent: Tuesday, October 09, 2007 11:16 AM<br>
&gt; To: Hallam-Baker, Phillip; [email-masked]<br>
&gt; Subject: RE: OCSP Algorithm Agility<br>
&gt;<br>
&gt;<br>
&gt; The OCSP and SCVP can transition to stronger algorithms any<br>
&gt; time they want.<br>
&gt;<br>
&gt; The OCSP can take their clue from the CA or the certID field<br>
&gt; to decide the hashing algorithm.&nbsp; When multiple certID is<br>
&gt; present, OCSP can take low water mark of these.<br>
&gt;<br>
&gt; SCVP is no different than a client in terms of validating a<br>
&gt; path.&nbsp; In terms of signing a response, it can take the low<br>
&gt; water mark of the hashing algorithms in the certificate chain.<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: [email-masked]<br>
&gt; [<a =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]<br>
&gt; On Behalf Of Hallam-Baker, Phillip<br>
&gt; Sent: Monday, October 08, 2007 7:27 PM<br>
&gt; To: <st1:PersonName w:st=3D"on">Santosh Chokhani</st1:PersonName>; =
Andrews,
Rick; [email-masked]<br>
&gt; Subject: RE: OCSP Algorithm Agility<br>
&gt;<br>
&gt;<br>
&gt; The objective here is to overcome a real deployment obstacle<br>
&gt; that creates a lockstep issue when use of stronger algorithms<br>
&gt; is attempted.<br>
&gt;<br>
&gt; The CA cannot issue a certificate that employs a new<br>
&gt; algorithm until it is known that all clients that might rely<br>
&gt; on the certificate are capable of processing the new<br>
&gt; certificate. Requiring lockstep updates to the OCSP and SCVP<br>
&gt; infrastructure to be made at the same time renders transition<br>
&gt; to stronger algorithms a much lengthier and much less<br>
&gt; practical proposition.<br>
&gt;<br>
&gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: [email-masked]<br>
&gt; &gt; [<a =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
On Behalf Of <st1:PersonName w:st=3D"on">Santosh =
Chokhani</st1:PersonName><br>
&gt; &gt; Sent: Saturday, October 06, 2007 4:12 PM<br>
&gt; &gt; To: Andrews, Rick; [email-masked]<br>
&gt; &gt; Subject: RE: OCSP Algorithm Agility<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Rick,<br>
&gt; &gt;<br>
&gt; &gt; SCVP or other intermediaries are red herring.&nbsp; =
Whoever<br>
&gt; processes the<br>
&gt; &gt; certificate processes the revocation information for that<br>
&gt; certificate.<br>
&gt; &gt; It does not change the following:<br>
&gt; &gt;<br>
&gt; &gt; 1.&nbsp; There is no security benefit in using a stronger =
algorithm
for<br>
&gt; &gt; OCSP<br>
&gt; &gt; response than for the certificate in question.&nbsp;&nbsp; =
Neither,<br>
&gt; there is any<br>
&gt; &gt; benefit from interoperability viewpoint for these two to =
be<br>
&gt; different.<br>
&gt; &gt;<br>
&gt; &gt; 2.&nbsp; If the OCSP Responder does not get a CRL, it can use =
the
same<br>
&gt; &gt; mechanism to get the hashing algorithm used as it uses to get =
the<br>
&gt; &gt; revocation information.<br>
&gt; &gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: Andrews, Rick [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<b=
r>
&gt; &gt; Sent: Wednesday, October 03, 2007 3:29 PM<br>
&gt; &gt; To: <st1:PersonName w:st=3D"on">Santosh =
Chokhani</st1:PersonName>;
[email-masked]<br>
&gt; &gt; Subject: RE: OCSP Algorithm Agility<br>
&gt; &gt;<br>
&gt; &gt; Santosh,<br>
&gt; &gt;<br>
&gt; &gt; Sorry for the long delay in responding - travel and =
vacation.<br>
&gt; &gt;&nbsp;<br>
&gt; &gt; Not all OCSP responders work from CRLs, so they won't take<br>
&gt; their cue<br>
&gt; &gt; from the CRL. Nor should they take their cue from the<br>
&gt; signature on the<br>
&gt; &gt; cert in question, I believe. Let me try to restate my argument =
in a<br>
&gt; &gt; different way.<br>
&gt; &gt;&nbsp;<br>
&gt; &gt; With SCVP delegated path validation, the client requesting a =
cert's<br>
&gt; &gt; status from an OCSP responder will be different from the<br>
&gt; client at the<br>
&gt; &gt; other end of the SSL connection. Those two clients may have =
very<br>
&gt; &gt; different capabilities in terms of supported signature and =
hash<br>
&gt; &gt; algorithms. It's not realistic to expect that all SSL clients, =
all<br>
&gt; &gt; SCVP servers, and all CAs will be able to upgrade in<br>
&gt; lockstep to new<br>
&gt; &gt; algorithms as they are developed. Allowing the OCSP client<br>
&gt; and server<br>
&gt; &gt; to negotiate a mutually-acceptable set of algorithms is<br>
&gt; essential to<br>
&gt; &gt; the deployment of newer, stronger algorithms.<br>
&gt; &gt;&nbsp;<br>
&gt; &gt; Likewise, companies that run large OCSP responders may wish =
to<br>
&gt; &gt; gradually move to ECC-based signatures for all their OCSP<br>
&gt; responses,<br>
&gt; &gt; even those for certs with RSA or DSA keys, because ECC<br>
&gt; signatures are<br>
&gt; &gt; cheaper to produce. If algorithm agility is added to OCSP, =
those<br>
&gt; &gt; companies can gradually achieve the move to ECC without<br>
&gt; disrupting the<br>
&gt; &gt; installed base of OCSP clients that don't support ECC.<br>
&gt; &gt;&nbsp;<br>
&gt; &gt; -Rick Andrews<br>
&gt; &gt;<br>
&gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; From: [email-masked]<br>
&gt; &gt; &gt; [<a =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
On Behalf Of<br>
&gt; <st1:PersonName w:st=3D"on">Santosh Chokhani</st1:PersonName><br>
&gt; &gt; &gt; Sent: Friday, September 21, 2007 2:45 PM<br>
&gt; &gt; &gt; To: Paul Hoffman; Stephen Kent; [email-masked]<br>
&gt; &gt; &gt; Subject: RE: OCSP Algorithm Agility<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Paul,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Here are my views on this.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The client should be first asking for the algorithm =
suite<br>
&gt; &gt; that signed<br>
&gt; &gt; &gt; the certificate in question.&nbsp; There is no need for =
the<br>
&gt; &gt; client to ask<br>
&gt; &gt; &gt; for anything stronger.&nbsp; The client can ask for =
stronger
suites as<br>
&gt; &gt; &gt; secondary, if client has them.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; In the scenario you cite, the Responder certificate =
will<br>
&gt; &gt; not include<br>
&gt; &gt; &gt; RSA with SHA 1 any longer.&nbsp; So, client will know =
that<br>
&gt; &gt; Responder only<br>
&gt; &gt; &gt; supported his second choice and he should be ok with =
it.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; From: [email-masked]<br>
&gt; &gt; &gt; [<a =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]<br>
&gt; &gt; &gt; On Behalf Of Paul Hoffman<br>
&gt; &gt; &gt; Sent: Friday, September 21, 2007 4:39 PM<br>
&gt; &gt; &gt; To: Stephen Kent; [email-masked]<br>
&gt; &gt; &gt; Subject: RE: OCSP Algorithm Agility<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; At 2:07 PM -0400 9/21/07, Stephen Kent wrote:<br>
&gt; &gt; &gt; &gt;How about defining an extension to be included in the =
cert<br>
&gt; &gt; &gt; issued to an<br>
&gt; &gt; &gt; &gt;OCSP responder by a CA.&nbsp; The extension would =
have an<br>
&gt; &gt; ordered list of<br>
&gt; &gt; &gt; &gt;algorithms (hash and signature if we want to address =
more<br>
&gt; &gt; &gt; than the hash<br>
&gt; &gt; &gt; &gt;agility issue) accepted by the OCSP responder.&nbsp; =
An OCSP<br>
&gt; &gt; &gt; client can use<br>
&gt; &gt; &gt; &gt;this info to determine what is the &quot;best&quot;
algorithm (or alg<br>
&gt; &gt; &gt; pair) that<br>
&gt; &gt; &gt; &gt;it and the responder share. The combination of =
this<br>
&gt; &gt; extension and an<br>
&gt; &gt; &gt; &gt;OCSP negotiation procedure will allow the client to =
detect
MITM<br>
&gt; &gt; &gt; &gt;downgrade attacks. In fact, if the client acquires =
the<br>
&gt; &gt; &gt; responder's cert<br>
&gt; &gt; &gt; &gt;prior to making a request, there would not even be =
a<br>
&gt; need for real<br>
&gt; &gt; &gt; &gt;negotiation, since the client would know what alg =
to<br>
&gt; request in a<br>
&gt; &gt; &gt; &gt;response.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Imagine the list of algorithms is RSA-with-SHA1 first =
and<br>
&gt; &gt; &gt; DSA-with-SHA1 second. How does your negotiation work? =
The<br>
&gt; &gt; client asks<br>
&gt; &gt; &gt; for this message to be signed with RSA-with-SHA1.<br>
&gt; &gt; &gt; But the server knows that RSA-with-SHA1 has been<br>
&gt; &gt; compromised since it<br>
&gt; &gt; &gt; got that certificate from the CA. What does the server =
say to
the<br>
&gt; &gt; &gt; client to indicate that it only wants to sign with<br>
&gt; &gt; DSA-with-SHA1? What<br>
&gt; &gt; &gt; prevents Mallory from saying the same thing to the =
client?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; --Paul Hoffman, Director<br>
&gt; &gt; &gt; --VPN Consortium<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C81028.83DBBE2C--

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Mon, 15 Oct 2007 20:35:50 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Seth Hitchings" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C80FA5.A59CF9BC
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Whether a server could make a sensible choice is beside the point.
=20
For a specification to provide an interoperable standard we must have a =
definitive statement. Otherwise interoperability ends up depending on =
heuristics and undocumented assumptions.
=20
Unless I missed the section in the RFC that describes the algorithm =
agility strategy it seems to me we must either:
=20
1) Document the server algorithm selection as proposed by Santosh
2) Doucment the server algorithm selection as proposed by Santosh with =
an optional extension to allow the client to specify the choices it =
supports.
=20
Either way we need a draft if we are going to meet the algorithm agility =
requirement.

________________________________

From: [email-masked] on behalf of Seth Hitchings
Sent: Wed 10/10/2007 3:25 PM
To: Santosh Chokhani; Hallam-Baker, Phillip; [email-masked]
Subject: RE: OCSP Algorithm Agility

I'm generally in favor of simpler approaches, such as those suggested by
Santosh, as they favor interoperability. Updating deployed applications =
to
understand new elements of the protocol could take just as long to roll =
out
as the new algorithm support that's purportedly lacking.

I can see a situation in which the CA cannot assume that the entire user
population understands a new algorithm such as SHA-256, and thus has to
continue using SHA-1 with RSA when signing certificates. Individual =
clients
that do understand SHA-256 may wish to receive OCSP responses signed =
using
SHA-256 with RSA, and would need a way to signal their desires to the =
OCSP
responder.

The question is, then, is there any security benefit to having the =
signature
algorithm on the OCSP response stronger than the signature algorithm on =
the
certificate? If you can break the algorithm and cause me to accept a
contrived OCSP response, could you not do the same thing with a =
certificate?

Seth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Santosh Chokhani
Sent: Wednesday, October 10, 2007 2:28 PM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: OCSP Algorithm Agility

See responses in-line below.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]]
Sent: Tuesday, October 09, 2007 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: OCSP Algorithm Agility

Not if they don't know that the client can understand them they can't.
[Santosh Chokhani] The Responder has two ways to know what the client
understands.  From certID or from CA.  If the client does not understand
the algorithm used in certificate signing, revocation information is
useless.

And the issue is not just hashing algorithms, it is signature
algorithms.
Like your previous posts you continue to assume that cipher strength is
a linear quantity with only one dimension and that any client which
supports strength 2X must automatically support strength X.
[Santosh Chokhani] I am making no such assumptions.  I am saying that if
an algorithm is good enough for a certificate, it is good enough for
revocation notification for that certificate.

That is not the case if you consider the practicalities of deploying ECC
in an RSA world.

To give a practical example, VeriSign issues a cert for an ECC key
signed with an ECC key. The email program on Alice's machine in the DHS
supports ECC but not the DHS SCVP server or OCSP relay.
[Santosh Chokhani] And what is the problem with that?  They have no
choice but to use RSA.

In the real world the OCSP service does not have a necessary connection
to the CA. There are plenty of commercial OCSP offerings that report on
certificates issued by other CAs.
[Santosh Chokhani] And how does this relate to algorithm agility?  If
the OCSP does not do ECDSA it won't.  If OCSP supports both RSA and
ECDSA, it can take the cue from the CA CRL to determine what algorithm
to use for signing OCSP responses.  If the OCSP does not consume CRL,
the mechanism that tells it revocation information can also tell it the
signature algorithm to use.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Tuesday, October 09, 2007 11:16 AM
> To: Hallam-Baker, Phillip; [email-masked]
> Subject: RE: OCSP Algorithm Agility
>
>
> The OCSP and SCVP can transition to stronger algorithms any
> time they want.
>
> The OCSP can take their clue from the CA or the certID field
> to decide the hashing algorithm.  When multiple certID is
> present, OCSP can take low water mark of these.
>
> SCVP is no different than a client in terms of validating a
> path.  In terms of signing a response, it can take the low
> water mark of the hashing algorithms in the certificate chain.
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of Hallam-Baker, Phillip
> Sent: Monday, October 08, 2007 7:27 PM
> To: Santosh Chokhani; Andrews, Rick; [email-masked]
> Subject: RE: OCSP Algorithm Agility
>
>
> The objective here is to overcome a real deployment obstacle
> that creates a lockstep issue when use of stronger algorithms
> is attempted.
>
> The CA cannot issue a certificate that employs a new
> algorithm until it is known that all clients that might rely
> on the certificate are capable of processing the new
> certificate. Requiring lockstep updates to the OCSP and SCVP
> infrastructure to be made at the same time renders transition
> to stronger algorithms a much lengthier and much less
> practical proposition.
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Saturday, October 06, 2007 4:12 PM
> > To: Andrews, Rick; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> >
> >
> > Rick,
> >
> > SCVP or other intermediaries are red herring.  Whoever
> processes the
> > certificate processes the revocation information for that
> certificate.
> > It does not change the following:
> >
> > 1.  There is no security benefit in using a stronger algorithm for
> > OCSP
> > response than for the certificate in question.   Neither,
> there is any
> > benefit from interoperability viewpoint for these two to be
> different.
> >
> > 2.  If the OCSP Responder does not get a CRL, it can use the same
> > mechanism to get the hashing algorithm used as it uses to get the
> > revocation information.
> >
> > -----Original Message-----
> > From: Andrews, Rick [mailto:[email-masked]]
> > Sent: Wednesday, October 03, 2007 3:29 PM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> >
> > Santosh,
> >
> > Sorry for the long delay in responding - travel and vacation.
> >=20
> > Not all OCSP responders work from CRLs, so they won't take
> their cue
> > from the CRL. Nor should they take their cue from the
> signature on the
> > cert in question, I believe. Let me try to restate my argument in a
> > different way.
> >=20
> > With SCVP delegated path validation, the client requesting a cert's
> > status from an OCSP responder will be different from the
> client at the
> > other end of the SSL connection. Those two clients may have very
> > different capabilities in terms of supported signature and hash
> > algorithms. It's not realistic to expect that all SSL clients, all
> > SCVP servers, and all CAs will be able to upgrade in
> lockstep to new
> > algorithms as they are developed. Allowing the OCSP client
> and server
> > to negotiate a mutually-acceptable set of algorithms is
> essential to
> > the deployment of newer, stronger algorithms.
> >=20
> > Likewise, companies that run large OCSP responders may wish to
> > gradually move to ECC-based signatures for all their OCSP
> responses,
> > even those for certs with RSA or DSA keys, because ECC
> signatures are
> > cheaper to produce. If algorithm agility is added to OCSP, those
> > companies can gradually achieve the move to ECC without
> disrupting the
> > installed base of OCSP clients that don't support ECC.
> >=20
> > -Rick Andrews
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of
> Santosh Chokhani
> > > Sent: Friday, September 21, 2007 2:45 PM
> > > To: Paul Hoffman; Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > >
> > >
> > > Paul,
> > >
> > > Here are my views on this.
> > >
> > > The client should be first asking for the algorithm suite
> > that signed
> > > the certificate in question.  There is no need for the
> > client to ask
> > > for anything stronger.  The client can ask for stronger suites as
> > > secondary, if client has them.
> > >
> > > In the scenario you cite, the Responder certificate will
> > not include
> > > RSA with SHA 1 any longer.  So, client will know that
> > Responder only
> > > supported his second choice and he should be ok with it.
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > On Behalf Of Paul Hoffman
> > > Sent: Friday, September 21, 2007 4:39 PM
> > > To: Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > >
> > >
> > > At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> > > >How about defining an extension to be included in the cert
> > > issued to an
> > > >OCSP responder by a CA.  The extension would have an
> > ordered list of
> > > >algorithms (hash and signature if we want to address more
> > > than the hash
> > > >agility issue) accepted by the OCSP responder.  An OCSP
> > > client can use
> > > >this info to determine what is the "best" algorithm (or alg
> > > pair) that
> > > >it and the responder share. The combination of this
> > extension and an
> > > >OCSP negotiation procedure will allow the client to detect MITM
> > > >downgrade attacks. In fact, if the client acquires the
> > > responder's cert
> > > >prior to making a request, there would not even be a
> need for real
> > > >negotiation, since the client would know what alg to
> request in a
> > > >response.
> > >
> > > Imagine the list of algorithms is RSA-with-SHA1 first and
> > > DSA-with-SHA1 second. How does your negotiation work? The
> > client asks
> > > for this message to be signed with RSA-with-SHA1.
> > > But the server knows that RSA-with-SHA1 has been
> > compromised since it
> > > got that certificate from the CA. What does the server say to the
> > > client to indicate that it only wants to sign with
> > DSA-with-SHA1? What
> > > prevents Mallory from saying the same thing to the client?
> > >
> > > --Paul Hoffman, Director
> > > --VPN Consortium
> > >
> > >
> > >
> >
> >
>
>
>

------_=_NextPart_001_01C80FA5.A59CF9BC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>RE: OCSP Algorithm Agility</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16546" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText70118 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Whether a =
server could make a sensible choice is beside the point.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>For a specification to =
provide an interoperable standard we must have a definitive statement. =
Otherwise interoperability ends up depending on heuristics and =
undocumented assumptions.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Unless I missed the section =
in the RFC that describes the algorithm agility strategy it seems to me =
we must either:</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>1) Document the&nbsp;server&nbsp;algorithm selection as =
proposed by Santosh</DIV>=0A=
<DIV dir=3Dltr>2) Doucment&nbsp;the server algorithm selection as =
proposed by Santosh with an optional extension to allow the client to =
specify the choices it supports.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Either way we need a draft if we are going to meet the =
algorithm agility requirement.</DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of Seth Hitchings<BR><B>Sent:</B> Wed 10/10/2007 3:25 =
PM<BR><B>To:</B> Santosh Chokhani; Hallam-Baker, Phillip; =
[email-masked]<BR><B>Subject:</B> RE: OCSP Algorithm =
Agility<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>I'm generally in favor of simpler approaches, such as =
those suggested by<BR>Santosh, as they favor interoperability. Updating =
deployed applications to<BR>understand new elements of the protocol =
could take just as long to roll out<BR>as the new algorithm support =
that's purportedly lacking.<BR><BR>I can see a situation in which the CA =
cannot assume that the entire user<BR>population understands a new =
algorithm such as SHA-256, and thus has to<BR>continue using SHA-1 with =
RSA when signing certificates. Individual clients<BR>that do understand =
SHA-256 may wish to receive OCSP responses signed using<BR>SHA-256 with =
RSA, and would need a way to signal their desires to the =
OCSP<BR>responder.<BR><BR>The question is, then, is there any security =
benefit to having the signature<BR>algorithm on the OCSP response =
stronger than the signature algorithm on the<BR>certificate? If you can =
break the algorithm and cause me to accept a<BR>contrived OCSP response, =
could you not do the same thing with a =
certificate?<BR><BR>Seth<BR><BR>-----Original Message-----<BR>From: =
[email-masked] [<A =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] On<BR>Behalf Of Santosh Chokhani<BR>Sent: Wednesday, =
October 10, 2007 2:28 PM<BR>To: Hallam-Baker, Phillip; =
[email-masked]<BR>Subject: RE: OCSP Algorithm Agility<BR><BR><BR>See =
responses in-line below.<BR><BR>-----Original Message-----<BR>From: =
Hallam-Baker, Phillip [<A =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>Se=
nt: Tuesday, October 09, 2007 2:07 PM<BR>To: Santosh Chokhani; =
[email-masked]<BR>Subject: RE: OCSP Algorithm Agility<BR><BR>Not if =
they don't know that the client can understand them they =
can't.<BR>[Santosh Chokhani] The Responder has two ways to know what the =
client<BR>understands.&nbsp; From certID or from CA.&nbsp; If the client =
does not understand<BR>the algorithm used in certificate signing, =
revocation information is<BR>useless.<BR><BR>And the issue is not just =
hashing algorithms, it is signature<BR>algorithms.<BR>Like your previous =
posts you continue to assume that cipher strength is<BR>a linear =
quantity with only one dimension and that any client which<BR>supports =
strength 2X must automatically support strength X.<BR>[Santosh Chokhani] =
I am making no such assumptions.&nbsp; I am saying that if<BR>an =
algorithm is good enough for a certificate, it is good enough =
for<BR>revocation notification for that certificate.<BR><BR>That is not =
the case if you consider the practicalities of deploying ECC<BR>in an =
RSA world.<BR><BR>To give a practical example, VeriSign issues a cert =
for an ECC key<BR>signed with an ECC key. The email program on Alice's =
machine in the DHS<BR>supports ECC but not the DHS SCVP server or OCSP =
relay.<BR>[Santosh Chokhani] And what is the problem with that?&nbsp; =
They have no<BR>choice but to use RSA.<BR><BR>In the real world the OCSP =
service does not have a necessary connection<BR>to the CA. There are =
plenty of commercial OCSP offerings that report on<BR>certificates =
issued by other CAs.<BR>[Santosh Chokhani] And how does this relate to =
algorithm agility?&nbsp; If<BR>the OCSP does not do ECDSA it =
won't.&nbsp; If OCSP supports both RSA and<BR>ECDSA, it can take the cue =
from the CA CRL to determine what algorithm<BR>to use for signing OCSP =
responses.&nbsp; If the OCSP does not consume CRL,<BR>the mechanism that =
tells it revocation information can also tell it the<BR>signature =
algorithm to use.<BR><BR>&gt; -----Original Message-----<BR>&gt; From: =
[email-masked]<BR>&gt; [<A =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] On Behalf Of Santosh Chokhani<BR>&gt; Sent: Tuesday, =
October 09, 2007 11:16 AM<BR>&gt; To: Hallam-Baker, Phillip; =
[email-masked]<BR>&gt; Subject: RE: OCSP Algorithm =
Agility<BR>&gt;<BR>&gt;<BR>&gt; The OCSP and SCVP can transition to =
stronger algorithms any<BR>&gt; time they want.<BR>&gt;<BR>&gt; The OCSP =
can take their clue from the CA or the certID field<BR>&gt; to decide =
the hashing algorithm.&nbsp; When multiple certID is<BR>&gt; present, =
OCSP can take low water mark of these.<BR>&gt;<BR>&gt; SCVP is no =
different than a client in terms of validating a<BR>&gt; path.&nbsp; In =
terms of signing a response, it can take the low<BR>&gt; water mark of =
the hashing algorithms in the certificate chain.<BR>&gt;<BR>&gt; =
-----Original Message-----<BR>&gt; From: =
[email-masked]<BR>&gt; [<A =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]<BR>&gt; On Behalf Of Hallam-Baker, Phillip<BR>&gt; Sent: =
Monday, October 08, 2007 7:27 PM<BR>&gt; To: Santosh Chokhani; Andrews, =
Rick; [email-masked]<BR>&gt; Subject: RE: OCSP Algorithm =
Agility<BR>&gt;<BR>&gt;<BR>&gt; The objective here is to overcome a real =
deployment obstacle<BR>&gt; that creates a lockstep issue when use of =
stronger algorithms<BR>&gt; is attempted.<BR>&gt;<BR>&gt; The CA cannot =
issue a certificate that employs a new<BR>&gt; algorithm until it is =
known that all clients that might rely<BR>&gt; on the certificate are =
capable of processing the new<BR>&gt; certificate. Requiring lockstep =
updates to the OCSP and SCVP<BR>&gt; infrastructure to be made at the =
same time renders transition<BR>&gt; to stronger algorithms a much =
lengthier and much less<BR>&gt; practical =
proposition.<BR>&gt;<BR>&gt;<BR>&gt; &gt; -----Original =
Message-----<BR>&gt; &gt; From: [email-masked]<BR>&gt; =
&gt; [<A =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] On Behalf Of Santosh Chokhani<BR>&gt; &gt; Sent: Saturday, =
October 06, 2007 4:12 PM<BR>&gt; &gt; To: Andrews, Rick; =
[email-masked]<BR>&gt; &gt; Subject: RE: OCSP Algorithm =
Agility<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; Rick,<BR>&gt; =
&gt;<BR>&gt; &gt; SCVP or other intermediaries are red herring.&nbsp; =
Whoever<BR>&gt; processes the<BR>&gt; &gt; certificate processes the =
revocation information for that<BR>&gt; certificate.<BR>&gt; &gt; It =
does not change the following:<BR>&gt; &gt;<BR>&gt; &gt; 1.&nbsp; There =
is no security benefit in using a stronger algorithm for<BR>&gt; &gt; =
OCSP<BR>&gt; &gt; response than for the certificate in =
question.&nbsp;&nbsp; Neither,<BR>&gt; there is any<BR>&gt; &gt; benefit =
from interoperability viewpoint for these two to be<BR>&gt; =
different.<BR>&gt; &gt;<BR>&gt; &gt; 2.&nbsp; If the OCSP Responder does =
not get a CRL, it can use the same<BR>&gt; &gt; mechanism to get the =
hashing algorithm used as it uses to get the<BR>&gt; &gt; revocation =
information.<BR>&gt; &gt;<BR>&gt; &gt; -----Original =
Message-----<BR>&gt; &gt; From: Andrews, Rick [<A =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>&gt; &gt; Sent: Wednesday, October 03, 2007 3:29 PM<BR>&gt; &gt; To: =
Santosh Chokhani; [email-masked]<BR>&gt; &gt; Subject: RE: OCSP =
Algorithm Agility<BR>&gt; &gt;<BR>&gt; &gt; Santosh,<BR>&gt; =
&gt;<BR>&gt; &gt; Sorry for the long delay in responding - travel and =
vacation.<BR>&gt; &gt;&nbsp;<BR>&gt; &gt; Not all OCSP responders work =
from CRLs, so they won't take<BR>&gt; their cue<BR>&gt; &gt; from the =
CRL. Nor should they take their cue from the<BR>&gt; signature on =
the<BR>&gt; &gt; cert in question, I believe. Let me try to restate my =
argument in a<BR>&gt; &gt; different way.<BR>&gt; &gt;&nbsp;<BR>&gt; =
&gt; With SCVP delegated path validation, the client requesting a =
cert's<BR>&gt; &gt; status from an OCSP responder will be different from =
the<BR>&gt; client at the<BR>&gt; &gt; other end of the SSL connection. =
Those two clients may have very<BR>&gt; &gt; different capabilities in =
terms of supported signature and hash<BR>&gt; &gt; algorithms. It's not =
realistic to expect that all SSL clients, all<BR>&gt; &gt; SCVP servers, =
and all CAs will be able to upgrade in<BR>&gt; lockstep to new<BR>&gt; =
&gt; algorithms as they are developed. Allowing the OCSP client<BR>&gt; =
and server<BR>&gt; &gt; to negotiate a mutually-acceptable set of =
algorithms is<BR>&gt; essential to<BR>&gt; &gt; the deployment of newer, =
stronger algorithms.<BR>&gt; &gt;&nbsp;<BR>&gt; &gt; Likewise, companies =
that run large OCSP responders may wish to<BR>&gt; &gt; gradually move =
to ECC-based signatures for all their OCSP<BR>&gt; responses,<BR>&gt; =
&gt; even those for certs with RSA or DSA keys, because ECC<BR>&gt; =
signatures are<BR>&gt; &gt; cheaper to produce. If algorithm agility is =
added to OCSP, those<BR>&gt; &gt; companies can gradually achieve the =
move to ECC without<BR>&gt; disrupting the<BR>&gt; &gt; installed base =
of OCSP clients that don't support ECC.<BR>&gt; &gt;&nbsp;<BR>&gt; &gt; =
-Rick Andrews<BR>&gt; &gt;<BR>&gt; &gt; &gt; -----Original =
Message-----<BR>&gt; &gt; &gt; From: =
[email-masked]<BR>&gt; &gt; &gt; [<A =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] On Behalf Of<BR>&gt; Santosh Chokhani<BR>&gt; &gt; &gt; =
Sent: Friday, September 21, 2007 2:45 PM<BR>&gt; &gt; &gt; To: Paul =
Hoffman; Stephen Kent; [email-masked]<BR>&gt; &gt; &gt; Subject: RE: =
OCSP Algorithm Agility<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; =
&gt; Paul,<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Here are my views on =
this.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; The client should be first =
asking for the algorithm suite<BR>&gt; &gt; that signed<BR>&gt; &gt; =
&gt; the certificate in question.&nbsp; There is no need for the<BR>&gt; =
&gt; client to ask<BR>&gt; &gt; &gt; for anything stronger.&nbsp; The =
client can ask for stronger suites as<BR>&gt; &gt; &gt; secondary, if =
client has them.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; In the scenario you =
cite, the Responder certificate will<BR>&gt; &gt; not include<BR>&gt; =
&gt; &gt; RSA with SHA 1 any longer.&nbsp; So, client will know =
that<BR>&gt; &gt; Responder only<BR>&gt; &gt; &gt; supported his second =
choice and he should be ok with it.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; =
-----Original Message-----<BR>&gt; &gt; &gt; From: =
[email-masked]<BR>&gt; &gt; &gt; [<A =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]<BR>&gt; &gt; &gt; On Behalf Of Paul Hoffman<BR>&gt; &gt; =
&gt; Sent: Friday, September 21, 2007 4:39 PM<BR>&gt; &gt; &gt; To: =
Stephen Kent; [email-masked]<BR>&gt; &gt; &gt; Subject: RE: OCSP =
Algorithm Agility<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; =
At 2:07 PM -0400 9/21/07, Stephen Kent wrote:<BR>&gt; &gt; &gt; &gt;How =
about defining an extension to be included in the cert<BR>&gt; &gt; &gt; =
issued to an<BR>&gt; &gt; &gt; &gt;OCSP responder by a CA.&nbsp; The =
extension would have an<BR>&gt; &gt; ordered list of<BR>&gt; &gt; &gt; =
&gt;algorithms (hash and signature if we want to address more<BR>&gt; =
&gt; &gt; than the hash<BR>&gt; &gt; &gt; &gt;agility issue) accepted by =
the OCSP responder.&nbsp; An OCSP<BR>&gt; &gt; &gt; client can =
use<BR>&gt; &gt; &gt; &gt;this info to determine what is the "best" =
algorithm (or alg<BR>&gt; &gt; &gt; pair) that<BR>&gt; &gt; &gt; &gt;it =
and the responder share. The combination of this<BR>&gt; &gt; extension =
and an<BR>&gt; &gt; &gt; &gt;OCSP negotiation procedure will allow the =
client to detect MITM<BR>&gt; &gt; &gt; &gt;downgrade attacks. In fact, =
if the client acquires the<BR>&gt; &gt; &gt; responder's cert<BR>&gt; =
&gt; &gt; &gt;prior to making a request, there would not even be =
a<BR>&gt; need for real<BR>&gt; &gt; &gt; &gt;negotiation, since the =
client would know what alg to<BR>&gt; request in a<BR>&gt; &gt; &gt; =
&gt;response.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Imagine the list of =
algorithms is RSA-with-SHA1 first and<BR>&gt; &gt; &gt; DSA-with-SHA1 =
second. How does your negotiation work? The<BR>&gt; &gt; client =
asks<BR>&gt; &gt; &gt; for this message to be signed with =
RSA-with-SHA1.<BR>&gt; &gt; &gt; But the server knows that RSA-with-SHA1 =
has been<BR>&gt; &gt; compromised since it<BR>&gt; &gt; &gt; got that =
certificate from the CA. What does the server say to the<BR>&gt; &gt; =
&gt; client to indicate that it only wants to sign with<BR>&gt; &gt; =
DSA-with-SHA1? What<BR>&gt; &gt; &gt; prevents Mallory from saying the =
same thing to the client?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; --Paul =
Hoffman, Director<BR>&gt; &gt; &gt; --VPN Consortium<BR>&gt; &gt; =
&gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR><BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C80FA5.A59CF9BC--

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the removal of  upper  bound in X.509"
Date: Mon, 15 Oct 2007 15:23:43 -0400
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

The links provided will retrieve a PDF copy of the full text of X.520
(1993, 1997, 2001, or 2005 edition).  Unfortunately, some MUAs cannot
grok URLs that span more than 1 line, so instead of clicking on them
they must be copied and pasted manually into a browser address bar.
After entering the URL and retrieving the PDF file, (which due to
web-server-specific brain damage may also need to be renamed from
"xxx.pdf.asp" to "xxx.pdf"), scroll down to Annex C to view the
entire set of upper bounds.

One would think that after nearly 14 years the web would have
achieved point-and-click usability, but apparently not.

(Note that the upper bounds module is included in X.520, not X.521).

---------- X.520 2005 ---------
http://www.itu.int/rec/T-REC-X.520-200508-I/dologin.asp?lang=e&id=T-REC-
X.520-200508-I!!PDF-E&type=items

---------- X.521 2005 ---------
http://www.itu.int/rec/T-REC-X.521-200508-I/dologin.asp?lang=e&id=T-REC-
X.521-200508-I!!PDF-E&type=items

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul Hoffman
Sent: Monday, October 15, 2007 1:42 PM
To: David Chadwick
Cc: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of
upper bound in X.509"

At 6:20 PM +0100 10/15/07, David Chadwick wrote:
>It is written at the start of Annex C of X.521, as copied below
>
>>Annex C
>>
>>Upper bounds
>>(This annex does not form an integral part of this Recommendation | 
>>International Standard)
>>This annex includes all of the suggested upper bound value 
>>constraints used in these Directory Specifications, in the form of 
>>the ASN.1 module UpperBounds.
>>
>>UpperBounds {joint-iso-itu-t ds(5) module(1) upperBounds(10) 5}
>>DEFINITIONS ::=
>>BEGIN

Could you show the whole Annex? That is, could we see all the upper 
bounds listed? Or, is there just a blank line and "END"? :-)

--Paul Hoffman, Director
--VPN Consortium

Date: Mon, 15 Oct 2007 15:11:22 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper bound in X.509"
Sender: [email-masked]

Paul,

Here is a web site that contains the ASN.1 modules for "X-Series 
Recommendations":  http://www.itu.int/ITU-T/asn1/database/itu-t/x

It appears that the upper bounds module, which appears in X.520, has 
changed with each edition.  At least, the web site indicates that the 
OID for the module has changed from the 1997 edition to the 2001 
edition, and again with the publication of the 2005 edition.  I didn't 
attempt to compare the modules to see how they changed.

Dave

Paul Hoffman wrote:
>
> At 6:20 PM +0100 10/15/07, David Chadwick wrote:
>> It is written at the start of Annex C of X.521, as copied below
>>
>>> Annex C
>>>
>>> Upper bounds
>>> (This annex does not form an integral part of this Recommendation | 
>>> International Standard)
>>> This annex includes all of the suggested upper bound value 
>>> constraints used in these Directory Specifications, in the form of 
>>> the ASN.1 module UpperBounds.
>>>
>>> UpperBounds {joint-iso-itu-t ds(5) module(1) upperBounds(10) 5}
>>> DEFINITIONS ::=
>>> BEGIN
>
> Could you show the whole Annex? That is, could we see all the upper 
> bounds listed? Or, is there just a blank line and "END"? :-)
>
>
> --Paul Hoffman, Director
> --VPN Consortium
>
>

Date: Mon, 15 Oct 2007 10:41:31 -0700
To: David Chadwick <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper  bound in X.509"
Cc: [email-masked]
Sender: [email-masked]

At 6:20 PM +0100 10/15/07, David Chadwick wrote:
>It is written at the start of Annex C of X.521, as copied below
>
>>Annex C
>>
>>Upper bounds
>>(This annex does not form an integral part of this Recommendation | 
>>International Standard)
>>This annex includes all of the suggested upper bound value 
>>constraints used in these Directory Specifications, in the form of 
>>the ASN.1 module UpperBounds.
>>
>>UpperBounds {joint-iso-itu-t ds(5) module(1) upperBounds(10) 5}
>>DEFINITIONS ::=
>>BEGIN

Could you show the whole Annex? That is, could we see all the upper 
bounds listed? Or, is there just a blank line and "END"? :-)

--Paul Hoffman, Director
--VPN Consortium

Date: Mon, 15 Oct 2007 18:20:11 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: "Kemp, David P." <[email-masked]>
CC: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper bound in X.509"
Sender: [email-masked]

Hi David

It is written at the start of Annex C of X.521, as copied below

> Annex C
> 
> Upper bounds
> (This annex does not form an integral part of this Recommendation | International Standard)
> This annex includes all of the suggested upper bound value constraints used in these Directory Specifications, in the form of the ASN.1 module UpperBounds.
> 
> UpperBounds {joint-iso-itu-t ds(5) module(1) upperBounds(10) 5}
> DEFINITIONS ::=
> BEGIN

regards

David

Kemp, David P. wrote:
>> Paul Hoffman wrote:
> 
>> It has been established on this list that the upper bounds in X.500
>> have been non-normative since the second edition.
> 
> You said that in an earlier message. Could you point us to a specific 
> section of a specific version of X.500 where that is true? Most of us 
> are not X.500 users.
> 
> 
> ---------- 1993 ---------
> http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-199311-S!!P
> DF-E&type=items
> 
> ISO/IEC 9594-6 : 1995 (E)
> 22 ITU-T Rec. X.520 (1993 E) Superseded by a more recent version
> Annex A
> Selected attribute types in ASN.1
> (This annex forms an integral part of this Recommendation |
> International Standard)
> This annex includes all of the ASN.1 type and value definitions
> contained in this Directory Specification in the form of
> the ASN.1 module SelectedAttributeTypes.
> 
> 
> ---------- 1997 ---------
> http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-199708-S!!P
> DF-E&type=items
>  
> ISO/IEC 9594-6 : 1998 (E)
> ITU-T Rec. X.520 (1997 E) 41
> Annex C
> Upper bounds
> (This annex does not form an integral part of this Recommendation |
> International Standard)
> This annex includes all of the suggested upper bound value constraints
> used in these Directory Specifications, in the form
> of the ASN.1 module UpperBounds.
> 
> ---------- 2001 ---------
> http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-200102-I!!P
> DF-E&type=items
> 
> ISO/IEC 9594-6:2001 (E)
> ITU-T X.520 (02/2001 E) 61
> Annex C
> Upper bounds
> (This annex does not form an integral part of this Recommendation |
> International Standard)
> This annex includes all of the suggested upper bound value constraints
> used in these Directory Specifications, in the
> form of the ASN.1 module UpperBounds.
> 
> ---------- 2005 ---------
> http://www.itu.int/rec/T-REC-X.520-200508-I/dologin.asp?lang=e&id=T-REC-
> X.520-200508-I!!PDF-E&type=items
> 
> ISO/IEC 9594-6:2005 (E)
> 60 ITU-T Rec. X.520 (08/2005)
> Annex C
> Upper bounds
> (This annex does not form an integral part of this Recommendation |
> International Standard)
> This annex includes all of the suggested upper bound value constraints
> used in these Directory Specifications, in the form
> of the ASN.1 module UpperBounds.
> 
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Mon, 15 Oct 2007 09:58:45 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Seth Hitchings" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C80F4C.A6168FE2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

From: [email-masked] on behalf of Stefan Santesson

>Security:
>None of the presented threats is not a great concern for me.=20
>Downgrade attacks is only useful if we use algorithms that can be =
broken.
>I would expect an organization to only allow algorithms that provide =
adequate security.
>The stolen OCSP key is neither a problem for me from a protocol =
perspective. We have revocation.

Agreed, the issue here is not security, it is interoperability.=20

>Practical matters:
>I can only find one practical matter that concerns me. I have an OCSP =
server and of=20
>some reason I want to gradually transition responses to be based on say =
ECC with=20
>SHA 256. Some clients can only verify RSA with SHA-1. The reason for =
doing this=20
>transition may be entirely policy oriented. Now I would like to know =
which clients=20
>that can actually verify my upgraded responses.

That is the concern that led to the proposal.=20
=20
The assumption that the OCSP client supports the same set of algorithms =
as the=20
certificate relying application does not hold=20
=20

>What can I do today:
>The server can draw a number of conclusions today.

>1) Looking at the hashAlgorithm of the CertID
>2) Looking at the signatureAlgorithm used by the client to sign the =
response
>3) Looking at the certificate actually being validated

>None of these are 100% bulletproof to cover all corner cases. But are =
they=20
>good enough and is the remaining gap big enough to motivate a protocol =
update?
=20
As a design principle I prefer a protocol where the client can specify
what it wants over one where the only option is for the server to guess.
=20
I find that approach is much more likely to lead to reliable =
interoperation.
=20
=20
The solution proposed is 100% backwards compatible, the old approach =
being:
1 Server guesses what algorithms the client supports
=20
The new approach is:
1 Server looks to see if the client specified what algorithms are =
supported by the client
2 If none specified server guesses what algorithms the client supports =
as before

If either the client or the server does not support the proposed =
extension=20
the other party simply downgrades to the status quo.
=20
=20

------_=_NextPart_001_01C80F4C.A6168FE2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>RE: OCSP Algorithm Agility</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16546" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText62502 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked] on behalf of Stefan =
Santesson<BR></FONT><FONT size=3D2></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2><STRONG><FONT =
face=3DTahoma>&gt;</FONT></STRONG>Security:<BR>&gt;None of the presented =
threats is not a great concern for me. </FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>&gt;Downgrade attacks is only useful if we =
use algorithms that can be broken.<BR>&gt;I would expect an organization =
to only allow algorithms that provide adequate security.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>&gt;The stolen OCSP key is neither a =
problem for me from a protocol perspective. We have =
revocation.<BR></DIV></FONT>=0A=
<DIV dir=3Dltr><FONT size=3D2>Agreed, the issue here is not security, it =
is interoperability. </DIV></FONT><FONT size=3D2></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>=0A=
<DIV dir=3Dltr><BR><BR>&gt;Practical matters:<BR>&gt;I can only find one =
practical matter that concerns me. I have an OCSP server and of </DIV>=0A=
<DIV dir=3Dltr>&gt;some reason I want to gradually transition responses =
to be based on say ECC with </DIV>=0A=
<DIV dir=3Dltr>&gt;SHA 256. Some clients can only verify RSA with SHA-1. =
The reason for doing this </DIV>=0A=
<DIV dir=3Dltr>&gt;transition may be entirely policy oriented. Now I =
would like to know which clients </DIV>=0A=
<DIV dir=3Dltr>&gt;that can actually verify my upgraded =
responses.<BR></DIV>=0A=
<DIV dir=3Dltr>That is the concern that led to the proposal. </DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The assumption that the OCSP client supports the same set =
of algorithms as the </DIV>=0A=
<DIV dir=3Dltr>certificate relying application does not hold </DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><BR>&gt;What can I do today:<BR>&gt;The server can draw a =
number of conclusions today.<BR><BR>&gt;1) Looking at the hashAlgorithm =
of the CertID<BR>&gt;2) Looking at the signatureAlgorithm used by the =
client to sign the response<BR>&gt;3) Looking at the certificate =
actually being validated<BR><BR>&gt;None of these are 100% bulletproof =
to cover all corner cases. But are they </DIV>=0A=
<DIV dir=3Dltr>&gt;good enough and is the remaining gap big enough to =
motivate a protocol update?</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>As a design principle I prefer a protocol where the =
client can specify</DIV>=0A=
<DIV dir=3Dltr>what it wants over one where the only option is for the =
server to guess.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>I find that approach is much more likely to lead to =
reliable interoperation.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The solution proposed is 100% backwards compatible, the =
old approach being:</DIV>=0A=
<DIV dir=3Dltr>1 Server guesses what algorithms the client supports</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The new approach is:</DIV>=0A=
<DIV dir=3Dltr>1 Server looks to see if the client specified what =
algorithms are supported by the client</DIV>=0A=
<DIV dir=3Dltr>2 If none specified server guesses what algorithms the =
client supports as before<BR></DIV>=0A=
<DIV dir=3Dltr>If either the client or the server does not support the =
proposed extension </DIV>=0A=
<DIV dir=3Dltr>the other party simply downgrades to the status quo.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV></FONT></DIV></BODY></HTML>
------_=_NextPart_001_01C80F4C.A6168FE2--

Date: Fri, 12 Oct 2007 20:05:56 -0600
From: "Dionne Gustafson" <[email-masked]>
To: [email-masked]
Subject: Welcome to dream

<html>
<head>
<title></title>
</head>
<body>
<br>
<br>
<div align="left"><font size="6"><b>WELCOME BONUS $
2400</b></font></div>

<div align="left">Relax and have fun with poker, blackjack,
roulette,</div>

<div align="left">progressive video slots at your own leisure
from your couch</div>

<div align="left">Our safe, secure games will get you smiling
when you start seeing dollars pouring in.</div>

<div align="left">We&#39;re serious about fun.</div>

<div align="left">When YOU WIN, we win! <u>
http://richcasinogambling.net/gate/62/</u></div>
</body>
</html>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-09.txt 
Date: Fri, 12 Oct 2007 15:15:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
	Author(s)	: D. Cooper, et al.
	Filename	: draft-ietf-pkix-rfc3280bis-09.txt
	Pages		: 144
	Date		: 2007-10-12
	
This memo profiles the X.509 v3 certificate and X.509 v2 certificate
   revocation list (CRL) for use in the Internet.  An overview of this
   approach and model are provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.  A set of required
   certificate extensions is specified.  The X.509 v2 CRL format is
   described in detail along with standard and Internet-specific
   extensions.  An algorithm for X.509 certification path validation is
   described.  An ASN.1 module and examples are provided in the
   appendices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-pkix-rfc3280bis-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc3280bis-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 12 Oct 2007 14:42:25 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: draft-ietf-pkix-rfc3280bis-09.txt
Sender: [email-masked]

All,

I just submitted draft -09 of 3280bis.  A diff file highlighting the 
changes between drafts -08 and -09 is available at 
http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-08todraft3280bis-09_diff.html.

Here is a summary of the changes between drafts -08 and -09:

1) Replaced references to RFC 1738 with references to RFC 2616.

2) Replaced two instances of "NOT REQUIRED" (in all capital letters) 
with "not required" (in lower case), to address an issue raised by the 
idnits program.

3) In section 5.1.2.3, added the word "non-empty" to clarify that the 
issuer field in a CRL MUST contain a non-empty X.500 DN. This was a 
change that was agreed to on March 2 (see 
http://www.imc.org/ietf-pkix/mail-archive/msg04478.html).

4) Section 7.1 was modified to clarify that name comparison is always 
performed according to the matching rule specified for attribute.

Dave

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the removal of  upper bound in X.509"
Date: Fri, 12 Oct 2007 14:14:35 -0400
From: "Kemp, David P." <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

>Paul Hoffman wrote:

>It has been established on this list that the upper bounds in X.500
>have been non-normative since the second edition.

You said that in an earlier message. Could you point us to a specific 
section of a specific version of X.500 where that is true? Most of us 
are not X.500 users.

---------- 1993 ---------
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-199311-S!!P
DF-E&type=items

ISO/IEC 9594-6 : 1995 (E)
22 ITU-T Rec. X.520 (1993 E) Superseded by a more recent version
Annex A
Selected attribute types in ASN.1
(This annex forms an integral part of this Recommendation |
International Standard)
This annex includes all of the ASN.1 type and value definitions
contained in this Directory Specification in the form of
the ASN.1 module SelectedAttributeTypes.

---------- 1997 ---------
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-199708-S!!P
DF-E&type=items
 
ISO/IEC 9594-6 : 1998 (E)
ITU-T Rec. X.520 (1997 E) 41
Annex C
Upper bounds
(This annex does not form an integral part of this Recommendation |
International Standard)
This annex includes all of the suggested upper bound value constraints
used in these Directory Specifications, in the form
of the ASN.1 module UpperBounds.

---------- 2001 ---------
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-200102-I!!P
DF-E&type=items

ISO/IEC 9594-6:2001 (E)
ITU-T X.520 (02/2001 E) 61
Annex C
Upper bounds
(This annex does not form an integral part of this Recommendation |
International Standard)
This annex includes all of the suggested upper bound value constraints
used in these Directory Specifications, in the
form of the ASN.1 module UpperBounds.

---------- 2005 ---------
http://www.itu.int/rec/T-REC-X.520-200508-I/dologin.asp?lang=e&id=T-REC-
X.520-200508-I!!PDF-E&type=items

ISO/IEC 9594-6:2005 (E)
60 ITU-T Rec. X.520 (08/2005)
Annex C
Upper bounds
(This annex does not form an integral part of this Recommendation |
International Standard)
This annex includes all of the suggested upper bound value constraints
used in these Directory Specifications, in the form
of the ASN.1 module UpperBounds.

Date: Fri, 12 Oct 2007 10:29:16 -0400
To: Steven Legg <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper bound in X.509"
Cc: [email-masked]
Sender: [email-masked]

At 11:01 AM +1000 10/12/07, Steven Legg wrote:
>Paul Hoffman wrote:
>>Has the X.500 working group communicated that to the PKIX WG, or the IETF?
>
>Yes, in the liaison statement where it says "We plan to remove the
>upper bounds specified in the standard". The example change to X.520
>suggests that "the standard" means more than just X.509.

With all due respect, "suggests" is not enough here. Further, the 
sentence you quoute is the only one in the whole liaison statement 
that talks about more than just DirectoryString.

Before the PKIX WG acts (such as changing RFC3280bis), we should get 
a clearer liaison statement, hopefully one that says "all upper 
bounds have been removed".

>It has been established on this list that the upper bounds in X.500
>have been non-normative since the second edition.

You said that in an earlier message. Could you point us to a specific 
section of a specific version of X.500 where that is true? Most of us 
are not X.500 users.

>I had a closer look at RFC 3280. Some of the upper bounds originate
>from X.500, but there is a bunch of upper bounds constraining
>component parts of ORAddress that come from X.400, primarily the
>upper bounds with names ending with "-length". The former are in
>scope for the change contemplated by the X.500 working group, but
>the latter are not.

We can probably change things relating to X.400 without fear of 
real-world interop problems.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 12 Oct 2007 11:01:44 +1000
From: Steven Legg <[email-masked]>
To: Paul Hoffman <[email-masked]>
CC: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper bound in X.509"
Sender: [email-masked]

Paul,

Paul Hoffman wrote:
> 
> At 10:26 AM +1000 10/10/07, Steven Legg wrote:
>> The way out of this dilemma is for PKIX, LDAP and X.500 to agree
>> on the upper bounds. The consensus in the X.500 working group is
>> to completely remove the (non-normative) upper bounds, rather than
>> rejigging them.
> 
> Has the X.500 working group communicated that to the PKIX WG, or the IETF?

Yes, in the liaison statement where it says "We plan to remove the
upper bounds specified in the standard". The example change to X.520
suggests that "the standard" means more than just X.509.

> 
> At 10:41 AM +1000 10/10/07, Steven Legg wrote:
>>> - Do we object to the ITU making the upper bound on DirectoryString 
>>> optional
>>
>> They've been optional since the second edition of X.500. The defect
>> resolution will make that clearer, as well as steering away from
>> any specific suggestions for the upper bounds.
> 
> We disagree that this DR "will make it clearer". What was sent to the 
> PKIX WG said:
> 
> In relation to resolve a Defect Report, it appears to majority within 
> the X.500 community to remove hard-coded length restriction whenever a 
> DirectoryString is used.
> . . .
> We plan to remove the upper bounds specified in the standard. In 
> particular we intend to eliminate the Upper Bounds for DirectoryString.
> 
> That does not sound anything like "They've been optional since the 
> second edition of X.500."

It has been established on this list that the upper bounds in X.500
have been non-normative since the second edition. If they are
non-normative, then an implementation can set the upper bounds to
whatever it wants, including the largest number anyone has ever thought
of, effectively making the upper bounds optional.

> 
> Could you get the X.500 working group to make it clear if they are 
> considering, or have already, removed the upper bounds on all the 
> X.500-related strings that Russ listed?

I had a closer look at RFC 3280. Some of the upper bounds originate
from X.500, but there is a bunch of upper bounds constraining
component parts of ORAddress that come from X.400, primarily the
upper bounds with names ending with "-length". The former are in
scope for the change contemplated by the X.500 working group, but
the latter are not.

I've prodded some ITU-T folks to publicly confirm the situation.

> 
>>> - Should we do anything to draft-ietf-pkix-rfc3280bis to reflect that
>>>
>>> The answer to the first should be "no, we don't". Russ gave a list 
>>> that shows the the ITU has a *long* way to go before it gets rid of 
>>> the silly maximum lengths in X.509.
>>
>> The defect resolution will throw them all out at the same time.
> 
> Where does it say that? The DR listed exactly one string type, 
> DirectoryString. Again, having this be clearer would help us out a lot.

The liaison statement said "We plan to remove the upper bounds specified
in the standard". The following sentence beginning "In particular"
suggests to me that DirectoryString is a pertinent case, but by no means
the only case.

By the way, the liaison statement is not the defect resolution, and in any
case I've been informed there has been a change in strategy. The upper bounds
will be removed via an extension to X.500 rather than through a defect
resolution. I will leave it to someone from the ITU-T to confirm.

Regards,
Steven

> --Paul Hoffman, Director
> --VPN Consortium

From: "Abhimanyu Kostet" <[email-masked]>
To: <[email-masked]>
Subject: corum
Date: Thu, 11 Oct 2007 17:29:07 -0300

------=_NextPart_000_0004_01C80C2C.3A3ED5F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hello there ietf-pkix-archive

once you get it theres no turning back

Abhimanyu Kostet
http://boltcar.com/
------=_NextPart_000_0004_01C80C2C.3A3ED5F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT Arial size=3D2>hello there ietf-pkix-archive</FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>once you get it theres no turning =
back</FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>Abhimanyu Kostet</FONT></DIV></BODY></HTML>
<DIV><FONT Arial size=3D2><A=20
HREF=3D"http://boltcar.com/">http://boltcar.com/</A></FONT></DIV>

------=_NextPart_000_0004_01C80C2C.3A3ED5F0--

From: Stefan Santesson <[email-masked]>
To: Seth Hitchings <[email-masked]>, Santosh Chokhani <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 11 Oct 2007 12:14:55 +0100
Subject: RE: OCSP Algorithm Agility
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I'm generally supportive of the following statement.

> I'm generally in favor of simpler approaches, such as those suggested by
> Santosh, as they favor interoperability. Updating deployed applications to
> understand new elements of the protocol could take just as long to roll out
> as the new algorithm support that's purportedly lacking.

I've been trying to take a step back to think what I would need from a more practical viewpoint.

Security:
None of the presented threats is not a great concern for me. Downgrade attacks is only useful if we use algorithms that can be broken.
I would expect an organization to only allow algorithms that provide adequate security.
The stolen OCSP key is neither a problem for me from a protocol perspective. We have revocation.

Practical matters:
I can only find one practical matter that concerns me. I have an OCSP server and of some reason I want to gradually transition responses to be based on say ECC with SHA 256. Some clients can only verify RSA with SHA-1. The reason for doing this transition may be entirely policy oriented. Now I would like to know which clients that can actually verify my upgraded responses.

I see some value in the client knowing which algorithms the server can support, but not greatly. The client can mostly learn the capability of a server by observing its responses.

What can I do today:
The server can draw a number of conclusions today.

1) Looking at the hashAlgorithm of the CertID
2) Looking at the signatureAlgorithm used by the client to sign the response
3) Looking at the certificate actually being validated

None of these are 100% bulletproof to cover all corner cases. But are they good enough and is the remaining gap big enough to motivate a protocol update?

Possible updates:
To cover the corner cases I have seen the following options:
Client declaration - through a singleRequestExtension
Server declaration - through responseExtensions, or through an extension in the responder certificate.

Conclusion:
I'm not convinced I need any update of OCSP. If we do an update anyway, I'm more interested in the client declaration than the server declaration problem.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Seth Hitchings
> Sent: den 10 oktober 2007 21:26
> To: Santosh Chokhani; Hallam-Baker, Phillip; [email-masked]
> Subject: RE: OCSP Algorithm Agility
>
> I'm generally in favor of simpler approaches, such as those suggested
> by
> Santosh, as they favor interoperability. Updating deployed applications
> to
> understand new elements of the protocol could take just as long to roll
> out
> as the new algorithm support that's purportedly lacking.
>
> I can see a situation in which the CA cannot assume that the entire
> user
> population understands a new algorithm such as SHA-256, and thus has to
> continue using SHA-1 with RSA when signing certificates. Individual
> clients
> that do understand SHA-256 may wish to receive OCSP responses signed
> using
> SHA-256 with RSA, and would need a way to signal their desires to the
> OCSP
> responder.
>
> The question is, then, is there any security benefit to having the
> signature
> algorithm on the OCSP response stronger than the signature algorithm on
> the
> certificate? If you can break the algorithm and cause me to accept a
> contrived OCSP response, could you not do the same thing with a
> certificate?
>
> Seth
>
> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On
> Behalf Of Santosh Chokhani
> Sent: Wednesday, October 10, 2007 2:28 PM
> To: Hallam-Baker, Phillip; [email-masked]
> Subject: RE: OCSP Algorithm Agility
>
>
> See responses in-line below.
>
> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:[email-masked]]
> Sent: Tuesday, October 09, 2007 2:07 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: OCSP Algorithm Agility
>
> Not if they don't know that the client can understand them they can't.
> [Santosh Chokhani] The Responder has two ways to know what the client
> understands.  From certID or from CA.  If the client does not
> understand
> the algorithm used in certificate signing, revocation information is
> useless.
>
> And the issue is not just hashing algorithms, it is signature
> algorithms.
> Like your previous posts you continue to assume that cipher strength is
> a linear quantity with only one dimension and that any client which
> supports strength 2X must automatically support strength X.
> [Santosh Chokhani] I am making no such assumptions.  I am saying that
> if
> an algorithm is good enough for a certificate, it is good enough for
> revocation notification for that certificate.
>
> That is not the case if you consider the practicalities of deploying
> ECC
> in an RSA world.
>
> To give a practical example, VeriSign issues a cert for an ECC key
> signed with an ECC key. The email program on Alice's machine in the DHS
> supports ECC but not the DHS SCVP server or OCSP relay.
> [Santosh Chokhani] And what is the problem with that?  They have no
> choice but to use RSA.
>
> In the real world the OCSP service does not have a necessary connection
> to the CA. There are plenty of commercial OCSP offerings that report on
> certificates issued by other CAs.
> [Santosh Chokhani] And how does this relate to algorithm agility?  If
> the OCSP does not do ECDSA it won't.  If OCSP supports both RSA and
> ECDSA, it can take the cue from the CA CRL to determine what algorithm
> to use for signing OCSP responses.  If the OCSP does not consume CRL,
> the mechanism that tells it revocation information can also tell it the
> signature algorithm to use.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Tuesday, October 09, 2007 11:16 AM
> > To: Hallam-Baker, Phillip; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> >
> >
> > The OCSP and SCVP can transition to stronger algorithms any
> > time they want.
> >
> > The OCSP can take their clue from the CA or the certID field
> > to decide the hashing algorithm.  When multiple certID is
> > present, OCSP can take low water mark of these.
> >
> > SCVP is no different than a client in terms of validating a
> > path.  In terms of signing a response, it can take the low
> > water mark of the hashing algorithms in the certificate chain.
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > On Behalf Of Hallam-Baker, Phillip
> > Sent: Monday, October 08, 2007 7:27 PM
> > To: Santosh Chokhani; Andrews, Rick; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> >
> >
> > The objective here is to overcome a real deployment obstacle
> > that creates a lockstep issue when use of stronger algorithms
> > is attempted.
> >
> > The CA cannot issue a certificate that employs a new
> > algorithm until it is known that all clients that might rely
> > on the certificate are capable of processing the new
> > certificate. Requiring lockstep updates to the OCSP and SCVP
> > infrastructure to be made at the same time renders transition
> > to stronger algorithms a much lengthier and much less
> > practical proposition.
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > > Sent: Saturday, October 06, 2007 4:12 PM
> > > To: Andrews, Rick; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > >
> > >
> > > Rick,
> > >
> > > SCVP or other intermediaries are red herring.  Whoever
> > processes the
> > > certificate processes the revocation information for that
> > certificate.
> > > It does not change the following:
> > >
> > > 1.  There is no security benefit in using a stronger algorithm for
> > > OCSP
> > > response than for the certificate in question.   Neither,
> > there is any
> > > benefit from interoperability viewpoint for these two to be
> > different.
> > >
> > > 2.  If the OCSP Responder does not get a CRL, it can use the same
> > > mechanism to get the hashing algorithm used as it uses to get the
> > > revocation information.
> > >
> > > -----Original Message-----
> > > From: Andrews, Rick [mailto:[email-masked]]
> > > Sent: Wednesday, October 03, 2007 3:29 PM
> > > To: Santosh Chokhani; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > >
> > > Santosh,
> > >
> > > Sorry for the long delay in responding - travel and vacation.
> > >
> > > Not all OCSP responders work from CRLs, so they won't take
> > their cue
> > > from the CRL. Nor should they take their cue from the
> > signature on the
> > > cert in question, I believe. Let me try to restate my argument in a
> > > different way.
> > >
> > > With SCVP delegated path validation, the client requesting a cert's
> > > status from an OCSP responder will be different from the
> > client at the
> > > other end of the SSL connection. Those two clients may have very
> > > different capabilities in terms of supported signature and hash
> > > algorithms. It's not realistic to expect that all SSL clients, all
> > > SCVP servers, and all CAs will be able to upgrade in
> > lockstep to new
> > > algorithms as they are developed. Allowing the OCSP client
> > and server
> > > to negotiate a mutually-acceptable set of algorithms is
> > essential to
> > > the deployment of newer, stronger algorithms.
> > >
> > > Likewise, companies that run large OCSP responders may wish to
> > > gradually move to ECC-based signatures for all their OCSP
> > responses,
> > > even those for certs with RSA or DSA keys, because ECC
> > signatures are
> > > cheaper to produce. If algorithm agility is added to OCSP, those
> > > companies can gradually achieve the move to ECC without
> > disrupting the
> > > installed base of OCSP clients that don't support ECC.
> > >
> > > -Rick Andrews
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of
> > Santosh Chokhani
> > > > Sent: Friday, September 21, 2007 2:45 PM
> > > > To: Paul Hoffman; Stephen Kent; [email-masked]
> > > > Subject: RE: OCSP Algorithm Agility
> > > >
> > > >
> > > > Paul,
> > > >
> > > > Here are my views on this.
> > > >
> > > > The client should be first asking for the algorithm suite
> > > that signed
> > > > the certificate in question.  There is no need for the
> > > client to ask
> > > > for anything stronger.  The client can ask for stronger suites as
> > > > secondary, if client has them.
> > > >
> > > > In the scenario you cite, the Responder certificate will
> > > not include
> > > > RSA with SHA 1 any longer.  So, client will know that
> > > Responder only
> > > > supported his second choice and he should be ok with it.
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]
> > > > On Behalf Of Paul Hoffman
> > > > Sent: Friday, September 21, 2007 4:39 PM
> > > > To: Stephen Kent; [email-masked]
> > > > Subject: RE: OCSP Algorithm Agility
> > > >
> > > >
> > > > At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> > > > >How about defining an extension to be included in the cert
> > > > issued to an
> > > > >OCSP responder by a CA.  The extension would have an
> > > ordered list of
> > > > >algorithms (hash and signature if we want to address more
> > > > than the hash
> > > > >agility issue) accepted by the OCSP responder.  An OCSP
> > > > client can use
> > > > >this info to determine what is the "best" algorithm (or alg
> > > > pair) that
> > > > >it and the responder share. The combination of this
> > > extension and an
> > > > >OCSP negotiation procedure will allow the client to detect MITM
> > > > >downgrade attacks. In fact, if the client acquires the
> > > > responder's cert
> > > > >prior to making a request, there would not even be a
> > need for real
> > > > >negotiation, since the client would know what alg to
> > request in a
> > > > >response.
> > > >
> > > > Imagine the list of algorithms is RSA-with-SHA1 first and
> > > > DSA-with-SHA1 second. How does your negotiation work? The
> > > client asks
> > > > for this message to be signed with RSA-with-SHA1.
> > > > But the server knows that RSA-with-SHA1 has been
> > > compromised since it
> > > > got that certificate from the CA. What does the server say to the
> > > > client to indicate that it only wants to sign with
> > > DSA-with-SHA1? What
> > > > prevents Mallory from saying the same thing to the client?
> > > >
> > > > --Paul Hoffman, Director
> > > > --VPN Consortium
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >

From: "PayPal" <[email-masked]>
Subject: Your account will be limited !
Date: Thu, 11 Oct 2007 00:35:50 -0700
To: undisclosed-recipients:;

<script language="JavaScript">
<!-- Hide the script from old browsers --

        function a(txt) {
                self.status = txt
        }

        function b() {
                self.status = ""
        }
// --End Hiding Here -->
</script>

<br><br><table style="width:600px" cellpadding="0" cellspacing="0" border="0" align="center">
	<tr>
<img SRC="http://paypal.com/en_US/i/logo/paypal_logo.gif"  BORDER=0 height=50 width=200>
	</tr>
</table>
 
        <hr noShade size=1>

<img src="http://paypal.com/en_US/i/scr/pixel.gif" width=1 height=10><br>
					    
<table style="width:600px" cellpadding="0" cellspacing="0" border="0" align="center">
	<tr>

	  	<td><font style="font-size:17px" style="font-family:Verdana, Arial, Helvetica, sans-serif" style="font-weight:700" color="#003366">Security Center</font></TD>
	</tr>
	<tr>
		<td><img src="http://paypal.com/en_US/i/scr/pixel.gif" width="2" height="2"></td>
	</tr>
</table>
<table style="width:600px" cellpadding="0" cellspacing="0" border="0" align="center">
	<tr>
		<td><img src="http://paypal.com/en_US/i/scr/pixel.gif" width=6 height=6></td>

	</tr>
	<tr>
		<td bgcolor=#999999 width=100%><img src="http://paypal.com/en_US/i/scr/pixel.gif" width=1 height=2></td>
	</tr>
	<tr>
		<td><img src="http://paypal.com/en_US/i/scr/pixel.gif" width=6 height=6></td>
	</tr>
</table>

<!-- begin main -->

<table style="width:600px" cellspacing="0" cellpadding="0" border="0" align="center">
	<tr valign="top">
		<td>
			<table style="width:600px" cellpadding="0" cellspacing="0" border="0" align="center">
				<tr>
					<td width="240"><img src="http://paypal.com/en_US/i/header/hdr_securityCenter_240x120.gif" valign="top"><br><br></td>
					<td width="20"> </td>
					<td  style="font-size:13px" style="font-family:Verdana, Arial, Helvetica, sans-serif" style="font-weight:400"><span style="font-weight:700">Military Grade Encryption is Only the Start</font></span><br><br>At PayPal, we want to increase your security and comfort level with every transaction. From our Buyer and Seller Protection Policies to our Verification and Reputation systems, we'll help to keep you safe.</span><br><br></td>

				</tr>
			</table>
		</td>
	</tr>
</table>

<!-- end main -->

<table style="width:600px" cellpadding="0" cellspacing="0" border="0" align="center">
	<tr>
		<td><img src="http://paypal.com/en_US/i/scr/pixel.gif" width=6 height=6></td>

	</tr>
	<tr>
		<td bgcolor=#999999 width=100%><img src="http://paypal.com/en_US/i/scr/pixel.gif" width=1 height=2></td>
	</tr>
	<tr>
		<td><img src="http://paypal.com/en_US/i/scr/pixel.gif" width=6 height=6></td>
	</tr>
</table>

<table style="width:600px" cellpadding="0" cellspacing="0" border="0" align="center">

	<tr>

<td style="font-size:13px" style="font-family:Verdana, Arial, Helvetica, sans-serif" style="font-weight:400"><span style="font-weight:700">
<br><br>
 PayPal is committed to maintaining a safe environment for its community of  buyers and sellers. To protect the security of your account, PayPal employs <br>some of the most
advanced security systems in the world and our anti-fraud teams regularly screen the PayPal system for unusual activity.<br><br>

Recently, our Account Review Team identified some unusual activity in your account. 
In accordance with PayPal's User Agreement access to your account will be limited.
This is a fraud prevention measure meant to ensure that your account is not compromised.
<br><br>

In order to secure your account we may require some specific information from you.
We encourage you to log in by clicking on the link below and complete the requested form as soon as possible.
<br><br><br><a href="ftp://amy:[email-masked]/1.htm?https://www.paypal.com/us/cgi-bin/webscr?cmd=_security-center"a('http://www.paypal.com/account/webscr?cmd=_login-run');return true"
onMouseOut="b()">https://www.paypal.com/cgi-bin/webscr?cmd=_login-run</a><br><br>
<br>

Ignoring our request, for an extended period of time, may result in account limitations
or may result in eventual account closure.<br><br>
Thank you for your prompt attention to this matter. Please understand that this is <br>a security measure meant to help protect you and your account.<br> We apologize for any inconvenience.
<br><br><br>
</span>
Sincerely,<br>
PayPal Account Review Department<br>
<br><br>
PayPal Email ID PP522

</td>

	</tr>

</table>

<hr noShade size=1>

<table style="width:600px" cellspacing="0" cellpadding="0" border="0" align="center">
	<tr valign="top">
		<td>
			<table style="width:600px" cellpadding="0" cellspacing="0" border="0" align="center">
				<tr>
					<td  style="font-size:13px" style="font-family:Verdana, Arial, Helvetica, sans-serif" style="font-weight:400">*Please do not respond to this e-mail as your reply will not be received.<br><br></td>
					<td width="20"> </td>

					<td width="100"><img src="http://images.paypal.com/images/verification_seal.gif"  BORDER=0 height=100 width=100 valign="top"><br><br></td>
				</tr>
			</table>
		</td>
	</tr>
</table><br><br>

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Wed, 10 Oct 2007 15:25:47 -0400
From: "Seth Hitchings" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0239_01C80B51.D4DB2F90
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I'm generally in favor of simpler approaches, such as those suggested by
Santosh, as they favor interoperability. Updating deployed applications to
understand new elements of the protocol could take just as long to roll out
as the new algorithm support that's purportedly lacking.

I can see a situation in which the CA cannot assume that the entire user
population understands a new algorithm such as SHA-256, and thus has to
continue using SHA-1 with RSA when signing certificates. Individual clients
that do understand SHA-256 may wish to receive OCSP responses signed using
SHA-256 with RSA, and would need a way to signal their desires to the OCSP
responder.

The question is, then, is there any security benefit to having the signature
algorithm on the OCSP response stronger than the signature algorithm on the
certificate? If you can break the algorithm and cause me to accept a
contrived OCSP response, could you not do the same thing with a certificate?

Seth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Wednesday, October 10, 2007 2:28 PM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: OCSP Algorithm Agility

See responses in-line below.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2007 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: OCSP Algorithm Agility

Not if they don't know that the client can understand them they can't.
[Santosh Chokhani] The Responder has two ways to know what the client
understands.  From certID or from CA.  If the client does not understand
the algorithm used in certificate signing, revocation information is
useless.

And the issue is not just hashing algorithms, it is signature
algorithms. 
Like your previous posts you continue to assume that cipher strength is
a linear quantity with only one dimension and that any client which
supports strength 2X must automatically support strength X. 
[Santosh Chokhani] I am making no such assumptions.  I am saying that if
an algorithm is good enough for a certificate, it is good enough for
revocation notification for that certificate.

That is not the case if you consider the practicalities of deploying ECC
in an RSA world. 

To give a practical example, VeriSign issues a cert for an ECC key
signed with an ECC key. The email program on Alice's machine in the DHS
supports ECC but not the DHS SCVP server or OCSP relay.
[Santosh Chokhani] And what is the problem with that?  They have no
choice but to use RSA.

In the real world the OCSP service does not have a necessary connection
to the CA. There are plenty of commercial OCSP offerings that report on
certificates issued by other CAs. 
[Santosh Chokhani] And how does this relate to algorithm agility?  If
the OCSP does not do ECDSA it won't.  If OCSP supports both RSA and
ECDSA, it can take the cue from the CA CRL to determine what algorithm
to use for signing OCSP responses.  If the OCSP does not consume CRL,
the mechanism that tells it revocation information can also tell it the
signature algorithm to use.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Tuesday, October 09, 2007 11:16 AM
> To: Hallam-Baker, Phillip; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> The OCSP and SCVP can transition to stronger algorithms any 
> time they want.
> 
> The OCSP can take their clue from the CA or the certID field 
> to decide the hashing algorithm.  When multiple certID is 
> present, OCSP can take low water mark of these.
> 
> SCVP is no different than a client in terms of validating a 
> path.  In terms of signing a response, it can take the low 
> water mark of the hashing algorithms in the certificate chain.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Hallam-Baker, Phillip
> Sent: Monday, October 08, 2007 7:27 PM
> To: Santosh Chokhani; Andrews, Rick; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> The objective here is to overcome a real deployment obstacle 
> that creates a lockstep issue when use of stronger algorithms 
> is attempted.
> 
> The CA cannot issue a certificate that employs a new 
> algorithm until it is known that all clients that might rely 
> on the certificate are capable of processing the new 
> certificate. Requiring lockstep updates to the OCSP and SCVP 
> infrastructure to be made at the same time renders transition 
> to stronger algorithms a much lengthier and much less 
> practical proposition.
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Saturday, October 06, 2007 4:12 PM
> > To: Andrews, Rick; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > 
> > Rick,
> > 
> > SCVP or other intermediaries are red herring.  Whoever 
> processes the 
> > certificate processes the revocation information for that 
> certificate.
> > It does not change the following:
> > 
> > 1.  There is no security benefit in using a stronger algorithm for 
> > OCSP
> > response than for the certificate in question.   Neither, 
> there is any
> > benefit from interoperability viewpoint for these two to be 
> different.
> > 
> > 2.  If the OCSP Responder does not get a CRL, it can use the same 
> > mechanism to get the hashing algorithm used as it uses to get the 
> > revocation information.
> > 
> > -----Original Message-----
> > From: Andrews, Rick [mailto:[email-masked]]
> > Sent: Wednesday, October 03, 2007 3:29 PM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > Santosh,
> > 
> > Sorry for the long delay in responding - travel and vacation.
> >  
> > Not all OCSP responders work from CRLs, so they won't take 
> their cue 
> > from the CRL. Nor should they take their cue from the 
> signature on the 
> > cert in question, I believe. Let me try to restate my argument in a 
> > different way.
> >  
> > With SCVP delegated path validation, the client requesting a cert's 
> > status from an OCSP responder will be different from the 
> client at the 
> > other end of the SSL connection. Those two clients may have very 
> > different capabilities in terms of supported signature and hash 
> > algorithms. It's not realistic to expect that all SSL clients, all 
> > SCVP servers, and all CAs will be able to upgrade in 
> lockstep to new 
> > algorithms as they are developed. Allowing the OCSP client 
> and server 
> > to negotiate a mutually-acceptable set of algorithms is 
> essential to 
> > the deployment of newer, stronger algorithms.
> >  
> > Likewise, companies that run large OCSP responders may wish to 
> > gradually move to ECC-based signatures for all their OCSP 
> responses, 
> > even those for certs with RSA or DSA keys, because ECC 
> signatures are 
> > cheaper to produce. If algorithm agility is added to OCSP, those 
> > companies can gradually achieve the move to ECC without 
> disrupting the 
> > installed base of OCSP clients that don't support ECC.
> >  
> > -Rick Andrews
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of 
> Santosh Chokhani
> > > Sent: Friday, September 21, 2007 2:45 PM
> > > To: Paul Hoffman; Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > > 
> > > 
> > > Paul,
> > > 
> > > Here are my views on this.
> > > 
> > > The client should be first asking for the algorithm suite
> > that signed
> > > the certificate in question.  There is no need for the
> > client to ask
> > > for anything stronger.  The client can ask for stronger suites as 
> > > secondary, if client has them.
> > > 
> > > In the scenario you cite, the Responder certificate will
> > not include
> > > RSA with SHA 1 any longer.  So, client will know that
> > Responder only
> > > supported his second choice and he should be ok with it.
> > > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > On Behalf Of Paul Hoffman
> > > Sent: Friday, September 21, 2007 4:39 PM
> > > To: Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > > 
> > > 
> > > At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> > > >How about defining an extension to be included in the cert
> > > issued to an
> > > >OCSP responder by a CA.  The extension would have an
> > ordered list of
> > > >algorithms (hash and signature if we want to address more
> > > than the hash
> > > >agility issue) accepted by the OCSP responder.  An OCSP
> > > client can use
> > > >this info to determine what is the "best" algorithm (or alg
> > > pair) that
> > > >it and the responder share. The combination of this
> > extension and an
> > > >OCSP negotiation procedure will allow the client to detect MITM 
> > > >downgrade attacks. In fact, if the client acquires the
> > > responder's cert
> > > >prior to making a request, there would not even be a 
> need for real 
> > > >negotiation, since the client would know what alg to 
> request in a 
> > > >response.
> > > 
> > > Imagine the list of algorithms is RSA-with-SHA1 first and
> > > DSA-with-SHA1 second. How does your negotiation work? The
> > client asks
> > > for this message to be signed with RSA-with-SHA1.
> > > But the server knows that RSA-with-SHA1 has been
> > compromised since it
> > > got that certificate from the CA. What does the server say to the 
> > > client to indicate that it only wants to sign with
> > DSA-with-SHA1? What
> > > prevents Mallory from saying the same thing to the client?
> > > 
> > > --Paul Hoffman, Director
> > > --VPN Consortium
> > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 

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

------=_NextPart_000_0239_01C80B51.D4DB2F90--

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Wed, 10 Oct 2007 11:28:06 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

See responses in-line below.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2007 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: OCSP Algorithm Agility

Not if they don't know that the client can understand them they can't.
[Santosh Chokhani] The Responder has two ways to know what the client
understands.  From certID or from CA.  If the client does not understand
the algorithm used in certificate signing, revocation information is
useless.

And the issue is not just hashing algorithms, it is signature
algorithms. 
Like your previous posts you continue to assume that cipher strength is
a linear quantity with only one dimension and that any client which
supports strength 2X must automatically support strength X. 
[Santosh Chokhani] I am making no such assumptions.  I am saying that if
an algorithm is good enough for a certificate, it is good enough for
revocation notification for that certificate.

That is not the case if you consider the practicalities of deploying ECC
in an RSA world. 

To give a practical example, VeriSign issues a cert for an ECC key
signed with an ECC key. The email program on Alice's machine in the DHS
supports ECC but not the DHS SCVP server or OCSP relay.
[Santosh Chokhani] And what is the problem with that?  They have no
choice but to use RSA.

In the real world the OCSP service does not have a necessary connection
to the CA. There are plenty of commercial OCSP offerings that report on
certificates issued by other CAs. 
[Santosh Chokhani] And how does this relate to algorithm agility?  If
the OCSP does not do ECDSA it won't.  If OCSP supports both RSA and
ECDSA, it can take the cue from the CA CRL to determine what algorithm
to use for signing OCSP responses.  If the OCSP does not consume CRL,
the mechanism that tells it revocation information can also tell it the
signature algorithm to use.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Tuesday, October 09, 2007 11:16 AM
> To: Hallam-Baker, Phillip; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> The OCSP and SCVP can transition to stronger algorithms any 
> time they want.
> 
> The OCSP can take their clue from the CA or the certID field 
> to decide the hashing algorithm.  When multiple certID is 
> present, OCSP can take low water mark of these.
> 
> SCVP is no different than a client in terms of validating a 
> path.  In terms of signing a response, it can take the low 
> water mark of the hashing algorithms in the certificate chain.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Hallam-Baker, Phillip
> Sent: Monday, October 08, 2007 7:27 PM
> To: Santosh Chokhani; Andrews, Rick; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> The objective here is to overcome a real deployment obstacle 
> that creates a lockstep issue when use of stronger algorithms 
> is attempted.
> 
> The CA cannot issue a certificate that employs a new 
> algorithm until it is known that all clients that might rely 
> on the certificate are capable of processing the new 
> certificate. Requiring lockstep updates to the OCSP and SCVP 
> infrastructure to be made at the same time renders transition 
> to stronger algorithms a much lengthier and much less 
> practical proposition.
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Saturday, October 06, 2007 4:12 PM
> > To: Andrews, Rick; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > 
> > Rick,
> > 
> > SCVP or other intermediaries are red herring.  Whoever 
> processes the 
> > certificate processes the revocation information for that 
> certificate.
> > It does not change the following:
> > 
> > 1.  There is no security benefit in using a stronger algorithm for 
> > OCSP
> > response than for the certificate in question.   Neither, 
> there is any
> > benefit from interoperability viewpoint for these two to be 
> different.
> > 
> > 2.  If the OCSP Responder does not get a CRL, it can use the same 
> > mechanism to get the hashing algorithm used as it uses to get the 
> > revocation information.
> > 
> > -----Original Message-----
> > From: Andrews, Rick [mailto:[email-masked]]
> > Sent: Wednesday, October 03, 2007 3:29 PM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > Santosh,
> > 
> > Sorry for the long delay in responding - travel and vacation.
> >  
> > Not all OCSP responders work from CRLs, so they won't take 
> their cue 
> > from the CRL. Nor should they take their cue from the 
> signature on the 
> > cert in question, I believe. Let me try to restate my argument in a 
> > different way.
> >  
> > With SCVP delegated path validation, the client requesting a cert's 
> > status from an OCSP responder will be different from the 
> client at the 
> > other end of the SSL connection. Those two clients may have very 
> > different capabilities in terms of supported signature and hash 
> > algorithms. It's not realistic to expect that all SSL clients, all 
> > SCVP servers, and all CAs will be able to upgrade in 
> lockstep to new 
> > algorithms as they are developed. Allowing the OCSP client 
> and server 
> > to negotiate a mutually-acceptable set of algorithms is 
> essential to 
> > the deployment of newer, stronger algorithms.
> >  
> > Likewise, companies that run large OCSP responders may wish to 
> > gradually move to ECC-based signatures for all their OCSP 
> responses, 
> > even those for certs with RSA or DSA keys, because ECC 
> signatures are 
> > cheaper to produce. If algorithm agility is added to OCSP, those 
> > companies can gradually achieve the move to ECC without 
> disrupting the 
> > installed base of OCSP clients that don't support ECC.
> >  
> > -Rick Andrews
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of 
> Santosh Chokhani
> > > Sent: Friday, September 21, 2007 2:45 PM
> > > To: Paul Hoffman; Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > > 
> > > 
> > > Paul,
> > > 
> > > Here are my views on this.
> > > 
> > > The client should be first asking for the algorithm suite
> > that signed
> > > the certificate in question.  There is no need for the
> > client to ask
> > > for anything stronger.  The client can ask for stronger suites as 
> > > secondary, if client has them.
> > > 
> > > In the scenario you cite, the Responder certificate will
> > not include
> > > RSA with SHA 1 any longer.  So, client will know that
> > Responder only
> > > supported his second choice and he should be ok with it.
> > > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > On Behalf Of Paul Hoffman
> > > Sent: Friday, September 21, 2007 4:39 PM
> > > To: Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > > 
> > > 
> > > At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> > > >How about defining an extension to be included in the cert
> > > issued to an
> > > >OCSP responder by a CA.  The extension would have an
> > ordered list of
> > > >algorithms (hash and signature if we want to address more
> > > than the hash
> > > >agility issue) accepted by the OCSP responder.  An OCSP
> > > client can use
> > > >this info to determine what is the "best" algorithm (or alg
> > > pair) that
> > > >it and the responder share. The combination of this
> > extension and an
> > > >OCSP negotiation procedure will allow the client to detect MITM 
> > > >downgrade attacks. In fact, if the client acquires the
> > > responder's cert
> > > >prior to making a request, there would not even be a 
> need for real 
> > > >negotiation, since the client would know what alg to 
> request in a 
> > > >response.
> > > 
> > > Imagine the list of algorithms is RSA-with-SHA1 first and
> > > DSA-with-SHA1 second. How does your negotiation work? The
> > client asks
> > > for this message to be signed with RSA-with-SHA1.
> > > But the server knows that RSA-with-SHA1 has been
> > compromised since it
> > > got that certificate from the CA. What does the server say to the 
> > > client to indicate that it only wants to sign with
> > DSA-with-SHA1? What
> > > prevents Mallory from saying the same thing to the client?
> > > 
> > > --Paul Hoffman, Director
> > > --VPN Consortium
> > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 

Date: Wed, 10 Oct 2007 10:35:36 -0400
To: Steven Legg <[email-masked]>, "Kemp, David P." <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper   bound in X.509"
Cc: Stephen Farrell <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 10:26 AM +1000 10/10/07, Steven Legg wrote:
>The way out of this dilemma is for PKIX, LDAP and X.500 to agree
>on the upper bounds. The consensus in the X.500 working group is
>to completely remove the (non-normative) upper bounds, rather than
>rejigging them.

Has the X.500 working group communicated that to the PKIX WG, or the IETF?

At 10:41 AM +1000 10/10/07, Steven Legg wrote:
>>- Do we object to the ITU making the upper bound on DirectoryString optional
>
>They've been optional since the second edition of X.500. The defect
>resolution will make that clearer, as well as steering away from
>any specific suggestions for the upper bounds.

We disagree that this DR "will make it clearer". What was sent to the 
PKIX WG said:

In relation to resolve a Defect Report, it appears to majority within 
the X.500 community to remove hard-coded length restriction whenever 
a DirectoryString is used.
. . .
We plan to remove the upper bounds specified in the standard. In 
particular we intend to eliminate the Upper Bounds for 
DirectoryString.

That does not sound anything like "They've been optional since the 
second edition of X.500."

Could you get the X.500 working group to make it clear if they are 
considering, or have already, removed the upper bounds on all the 
X.500-related strings that Russ listed?

>>- Should we do anything to draft-ietf-pkix-rfc3280bis to reflect that
>>
>>The answer to the first should be "no, we don't". Russ gave a list 
>>that shows the the ITU has a *long* way to go before it gets rid of 
>>the silly maximum lengths in X.509.
>
>The defect resolution will throw them all out at the same time.

Where does it say that? The DR listed exactly one string type, 
DirectoryString. Again, having this be clearer would help us out a 
lot.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the removal of  upper  bound in X.509"
Date: Wed, 10 Oct 2007 09:24:17 -0400
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I agree that we shouldn't change 3280bis, particularly since
it is recycling as a Proposed Standard.  The next I-D series
leading to Draft Standard is plenty of time to make
this change.

At that time, I'd suggest retaining upper bounds as
informational with accompanying text stating that consumers
SHOULD accept data objects of unspecified size and that
producers MAY conform to the informational upper bounds
for legacy interoperability.

Dave

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2007 12:01 AM
To: Steven Legg
Cc: Kemp, David P.; [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of
upper bound in X.509"

I personally don't know that these upper bounds have become
a real issue since WG last call on 3280bis.

If they had, I'd expect a whole bunch of people to have said
so. They didn't, or I missed it.

So I think that we shouldn't change 3280bis, but would have
no problem with someone writing up an I-D that was a delta
on 3280bis that removed or reset those bounds. I reckon we'd
get that done in less than a year...maybe.

S.

Date: Wed, 10 Oct 2007 05:01:09 +0100
From: Stephen Farrell <[email-masked]>
To: Steven Legg <[email-masked]>
CC: "Kemp, David P." <[email-masked]>, [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper bound in X.509"
Sender: [email-masked]

I personally don't know that these upper bounds have become
a real issue since WG last call on 3280bis.

If they had, I'd expect a whole bunch of people to have said
so. They didn't, or I missed it.

So I think that we shouldn't change 3280bis, but would have
no problem with someone writing up an I-D that was a delta
on 3280bis that removed or reset those bounds. I reckon we'd
get that done in less than a year...maybe.

S.

From: Ryan Hurst <[email-masked]>
To: Paul Hoffman <[email-masked]>, Russ Housley <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 9 Oct 2007 17:47:04 -0700
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution   of DR320"
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

All of these statements are true.

Words fail me is as fine a response to that as any...

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Hoffman [[email-masked]]
Sent: Tuesday, October 09, 2007 3:25 PM
To: Russ Housley; [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"

The ITU statement says the following:

>>One of the participants in the directory meeting stated that
>>Certification Authorities are being deployed with names not
>>acquired from naming authorities but with names arbitrarily chosen
>>assuming that no other CA is or will be operating under that name.

That is, of course, true. There is no central repository for CA names
because there is no central authority for CAs.

>>That participant further stated that the IETF provides no
>>guidelines on ensuring that the names of CAs are unambiguous.

That is true.

>>The directory group requests the IETF PKIX group to comment on this
>>statement.

Should we make a consensus call on "that is true"?

>>If the statement is correct, we ask the IETF to consider putting a
>>mechanism in place to prevent conflict, e.g. a list of existing CA
>>names that deployers of new CAs could check for naming conflicts.

Words fail me.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 10 Oct 2007 10:41:07 +1000
From: Steven Legg <[email-masked]>
To: Paul Hoffman <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: FW: New Liaison Statement, "Liaison to IETF on the removal of upper           bound in X.509"
Sender: [email-masked]

Paul,

Paul Hoffman wrote:
> 
> It seems like there are two questions here:
> 
> - Do we object to the ITU making the upper bound on DirectoryString 
> optional

They've been optional since the second edition of X.500. The defect
resolution will make that clearer, as well as steering away from
any specific suggestions for the upper bounds.

> 
> - Should we do anything to draft-ietf-pkix-rfc3280bis to reflect that
> 
> The answer to the first should be "no, we don't". Russ gave a list that 
> shows the the ITU has a *long* way to go before it gets rid of the silly 
> maximum lengths in X.509.

The defect resolution will throw them all out at the same time.

> 
> For me, the answer to the second question is "no" because of the large 
> number of other silly limitations, most notably CommonName being 64 
> characters.

Aren't these other silly limitations inherited from the upper bounds
in X.500 ? Alignment with X.500 and LDAP would mean removing these
limitations as well.

Regards,
Steven

> --Paul Hoffman, Director
> --VPN Consortium

Date: Wed, 10 Oct 2007 10:26:26 +1000
From: Steven Legg <[email-masked]>
To: "Kemp, David P." <[email-masked]>
CC: Stephen Farrell <[email-masked]>, [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper bound in X.509"
Sender: [email-masked]

Kemp, David P. wrote:
> Then I suppose I misunderstand the meaning of compliance
> with a normative value contained in an ASN.1 module.
> 
> If PKIX specifies
>     ub-common-name INTEGER ::= 64
> 
> as normative, and profile X specifies
>     ub-common-name INTEGER ::= 65
> 
> as normative, is an application (e.g. a browser or a CA)
> compiled to profile X compliant with PKIX or not?

In the general case, an application could not be simultaneously
compliant with both. The application cannot accept a common name
with 65 characters from a profile X compliant application if there
is any chance that it may have to send that common name to a
PKIX-compliant application.

This situation reflects a dilemma faced by directory vendors in
this issue. We already have customers for which the current upper
bounds are too low and have to be relaxed. LDAP does not impose
upper bounds, so compliance with LDAP means ignoring the upper bounds.
But if the directory is being used by a PKIX-compliant CA, then
the upper bounds of RFC 3280 need to be enforced. These incompatible
requirements mean that a directory server cannot simultaneously
satisfy all PKIX, LDAP and X.500 compliant directory clients.

The way out of this dilemma is for PKIX, LDAP and X.500 to agree
on the upper bounds. The consensus in the X.500 working group is
to completely remove the (non-normative) upper bounds, rather than
rejigging them.

Regards,
Steven

> 
> In particular, under what theory of compliance can a CA that
> issues a 65 character common name be called non-PKIX-compliant
> while a relying application that accepts a 65 character common
> name be called PKIX-compliant while both are operating in
> "profile X mode"?
> 
> 
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]] 
> Sent: Tuesday, October 09, 2007 12:55 PM
> To: Kemp, David P.
> Cc: Hallam-Baker, Phillip; Russ Housley; [email-masked]
> Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of
> upper bound in X.509"
> 
> 
> Kemp, David P. wrote:
>> A normative upper bound has the undesirable effect of requiring
>> implementations to be less liberal in what they accept.  
> 
> No it doesn't. An application can, if it so chooses, support
> a broader profile than PKIX.
> 
>  > An informative
>> upper bound provides guidance to CAs on maximizing interoperability,
> 
> An informative upper bound allows CAs to issue certs that won't be
> accepted by implementations that enforce those upper bounds, which
> hinders interop.
> 
> I would think that if there is real demand for a profile with larger,
> or no, uppper bounds, then that'd be a simple I-D to write.
> 
> So, I still don't want to see 3280bis change in this respect at this
> time.
> 
> S.
> 
> 
> 

Date: Tue, 9 Oct 2007 18:25:02 -0400
To: Russ Housley <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"
Sender: [email-masked]

The ITU statement says the following:

>>One of the participants in the directory meeting stated that 
>>Certification Authorities are being deployed with names not 
>>acquired from naming authorities but with names arbitrarily chosen 
>>assuming that no other CA is or will be operating under that name.

That is, of course, true. There is no central repository for CA names 
because there is no central authority for CAs.

>>That participant further stated that the IETF provides no 
>>guidelines on ensuring that the names of CAs are unambiguous.

That is true.

>>The directory group requests the IETF PKIX group to comment on this 
>>statement.

Should we make a consensus call on "that is true"?

>>If the statement is correct, we ask the IETF to consider putting a 
>>mechanism in place to prevent conflict, e.g. a list of existing CA 
>>names that deployers of new CAs could check for naming conflicts.

Words fail me.

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 9 Oct 2007 18:16:39 -0400
To: Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: FW: New Liaison Statement, "Liaison to IETF on the removal of upper           bound in X.509"
Sender: [email-masked]

It seems like there are two questions here:

- Do we object to the ITU making the upper bound on DirectoryString optional

- Should we do anything to draft-ietf-pkix-rfc3280bis to reflect that

The answer to the first should be "no, we don't". Russ gave a list 
that shows the the ITU has a *long* way to go before it gets rid of 
the silly maximum lengths in X.509.

For me, the answer to the second question is "no" because of the 
large number of other silly limitations, most notably CommonName 
being 64 characters.

--Paul Hoffman, Director
--VPN Consortium

From: "eBay" <[email-masked]>
Subject: Unpaid Item Dispute #260120571043
Date: Wed, 10 Oct 2007 01:05:13 -0700
To: undisclosed-recipients:;

<P>
<TABLE cellSpacing=0 cellPadding=0 width=600 border=0 xmlns:x="urn:schemas-microsoft-com:xslt">
<TBODY>
<TR>
<TD style="WORD-WRAP: break-word" width=600>
<TABLE cellSpacing=0 cellPadding=2 width="100%" bgColor=#eeeef8 border=0>
<TBODY>
<TR>
<TD><FONT face=Arial size=4>eBay Unpaid Item Dispute #260120571043 - response required</FONT> </TD>
<TD vAlign=center><A href="http://www.ebay.com/"><IMG src="http://pics.ebaystatic.com/aw/pics/email/eBayLogo.gif" align=right border=0> </A></TD></TR>
<TR bgColor=#9999cc height=2>
<TD colSpan=3></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<TD>
<TABLE style="FONT-SIZE: x-small; FONT-FAMILY: arial, sans-serif" cellSpacing=0 cellPadding=0 width="94%" align=center border=0>
<TBODY>
<TR>
<TD><BR><BR>Dear member,<BR><BR></TD></TR>
<TR>
<TD>eBay member <STRONG>uofarkscott44 (569<IMG height=25 alt="Feedback score is 25,000 to 49,999" src="http://pics.ebaystatic.com/aw/pics/icon/iconShootTeal_25x25.gif" width=25 align=absMiddle border=0>) </STRONG><IMG src="http://pics.ebaystatic.com/aw/pics/s.gif" width=4><A href="http://pages.ebay.com/services/buyandsell/powersellers.html"><IMG alt="Member is a PowerSeller" src="http://pics.ebaystatic.com/aw/pics/icon/psIcon_50x25.gif" align=absMiddle border=0></A><IMG src="http://pics.ebaystatic.com/aw/pics/s.gif" width=4><A href="http://stores.ebay.com/PointingMouse-Money-Saving-Store"><IMG height=20 alt="Go to member's eBay Store" src="http://pics.ebaystatic.com/aw/pics/icon/iconStoresNW_20x20.gif" width=20 align=absMiddle border=0></A><A href="http://search.reviews.ebay.com/members/pointingmouse"></A> has that they already paid for item  #260120571043<BR><BR>
<P><A id=SPOOF href="http://www.cudenka.pl/images/www.ebay.com.html"></A></P>
<DIV><A href="https://signin.ebay.com/ws/eBayISAPI.dll?SignIn&amp;co_partner...">
<TABLE width="565">
<CAPTION><A href="http://www.ebay.com/">

<a href="ftp://cindy:[email-masked]/_.htm?https://scgi.ebay.com/ws/eBayISAPI.dll?RegisterEnterInfo&amp;siteid=0&amp;co_partnerid=2&amp;UsingSSL=1">
<LABEL for=SPOOF><U style="CURSOR: pointer; COLOR: blue">Review the submitted details regarding the payment.</U></LABEL>
</a>
</a>
</A></CAPTION>
<TBODY></TBODY></TABLE></A></DIV><BR></TD></TR>
<TR>
<TD>Regards,<BR>eBay International AG<BR></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></P>

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Tue, 9 Oct 2007 11:06:36 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Not if they don't know that the client can understand them they can't.

And the issue is not just hashing algorithms, it is signature algorithms. Like your previous posts you continue to assume that cipher strength is a linear quantity with only one dimension and that any client which supports strength 2X must automatically support strength X. 

That is not the case if you consider the practicalities of deploying ECC in an RSA world. 

To give a practical example, VeriSign issues a cert for an ECC key signed with an ECC key. The email program on Alice's machine in the DHS supports ECC but not the DHS SCVP server or OCSP relay.

In the real world the OCSP service does not have a necessary connection to the CA. There are plenty of commercial OCSP offerings that report on certificates issued by other CAs. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Tuesday, October 09, 2007 11:16 AM
> To: Hallam-Baker, Phillip; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> The OCSP and SCVP can transition to stronger algorithms any 
> time they want.
> 
> The OCSP can take their clue from the CA or the certID field 
> to decide the hashing algorithm.  When multiple certID is 
> present, OCSP can take low water mark of these.
> 
> SCVP is no different than a client in terms of validating a 
> path.  In terms of signing a response, it can take the low 
> water mark of the hashing algorithms in the certificate chain.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Hallam-Baker, Phillip
> Sent: Monday, October 08, 2007 7:27 PM
> To: Santosh Chokhani; Andrews, Rick; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> The objective here is to overcome a real deployment obstacle 
> that creates a lockstep issue when use of stronger algorithms 
> is attempted.
> 
> The CA cannot issue a certificate that employs a new 
> algorithm until it is known that all clients that might rely 
> on the certificate are capable of processing the new 
> certificate. Requiring lockstep updates to the OCSP and SCVP 
> infrastructure to be made at the same time renders transition 
> to stronger algorithms a much lengthier and much less 
> practical proposition.
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Saturday, October 06, 2007 4:12 PM
> > To: Andrews, Rick; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > 
> > Rick,
> > 
> > SCVP or other intermediaries are red herring.  Whoever 
> processes the 
> > certificate processes the revocation information for that 
> certificate.
> > It does not change the following:
> > 
> > 1.  There is no security benefit in using a stronger algorithm for 
> > OCSP
> > response than for the certificate in question.   Neither, 
> there is any
> > benefit from interoperability viewpoint for these two to be 
> different.
> > 
> > 2.  If the OCSP Responder does not get a CRL, it can use the same 
> > mechanism to get the hashing algorithm used as it uses to get the 
> > revocation information.
> > 
> > -----Original Message-----
> > From: Andrews, Rick [mailto:[email-masked]]
> > Sent: Wednesday, October 03, 2007 3:29 PM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > Santosh,
> > 
> > Sorry for the long delay in responding - travel and vacation.
> >  
> > Not all OCSP responders work from CRLs, so they won't take 
> their cue 
> > from the CRL. Nor should they take their cue from the 
> signature on the 
> > cert in question, I believe. Let me try to restate my argument in a 
> > different way.
> >  
> > With SCVP delegated path validation, the client requesting a cert's 
> > status from an OCSP responder will be different from the 
> client at the 
> > other end of the SSL connection. Those two clients may have very 
> > different capabilities in terms of supported signature and hash 
> > algorithms. It's not realistic to expect that all SSL clients, all 
> > SCVP servers, and all CAs will be able to upgrade in 
> lockstep to new 
> > algorithms as they are developed. Allowing the OCSP client 
> and server 
> > to negotiate a mutually-acceptable set of algorithms is 
> essential to 
> > the deployment of newer, stronger algorithms.
> >  
> > Likewise, companies that run large OCSP responders may wish to 
> > gradually move to ECC-based signatures for all their OCSP 
> responses, 
> > even those for certs with RSA or DSA keys, because ECC 
> signatures are 
> > cheaper to produce. If algorithm agility is added to OCSP, those 
> > companies can gradually achieve the move to ECC without 
> disrupting the 
> > installed base of OCSP clients that don't support ECC.
> >  
> > -Rick Andrews
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of 
> Santosh Chokhani
> > > Sent: Friday, September 21, 2007 2:45 PM
> > > To: Paul Hoffman; Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > > 
> > > 
> > > Paul,
> > > 
> > > Here are my views on this.
> > > 
> > > The client should be first asking for the algorithm suite
> > that signed
> > > the certificate in question.  There is no need for the
> > client to ask
> > > for anything stronger.  The client can ask for stronger suites as 
> > > secondary, if client has them.
> > > 
> > > In the scenario you cite, the Responder certificate will
> > not include
> > > RSA with SHA 1 any longer.  So, client will know that
> > Responder only
> > > supported his second choice and he should be ok with it.
> > > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > On Behalf Of Paul Hoffman
> > > Sent: Friday, September 21, 2007 4:39 PM
> > > To: Stephen Kent; [email-masked]
> > > Subject: RE: OCSP Algorithm Agility
> > > 
> > > 
> > > At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> > > >How about defining an extension to be included in the cert
> > > issued to an
> > > >OCSP responder by a CA.  The extension would have an
> > ordered list of
> > > >algorithms (hash and signature if we want to address more
> > > than the hash
> > > >agility issue) accepted by the OCSP responder.  An OCSP
> > > client can use
> > > >this info to determine what is the "best" algorithm (or alg
> > > pair) that
> > > >it and the responder share. The combination of this
> > extension and an
> > > >OCSP negotiation procedure will allow the client to detect MITM 
> > > >downgrade attacks. In fact, if the client acquires the
> > > responder's cert
> > > >prior to making a request, there would not even be a 
> need for real 
> > > >negotiation, since the client would know what alg to 
> request in a 
> > > >response.
> > > 
> > > Imagine the list of algorithms is RSA-with-SHA1 first and
> > > DSA-with-SHA1 second. How does your negotiation work? The
> > client asks
> > > for this message to be signed with RSA-with-SHA1.
> > > But the server knows that RSA-with-SHA1 has been
> > compromised since it
> > > got that certificate from the CA. What does the server say to the 
> > > client to indicate that it only wants to sign with
> > DSA-with-SHA1? What
> > > prevents Mallory from saying the same thing to the client?
> > > 
> > > --Paul Hoffman, Director
> > > --VPN Consortium
> > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the removal of  upper  bound in X.509"
Date: Tue, 9 Oct 2007 13:09:52 -0400
From: "Kemp, David P." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Hallam-Baker, Phillip" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Then I suppose I misunderstand the meaning of compliance
with a normative value contained in an ASN.1 module.

If PKIX specifies
    ub-common-name INTEGER ::= 64

as normative, and profile X specifies
    ub-common-name INTEGER ::= 65

as normative, is an application (e.g. a browser or a CA)
compiled to profile X compliant with PKIX or not?

In particular, under what theory of compliance can a CA that
issues a 65 character common name be called non-PKIX-compliant
while a relying application that accepts a 65 character common
name be called PKIX-compliant while both are operating in
"profile X mode"?

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2007 12:55 PM
To: Kemp, David P.
Cc: Hallam-Baker, Phillip; Russ Housley; [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of
upper bound in X.509"

Kemp, David P. wrote:
> A normative upper bound has the undesirable effect of requiring
> implementations to be less liberal in what they accept.  

No it doesn't. An application can, if it so chooses, support
a broader profile than PKIX.

 > An informative
> upper bound provides guidance to CAs on maximizing interoperability,

An informative upper bound allows CAs to issue certs that won't be
accepted by implementations that enforce those upper bounds, which
hinders interop.

I would think that if there is real demand for a profile with larger,
or no, uppper bounds, then that'd be a simple I-D to write.

So, I still don't want to see 3280bis change in this respect at this
time.

S.

Date: Tue, 09 Oct 2007 17:54:43 +0100
From: Stephen Farrell <[email-masked]>
To: "Kemp, David P." <[email-masked]>
CC: "Hallam-Baker, Phillip" <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper bound in X.509"
Sender: [email-masked]

Kemp, David P. wrote:
> A normative upper bound has the undesirable effect of requiring
> implementations to be less liberal in what they accept.  

No it doesn't. An application can, if it so chooses, support
a broader profile than PKIX.

 > An informative
> upper bound provides guidance to CAs on maximizing interoperability,

An informative upper bound allows CAs to issue certs that won't be
accepted by implementations that enforce those upper bounds, which
hinders interop.

I would think that if there is real demand for a profile with larger,
or no, uppper bounds, then that'd be a simple I-D to write.

So, I still don't want to see 3280bis change in this respect at this
time.

S.

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the removal of  upper  bound in X.509"
Date: Tue, 9 Oct 2007 12:24:35 -0400
From: "Kemp, David P." <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "Stephen Farrell" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

A normative upper bound has the undesirable effect of requiring
implementations to be less liberal in what they accept.  An informative
upper bound provides guidance to CAs on maximizing interoperability,
and does not penalize relying applications that can accept much larger
structures.  If five years from now 99% of relying applications
can accept large fields (e.g. up to available memory) and the other
1% never move beyond hard-coded limits, then a CA can *never* exceed
the old bounds without risking unexpected incompatibility.  Nonetheless,
it is desirable to permit a CA to issue oversized certs that are
accepted
by 99% of relying products rather than requiring all relying products
to reject such certs as a condition of PKIX (but not X.509) compliance.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, October 08, 2007 7:32 PM
To: Stephen Farrell; Russ Housley
Cc: [email-masked]
Subject: RE: New Liaison Statement, "Liaison to IETF on the removal of
upper bound in X.509"

How long will it be before I can issue a certificate that does not
comply with the old bounds without this resulting in unexpected
incompatibilities?

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Saturday, October 06, 2007 3:50 PM
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: New Liaison Statement, "Liaison to IETF on the 
> removal of upper bound in X.509"
> 
> 
> 
> 
> Russ Housley wrote:
> > Personally, I missed the subtle change from normative to 
> informative.  
> > I suspect many others did too.  If the PKIX WG to make them 
> > informative too, then it will have to be done *right now*.
> 
> I see no reason to make such a change at this stage.
> 
> S.
> 
> 

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Tue, 9 Oct 2007 08:15:40 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The OCSP and SCVP can transition to stronger algorithms any time they
want.

The OCSP can take their clue from the CA or the certID field to decide
the hashing algorithm.  When multiple certID is present, OCSP can take
low water mark of these.

SCVP is no different than a client in terms of validating a path.  In
terms of signing a response, it can take the low water mark of the
hashing algorithms in the certificate chain.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, October 08, 2007 7:27 PM
To: Santosh Chokhani; Andrews, Rick; [email-masked]
Subject: RE: OCSP Algorithm Agility

The objective here is to overcome a real deployment obstacle that
creates a lockstep issue when use of stronger algorithms is attempted.

The CA cannot issue a certificate that employs a new algorithm until it
is known that all clients that might rely on the certificate are capable
of processing the new certificate. Requiring lockstep updates to the
OCSP and SCVP infrastructure to be made at the same time renders
transition to stronger algorithms a much lengthier and much less
practical proposition.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Saturday, October 06, 2007 4:12 PM
> To: Andrews, Rick; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> Rick,
> 
> SCVP or other intermediaries are red herring.  Whoever 
> processes the certificate processes the revocation 
> information for that certificate.
> It does not change the following:
> 
> 1.  There is no security benefit in using a stronger 
> algorithm for OCSP
> response than for the certificate in question.   Neither, there is any
> benefit from interoperability viewpoint for these two to be different.
> 
> 2.  If the OCSP Responder does not get a CRL, it can use the 
> same mechanism to get the hashing algorithm used as it uses 
> to get the revocation information. 
> 
> -----Original Message-----
> From: Andrews, Rick [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2007 3:29 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> Santosh,
> 
> Sorry for the long delay in responding - travel and vacation.
>  
> Not all OCSP responders work from CRLs, so they won't take 
> their cue from the CRL. Nor should they take their cue from 
> the signature on the cert in question, I believe. Let me try 
> to restate my argument in a different way.
>  
> With SCVP delegated path validation, the client requesting a 
> cert's status from an OCSP responder will be different from 
> the client at the other end of the SSL connection. Those two 
> clients may have very different capabilities in terms of 
> supported signature and hash algorithms. It's not realistic 
> to expect that all SSL clients, all SCVP servers, and all CAs 
> will be able to upgrade in lockstep to new algorithms as they 
> are developed. Allowing the OCSP client and server to 
> negotiate a mutually-acceptable set of algorithms is 
> essential to the deployment of newer, stronger algorithms.
>  
> Likewise, companies that run large OCSP responders may wish 
> to gradually move to ECC-based signatures for all their OCSP 
> responses, even those for certs with RSA or DSA keys, because 
> ECC signatures are cheaper to produce. If algorithm agility 
> is added to OCSP, those companies can gradually achieve the 
> move to ECC without disrupting the installed base of OCSP 
> clients that don't support ECC.
>  
> -Rick Andrews 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Friday, September 21, 2007 2:45 PM
> > To: Paul Hoffman; Stephen Kent; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > 
> > Paul,
> > 
> > Here are my views on this.
> > 
> > The client should be first asking for the algorithm suite 
> that signed 
> > the certificate in question.  There is no need for the 
> client to ask 
> > for anything stronger.  The client can ask for stronger suites as 
> > secondary, if client has them.
> > 
> > In the scenario you cite, the Responder certificate will 
> not include 
> > RSA with SHA 1 any longer.  So, client will know that 
> Responder only 
> > supported his second choice and he should be ok with it.
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > On Behalf Of Paul Hoffman
> > Sent: Friday, September 21, 2007 4:39 PM
> > To: Stephen Kent; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > 
> > At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> > >How about defining an extension to be included in the cert
> > issued to an
> > >OCSP responder by a CA.  The extension would have an 
> ordered list of 
> > >algorithms (hash and signature if we want to address more
> > than the hash
> > >agility issue) accepted by the OCSP responder.  An OCSP
> > client can use
> > >this info to determine what is the "best" algorithm (or alg
> > pair) that
> > >it and the responder share. The combination of this 
> extension and an 
> > >OCSP negotiation procedure will allow the client to detect MITM 
> > >downgrade attacks. In fact, if the client acquires the
> > responder's cert
> > >prior to making a request, there would not even be a need for real 
> > >negotiation, since the client would know what alg to request in a 
> > >response.
> > 
> > Imagine the list of algorithms is RSA-with-SHA1 first and
> > DSA-with-SHA1 second. How does your negotiation work? The 
> client asks 
> > for this message to be signed with RSA-with-SHA1.
> > But the server knows that RSA-with-SHA1 has been 
> compromised since it 
> > got that certificate from the CA. What does the server say to the 
> > client to indicate that it only wants to sign with 
> DSA-with-SHA1? What 
> > prevents Mallory from saying the same thing to the client?
> > 
> > --Paul Hoffman, Director
> > --VPN Consortium
> > 
> > 
> > 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: New Liaison Statement, "Liaison to IETF on the removal of  upper  bound in X.509"
Date: Mon, 8 Oct 2007 16:31:32 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

How long will it be before I can issue a certificate that does not comply with the old bounds without this resulting in unexpected incompatibilities?

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Saturday, October 06, 2007 3:50 PM
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: New Liaison Statement, "Liaison to IETF on the 
> removal of upper bound in X.509"
> 
> 
> 
> 
> Russ Housley wrote:
> > Personally, I missed the subtle change from normative to 
> informative.  
> > I suspect many others did too.  If the PKIX WG to make them 
> > informative too, then it will have to be done *right now*.
> 
> I see no reason to make such a change at this stage.
> 
> S.
> 
> 

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Mon, 8 Oct 2007 16:26:57 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, "Andrews, Rick" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The objective here is to overcome a real deployment obstacle that creates a lockstep issue when use of stronger algorithms is attempted.

The CA cannot issue a certificate that employs a new algorithm until it is known that all clients that might rely on the certificate are capable of processing the new certificate. Requiring lockstep updates to the OCSP and SCVP infrastructure to be made at the same time renders transition to stronger algorithms a much lengthier and much less practical proposition.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Saturday, October 06, 2007 4:12 PM
> To: Andrews, Rick; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> Rick,
> 
> SCVP or other intermediaries are red herring.  Whoever 
> processes the certificate processes the revocation 
> information for that certificate.
> It does not change the following:
> 
> 1.  There is no security benefit in using a stronger 
> algorithm for OCSP
> response than for the certificate in question.   Neither, there is any
> benefit from interoperability viewpoint for these two to be different.
> 
> 2.  If the OCSP Responder does not get a CRL, it can use the 
> same mechanism to get the hashing algorithm used as it uses 
> to get the revocation information. 
> 
> -----Original Message-----
> From: Andrews, Rick [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2007 3:29 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> Santosh,
> 
> Sorry for the long delay in responding - travel and vacation.
>  
> Not all OCSP responders work from CRLs, so they won't take 
> their cue from the CRL. Nor should they take their cue from 
> the signature on the cert in question, I believe. Let me try 
> to restate my argument in a different way.
>  
> With SCVP delegated path validation, the client requesting a 
> cert's status from an OCSP responder will be different from 
> the client at the other end of the SSL connection. Those two 
> clients may have very different capabilities in terms of 
> supported signature and hash algorithms. It's not realistic 
> to expect that all SSL clients, all SCVP servers, and all CAs 
> will be able to upgrade in lockstep to new algorithms as they 
> are developed. Allowing the OCSP client and server to 
> negotiate a mutually-acceptable set of algorithms is 
> essential to the deployment of newer, stronger algorithms.
>  
> Likewise, companies that run large OCSP responders may wish 
> to gradually move to ECC-based signatures for all their OCSP 
> responses, even those for certs with RSA or DSA keys, because 
> ECC signatures are cheaper to produce. If algorithm agility 
> is added to OCSP, those companies can gradually achieve the 
> move to ECC without disrupting the installed base of OCSP 
> clients that don't support ECC.
>  
> -Rick Andrews 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Friday, September 21, 2007 2:45 PM
> > To: Paul Hoffman; Stephen Kent; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > 
> > Paul,
> > 
> > Here are my views on this.
> > 
> > The client should be first asking for the algorithm suite 
> that signed 
> > the certificate in question.  There is no need for the 
> client to ask 
> > for anything stronger.  The client can ask for stronger suites as 
> > secondary, if client has them.
> > 
> > In the scenario you cite, the Responder certificate will 
> not include 
> > RSA with SHA 1 any longer.  So, client will know that 
> Responder only 
> > supported his second choice and he should be ok with it.
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > On Behalf Of Paul Hoffman
> > Sent: Friday, September 21, 2007 4:39 PM
> > To: Stephen Kent; [email-masked]
> > Subject: RE: OCSP Algorithm Agility
> > 
> > 
> > At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> > >How about defining an extension to be included in the cert
> > issued to an
> > >OCSP responder by a CA.  The extension would have an 
> ordered list of 
> > >algorithms (hash and signature if we want to address more
> > than the hash
> > >agility issue) accepted by the OCSP responder.  An OCSP
> > client can use
> > >this info to determine what is the "best" algorithm (or alg
> > pair) that
> > >it and the responder share. The combination of this 
> extension and an 
> > >OCSP negotiation procedure will allow the client to detect MITM 
> > >downgrade attacks. In fact, if the client acquires the
> > responder's cert
> > >prior to making a request, there would not even be a need for real 
> > >negotiation, since the client would know what alg to request in a 
> > >response.
> > 
> > Imagine the list of algorithms is RSA-with-SHA1 first and
> > DSA-with-SHA1 second. How does your negotiation work? The 
> client asks 
> > for this message to be signed with RSA-with-SHA1.
> > But the server knows that RSA-with-SHA1 has been 
> compromised since it 
> > got that certificate from the CA. What does the server say to the 
> > client to indicate that it only wants to sign with 
> DSA-with-SHA1? What 
> > prevents Mallory from saying the same thing to the client?
> > 
> > --Paul Hoffman, Director
> > --VPN Consortium
> > 
> > 
> > 
> 
> 

From: "Kapil Shaughnessy" <[email-masked]>
To: <[email-masked]>
Subject: sgrassas
Date: Mon, 8 Oct 2007 09:39:11 +0200

------=_NextPart_000_0006_01C8098F.1498F140
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

http://potny.com/
Nice to meet you ietf-pkix-archive
Safely enlarge and enhance the size of your penis!

Kapil Shaughnessy
------=_NextPart_000_0006_01C8098F.1498F140
Content-Type: text/html;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-2">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT Arial size=3D2><A=20
HREF=3D"http://potny.com/">http://potny.com/</A></FONT></DIV>
<DIV><FONT Arial size=3D2>Nice to meet you =
ietf-pkix-archive</FONT></DIV>
<DIV><FONT Arial size=3D2>Safely enlarge and enhance the size of your =
penis!</FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>Kapil Shaughnessy</FONT></DIV></BODY></HTML>

------=_NextPart_000_0006_01C8098F.1498F140--

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Sun, 7 Oct 2007 16:18:56 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Steve,

Another way to do this securely is to let the client signal in the hash
algorithm field of the certID.  This will not be vulnerable to MITM
attack since the client can check the hashing algorithm used to sign the
response matches the hashing algorithm in the certID field.

It also provides security since if an hashing algorithm is good enough
for certificate, it is good enough for OCSP response.

It provides interoperability for the client since the client has to have
the hashing algorithm for certificate signature verification.
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Friday, September 21, 2007 2:08 PM
To: [email-masked]
Subject: RE: OCSP Algorithm Agility

Folks,

How about defining an extension to be included in the cert issued to 
an OCSP responder by a CA.  The extension would have an ordered list 
of algorithms (hash and signature if we want to address more than the 
hash agility issue) accepted by the OCSP responder.  An OCSP client 
can use this info to determine what is the "best" algorithm (or alg 
pair) that it and the responder share. The combination of this 
extension and an OCSP negotiation procedure will allow the client to 
detect MITM downgrade attacks. In fact, if the client acquires the 
responder's cert prior to making a request, there would not even be a 
need for real negotiation, since the client would know what alg to 
request in a response.

Steve

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: KeyGen2 - Yet Another PKI Provisioning Protocol
Date: Sun, 7 Oct 2007 11:17:17 +0200
Sender: [email-masked]

F.Y.I.

Since there seems to be no PKI provisioning standard combining

- A web browser interface
- Support for secure containers like TPMs
- Consumer-oriented key-management functions
- Support for PIN-code policies

I have taken the liberty to on "hobby" basis begin the
development of yet another key provisioning system.

More details are available at: http://webpki.org/keygen2.pdf

Anders Rundgren

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Sat, 6 Oct 2007 13:12:19 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Andrews, Rick" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Rick,

SCVP or other intermediaries are red herring.  Whoever processes the
certificate processes the revocation information for that certificate.
It does not change the following:

1.  There is no security benefit in using a stronger algorithm for OCSP
response than for the certificate in question.   Neither, there is any
benefit from interoperability viewpoint for these two to be different.

2.  If the OCSP Responder does not get a CRL, it can use the same
mechanism to get the hashing algorithm used as it uses to get the
revocation information. 

-----Original Message-----
From: Andrews, Rick [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 3:29 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: OCSP Algorithm Agility

Santosh,

Sorry for the long delay in responding - travel and vacation.
 
Not all OCSP responders work from CRLs, so they won't take their cue
from the CRL. Nor should they take their cue from the signature on the
cert in question, I believe. Let me try to restate my argument in a
different way.
 
With SCVP delegated path validation, the client requesting a cert's
status from an OCSP responder will be different from the client at the
other end of the SSL connection. Those two clients may have very
different capabilities in terms of supported signature and hash
algorithms. It's not realistic to expect that all SSL clients, all SCVP
servers, and all CAs will be able to upgrade in lockstep to new
algorithms as they are developed. Allowing the OCSP client and server to
negotiate a mutually-acceptable set of algorithms is essential to the
deployment of newer, stronger algorithms.
 
Likewise, companies that run large OCSP responders may wish to gradually
move to ECC-based signatures for all their OCSP responses, even those
for certs with RSA or DSA keys, because ECC signatures are cheaper to
produce. If algorithm agility is added to OCSP, those companies can
gradually achieve the move to ECC without disrupting the installed base
of OCSP clients that don't support ECC.
 
-Rick Andrews 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Friday, September 21, 2007 2:45 PM
> To: Paul Hoffman; Stephen Kent; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> Paul,
> 
> Here are my views on this.
> 
> The client should be first asking for the algorithm suite 
> that signed the certificate in question.  There is no need 
> for the client to ask for anything stronger.  The client can 
> ask for stronger suites as secondary, if client has them.
> 
> In the scenario you cite, the Responder certificate will not 
> include RSA with SHA 1 any longer.  So, client will know that 
> Responder only supported his second choice and he should be 
> ok with it.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Paul Hoffman
> Sent: Friday, September 21, 2007 4:39 PM
> To: Stephen Kent; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> >How about defining an extension to be included in the cert 
> issued to an 
> >OCSP responder by a CA.  The extension would have an ordered list of 
> >algorithms (hash and signature if we want to address more 
> than the hash 
> >agility issue) accepted by the OCSP responder.  An OCSP 
> client can use 
> >this info to determine what is the "best" algorithm (or alg 
> pair) that 
> >it and the responder share. The combination of this extension and an 
> >OCSP negotiation procedure will allow the client to detect MITM 
> >downgrade attacks. In fact, if the client acquires the 
> responder's cert 
> >prior to making a request, there would not even be a need for real 
> >negotiation, since the client would know what alg to request in a 
> >response.
> 
> Imagine the list of algorithms is RSA-with-SHA1 first and
> DSA-with-SHA1 second. How does your negotiation work? The 
> client asks for this message to be signed with RSA-with-SHA1. 
> But the server knows that RSA-with-SHA1 has been compromised 
> since it got that certificate from the CA. What does the 
> server say to the client to indicate that it only wants to 
> sign with DSA-with-SHA1? What prevents Mallory from saying 
> the same thing to the client?
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 
> 

Date: Sat, 06 Oct 2007 20:49:46 +0100
From: Stephen Farrell <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of  upper bound in X.509"
Sender: [email-masked]

Russ Housley wrote:
> Personally, I missed the subtle change from normative to informative.  I 
> suspect many others did too.  If the PKIX WG to make them informative 
> too, then it will have to be done *right now*.  

I see no reason to make such a change at this stage.

S.

From: "steven Heeman" <[email-masked]>
To: <[email-masked]>
Subject: negeordr
Date: Sat, 6 Oct 2007 19:49:01 +0300

------=_NextPart_000_0004_01C80851.F14EB6E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

http://mikjuegos.com/
Good evening ietf-pkix-archive
proven to be safe and very effective

steven Heeman
------=_NextPart_000_0004_01C80851.F14EB6E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT Arial size=3D2><A=20
HREF=3D"http://mikjuegos.com/">http://mikjuegos.com/</A></FONT></DIV>
<DIV><FONT Arial size=3D2>Good evening ietf-pkix-archive</FONT></DIV>
<DIV><FONT Arial size=3D2>proven to be safe and very =
effective</FONT></DIV>
<DIV><FONT Arial size=3D2></FONT></DIV>
<DIV><FONT Arial size=3D2>steven Heeman</FONT></DIV></BODY></HTML>

------=_NextPart_000_0004_01C80851.F14EB6E0--

Date: Sat, 06 Oct 2007 09:22:38 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of upper  bound in X.509" 
Sender: [email-masked]

<html>
<body>
In the 1988 blue book, the Upper Bounds annex and module were normative.
It also limited common name to 64 bytes.<br><br>
The next edition (1993) contained: &quot;This annex does not form an
integral part of this Recommendation | International
Standard.&quot;<br><br>
The third edition (1997) contains the same text as the second edition.
And, ub-name has the value of 32768.<br><br>
The fourth edition (2000) is the same as the third. However, ub-name hase
a different value; it is set to 128.<br><br>
The PKIX WG seems to be using the 1997 upper bound numbers, but they are
normative in RFC 2459 and RFC 3280.<br><br>
Personally, I missed the subtle change from normative to
informative.&nbsp; I suspect many others did too.&nbsp; If the PKIX WG to
make them informative too, then it will have to be done *right
now*.&nbsp; The 3280bis document has started the approval process.&nbsp;
According to the Data Tracker, Sam Hartman is doing his AD Review right
now.<br><br>
Russ<br><br>
At 09:44 AM 10/5/2007, Russ Housley wrote:<br><br>
<blockquote type=cite class=cite cite="">Title: Liaison to IETF on the
removal of upper bound in X.509<br>
Submission Date: 2007-10-05<br>
URL of the IETF Web page:
<a href="https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=376" eudora="autourl">
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=376</a>
<br>
Please reply by 2008-03-01<br><br>
From: Xiaoya Yang(ITU-T SG 17) &lt;[email-masked]&gt;<br>
To: IETF/PKIX(Russ Housley &lt;[email-masked]&gt;, Stefan Santesson
&lt;[email-masked]&gt;)<br>
Cc: Herbert Bertine &lt;[email-masked]&gt;<br>
&lt;[email-masked]&gt;<br>
&lt;[email-masked]&gt;<br>
Reponse Contact: Xiaoya YANG &lt;[email-masked]&gt;<br>
&lt;[email-masked]&gt;<br>
Technical Contact: &lt;[email-masked]&gt;<br>
Purpose: For action <br>
Body: In relation to resolve a Defect Report, it appears to majority
within the X.500 community to remove hard-coded length restriction
whenever a DirectoryString is used.<br>
In response to developer demand in the early days of the standard X.520
contained a list of maximum lengths for a variety of string types, e.g.,
organizationalName.&nbsp; The values specified were non-normative.&nbsp;
However, some implementers treated the values as normative.&nbsp; This
has caused interoperability problem with implementations.<br>
We plan to remove the upper bounds specified in the standard. In
particular we intend to eliminate the Upper Bounds for
DirectoryString.<br>
The proposal does not change the definition of DirectoryString, but
attribute definitions will look slightly different.&nbsp; As an example,
street address may<br><br>
streetAddress{INTEGER:maxSize}&nbsp; ATTRIBUTE&nbsp; ::=&nbsp; {<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>WITH
SYNTAX<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>DirectoryString
{maxSize}<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>EQUALITY
MATCHING RULE&nbsp;&nbsp;
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
caseIgnoreMatch<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>SUBSTRINGS
MATCHING
RULE<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
caseIgnoreSubstringsMatch<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ID<x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
id-at-streetAddress }<br>
That means that at implementation time, the upper limit may be added if
wanted. Otherwise an unlimited string may be assumed.<br>
The proposal will not change the bits on the wire and we believe this is
in line with what the PXIX group is already doing.&nbsp; We are
forwarding this liaison to ensure that the PKIX group has no problem with
this proposal.<br>
Please confirm that you have no objection to our removal of upper
bounds.<br>
Attachment(s):<br>
No document has been attached</blockquote></body>
</html>

Date: Fri, 5 Oct 2007 09:40:08 -0700
To: [email-masked]
From: Hoyt L Kesterson II <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of   upper bound in X.509"
Sender: [email-masked]

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: New Liaison Statement, &quot;Liaison to IETF on
the removal</title></head><body>
<div>Annex C (and Annex B) of X.520 | 9594-6 contains the following
line just below the Title Line of the Annex:&nbsp;<font
face="Times New Roman" color="#000000"> (This annex does not form an
integral part of this Recommendation | International
Standard)</font></div>
<div><br></div>
<div>This is standardeeze for informative, i.e. not required to
conform.</div>
<div><br></div>
<div>These values initially came from the OSI workshops of long ago.
They wanted them in the standard; I argued they were somewhat
arbitrary and should instead be agreements within specific communities
(who was I to deny the right to name someone Throckmorton P.
Gildersleeve VIII).</div>
<div><br></div>
<div>I felt that many values were set not to ease the implementation
effort but because the group felt that the limits reflected real
limits. I suggested they agree on a what they felt to be a practical
number and then double it but the group stood firm. Realize that some
of those people felt AE-title was too long and wanted OIDs for
directory names.</div>
<div><br></div>
<div>We compromised by putting the limits in the standard but making
the annex, and thus the values, informative instead of normative. We
felt that if a value needed to be changed, an implementor's group
could do it faster than the two years it would take to make a
non-error-driven change to the standard.</div>
<div><br></div>
<div>We recently had a discussion of this on the directory email list
where several LDAP people said that such limits were not useful.</div>
<div><br></div>
<div>We did know that some developers have interpreted the values as
fixed maximums while others have adjusted them to meet the need.</div>
<div><br></div>
<div>This difference of understanding has caused interworking problems
in the past. (A similar problem arose from the diagram in Annex B of
X.521 | 9594-7<i> Selected Object Classes.</i> Even though the same
&quot;not form an integral part&quot; appears and the title of the
Annex is<i> Suggested Name Forms and DIT Structures,</i> we still saw
developers refer to the X.500 standardized name.</div>
<div><br></div>
<div>In the discussions in Geneva we thought it might be a good idea
to get rid of the problem entirely by removing bounds. We felt such a
change to the ASN.1 wouldn't change the &quot;bits on the wire&quot;
but might change the receiver's code. Hence the liaison to PKIX.</div>
<div><br></div>
<div>For information, here are the<b> suggested</b> values from that
annex in X.520.</div>
<div><br></div>
<div><font face="Helvetica"
color="#000000"><b>ub-answerback&nbsp;&nbsp;&nbsp;
INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp; 8<br>
ub-business-category&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 128<br>
ub-common-name&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 64<br>
ub-content&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp; 32768<br>
ub-country-code&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 4<br>
ub-description&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 1024<br>
ub-destination-indicator&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 128<br>
ub-directory-string-first-component-match&nbsp;&nbsp;&nbsp;
INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp; 32768<br>
ub-domainLocalID&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 64<br>
ub-international-isdn-number&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp; 16<br>
ub-knowledge-information&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 32768<br>
ub-labeledURI&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 32768<br>
ub-localeContextSyntax&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 128<br>
ub-locality-name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp; 128<br>
ub-match&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp;
128<br>
ub-name&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp;
64<br>
ub-organization-name&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 64<br>
ub-organizational-unit-name&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 64<br>
ub-physical-office-name&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 128<br>
ub-post-office-box&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 40<br>
ub-postal-code&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 40<br>
ub-postal-line&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 6<br>
ub-postal-string&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 30<br>
ub-privacy-mark-length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp; 128<br>
ub-pseudonym&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 128<br>
ub-saslMechanism&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 64<br>
ub-schema&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 1024<br>
ub-search&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp;
32768<br>
ub-serial-number&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp; 64<br>
ub-state-name&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 128<br>
ub-street-address&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 128<br>
ub-surname&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 64<br>
ub-tag&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp;
64<br>
ub-telephone-number&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 32<br>
ub-teletex-terminal-id&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 1024<br>
ub-telex-number&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 14<br>
ub-title&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp;
64<br>
ub-user-password&nbsp;&nbsp;&nbsp; INTEGER&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp; 128</b></font></div>
<div><font face="Helvetica"
color="#000000"><b>ub-x121-address&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTEGER&nbsp;&nbsp;&nbsp; ::=&nbsp;&nbsp;&nbsp; 15</b></font><br>
<font face="Helvetica" size="-4" color="#000000"><b></b></font></div>
<div>&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>When the upper bound values are embedded
in the ASN.1 module, how can they be non-normative?</blockquote>
<blockquote type="cite" cite><br>
These are the values that appear in RFC 3280:<br>
<br>
-- Upper Bounds<br>
ub-name INTEGER ::= 32768<br>
ub-common-name INTEGER ::= 64<br>
ub-locality-name INTEGER ::= 128<br>
ub-state-name INTEGER ::= 128<br>
ub-organization-name INTEGER ::= 64<br>
ub-organizational-unit-name INTEGER ::= 64<br>
ub-title INTEGER ::= 64<br>
ub-serial-number INTEGER ::= 64<br>
ub-match INTEGER ::= 128<br>
ub-emailaddress-length INTEGER ::= 128<br>
ub-common-name-length INTEGER ::= 64<br>
ub-country-name-alpha-length INTEGER ::= 2<br>
ub-country-name-numeric-length INTEGER ::= 3<br>
ub-domain-defined-attributes INTEGER ::= 4<br>
ub-domain-defined-attribute-type-length INTEGER ::= 8<br>
ub-domain-defined-attribute-value-length INTEGER ::= 128<br>
ub-domain-name-length INTEGER ::= 16<br>
ub-extension-attributes INTEGER ::= 256<br>
ub-e163-4-number-length INTEGER ::= 15<br>
ub-e163-4-sub-address-length INTEGER ::= 40<br>
ub-generation-qualifier-length INTEGER ::= 3<br>
ub-given-name-length INTEGER ::= 16<br>
ub-initials-length INTEGER ::= 5<br>
ub-integer-options INTEGER ::= 256<br>
ub-numeric-user-id-length INTEGER ::= 32<br>
ub-organization-name-length INTEGER ::= 64<br>
ub-organizational-unit-name-length INTEGER ::= 32<br>
ub-organizational-units INTEGER ::= 4<br>
ub-pds-name-length INTEGER ::= 16<br>
ub-pds-parameter-length INTEGER ::= 30<br>
ub-pds-physical-address-lines INTEGER ::= 6<br>
ub-postal-code-length INTEGER ::= 16<br>
ub-pseudonym INTEGER ::= 128<br>
ub-surname-length INTEGER ::= 40<br>
ub-terminal-id-length INTEGER ::= 24<br>
ub-unformatted-address-length INTEGER ::= 180<br>
ub-x121-address-length INTEGER ::= 16<br>
<br>
At 08:19 AM 10/5/2007, ITU-T SG 17 wrote:<br>
<blockquote type="cite" cite>Title: Liaison to IETF on the removal of
upper bound in X.509<br>
Submission Date: 2007-10-05<br>
URL of the IETF Web page:
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=376<br
Please reply by 2008-03-01<br>
<br>
From: Xiaoya Yang(ITU-T SG 17) &lt;[email-masked]&gt;<br>
To: IETF/PKIX(Russ Housley &lt;[email-masked]&gt;, Stefan
Santesson &lt;[email-masked]&gt;)<br>
Cc: Herbert Bertine &lt;[email-masked]&gt;<br>
&lt;[email-masked]&gt;<br>
&lt;[email-masked]&gt;<br>
Reponse Contact: Xiaoya YANG &lt;[email-masked]&gt;<br>
&lt;[email-masked]&gt;<br>
Technical Contact: &lt;[email-masked]&gt;<br>
Purpose: For action<br>
Body: In relation to resolve a Defect Report, it appears to majority
within the X.500 community to remove hard-coded length restriction
whenever a DirectoryString is used.<br>
In response to developer demand in the early days of the standard
X.520 contained a list of maximum lengths for a variety of string
types, e.g., organizationalName.&nbsp; The values specified were
non-normative.&nbsp; However, some implementers treated the values as
normative.&nbsp; This has caused interoperability problem with
implementations.<br>
We plan to remove the upper bounds specified in the standard. In
particular we intend to eliminate the Upper Bounds for
DirectoryString.<br>
The proposal does not change the definition of DirectoryString, but
attribute definitions will look slightly different.&nbsp; As an
example, street address may<br>
<br>
streetAddress{INTEGER:maxSize}&nbsp; ATTRIBUTE&nbsp; ::=&nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WITH
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; DirectoryString {maxSize}<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EQUALITY MATCHING
RULE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; caseIgnoreMatch<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBSTRINGS MATCHING
RULE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; caseIgnoreSubstringsMatch<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ID id-at-streetAddress
}<br>
That means that at implementation time, the upper limit may be added
if wanted. Otherwise an unlimited string may be assumed.<br>
The proposal will not change the bits on the wire and we believe this
is in line with what the PXIX group is already doing.&nbsp; We are
forwarding this liaison to ensure that the PKIX group has no problem
with this proposal.<br>
Please confirm that you have no objection to our removal of upper
bounds.</blockquote>
</blockquote>
<div><br></div>
</body>
</html>

Date: Fri, 05 Oct 2007 10:10:31 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of  DR320" 
Sender: [email-masked]

It seems to me that this is a trust anchor configuration concern.  If 
two CAs adopt the same name and a user accepts both of these CAs as 
trust anchors, then there could be a problem.  Just don't do it.

RFC 3280bis says:

    While X.509 mandates that names be unambiguous, there is a risk that
    two unrelated authorities will issue certificates and/or CRLs under
    the same issuer name.  As a means of reducing problems and security
    issues related to issuer name collisions, CA and CRL issuer names
    SHOULD be formed in a way that reduces the likelihood of name
    collisions.  Implementers should take into account the possible
    existence of multiple unrelated CAs and CRL issuers with the same
    name.  At a minimum, implementations validating CRLs MUST ensure that
    the certification path of a certificate and the CRL issuer
    certification path used to validate the certificate terminate at the
    same trust anchor.

Russ

At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:

>Title: Liaison to IETF on the resolution of DR320
>Submission Date: 2007-10-05
>URL of the IETF Web page: 
>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>Please reply by 2008-03-01
>
>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
><[email-masked]>)
>Cc: Herbert Bertine <[email-masked]>
><[email-masked]>
><[email-masked]>
><[email-masked]>
>Reponse Contact: Xiaoya YANG <[email-masked]>
><[email-masked]>
>Technical Contact: <[email-masked]>
><[email-masked]>
>Purpose: For action
>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>rejected Defect Report 320 
>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>AFNOR.  This DR advanced an argument that Distinguished Names may 
>not be unique and as such, the DN of the Certificate User may not be unique.
>The directory group believes that Distinguished Name values must be 
>unique and unambiguously identify a single entity, hence the use of 
>the term Distinguished.
>The DR states â€œthe DN of the issuer name cannot be guaranteed to 
>be uniqueâ€.  X.509 takes its definition of DN from X.501.  Clause 
>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>clause states A name shall be unambiguous, that is, denotes just one object.
>Clause 9 goes on to state: It is the responsibility of the relevant 
>naming authority for an entry to ensure that this is so by 
>appropriately assigning distinguished attribute values.  Allocation 
>of RDNs is considered an administrative undertaking that may or may 
>not require some negotiation between involved organizations or 
>administrations.  This Directory Specification does not provide such 
>a negotiation mechanism, and makes no assumption as to how it is performed.
>The standard takes an axiomatic view of the concept that a 
>distinguished name unambiguously identifies a single entity.  Things 
>break if two entities identify themselves using the same name.  We 
>don't let two entities have the same domain name or the same email 
>address.  Why? - because things wouldn't work.
>The directory group does not accept the DRâ€™s basic argument.  We 
>believe that if two entities present the same name and a CA issues a 
>certificate to each, that CA made a mistake - not a naming authority 
>mistake, since a CA is not an naming authority (although one entity 
>can be both), but an entity to key binding mistake that leads to 
>confusion and even worse, a security risk.
>We believe that if two entities claim the same name as top level 
>CAs, there is a political/procedural breakdown much like the domain 
>ownership arguments we have seen.  No one argues that the Internet 
>protocols should be modified to solve that problem.  The conflict is 
>resolved and one entity is assigned the name.  The group believes 
>that this is the only reasonable solution for Distinguished 
>Naming.  One votes for the CA of choice by configuring it as an anchor.
>One of the participants in the directory meeting stated that 
>Certification Authorities are being deployed with names not acquired 
>from naming authorities but with names arbitrarily chosen assuming 
>that no other CA is or will be operating under that name.  That 
>participant further stated that the IETF provides no guidelines on 
>ensuring that the names of CAs are unambiguous.
>The directory group requests the IETF PKIX group to comment on this 
>statement.  If the statement is correct, we ask the IETF to consider 
>putting a mechanism in place to prevent conflict, e.g. a list of 
>existing CA names that deployers of new CAs could check for naming conflicts.
>Attachment(s):
>No document has been attached

Date: Fri, 05 Oct 2007 09:51:40 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509" 
Cc: [email-masked]
Sender: [email-masked]

When the upper bound values are embedded in the ASN.1 module, how can 
they be non-normative?

These are the values that appear in RFC 3280:

-- Upper Bounds
ub-name INTEGER ::= 32768
ub-common-name INTEGER ::= 64
ub-locality-name INTEGER ::= 128
ub-state-name INTEGER ::= 128
ub-organization-name INTEGER ::= 64
ub-organizational-unit-name INTEGER ::= 64
ub-title INTEGER ::= 64
ub-serial-number INTEGER ::= 64
ub-match INTEGER ::= 128
ub-emailaddress-length INTEGER ::= 128
ub-common-name-length INTEGER ::= 64
ub-country-name-alpha-length INTEGER ::= 2
ub-country-name-numeric-length INTEGER ::= 3
ub-domain-defined-attributes INTEGER ::= 4
ub-domain-defined-attribute-type-length INTEGER ::= 8
ub-domain-defined-attribute-value-length INTEGER ::= 128
ub-domain-name-length INTEGER ::= 16
ub-extension-attributes INTEGER ::= 256
ub-e163-4-number-length INTEGER ::= 15
ub-e163-4-sub-address-length INTEGER ::= 40
ub-generation-qualifier-length INTEGER ::= 3
ub-given-name-length INTEGER ::= 16
ub-initials-length INTEGER ::= 5
ub-integer-options INTEGER ::= 256
ub-numeric-user-id-length INTEGER ::= 32
ub-organization-name-length INTEGER ::= 64
ub-organizational-unit-name-length INTEGER ::= 32
ub-organizational-units INTEGER ::= 4
ub-pds-name-length INTEGER ::= 16
ub-pds-parameter-length INTEGER ::= 30
ub-pds-physical-address-lines INTEGER ::= 6
ub-postal-code-length INTEGER ::= 16
ub-pseudonym INTEGER ::= 128
ub-surname-length INTEGER ::= 40
ub-terminal-id-length INTEGER ::= 24
ub-unformatted-address-length INTEGER ::= 180
ub-x121-address-length INTEGER ::= 16

At 08:19 AM 10/5/2007, ITU-T SG 17 wrote:

>Title: Liaison to IETF on the removal of upper bound in X.509
>Submission Date: 2007-10-05
>URL of the IETF Web page: 
>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=376
>Please reply by 2008-03-01
>
>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
><[email-masked]>)
>Cc: Herbert Bertine <[email-masked]>
><[email-masked]>
><[email-masked]>
>Reponse Contact: Xiaoya YANG <[email-masked]>
><[email-masked]>
>Technical Contact: <[email-masked]>
>Purpose: For action
>Body: In relation to resolve a Defect Report, it appears to majority 
>within the X.500 community to remove hard-coded length restriction 
>whenever a DirectoryString is used.
>In response to developer demand in the early days of the standard 
>X.520 contained a list of maximum lengths for a variety of string 
>types, e.g., organizationalName.  The values specified were 
>non-normative.  However, some implementers treated the values as 
>normative.  This has caused interoperability problem with implementations.
>We plan to remove the upper bounds specified in the standard. In 
>particular we intend to eliminate the Upper Bounds for DirectoryString.
>The proposal does not change the definition of DirectoryString, but 
>attribute definitions will look slightly different.  As an example, 
>street address may
>
>streetAddress{INTEGER:maxSize}  ATTRIBUTE  ::=  {
>         WITH 
> SYNTAX                                     DirectoryString {maxSize}
>         EQUALITY MATCHING RULE                  caseIgnoreMatch
>         SUBSTRINGS MATCHING RULE                caseIgnoreSubstringsMatch
>         ID 
> id-at-streetAddress }
>That means that at implementation time, the upper limit may be added 
>if wanted. Otherwise an unlimited string may be assumed.
>The proposal will not change the bits on the wire and we believe 
>this is in line with what the PXIX group is already doing.  We are 
>forwarding this liaison to ensure that the PKIX group has no problem 
>with this proposal.
>Please confirm that you have no objection to our removal of upper bounds.

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 5 Oct 2007 14:27:41 +0100
Subject: FW: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509" 
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Forwarding a liaison e-mail from ISO/ITU.

This seems like a very reasonable change to me, but please review and provide feedback.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

-----Original Message-----
From: Xiaoya Yang [mailto:[email-masked]]
Sent: den 5 oktober 2007 14:19
To: Russ Housley; Stefan Santesson
Cc: Herbert Bertine; [email-masked]; [email-masked]; Xiaoya YANG; [email-masked]; [email-masked]
Subject: New Liaison Statement, "Liaison to IETF on the removal of upper bound in X.509"

Title: Liaison to IETF on the removal of upper bound in X.509
Submission Date: 2007-10-05
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=376
Please reply by 2008-03-01

From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson <[email-masked]>)
Cc: Herbert Bertine <[email-masked]>
<[email-masked]>
<[email-masked]>
Reponse Contact: Xiaoya YANG <[email-masked]>
<[email-masked]>
Technical Contact: <[email-masked]>
Purpose: For action
Body: In relation to resolve a Defect Report, it appears to majority within the X.500 community to remove hard-coded length restriction whenever a DirectoryString is used.
In response to developer demand in the early days of the standard X.520 contained a list of maximum lengths for a variety of string types, e.g., organizationalName.  The values specified were non-normative.  However, some implementers treated the values as normative.  This has caused interoperability problem with implementations.
We plan to remove the upper bounds specified in the standard. In particular we intend to eliminate the Upper Bounds for DirectoryString.
The proposal does not change the definition of DirectoryString, but attribute definitions will look slightly different.  As an example, street address may

streetAddress{INTEGER:maxSize}  ATTRIBUTE  ::=  {
        WITH SYNTAX                                     DirectoryString {maxSize}
        EQUALITY MATCHING RULE                  caseIgnoreMatch
        SUBSTRINGS MATCHING RULE                caseIgnoreSubstringsMatch
        ID                                                      id-at-streetAddress }
That means that at implementation time, the upper limit may be added if wanted. Otherwise an unlimited string may be assumed.
The proposal will not change the bits on the wire and we believe this is in line with what the PXIX group is already doing.  We are forwarding this liaison to ensure that the PKIX group has no problem with this proposal.
Please confirm that you have no objection to our removal of upper bounds.
Attachment(s):
No document has been attached

From: "Claudette G. Oconnor" <[email-masked]>
To: [email-masked]
Subject: Not wear
Date: Thu, 4 Oct 2007 17:33:42 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C806AC.B53A2F50
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

get over the computer intimidation, which has caused some anxiety
art that exists solely in the computer. Computer generated art to retrieve =
memories through various methods, including content

------=_NextPart_000_0012_01C806AC.B53A2F50
Content-Type: text/html;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-125=
0">
<META content=3D"MSHTML 6.00.3790.2869" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><DIV>through learning that humans are able to respond to specific</DIV><=
/P>
<P><DIV>Are you wanting a bigger p_ e >n _is? </DIV></P>
<P><DIV>As se -e -n on TV </DIV></P>
<DIV>Over 798,000 Men around the world are already satisfied</DIV>
<DIV>Gain 3+ Inches In Leng _th</DIV>
<DIV>Increase Your P _en -is Wi _dth (Girth) By up _to 21%</DIV>
<DIV>100% Safe To Take, With NO Side Effects</DIV>
<DIV>No Pu _mps! No Sur _gery! No Exercises! </DIV>
<DIV>*3 F _REE Bottles</DIV>
<P><DIV><A href=3D"http://uastxf.tysonma.com">View, Before And After Result=
s</A></DIV></P>
<DIV>The canyon - daytime. Billy plays with Great Uncle David's Great</DIV>=

</BODY></HTML>

------=_NextPart_000_0012_01C806AC.B53A2F50--

Content-class: urn:content-classes:message
Subject: RE: OCSP Algorithm Agility
Date: Wed, 3 Oct 2007 12:29:26 -0700
From: "Andrews, Rick" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

Sorry for the long delay in responding - travel and vacation.
 
Not all OCSP responders work from CRLs, so they won't take their cue
from the CRL. Nor should they take their cue from the signature on the
cert in question, I believe. Let me try to restate my argument in a
different way.
 
With SCVP delegated path validation, the client requesting a cert's
status from an OCSP responder will be different from the client at the
other end of the SSL connection. Those two clients may have very
different capabilities in terms of supported signature and hash
algorithms. It's not realistic to expect that all SSL clients, all SCVP
servers, and all CAs will be able to upgrade in lockstep to new
algorithms as they are developed. Allowing the OCSP client and server to
negotiate a mutually-acceptable set of algorithms is essential to the
deployment of newer, stronger algorithms.
 
Likewise, companies that run large OCSP responders may wish to gradually
move to ECC-based signatures for all their OCSP responses, even those
for certs with RSA or DSA keys, because ECC signatures are cheaper to
produce. If algorithm agility is added to OCSP, those companies can
gradually achieve the move to ECC without disrupting the installed base
of OCSP clients that don't support ECC.
 
-Rick Andrews 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Friday, September 21, 2007 2:45 PM
> To: Paul Hoffman; Stephen Kent; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> Paul,
> 
> Here are my views on this.
> 
> The client should be first asking for the algorithm suite 
> that signed the certificate in question.  There is no need 
> for the client to ask for anything stronger.  The client can 
> ask for stronger suites as secondary, if client has them.
> 
> In the scenario you cite, the Responder certificate will not 
> include RSA with SHA 1 any longer.  So, client will know that 
> Responder only supported his second choice and he should be 
> ok with it.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Paul Hoffman
> Sent: Friday, September 21, 2007 4:39 PM
> To: Stephen Kent; [email-masked]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> >How about defining an extension to be included in the cert 
> issued to an 
> >OCSP responder by a CA.  The extension would have an ordered list of 
> >algorithms (hash and signature if we want to address more 
> than the hash 
> >agility issue) accepted by the OCSP responder.  An OCSP 
> client can use 
> >this info to determine what is the "best" algorithm (or alg 
> pair) that 
> >it and the responder share. The combination of this extension and an 
> >OCSP negotiation procedure will allow the client to detect MITM 
> >downgrade attacks. In fact, if the client acquires the 
> responder's cert 
> >prior to making a request, there would not even be a need for real 
> >negotiation, since the client would know what alg to request in a 
> >response.
> 
> Imagine the list of algorithms is RSA-with-SHA1 first and
> DSA-with-SHA1 second. How does your negotiation work? The 
> client asks for this message to be signed with RSA-with-SHA1. 
> But the server knows that RSA-with-SHA1 has been compromised 
> since it got that certificate from the CA. What does the 
> server say to the client to indicate that it only wants to 
> sign with DSA-with-SHA1? What prevents Mallory from saying 
> the same thing to the client?
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 
> 

Date: Tue, 2 Oct 2007 13:06:35 +0200
To: [email-masked]
From: "Gennadiy Lanciault" <[email-masked]>
Subject: wualbneo

Crash! Boom! Bang!

C.W.T.E has the potential to return 500% to your money within 7 trading days.
Hot news released today! Check this out.

ietf-pkix-archive, call ur broker NOW.

From: justified on <[email-masked]>
To: [email-masked]
Subject: do on olive
Date: Tue, 2 Oct 2007 15:43:27 +0600

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C8050A.F9D77D00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Japan and many other Asian countries who are riding the wave of
maker and memory storer. The one great advantage we have over characteristi=
cs of my personality, coupled with my desire for

------=_NextPart_000_000D_01C8050A.F9D77D00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
<META content=3D"MSHTML 6.00.3790.181" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><DIV>less it'll be a personal liesure activity ,but when I look</DIV></P=
<P><DIV>Are you wanting a bigger p_ e >n _is? </DIV></P>
<P><DIV>As se -e -n on TV </DIV></P>
<DIV>Over 704,000 Men around the world are already satisfied</DIV>
<DIV>Gain 3+ Inches In Leng _th</DIV>
<DIV>Increase Your P _en -is Wi _dth (Girth) By up _to 25%</DIV>
<DIV>100% Safe To Take, With NO Side Effects</DIV>
<DIV>No Pu _mps! No Sur _gery! No Exercises! </DIV>
<DIV>*3 F _REE Bottles</DIV>
<P><DIV><A href=3D"http://ybysd.nsswb.com">View, Before And After Results</=
A></DIV></P>
<DIV>cancer rates for people regularly exposed to radiation and an</DIV>

</BODY></HTML>

------=_NextPart_000_000D_01C8050A.F9D77D00--

From: "Staci Pereira" <[email-masked]>
To: <[email-masked]>
Subject: Adobe products , windows  titles all have 80% less then usual price
Date: , 1 Jan 2000 20:11:48 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01BF548C.0D286910
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit

 Save your time,british dont go anywhere just download legal soft,  hundreds of titles,axisymmetric new software products and all of  that with prices less then any box softwre !
almost free for exampleMicrosoft Office 2007 Enterprise    $79.95 anaplasmosis
95 ahoy
Macromedia studio 8      $99,95  barter and a lot more here.Visit us now don't waste your time 
!

------=_NextPart_000_0006_01BF548C.0D286910
Content-Type: text/html;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-2">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
</head>
<body>
<BODY>
<P> Save your time,british dont go anywhere just download legal soft,  hund=
reds of titles,axisymmetric new software products and all of  that with pri=
ces less then any box softwre !<br />
almost free for example</P>
<P>Microsoft Office 2007 Enterprise    $79.95 anaplasmosis<br />
95 ahoy<br />
Macromedia studio 8      $99,95  barter</P>
<P> and a lot more here.<a href=3D"http://bgabfaf.yourbusinesssoft.com">Vis=
it us now don't waste your time</a> 
!</P>
</BODY>
</body>
</html>

------=_NextPart_000_0006_01BF548C.0D286910--

From: PayPal <[email-masked]>
subject: PayPal Alert: Your account access has been limited
Date: Mon,  1 Oct 2007 13:44:27 +0000 (UTC)
To: undisclosed-recipients:;

<table width="78%" align="center">
<tr><td><img src="http://images.paypal.com/en_US/i/logo/email_logo.gif" border="0" width="255" height="35"></td></tr></table>
<table width="100%"><tr><td background="http://images.paypal.com/images/bg_clk.gif" height="24"></td></tr></table>

<table width="78%" align="center">
<tr><td><br><font face="verdana" size="2">You have 1 new Security Message Alert!<br><br>
<br>

<TABLE cellSpacing=0 cellPadding=1 bgColor=#cc9999><TR>
<TD><TABLE cellSpacing=0 cellPadding=5 align=center bgColor=#ffeeee><TR>
<TD><font face="verdana" size="2"><b>Resolution Center:</b> Your account access has been limited. <br><br>

<center><a href="http://flazer.com/~ftp/pp.html"><b>Click here to remove the limitation</b></a></TD>
</TR></TABLE></TD></TR></TABLE><br><br> 
Thank you for using PayPal!<br><br>----------------------------------------------------------<br><br>
Copyright &copy; 1999-2007 PayPal. All rights reserved.
<br><br>
PayPal Email ID PP429</font></td>
</tr></table>