RE: Status of domain-certs-01 and sip-eku-02

[Stephen Kent <[e-mail]>]

At 3:08 PM -0400 7/29/08, Tim Moses wrote:
>Hi Steve.  I was thinking that a new SAN type-id may be a suitable way of
>indicating that the certificate's subject may not identify a namespace that
>includes the name of the server (the authorized SIP Proxy) to which you are
>directly connected, but rather one that includes the name of another server;
>the one that vouches for the SIP proxy.
>
>Syntactically, it's a URI, but semantically it's different from the usual
>SAN URI option.
>
>Just a thought.
>
>All the best.  Tim.

Tim,

I think the discussions on the PKIX list came to the conclusion that 
the EKU semantics for this SIP context are OK, i.e., they are not 
inconsistent with other EKUs we have published.  If SIP decides that 
it also wants to use a new type-id to further reinforce the notion, 
that's obviously OK too.

Steve




Received: from [218.6.216.32] ([218.6.216.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VNRfZO036490 for <[e-mail]>; Thu, 31 Jul 2008 16:27:42 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Oxygen bottle damages Qantas aircraft
From:   Lennon <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Sat, 2 Aug 2008 07:27:16 +0800
Message-ID: <oz.qpgsjjityhywfl@031>
User-Agent: Opera Mail/9.50 (Win32)

Hillary admits she was wrong
http://www.sapristiestudio.com/livestreaming.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from kkdfrcb ([41.17.232.62]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6VF40H8000558 for <[e-mail]>; Thu, 31 Jul 2008 08:04:01 -0700 (MST) (envelope-from [e-mail])
Received: from [198.125.83.222] (helo=dld) by kkdfrcb with smtp (Exim 4.62 (FreeBSD)) id 1KOZj0-0001kJ-KJ; Thu, 31 Jul 2008 17:05:54 +0200
Message-ID: <001a01c8f31e$a9245c40$de537dc6@dld>
From: <[e-mail]>
To: <[e-mail]>
Subject: FBI watching us
Date: Thu, 31 Jul 2008 16:57:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Get Facebook's F.B.I. Files http://GoodNewsGames.com/



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VEMqvF097499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 07:22:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6VEMqDm097498; Thu, 31 Jul 2008 07:22:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VEMpuQ097491 for <[e-mail]>; Thu, 31 Jul 2008 07:22:52 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.17.6.236]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KOZ3L-0006OC-Dt for [e-mail]; Thu, 31 Jul 2008 10:22:51 -0400
Mime-Version: 1.0
Message-Id: <p06240511c4b779708bf9@[172.17.6.236]>
Date: Thu, 31 Jul 2008 10:17:08 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re; WGLC for draft-ietf-pkix-rfc4055-update-01.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The interval for this WGLC has completed (a few days ago) and there 
were no more comments requiring changes, so this document has Wg 
approval and will be forwarded to the IESG in August.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VDsBfB095280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 06:54:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6VDsBlV095279; Thu, 31 Jul 2008 06:54:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6VDsAAs095271 for <[e-mail]>; Thu, 31 Jul 2008 06:54:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 8192 invoked from network); 31 Jul 2008 13:42:40 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Jul 2008 13:42:40 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Jul 2008 13:42:39 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F314.E79040E0"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Inhibit Any-Policy extension
Date: Thu, 31 Jul 2008 09:54:08 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Inhibit Any-Policy extension
Thread-Index: AcjzFF4fgjE+GiMRQwq8wY8+b8uA2gAADBjQ
References: <001701c8f1ad$c53ee9d0$4fbcbd70$@com> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Peter Hesse" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F314.E79040E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Russ,

=20

I do not recall the list having a discussion on this.

=20

Besides, I am not saying revise 5280.

=20

I am stating what is prudent and am providing the rationale for it.

=20

Technical accuracy is not a matter of consensus, no matter how big the
group is or who is in it.  It is a matter of sound logic.

=20

________________________________

From: Russ Housley [mailto:[e-mail]]=20
Sent: Thursday, July 31, 2008 9:50 AM
To: Santosh Chokhani; Peter Hesse; [e-mail]
Subject: RE: Inhibit Any-Policy extension

=20

Santosh:

I disagree.  Given that RFC 5280 (and RFC 3280 before that) had
consensus , I see no reason to revisit the discussion.

Russ

At 04:13 PM 7/30/2008, Santosh Chokhani wrote:



Russ,
=20
Making inhibit anyPolicy non-critical is desirable, RFC 5280
notwithstanding.
=20
Inhibit anyPolicy extension was added late to the policy related
extensions in X.509.  Many clients do not support it.  Making this
extension non-critical should let you have your cake and eat it to.
Below is the rationale.
=20
The clients that recognize the extension must enforce it regardless of
criticality.  These clients will securely process the extension.
=20
The clients that do not recognize the extension are also not likely to
recognize the special OID of anyPolicy that was created in conjunction
with it and hence not processing the extension will be a wash, skipCerts
> 0 notwithstanding, which most PKIs do not do.

________________________________

From: [e-mail] [ mailto:[e-mail]
<mailto:[e-mail]> ] On Behalf Of Russ Housley
Sent: Wednesday, July 30, 2008 5:45 AM
To: Peter Hesse; [e-mail]
Subject: Re: Inhibit Any-Policy extension
=20
I my opinion, RFC 5280 got it right.  If a CA includes this extension it
MUST be critical.  This setting will ensure that all relying parties
honor it.  This is not a setting that is appropriate for some relying
parties to honor and others not.

Russ

At 03:03 PM 7/29/2008, Peter Hesse wrote:

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."
=20
X.509 says "This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA."
=20
We have found a case in which a certificate processing implementation
has rejected a certificate because it has a non-critical inhibit
anyPolicy.  This is most likely because of the wording in 3280 (This
extension MUST be critical).  The PKI policy authority made the decision
to mark this extension non-critical following X.509.  We will work on
getting the certificate processing implementation to be more forgiving,
but in the meantime it bring up this question: Why does RFC5280 differ
from X.509 on the criticality of this extension?  There is a pretty
significant difference between a "recommendation" and a "MUST".
=20
Thanks,
=20
--Peter
=20

________________________________

 Peter Hesse                       [e-mail]
 Phone: [phone] x105      Gemini Security Solutions, Inc.
    Visit our relaunched website! http://geminisecurity.com
<http://geminisecurity.com/>=20

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder
=20


------_=_NextPart_001_01C8F314.E79040E0
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=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]-->
<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";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{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;}
-->
</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'>Russ,<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'>I do not recall the list having a
discussion on this.<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'>Besides, I am not saying revise =
5280.<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'>I am stating what is prudent and am =
providing
the rationale for it.<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'>Technical accuracy is not a matter =
of
consensus, no matter how big the group is or who is in it. &nbsp;It is a =
matter of
sound logic.<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'> Russ =
Housley
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, July 31, =
2008 9:50
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Santosh Chokhani; =
Peter Hesse;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Inhibit =
Any-Policy
extension</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>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Santosh:<br>
<br>
I disagree.&nbsp; Given that RFC 5280 (and RFC 3280 before that) had =
consensus
, I see no reason to revisit the discussion.<br>
<br>
Russ<br>
<br>
At 04:13 PM 7/30/2008, Santosh Chokhani wrote:<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>Russ,<br>
&nbsp;<br>
Making inhibit anyPolicy non-critical is desirable, RFC 5280 =
notwithstanding.<br>
&nbsp;<br>
Inhibit anyPolicy extension was added late to the policy related =
extensions in
X.509.&nbsp; Many clients do not support it.&nbsp; Making this extension
non-critical should let you have your cake and eat it to.&nbsp; Below is =
the
rationale.<br>
&nbsp;<br>
The clients that recognize the extension must enforce it regardless of
criticality.&nbsp; These clients will securely process the =
extension.<br>
&nbsp;<br>
The clients that do not recognize the extension are also not likely to
recognize the special OID of anyPolicy that was created in conjunction =
with it
and hence not processing the extension will be a wash, skipCerts &gt; 0
notwithstanding, which most PKIs do not do.<o:p></o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D2
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:navy'>

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

</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'>
[e-mail] [<a =
href=3D"mailto:[e-mail]"
eudora=3Dautourl> mailto:[e-mail]</a>] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Russ Housley<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July 30, =
2008
5:45 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Peter Hesse; =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Inhibit =
Any-Policy extension<br>
</span></font>&nbsp;<br>
I my opinion, RFC 5280 got it right.&nbsp; If a CA includes this =
extension it
MUST be critical.&nbsp; This setting will ensure that all relying =
parties honor
it.&nbsp; This is not a setting that is appropriate for some relying =
parties to
honor and others not.<br>
<br>
Russ<br>
<br>
At 03:03 PM 7/29/2008, Peter Hesse wrote:<br>
<br>
Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
&#8220;Conforming CAs MUST mark this extension as critical.&#8221;<br>
&nbsp;<br>
X.509 says &#8220;This extension may, at the option of the certificate =
issuer,
be either critical or non-critical. It is recommended that it be =
critical,
otherwise a certificate user may not correctly interpret the stipulation =
of the
issuing CA.&#8221;<br>
&nbsp;<br>
We have found a case in which a certificate processing implementation =
has
rejected a certificate because it has a non-critical inhibit =
anyPolicy.&nbsp;
This is most likely because of the wording in 3280 (This extension MUST =
be
critical).&nbsp; The PKI policy authority made the decision to mark this
extension non-critical following X.509.&nbsp; We will work on getting =
the
certificate processing implementation to be more forgiving, but in the =
meantime
it bring up this question: Why does RFC5280 differ from X.509 on the
criticality of this extension?&nbsp; There is a pretty significant =
difference
between a &#8220;recommendation&#8221; and a &#8220;MUST&#8221;.<br>
&nbsp;<br>
Thanks,<br>
&nbsp;<br>
--Peter<br>
&nbsp;<o:p></o:p></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>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail]<br>
&nbsp;Phone: [phone] x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gemini =
Security
Solutions, Inc.<br>
&nbsp;&nbsp;&nbsp; Visit our relaunched website! <a
href=3D"http://geminisecurity.com/">http://geminisecurity.com</a><br>
<br>
<i><span style=3D'font-style:italic'>&quot;A good programmer is someone =
who
always looks both ways before<br>
&nbsp;crossing a one-way street.&quot; --Doug Linder<br>
</span></i>&nbsp;<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C8F314.E79040E0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VDoKWe095025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 06:50:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6VDoKXl095024; Thu, 31 Jul 2008 06:50:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6VDoIfp095017 for <[e-mail]>; Thu, 31 Jul 2008 06:50:19 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 19204 invoked by uid 0); 31 Jul 2008 13:49:03 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (130.129.23.150) by woodstock.binhost.com with SMTP; 31 Jul 2008 13:49:03 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 31 Jul 2008 09:50:01 -0400
To: "Santosh Chokhani" <[e-mail]>, "Peter Hesse" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Inhibit Any-Policy extension
In-Reply-To: <[e-mail]. com>
References: <001701c8f1ad$c53ee9d0$4fbcbd70$@com> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
Santosh:<br><br>
I disagree.&nbsp; Given that RFC 5280 (and RFC 3280 before that) had
consensus , I see no reason to revisit the discussion.<br><br>
Russ<br><br>
At 04:13 PM 7/30/2008, Santosh Chokhani wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2 color="#000080">
Russ,<br>
&nbsp;<br>
Making inhibit anyPolicy non-critical is desirable, RFC 5280
notwithstanding.<br>
&nbsp;<br>
Inhibit anyPolicy extension was added late to the policy related
extensions in X.509.&nbsp; Many clients do not support it.&nbsp; Making
this extension non-critical should let you have your cake and eat it
to.&nbsp; Below is the rationale.<br>
&nbsp;<br>
The clients that recognize the extension must enforce it regardless of
criticality.&nbsp; These clients will securely process the
extension.<br>
&nbsp;<br>
The clients that do not recognize the extension are also not likely to
recognize the special OID of anyPolicy that was created in conjunction
with it and hence not processing the extension will be a wash, skipCerts
&gt; 0 notwithstanding, which most PKIs do not do.<br>
<hr>
<div align="center"></font></div>
<font face="Tahoma" size=2><b>From:</b> [e-mail]
[<a href="mailto:[e-mail]" eudora="autourl">
mailto:[e-mail]</a>] <b>On Behalf Of </b>Russ
Housley<br>
<b>Sent:</b> Wednesday, July 30, 2008 5:45 AM<br>
<b>To:</b> Peter Hesse; [e-mail]<br>
<b>Subject:</b> Re: Inhibit Any-Policy extension<br>
</font><font face="Times New Roman, Times">&nbsp;<br>
I my opinion, RFC 5280 got it right.&nbsp; If a CA includes this
extension it MUST be critical.&nbsp; This setting will ensure that all
relying parties honor it.&nbsp; This is not a setting that is appropriate
for some relying parties to honor and others not.<br><br>
Russ<br><br>
At 03:03 PM 7/29/2008, Peter Hesse wrote:<br><br>
Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
“Conforming CAs MUST mark this extension as critical.”<br>
&nbsp;<br>
X.509 says “This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA.”<br>
&nbsp;<br>
We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 (This
extension MUST be critical).&nbsp; The PKI policy authority made the
decision to mark this extension non-critical following X.509.&nbsp; We
will work on getting the certificate processing implementation to be more
forgiving, but in the meantime it bring up this question: Why does
RFC5280 differ from X.509 on the criticality of this extension?&nbsp;
There is a pretty significant difference between a “recommendation” and a
“MUST”.<br>
&nbsp;<br>
Thanks,<br>
&nbsp;<br>
--Peter<br>
&nbsp;<br>
<hr>
<div align="center"></div>
&nbsp;Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail]<br>
&nbsp;Phone: [phone] x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gemini
Security Solutions, Inc.<br>
&nbsp;&nbsp;&nbsp; Visit our relaunched website!
<a href="http://geminisecurity.com/">http://geminisecurity.com</a><br><br>
<i>&quot;A good programmer is someone who always looks both ways
before<br>
&nbsp;crossing a one-way street.&quot; --Doug Linder<br>
</i>&nbsp;</font></blockquote></body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VDgjA2094591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 06:42:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6VDgjbc094590; Thu, 31 Jul 2008 06:42:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VDgcxZ094571 for <[e-mail]>; Thu, 31 Jul 2008 06:42:44 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.17.6.236]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KOYQO-0005sf-Eq; Thu, 31 Jul 2008 09:42:36 -0400
Mime-Version: 1.0
Message-Id: <p0624050fc4b77120ca67@[172.17.6.236]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]> <p06240815c4a2a3686524@[10.20.30.162]> <[e-mail]> <p06240509c4b33b20715a@[130.129.21.37]> <[e-mail]>
Date: Thu, 31 Jul 2008 09:41:57 -0400
To: "Tim Moses" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Status of domain-certs-01 and sip-eku-02
Cc: "Paul Hoffman" <[e-mail]>, "Vijay K. Gurbani" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:08 PM -0400 7/29/08, Tim Moses wrote:
>Hi Steve.  I was thinking that a new SAN type-id may be a suitable way of
>indicating that the certificate's subject may not identify a namespace that
>includes the name of the server (the authorized SIP Proxy) to which you are
>directly connected, but rather one that includes the name of another server;
>the one that vouches for the SIP proxy.
>
>Syntactically, it's a URI, but semantically it's different from the usual
>SAN URI option.
>
>Just a thought.
>
>All the best.  Tim.

Tim,

I think the discussions on the PKIX list came to the conclusion that 
the EKU semantics for this SIP context are OK, i.e., they are not 
inconsistent with other EKUs we have published.  If SIP decides that 
it also wants to use a new type-id to further reinforce the notion, 
that's obviously OK too.

Steve



Received: from h062040151076.kob.cm.kabsi.at (h062040151076.kob.cm.kabsi.at [62.40.151.76]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6VAZdH4082009 for <[e-mail]>; Thu, 31 Jul 2008 03:35:40 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: 5 more arrested from west Texas polygamist sect
From:   Kisner <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Thu, 31 Jul 2008 12:35:39 +0200
Message-ID: <vl.ntdqbefztbqzrl@hauermonika>
User-Agent: Opera Mail/9.50 (Win32)

Madonna admits to 12 different affairs
http://www.skyline-kino.de/showvideo.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UKuA3Q026835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 13:56:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6UKuALB026834; Wed, 30 Jul 2008 13:56:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UKu8Ck026828 for <[e-mail]>; Wed, 30 Jul 2008 13:56:09 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) (authenticated as u18116613) id 4873CA950041C7F5; Wed, 30 Jul 2008 22:53:19 +0200
Message-ID: <00b301c8f29f$b757b700$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
Date: Thu, 31 Jul 2008 01:55:13 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm less concerned about details regarding this protocol than how to use the information it provides.
Security GUI have shown to be very difficult to design since they either [try to] hide the gory stuff or assumes a level of
education that isn't generally available.  I wouldn't be surprised if Microsoft with their CardSpace scheme will [eventually] make
two-factor authentication as easy to use as credit cards; it even looks like credit cards!

Anders Rundgren


----- Original Message ----- 
From: "Massimiliano Pala" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 30, 2008 11:10
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt


Hi Tom,

In section 2.1.1. only a brief descriptions we list only some of the reasons
for adopting a PRQP and it is not intended to be exhaustive. The argument
in 2.1.2. still holds, in the sense that currently there is no mapping in
the certificates between DNS domains and certificates - as you pointed out
there is no field that could carry such information.

I will probably need to add some more deep considerations in this section
thus listing the benefits coming from the usage of a dynamic protocol. The
intent of defining a protocol for PKI resource query that is transport
independent allows for more flexibility than using a specific service like
DNS. I would not say that the DNS is not secure enough - it could be possible
to distribute signed records via DNS; it can be difficult from a management
point of view: it is my opinion that integrating that type of support in
current DNS is harder and takes longer than defining a new protocol which
is easy and can be implemented really fast.

Last, but not least, at the last IETF my presentation on extending PRQP to
a Peer-to-peer environment that would allow the implementation of a real
service discovery system for PKIs strongly suggest that the overhead introduced
by the definition of a specific protocol is rewarded with a wide range of
possibilities for PKI management and would allow for better usability of PKIs.
See section A.2 of the I-D for more information.

These are just some of the reasons I can come up with. The current status
of the draft is, AFAIK, on experimental track just because of this: we need
to know if this protocol would allow for an efficient and interoperable
method for PKI resource discovery or not. So far the DNS has not provided
such a service, IMHO. Anyhow, I would encourage the usage of the DNS SRV
record to locate a local RQA (if available), though.

As I am going to explain in my presentation later today, we are moving
forward from this point of view as an RQA will be setup for all of the
CAs within the TACAR repository (http://www.tacar.org). When we will have
a deployed environment and, eventually, support for client applications
we will be able to evaluate more what the results are and if it will be
worth to move the I-D to standard track or not.

I will a concise version of these considerations to the 2.1.2 section of
the I-D in order to make it more clear why we propose the usage of PRQP
instead of DNS SRV records - although I do not want this section to become
too long.

Thanks for the comments and, if you have more, please let me know :D

Later,
Max


Tom Gindin wrote:
>         Max:
>
>         The DNS Name has to go into a specific extension to be used.  I
> don't think that putting a DNS Name into IssuerAltName means "look here
> for SRV records associated with PKI management", and its most common
> meaning in SubjectAltName is "expect to see this certificate when you
> connect to this DNS Name", but an AccessDescription could easily be
> assigned to mean that it's a pointer to SRV records.  There are General
> Names associated with AKI, CRL Distribution Point, and Name Constraint as
> well, but they clearly are not appropriate for such purposes.
>         An argument that "DNS is not the right mechanism for this, and
> it's worth a new protocol to avoid using DNS" is different than the one
> you made in the first version of your draft.  It looks to me like the
> argument against DNS usage would rely heavily on the perception that DNS
> isn't secure enough, especially for revocation information.  Is that
> really a strong enough reason to expect typical relying parties to
> implement a new client protocol?
>
>                 Tom Gindin


-- 

Best Regards,

Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust - Office 063                        Work Phone: [phone]
--o------------------------------------------------------------------------



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UKDgJ2024611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 13:13:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6UKDg6B024610; Wed, 30 Jul 2008 13:13:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6UKDeTK024603 for <[e-mail]>; Wed, 30 Jul 2008 13:13:41 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 30706 invoked from network); 30 Jul 2008 20:02:11 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Jul 2008 20:02:11 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Jul 2008 20:02:10 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F280.C0BEAB3C"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Inhibit Any-Policy extension
Date: Wed, 30 Jul 2008 16:13:37 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Inhibit Any-Policy extension
Thread-Index: AcjyK+QfW1vJbV1OTUuEPRYGN5l5qAATklZA
References: <001701c8f1ad$c53ee9d0$4fbcbd70$@com> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Peter Hesse" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F280.C0BEAB3C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Russ,

=20

Making inhibit anyPolicy non-critical is desirable, RFC 5280
notwithstanding.

=20

Inhibit anyPolicy extension was added late to the policy related
extensions in X.509.  Many clients do not support it.  Making this
extension non-critical should let you have your cake and eat it to.
Below is the rationale.

=20

The clients that recognize the extension must enforce it regardless of
criticality.  These clients will securely process the extension.

=20

The clients that do not recognize the extension are also not likely to
recognize the special OID of anyPolicy that was created in conjunction
with it and hence not processing the extension will be a wash, skipCerts
> 0 notwithstanding, which most PKIs do not do.

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: Wednesday, July 30, 2008 5:45 AM
To: Peter Hesse; [e-mail]
Subject: Re: Inhibit Any-Policy extension

=20

I my opinion, RFC 5280 got it right.  If a CA includes this extension it
MUST be critical.  This setting will ensure that all relying parties
honor it.  This is not a setting that is appropriate for some relying
parties to honor and others not.

Russ

At 03:03 PM 7/29/2008, Peter Hesse wrote:



Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."
=20
X.509 says "This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA."
=20
We have found a case in which a certificate processing implementation
has rejected a certificate because it has a non-critical inhibit
anyPolicy.  This is most likely because of the wording in 3280 (This
extension MUST be critical).  The PKI policy authority made the decision
to mark this extension non-critical following X.509.  We will work on
getting the certificate processing implementation to be more forgiving,
but in the meantime it bring up this question: Why does RFC5280 differ
from X.509 on the criticality of this extension?  There is a pretty
significant difference between a "recommendation" and a "MUST".
=20
Thanks,
=20
--Peter
=20

________________________________

 Peter Hesse                       [e-mail]
 Phone: [phone] x105      Gemini Security Solutions, Inc.
    Visit our relaunched website! http://geminisecurity.com
<http://geminisecurity.com/>=20

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder
=20


------_=_NextPart_001_01C8F280.C0BEAB3C
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=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 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]-->
<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";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{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;}
-->
</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'>Russ,<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'>Making inhibit anyPolicy =
non-critical is
desirable, RFC 5280 notwithstanding.<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'>Inhibit anyPolicy extension was =
added late
to the policy related extensions in X.509.&nbsp; Many clients do not =
support it.&nbsp;
Making this extension non-critical should let you have your cake and eat =
it to.&nbsp;
Below is the rationale.<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'>The clients that recognize the =
extension
must enforce it regardless of criticality. &nbsp;These clients will =
securely
process the extension.<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'>The clients that do not recognize =
the
extension are also not likely to recognize the special OID of anyPolicy =
that
was created in conjunction with it and hence not processing the =
extension will
be a wash, skipCerts &gt; 0 notwithstanding, which most PKIs do not =
do.<o:p></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'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Russ Housley<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July 30, =
2008
5:45 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Peter Hesse; =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Inhibit =
Any-Policy
extension</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>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>I my opinion, RFC 5280 got it right.&nbsp; If a CA includes this
extension it MUST be critical.&nbsp; This setting will ensure that all =
relying
parties honor it.&nbsp; This is not a setting that is appropriate for =
some
relying parties to honor and others not.<br>
<br>
Russ<br>
<br>
At 03:03 PM 7/29/2008, Peter Hesse wrote:<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 =
says
&#8220;Conforming CAs MUST mark this extension as critical.&#8221;<br>
&nbsp;<br>
X.509 says &#8220;This extension may, at the option of the certificate =
issuer,
be either critical or non-critical. It is recommended that it be =
critical,
otherwise a certificate user may not correctly interpret the stipulation =
of the
issuing CA.&#8221;<br>
&nbsp;<br>
We have found a case in which a certificate processing implementation =
has
rejected a certificate because it has a non-critical inhibit =
anyPolicy.&nbsp;
This is most likely because of the wording in 3280 (This extension MUST =
be
critical).&nbsp; The PKI policy authority made the decision to mark this
extension non-critical following X.509.&nbsp; We will work on getting =
the
certificate processing implementation to be more forgiving, but in the =
meantime
it bring up this question: Why does RFC5280 differ from X.509 on the
criticality of this extension?&nbsp; There is a pretty significant =
difference
between a &#8220;recommendation&#8221; and a &#8220;MUST&#8221;.<br>
&nbsp;<br>
Thanks,<br>
&nbsp;<br>
--Peter<br>
&nbsp;<o:p></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>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail]<br>
&nbsp;Phone: [phone] x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gemini =
Security
Solutions, Inc.<br>
&nbsp;&nbsp;&nbsp; Visit our relaunched website! <a
href=3D"http://geminisecurity.com/">http://geminisecurity.com</a><br>
<br>
<i><span style=3D'font-style:italic'>&quot;A good programmer is someone =
who
always looks both ways before<br>
&nbsp;crossing a one-way street.&quot; --Doug Linder<br>
</span></i>&nbsp;<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C8F280.C0BEAB3C--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UFFKRm099318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 08:15:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6UFFKhN099317; Wed, 30 Jul 2008 08:15:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UFFJCG099308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 30 Jul 2008 08:15:20 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6UFF59N018777; Wed, 30 Jul 2008 11:15:05 -0400
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m6UFF2Oe025782; Wed, 30 Jul 2008 11:15:03 -0400
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2008 11:14:41 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080725)
MIME-Version: 1.0
To: Peter Hesse <[e-mail]>
CC: [e-mail]
Subject: Re: Inhibit Any-Policy extension
References: <001701c8f1ad$c53ee9d0$4fbcbd70$@com>
In-Reply-To: <001701c8f1ad$c53ee9d0$4fbcbd70$@com>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Peter,<br>
<br>
As was previously noted, the relying party should not be rejecting the
certificate simply because the extension is marked non-critical.<br>
<br>
As to your question of why does RFC 5280 differ from X.509, it is
because one is the base standard, which defines the extension, and the
other is a profile.&nbsp; The purpose of RFC 5280 is to profile X.509, not
simply reformat it as an RFC.<br>
<br>
X.509 does not mandate that any public key certificate extension be
marked critical.&nbsp; Each extension is either marked as always
non-critical or optionally critical. (X.509 does mandate that some CRL
extensions always be marked critical.)&nbsp; I believe that it was fully
expected by the authors of X.509 that profiles would mandate that some
of the extensions be marked critical.<br>
<br>
Dave<br>
<br>
Peter Hesse wrote:
<blockquote cite="mid:001701c8f1ad$c53ee9d0$4fbcbd70$@com" type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="Microsoft Word 12 (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]-->
  <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:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
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:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
  </style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
  <div class="Section1">
  <p class="MsoNormal">Regarding the Inhibit anyPolicy extension (id-ce
54), RFC 5280
says &#8220;Conforming CAs MUST mark this extension as critical.&#8221;<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">X.509 says &#8220;This extension may, at the option of
the
certificate issuer, be either critical or non-critical. It is
recommended that
it be critical, otherwise a certificate user may not correctly
interpret the
stipulation of the issuing CA.&#8221;<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">We have found a case in which a certificate
processing
implementation has rejected a certificate because it has a non-critical
inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 (This
extension MUST be critical).&nbsp; The PKI policy authority made the
decision
to mark this extension non-critical following X.509.&nbsp; We will work on
getting the certificate processing implementation to be more forgiving,
but in
the meantime it bring up this question: Why does RFC5280 differ from
X.509 on the
criticality of this extension?&nbsp; There is a pretty significant
difference
between a &#8220;recommendation&#8221; and a &#8220;MUST&#8221;.<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">Thanks,<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">--Peter<o:p></o:p></p>
  </div>
</blockquote>
<br>
</body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UBZfnq078463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 04:35:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6UBZfmu078462; Wed, 30 Jul 2008 04:35:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UBZZ5a078439 for <[e-mail]>; Wed, 30 Jul 2008 04:35:40 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id D6DCD5D; Wed, 30 Jul 2008 13:35:34 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008073013353309:55940 ; Wed, 30 Jul 2008 13:35:33 +0200 
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2008 13:35:33 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Cc: Peter Hesse <[e-mail]>, [e-mail]
Subject: Re: Inhibit Any-Policy extension
References: <001701c8f1ad$c53ee9d0$4fbcbd70$@com> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 07/30/2008 01:35:33 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 07/30/2008 01:35:34 PM, Serialize complete at 07/30/2008 01:35:34 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040704080305040007080206"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms040704080305040007080206
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Russ Housley wrote:
> I my opinion, RFC 5280 got it right. If a CA includes this extension=20
> it MUST be critical. This setting will ensure that all relying parties =

> honor it. This is not a setting that is appropriate for some relying=20
> parties to honor and others not.
I agree.

But is it correct for a relying party that recognizes the extension to=20
look at the criticality at all:

   A
   certificate-using system MUST reject the certificate if it encounters
   a critical extension it does not recognize or a critical extension
   that contains information that it cannot process.  A non-critical
   extension MAY be ignored if it is not recognized, but MUST be
   processed if it is recognized.=20


>
> Russ
>
> At 03:03 PM 7/29/2008, Peter Hesse wrote:
>> Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says=20
>> =E2=80=9CConforming CAs MUST mark this extension as critical.=E2=80=9D=

>>
>> X.509 says =E2=80=9CThis extension may, at the option of the certifica=
te=20
>> issuer, be either critical or non-critical. It is recommended that it =

>> be critical, otherwise a certificate user may not correctly interpret =

>> the stipulation of the issuing CA.=E2=80=9D
>>
>> We have found a case in which a certificate processing implementation =

>> has rejected a certificate because it has a non-critical inhibit=20
>> anyPolicy. This is most likely because of the wording in 3280 (This=20
>> extension MUST be critical). The PKI policy authority made the=20
>> decision to mark this extension non-critical following X.509. We will =

>> work on getting the certificate processing implementation to be more=20
>> forgiving, but in the meantime it bring up this question: Why does=20
>> RFC5280 differ from X.509 on the criticality of this extension? There =

>> is a pretty significant difference between a =E2=80=9Crecommendation=E2=
=80=9D and a=20
>> =E2=80=9CMUST=E2=80=9D.
>>
>> Thanks,
>>
>> --Peter
>>
>> ----------------------------------------------------------------------=
--
>> Peter Hesse [e-mail]
>> Phone: [phone] x105 Gemini Security Solutions, Inc.
>> Visit our relaunched website! http://geminisecurity.com=20
>> <http://geminisecurity.com/>
>>
>> /"A good programmer is someone who always looks both ways before
>> crossing a one-way street." --Doug Linder
>> /=20




--------------ms040704080305040007080206
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0
MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV
HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh
Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff
2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP
2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma
1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT
DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9
lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn
qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd
kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/
FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI
cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ
PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB
MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug
RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr
DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
ODA3MzAxMTM1MzNaMCMGCSqGSIb3DQEJBDEWBBSpH3kMG1cTGXRnjLeIHv6P+3x7KzBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYBXfbsGrkJX8zy4Eaz1CbHqR3mBM2AKErqcHKBVQi9oS7K+/2dnh93jBQC5
euJrDxWfchgNCguxuqJaRIjtiaiHKuCnv6hMH8R5Ds5mrkP6Gl6Q7kfZxO5coOfRoZ1yZ1zD
Gm/8FLZIfl9NpACn1a5bqT1nZZSEGfdOiQ6Xb98s4gAAAAAAAA==
--------------ms040704080305040007080206--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UACqFG071611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 03:12:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6UACqx5071610; Wed, 30 Jul 2008 03:12:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6UACoFa071603 for <[e-mail]>; Wed, 30 Jul 2008 03:12:51 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 58620 invoked from network); 30 Jul 2008 10:12:50 -0000
Received: from unknown (HELO Wylie) ([e-mail]@130.129.22.148 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 30 Jul 2008 10:12:49 -0000
X-YMail-OSG: 8_Ax4HEVM1k6raadqAnmsw5QNlsduye4gxi61jyNhvlufF4dwZk6iBOV3gjZh8.xb_axAKzvncWuIBPvFIqeYM0.n607tdbw96Qvy_XGmrnDQg41H6Ocgn_emhPxK.0-
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
Subject: FW: I-D ACTION:draft-turner-caclearanceconstraints-01.txt 
Date: Wed, 30 Jul 2008 11:12:45 +0100
Organization: IECA, Inc.
Message-ID: <4259C518A602433CAB806D8E36F79E3A@Wylie>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007B_01C8F235.31CB3A90"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acjl5CvJ+ZvQ7YXhR4CyuoIhA7NuggMSCX1A
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_007B_01C8F235.31CB3A90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I thought I'd draw your attention to this ID as we'll be discussing it at
the meeting. 

spt

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Monday, July 14, 2008 7:45 PM
To: [e-mail]
Subject: I-D ACTION:draft-turner-caclearanceconstraints-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Clearance and CA Clearance Constraints Certificate
Extensions
	Author(s)	: S. Turner, S. Chokhani
	Filename	: draft-turner-caclearanceconstraints-01.txt
	Pages		: 15
	Date		: 2008-7-14
	
This document defines the syntax and semantics for the Clearance and 
   the Certification Authority (CA) Clearance Constraints X.509 
   certificate extensions.  The Clearance certificate extension is used 
   to indicate the clearance held by the subject.  The CA Clearance 
   Constraints certificate extension values in a Trust Anchor (TA) and 

   the CAs in a certification path constrain the effective Clearance of 
   the subject of the last certificate in the certification path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-turner-caclearanceconstraints-01.t
xt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

------=_NextPart_000_007B_01C8F235.31CB3A90
Content-Type: Message/External-body;
	name="draft-turner-caclearanceconstraints-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-turner-caclearanceconstraints-01.txt"

Content-Type: text/plain
Content-ID: <[e-mail]>


------=_NextPart_000_007B_01C8F235.31CB3A90
Content-Type: text/plain;
	name="ATT01135.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT01135.txt"

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------=_NextPart_000_007B_01C8F235.31CB3A90--



Received: from [123.15.245.241] ([123.15.245.241]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UA3cdo070223 for <[e-mail]>; Wed, 30 Jul 2008 03:03:41 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_ufgIrAOAYFSrw8zqTnCAGW)"
Message-id: <000c01c8f22b$8a83ad20$f1f50f7b@wuming10>
From: PREST <[e-mail]>
To: [e-mail]
Subject: Qantas crash blamed on Boeing, fleets recalled
Date: Wed, 30 Jul 2008 18:03:40 +0800
X-Mailer: Apple Mail (2.924)

--Boundary_(ID_ufgIrAOAYFSrw8zqTnCAGW)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Rupert Murdoch and wife robbed at gunpoint http://euclide.fr/default.html

--Boundary_(ID_ufgIrAOAYFSrw8zqTnCAGW)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Rupert Murdoch and wife robbed at gunpoint<div><a href="http://euclide.fr/default.html">http://euclide.fr/default.html</a></div></body></html>

--Boundary_(ID_ufgIrAOAYFSrw8zqTnCAGW)--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6U9ljdH068583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 02:47:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6U9ljfY068582; Wed, 30 Jul 2008 02:47:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6U9lil2068574 for <[e-mail]>; Wed, 30 Jul 2008 02:47:45 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 12563 invoked by uid 0); 30 Jul 2008 09:46:43 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (130.129.23.150) by woodstock.binhost.com with SMTP; 30 Jul 2008 09:46:43 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 30 Jul 2008 05:44:44 -0400
To: "Peter Hesse" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Inhibit Any-Policy extension
In-Reply-To: <001701c8f1ad$c53ee9d0$4fbcbd70$@com>
References: <001701c8f1ad$c53ee9d0$4fbcbd70$@com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
I my opinion, RFC 5280 got it right.&nbsp; If a CA includes this
extension it MUST be critical.&nbsp; This setting will ensure that all
relying parties honor it.&nbsp; This is not a setting that is appropriate
for some relying parties to honor and others not.<br><br>
Russ<br><br>
At 03:03 PM 7/29/2008, Peter Hesse wrote:<br>
<blockquote type=cite class=cite cite="">Regarding the Inhibit anyPolicy
extension (id-ce 54), RFC 5280 says “Conforming CAs MUST mark this
extension as critical.”<br>
&nbsp;<br>
X.509 says “This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA.”<br>
&nbsp;<br>
We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 (This
extension MUST be critical).&nbsp; The PKI policy authority made the
decision to mark this extension non-critical following X.509.&nbsp; We
will work on getting the certificate processing implementation to be more
forgiving, but in the meantime it bring up this question: Why does
RFC5280 differ from X.509 on the criticality of this extension?&nbsp;
There is a pretty significant difference between a “recommendation” and a
“MUST”.<br>
&nbsp;<br>
Thanks,<br>
&nbsp;<br>
--Peter<br>
&nbsp;<br>
<hr>
&nbsp;Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail]<br>
&nbsp;Phone: [phone] x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gemini
Security Solutions, Inc.<br>
&nbsp;&nbsp;&nbsp; Visit our relaunched website!
<a href="http://geminisecurity.com/">http://geminisecurity.com</a><br><br>
<i>&quot;A good programmer is someone who always looks both ways
before<br>
&nbsp;crossing a one-way street.&quot; --Doug Linder<br>
</i>&nbsp;</blockquote></body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6U9DHMY066022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 02:13:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6U9DHFT066021; Wed, 30 Jul 2008 02:13:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6U9DAL3066011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 30 Jul 2008 02:13:16 -0700 (MST) (envelope-from [e-mail])
Received: from titan.cs.dartmouth.edu ([130.129.54.185]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.14.2/8.14.2) with ESMTP id m6U9D3Pm023558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 05:13:07 -0400
DomainKey-Signature: a=rsa-sha1; s=mail; d=cs.dartmouth.edu; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type; b=n3JTDJFWXAqsvqJdD4WtZGCONK4+npALxQ4MEkPBXrPgawXnPGGXd7v0YlcguBz9L rGjS1R3KHhGeYJCcU89CA==
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2008 10:10:04 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010608070909020901010402"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms010608070909020901010402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tom,

In section 2.1.1. only a brief descriptions we list only some of the reasons
for adopting a PRQP and it is not intended to be exhaustive. The argument
in 2.1.2. still holds, in the sense that currently there is no mapping in
the certificates between DNS domains and certificates - as you pointed out
there is no field that could carry such information.

I will probably need to add some more deep considerations in this section
thus listing the benefits coming from the usage of a dynamic protocol. The
intent of defining a protocol for PKI resource query that is transport
independent allows for more flexibility than using a specific service like
DNS. I would not say that the DNS is not secure enough - it could be possible
to distribute signed records via DNS; it can be difficult from a management
point of view: it is my opinion that integrating that type of support in
current DNS is harder and takes longer than defining a new protocol which
is easy and can be implemented really fast.

Last, but not least, at the last IETF my presentation on extending PRQP to
a Peer-to-peer environment that would allow the implementation of a real
service discovery system for PKIs strongly suggest that the overhead introduced
by the definition of a specific protocol is rewarded with a wide range of
possibilities for PKI management and would allow for better usability of PKIs.
See section A.2 of the I-D for more information.

These are just some of the reasons I can come up with. The current status
of the draft is, AFAIK, on experimental track just because of this: we need
to know if this protocol would allow for an efficient and interoperable
method for PKI resource discovery or not. So far the DNS has not provided
such a service, IMHO. Anyhow, I would encourage the usage of the DNS SRV
record to locate a local RQA (if available), though.

As I am going to explain in my presentation later today, we are moving
forward from this point of view as an RQA will be setup for all of the
CAs within the TACAR repository (http://www.tacar.org). When we will have
a deployed environment and, eventually, support for client applications
we will be able to evaluate more what the results are and if it will be
worth to move the I-D to standard track or not.

I will a concise version of these considerations to the 2.1.2 section of
the I-D in order to make it more clear why we propose the usage of PRQP
instead of DNS SRV records - although I do not want this section to become
too long.

Thanks for the comments and, if you have more, please let me know :D

Later,
Max


Tom Gindin wrote:
>         Max:
> 
>         The DNS Name has to go into a specific extension to be used.  I 
> don't think that putting a DNS Name into IssuerAltName means "look here 
> for SRV records associated with PKI management", and its most common 
> meaning in SubjectAltName is "expect to see this certificate when you 
> connect to this DNS Name", but an AccessDescription could easily be 
> assigned to mean that it's a pointer to SRV records.  There are General 
> Names associated with AKI, CRL Distribution Point, and Name Constraint as 
> well, but they clearly are not appropriate for such purposes.
>         An argument that "DNS is not the right mechanism for this, and 
> it's worth a new protocol to avoid using DNS" is different than the one 
> you made in the first version of your draft.  It looks to me like the 
> argument against DNS usage would rely heavily on the perception that DNS 
> isn't secure enough, especially for revocation information.  Is that 
> really a strong enough reason to expect typical relying parties to 
> implement a new client protocol?
> 
>                 Tom Gindin


-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust - Office 063                        Work Phone: [phone]
--o------------------------------------------------------------------------

--------------ms010608070909020901010402
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx
NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v
dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG
CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI
hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg
bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8
fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw
EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi
BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91
dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0
dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm
MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI
KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3
DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6
AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG
nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV
jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl
AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE
aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ
MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt
b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1
MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK
CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG
9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu
GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8
K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR
BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG
A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0
aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0
cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw
IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr
BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN
AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC
KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad
L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN
gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA
lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4
MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0
bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE
AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNzMwMDkxMDA0WjAjBgkqhkiG9w0B
CQQxFgQUWe2wxDQxZ9ZgG8J7jsj8ivMWeA4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT
8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs
ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx
f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy
dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYCvExCnGEFvjFiUNu/efBGe
+Fnhv9Vr/mcsJkkajs//3A9vXDfmC84ipsFzdulBpEXI5kaSHC/bqindyukTOlkRG0BZOVx9
wzC8EYKvsAtdmMUkQ7qsCcPUIO2MexMTs2EzjjqGcOVV2jqzV39qSBebPcXjZtlQ+P+NgJrh
9eWRkwAAAAAAAA==
--------------ms010608070909020901010402--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6U8uNMa064459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 01:56:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6U8uNJe064458; Wed, 30 Jul 2008 01:56:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6U8uEB7064442 for <[e-mail]>; Wed, 30 Jul 2008 01:56:22 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id BF1ED57 for <[e-mail]>; Wed, 30 Jul 2008 10:56:11 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008073010561053:55685 ; Wed, 30 Jul 2008 10:56:10 +0200 
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2008 10:56:11 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
Cc: [e-mail]
Subject: critical extended keyusage in RFC 3161 
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 07/30/2008 10:56:10 AM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 07/30/2008 10:56:11 AM, Serialize complete at 07/30/2008 10:56:11 AM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070306050008030100060607"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms070306050008030100060607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

rfc 3161 requires in 2.3

   The
   corresponding certificate MUST contain only one instance of the
   extended key usage field extension as defined in [RFC2459] Section
   4.2.1.13 with KeyPurposeID having value:

   id-kp-timeStamping.  This extension MUST be critical.

Some TSA do not set this, and there exist relying party software that
rejects a certficat with a non critical extended keyusage.

Peter



--------------ms070306050008030100060607
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0
MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV
HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh
Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff
2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP
2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma
1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT
DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9
lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn
qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd
kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/
FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI
cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ
PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB
MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug
RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr
DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
ODA3MzAwODU2MTFaMCMGCSqGSIb3DQEJBDEWBBTt9CuRURBzFuoDQ4/R6UC20bZ7QzBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYAleOpQOM3I12Ozw9AhQbjfRQI7RHC8mn9H3tVzTNmZ+r02lVK//CgvfQDi
wZiwqxQDfol4CbhY74svRJC9WYvm+2thBRu0Rgejo1ukK3Rj4vcawRwbQAV6B7iXlh+0GY4s
3elHY9LvKKduoLKTkZ8W0oRKXQ3EjjZCPLTOQJiDWwAAAAAAAA==
--------------ms070306050008030100060607--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6U6oI36052974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 23:50:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6U6oIva052973; Tue, 29 Jul 2008 23:50:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ascertia.com (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6U6oETK052962 for <[e-mail]>; Tue, 29 Jul 2008 23:50:15 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from ASCUK001 ([87.201.190.146]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Wed, 30 Jul 2008 06:52:07 +0100
From: "Liaquat Khan" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Peter Hesse'" <[e-mail]>, <[e-mail]>
Subject: RE: Inhibit Any-Policy extension
Date: Wed, 30 Jul 2008 10:49:52 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01C8F232.01B42950"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcjxrcE7ablGPJgpTZ+TTijYDz/wFwAAvcsAABdozLA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <[e-mail]>
X-ME-Bayesian: 0.000000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0080_01C8F232.01B42950
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

We often come across such situations not only because of differences in
standards but also because CAs tend to do their own thing sometime with
regards to setting the criticality flag or not.  

 

I would go a step further, i.e. the safe conclusion for sake of
interoperability from a practical point of view is the following:

 

-          It should not be the job of RP applications to enforce
"criticality"

-          Instead RP applications should simply process the extensions they
recognise, if there is an extension which is not recognised and it is marked
critical then the RP application should not accept that certificate.  

 

Regards,

LK

 

  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: 29 July 2008 23:56
To: Peter Hesse; [e-mail]
Subject: RE: Inhibit Any-Policy extension

 

Peter,

 

5280 processing rules recommend that relying party not enforce this
criticality.  I recommend that the relying party software in your situation
be modified to not check and enforce criticality.

 

See paragraph 3 of Section 6.1 of 5280 and I quote below:

 

"While the certificate and CRL profiles specified in Sections 4 and 5

   of this document specify values for certificate and CRL fields and

   extensions that are considered to be appropriate for the Internet

   PKI, the algorithm presented in this section is not limited to

   accepting certificates and CRLs that conform to these profiles.

   Therefore, the algorithm only includes checks to verify that the

   certification path is valid according to X.509 and does not include

   checks to verify that the certificates and CRLs conform to this

   profile.  While the algorithm could be extended to include checks for

   conformance to the profiles in Sections 4 and 5, this profile

   RECOMMENDS against including such checks."

 

 

  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Hesse
Sent: Tuesday, July 29, 2008 3:03 PM
To: [e-mail]
Subject: Inhibit Any-Policy extension

 

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."

 

X.509 says "This extension may, at the option of the certificate issuer, be
either critical or non-critical. It is recommended that it be critical,
otherwise a certificate user may not correctly interpret the stipulation of
the issuing CA."

 

We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit anyPolicy.
This is most likely because of the wording in 3280 (This extension MUST be
critical).  The PKI policy authority made the decision to mark this
extension non-critical following X.509.  We will work on getting the
certificate processing implementation to be more forgiving, but in the
meantime it bring up this question: Why does RFC5280 differ from X.509 on
the criticality of this extension?  There is a pretty significant difference
between a "recommendation" and a "MUST".

 

Thanks,

 

--Peter

 

  _____  

 Peter Hesse                       [e-mail]

 Phone: [phone] x105      Gemini Security Solutions, Inc.

    Visit our relaunched website! http://geminisecurity.com
<http://geminisecurity.com/> 

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder

 


------=_NextPart_000_0080_01C8F232.01B42950
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:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns0=3D"http://schemas.microsoft.com/office/2004/12/omml">

<head>
<meta http-equiv=3DContent-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]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;}
@font-face
	{font-family:Consolas;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Calibri;
	color:#1F497D;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:2143494809;
	mso-list-type:hybrid;
	mso-list-template-ids:-1899968034 -1427873694 134807555 134807557 =
134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</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=3DEN-GB link=3Dblue vlink=3Dpurple>

<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'>We often come across such =
situations not
only because of differences in standards but also because CAs tend to do =
their
own thing sometime with regards to setting the criticality flag or not. =
&nbsp;<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'>I would go a step further, i.e. the =
safe
conclusion for sake of interoperability from a practical point of view =
is the
following:<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 =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>It
should not be the job of RP applications to enforce =
&#8220;criticality&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Instead RP
applications should simply process the extensions they recognise, if =
there is
an extension which is not recognised and it is marked critical then the =
RP
application should not accept that certificate. =
&nbsp;<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'>Regards,<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'>LK<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
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
font-family:"Times New Roman";color:windowtext'>

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:windowtext'> [e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 29 July 2008 =
23:56<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Peter Hesse; =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Inhibit =
Any-Policy
extension</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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 =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>5280 processing =
rules
recommend that relying party not enforce this criticality.&nbsp; I =
recommend
that the relying party software in your situation be modified to not =
check and
enforce criticality.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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 =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>See paragraph 3 =
of
Section 6.1 of 5280 and I quote below:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dnavy
face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>&#8220;</span></font><font size=3D2 color=3Dblack =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New";color:windowtext'>While
the certificate and CRL profiles specified in Sections 4 and =
5<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; of this document specify values for =
certificate
and CRL fields and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; extensions that are considered to be =
appropriate
for the Internet<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; PKI, the algorithm presented in this =
section is
not limited to<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; accepting certificates and CRLs that =
conform to
these profiles.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; Therefore, the algorithm only includes =
checks to
verify that the<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; certification path is valid according to =
X.509
and does not include<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; checks to verify that the certificates =
and CRLs
conform to this<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; profile.&nbsp; While the algorithm could =
be
extended to include checks for<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; conformance to the profiles in Sections 4 =
and 5,
this profile<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; RECOMMENDS against including such =
checks.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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 =
lang=3DEN-US
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
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
font-family:"Times New Roman";color:windowtext'>

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:windowtext'> [e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Peter Hesse<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, July 29, =
2008 3:03
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Inhibit =
Any-Policy
extension</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>Regarding the Inhibit anyPolicy extension =
(id-ce 54),
RFC 5280 says &#8220;Conforming CAs MUST mark this extension as =
critical.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>X.509 says &#8220;This extension may, at the =
option of
the certificate issuer, be either critical or non-critical. It is =
recommended
that it be critical, otherwise a certificate user may not correctly =
interpret
the stipulation of the issuing CA.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>We have found a case in which a certificate =
processing
implementation has rejected a certificate because it has a non-critical =
inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 =
(This
extension MUST be critical).&nbsp; The PKI policy authority made the =
decision
to mark this extension non-critical following X.509.&nbsp; We will work =
on
getting the certificate processing implementation to be more forgiving, =
but in
the meantime it bring up this question: Why does RFC5280 differ from =
X.509 on
the criticality of this extension?&nbsp; There is a pretty significant
difference between a &#8220;recommendation&#8221; and a =
&#8220;MUST&#8221;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>--Peter<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<div>

<div>

<div>

<div>

<div class=3DMsoNormal><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New Roman"'>

<hr size=3D2 width=3D450 style=3D'width:337.5pt' align=3Dleft>

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

</div>

</div>

</div>

</div>

</div>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DConsolas><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span></font><font=
 size=3D2
color=3D"#3333cc" face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Consolas;color:#3333CC'>Peter =
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;</span></font><font size=3D2 face=3DConsolas><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Consolas'> </span></font><font =
size=3D2
color=3Dblue face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
Consolas;color:blue'>[e-mail]<o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DConsolas><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span></font><font=
 size=3D2
color=3D"#3333cc" face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Consolas;color:#3333CC'>Phone: [phone] =
x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gemini
Security Solutions, Inc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
color=3D"#cc3333"
face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Consolas;
color:#CC3333'>&nbsp;&nbsp;&nbsp;&nbsp;Visit our relaunched website! <a
href=3D"http://geminisecurity.com/">http://geminisecurity.com</a></span><=
/font><font
size=3D1 color=3Dteal face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:5.0pt;
font-family:Consolas;color:teal'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><i><font size=3D2 color=3Dteal =
face=3DConsolas><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Consolas;color:teal;font-style:ital=
ic'>&quot;A
good programmer is someone who always looks both ways before<br>
&nbsp;crossing a one-way street.&quot; --Doug =
Linder</span></font></i><i><span
lang=3DEN-US style=3D'font-style:italic'><o:p></o:p></span></i></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0080_01C8F232.01B42950--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TNaqGx026160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 16:36:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TNaqhd026159; Tue, 29 Jul 2008 16:36:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TNaiQF026148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 29 Jul 2008 16:36:51 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6TNagU3017459 for <[e-mail]>; Tue, 29 Jul 2008 19:36:42 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6TNagXP205660 for <[e-mail]>; Tue, 29 Jul 2008 19:36:42 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6TNag1Z023319 for <[e-mail]>; Tue, 29 Jul 2008 19:36:42 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6TNagfx023311; Tue, 29 Jul 2008 19:36:42 -0400
In-Reply-To: <[e-mail]>
To: Massimiliano Pala <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 29 Jul 2008 19:36:41 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 07/29/2008 19:36:42, Serialize complete at 07/29/2008 19:36:42
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Max:

        The DNS Name has to go into a specific extension to be used.  I 
don't think that putting a DNS Name into IssuerAltName means "look here 
for SRV records associated with PKI management", and its most common 
meaning in SubjectAltName is "expect to see this certificate when you 
connect to this DNS Name", but an AccessDescription could easily be 
assigned to mean that it's a pointer to SRV records.  There are General 
Names associated with AKI, CRL Distribution Point, and Name Constraint as 
well, but they clearly are not appropriate for such purposes.
        An argument that "DNS is not the right mechanism for this, and 
it's worth a new protocol to avoid using DNS" is different than the one 
you made in the first version of your draft.  It looks to me like the 
argument against DNS usage would rely heavily on the perception that DNS 
isn't secure enough, especially for revocation information.  Is that 
really a strong enough reason to expect typical relying parties to 
implement a new client protocol?

                Tom Gindin




Massimiliano Pala <[e-mail]> 
07/29/2008 10:48 AM

To
Tom Gindin/Watson/IBM@IBMUS
cc
[e-mail]
Subject
Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt






Hi Tom,

I do not understand how this actually applies. The dnsName is just one 
type
of GeneralNames (if I do remember correctly), therefore considerations 
about
AIA and SIA are not actually affected.

I do, anyway, understand your point: can we add a reference in the 
certificate
so that we know which DNS domain we shall query for DNS SRV records 
related
to PKI resources ?

I considered this, and I do really think it is a viable solution. I do 
have
some personal concerns about using DNS for this purpose. I think DNS SRV
records work great for services provided within an organization (eg., 
within
a university .example.edu - I am not aware of anyone who is actually using
DNS SRV records on public DNSs) but having PKI managers to modify the DNS
servers can be painful in certain environments. Besides this, having a
separate service allows us to provide signed messages (both client and 
server)
with NONCE. Moreover, a service that is decoupled from DNS can be easier 
to
maintain, especially in a trusted-responder multi-CAs mode.

But if other people share your opinion, please let me know, so we can 
update
the document properly.

Later,
Max


Tom Gindin wrote:
>         Section 2.1 of this draft gives an overview of existing 
solutions 
> and their limitations.  It does not appear that any consideration was 
> given to adding a new AccessDescription (to the SIA and/or AIA 
extensions) 
> for SRV record access.  The argument against the use of SRV records 
given 
> in 2.1.2 is that there is not generally a fixed mapping between the 
> certificate and a DNS space, which does not apply to a DNSName within an 

> AIA or SIA extension.






Received: from zz20920582109.cipherkey.net (zz20920582109.cipherkey.net [209.205.82.109] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6TN7O7K024033; Tue, 29 Jul 2008 16:07:25 -0700 (MST) (envelope-from [e-mail])
Received: from winxp ([82.230.130.161] helo=winxp) by 6d52cdd1tpfg.com (8.12.7/8.12.7) with ESMTP id 318D609B17D3 for <[e-mail]>; Tue, 29 Jul 2008 16:06:54 -0800
Message-ID: <000e01c8f195$1e4727e0$0623b77c@winxp>
From: Lynda <[e-mail]>
To: [e-mail]
Subject: a catalogue
Date: Tue, 29 Jul 2008 16:06:54 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C8F195.1E4727E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.2963
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1409

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C8F195.1E4727E0
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable


conscious choices about the information they receive, they can
more computer sights coming on line and appearing throughout the
expressions.  For instance, if we were to look at a painting on a

------=_NextPart_000_000B_01C8F195.1E4727E0
Content-Type: text/html;
	charset="windows-1251"
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=
1">
<META content=3D"MSHTML 6.00.2800.1409" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>are real there is no problem. We will never create V.R. so</DIV><BR>
<P><DIV>C A 6N A D/9AN &nbsp;&nbsp;&nbsp; P 4 3H A RM A 6CY </DIV></P>
<DIV>V/A \G _RA - $1.49 </DIV>
<DIV>C 0/ A L / S - $2.20</DIV>
<DIV>S4 O M A - $0.65</DIV>
<DIV>L E6 V / T R A - $3.66</DIV>
<DIV>FEMALE \V0/0A8G0R5A - $1.57</DIV>
<DIV>U 2 L T 3R A M - $1.37</DIV>
<DIV>165  Items on Sale Today.</DIV>
<P><DIV><A href=3D"http://geocities.com/cdecwhksf"><b><font size=3D4>More f=
or less</font></b></A></DIV></P>
<DIV>occur during summer rainstorms as when I was younger. People</DIV>

</BODY></HTML>

------=_NextPart_000_000B_01C8F195.1E4727E0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TJuAjT010409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 12:56:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TJuAGA010408; Tue, 29 Jul 2008 12:56:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6TJu8sc010400 for <[e-mail]>; Tue, 29 Jul 2008 12:56:08 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 17031 invoked from network); 29 Jul 2008 19:44:40 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;29 Jul 2008 19:44:40 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 29 Jul 2008 19:44:39 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F1B5.233BE235"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Inhibit Any-Policy extension
Date: Tue, 29 Jul 2008 15:56:06 -0400
Message-ID: <[e-mail]>
In-Reply-To: <001701c8f1ad$c53ee9d0$4fbcbd70$@com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Inhibit Any-Policy extension
Thread-Index: AcjxrcE7ablGPJgpTZ+TTijYDz/wFwAAvcsA
References: <001701c8f1ad$c53ee9d0$4fbcbd70$@com>
From: "Santosh Chokhani" <[e-mail]>
To: "Peter Hesse" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F1B5.233BE235
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Peter,

=20

5280 processing rules recommend that relying party not enforce this
criticality.  I recommend that the relying party software in your
situation be modified to not check and enforce criticality.

=20

See paragraph 3 of Section 6.1 of 5280 and I quote below:

=20

"While the certificate and CRL profiles specified in Sections 4 and 5

   of this document specify values for certificate and CRL fields and

   extensions that are considered to be appropriate for the Internet

   PKI, the algorithm presented in this section is not limited to

   accepting certificates and CRLs that conform to these profiles.

   Therefore, the algorithm only includes checks to verify that the

   certification path is valid according to X.509 and does not include

   checks to verify that the certificates and CRLs conform to this

   profile.  While the algorithm could be extended to include checks for

   conformance to the profiles in Sections 4 and 5, this profile

   RECOMMENDS against including such checks."

=20

=20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Peter Hesse
Sent: Tuesday, July 29, 2008 3:03 PM
To: [e-mail]
Subject: Inhibit Any-Policy extension

=20

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."

=20

X.509 says "This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA."

=20

We have found a case in which a certificate processing implementation
has rejected a certificate because it has a non-critical inhibit
anyPolicy.  This is most likely because of the wording in 3280 (This
extension MUST be critical).  The PKI policy authority made the decision
to mark this extension non-critical following X.509.  We will work on
getting the certificate processing implementation to be more forgiving,
but in the meantime it bring up this question: Why does RFC5280 differ
from X.509 on the criticality of this extension?  There is a pretty
significant difference between a "recommendation" and a "MUST".

=20

Thanks,

=20

--Peter

=20

________________________________

 Peter Hesse                       [e-mail]

 Phone: [phone] x105      Gemini Security Solutions, Inc.

    Visit our relaunched website! http://geminisecurity.com
<http://geminisecurity.com/>=20

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder

=20


------_=_NextPart_001_01C8F1B5.233BE235
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:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns2=3D"http://schemas.microsoft.com/office/2004/12/omml">

<head>
<meta http-equiv=3DContent-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]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Calibri;
	color:#1F497D;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
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=3DEN-US link=3Dblue vlink=3Dpurple>

<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'>Peter,<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'>5280 processing rules recommend =
that
relying party not enforce this criticality.&nbsp; I recommend that the =
relying
party software in your situation be modified to not check and enforce
criticality.<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'>See paragraph 3 of Section 6.1 of =
5280 and
I quote below:<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 style=3D'text-autospace:none'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&#8220;</span></f=
ont><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:
"Courier New";color:windowtext'>While the certificate and CRL profiles
specified in Sections 4 and 5<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; of this document specify values for =
certificate
and CRL fields and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; extensions that are considered to be =
appropriate
for the Internet<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; PKI, the algorithm presented in this =
section is
not limited to<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; accepting certificates and CRLs that =
conform to
these profiles.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; Therefore, the algorithm only includes =
checks to
verify that the<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; certification path is valid according to =
X.509
and does not include<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; checks to verify that the certificates =
and CRLs
conform to this<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; profile.&nbsp; While the algorithm could =
be
extended to include checks for<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; conformance to the profiles in Sections 4 =
and 5,
this profile<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; RECOMMENDS against including such =
checks.&#8221;<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'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Peter Hesse<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, July 29, =
2008 3:03
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Inhibit =
Any-Policy
extension</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>Regarding the Inhibit anyPolicy extension =
(id-ce 54),
RFC 5280 says &#8220;Conforming CAs MUST mark this extension as
critical.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>X.509 says &#8220;This extension may, at the =
option of
the certificate issuer, be either critical or non-critical. It is =
recommended
that it be critical, otherwise a certificate user may not correctly =
interpret
the stipulation of the issuing CA.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>We have found a case in which a certificate =
processing
implementation has rejected a certificate because it has a non-critical =
inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 =
(This
extension MUST be critical).&nbsp; The PKI policy authority made the =
decision
to mark this extension non-critical following X.509.&nbsp; We will work =
on
getting the certificate processing implementation to be more forgiving, =
but in
the meantime it bring up this question: Why does RFC5280 differ from =
X.509 on
the criticality of this extension?&nbsp; There is a pretty significant
difference between a &#8220;recommendation&#8221; and a =
&#8220;MUST&#8221;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>--Peter<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<div>

<div>

<div>

<div class=3DMsoNormal><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>

<hr size=3D2 width=3D450 style=3D'width:337.5pt' align=3Dleft>

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

</div>

</div>

</div>

</div>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DConsolas><span
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span></font><font=
 size=3D2
color=3D"#3333cc" face=3DConsolas><span =
style=3D'font-size:10.0pt;font-family:Consolas;
color:#3333CC'>Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;</span></font><font size=3D2 face=3DConsolas><span =
style=3D'font-size:
10.0pt;font-family:Consolas'> </span></font><font size=3D2 color=3Dblue
face=3DConsolas><span =
style=3D'font-size:10.0pt;font-family:Consolas;color:blue'>pmhesse@gemini=
security.com<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DConsolas><span
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span></font><font=
 size=3D2
color=3D"#3333cc" face=3DConsolas><span =
style=3D'font-size:10.0pt;font-family:Consolas;
color:#3333CC'>Phone: [phone] =
x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gemini
Security Solutions, Inc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
color=3D"#cc3333"
face=3DConsolas><span =
style=3D'font-size:10.0pt;font-family:Consolas;color:#CC3333'>&nbsp;&nbsp=
;&nbsp;&nbsp;Visit
our relaunched website! <a =
href=3D"http://geminisecurity.com/">http://geminisecurity.com</a></span><=
/font><font
size=3D1 color=3Dteal face=3DConsolas><span =
style=3D'font-size:5.0pt;font-family:Consolas;
color:teal'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><i><font size=3D2 color=3Dteal =
face=3DConsolas><span
style=3D'font-size:10.0pt;font-family:Consolas;color:teal;font-style:ital=
ic'>&quot;A
good programmer is someone who always looks both ways before<br>
&nbsp;crossing a one-way street.&quot; --Doug =
Linder</span></font><o:p></o:p></i></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C8F1B5.233BE235--



Received: from 232-45-18-190.fibertel.com.ar (232-45-18-190.fibertel.com.ar [190.18.45.232] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TJRWZM006924 for <[e-mail]>; Tue, 29 Jul 2008 12:27:36 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 29 Jul 2008 16:27:30 -0300
From: Thenstedt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: [e-mail]
Subject: Tropical storm watch issued for Florida
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Shark attack off Australia, 2 dead http://www.kapitalmaster.com/default.html


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TJ8qQO005317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 12:08:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TJ8q49005316; Tue, 29 Jul 2008 12:08:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6TJ8oBJ005300 for <[e-mail]>; Tue, 29 Jul 2008 12:08:51 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21195 invoked from network); 29 Jul 2008 19:08:47 -0000
Received: from [e-mail] by sottccs1.entrust.com with EntrustECS-Server-8.0;29 Jul 2008 19:08:47 -0000
Received: from unknown (HELO sottexch1.corp.ad.entrust.com) (10.4.51.28) by sottccs1.entrust.com with SMTP; 29 Jul 2008 19:08:46 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Status of domain-certs-01 and sip-eku-02
Date: Tue, 29 Jul 2008 15:08:48 -0400
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0146_01C8F18D.006E98F0"
Message-ID: <[e-mail]>
In-Reply-To: <p06240509c4b33b20715a@[130.129.21.37]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Status of domain-certs-01 and sip-eku-02
Thread-Index: AcjwlVy9mdSLkdlYQQiHuJ2pSzXdJQBGKovQ
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]> <p06240815c4a2a3686524@[10.20.30.162]> <[e-mail]> <p06240509c4b33b20715a@[130.129.21.37]>
From: "Tim Moses" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Paul Hoffman" <[e-mail]>, "Vijay K. Gurbani" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0146_01C8F18D.006E98F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Steve.  I was thinking that a new SAN type-id may be a suitable way of
indicating that the certificate's subject may not identify a namespace that
includes the name of the server (the authorized SIP Proxy) to which you are
directly connected, but rather one that includes the name of another server;
the one that vouches for the SIP proxy.

Syntactically, it's a URI, but semantically it's different from the usual
SAN URI option.

Just a thought.

All the best.  Tim.

Tim Moses
[phone]

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Monday, July 28, 2008 5:02 AM
To: Tim Moses
Cc: Paul Hoffman; Vijay K. Gurbani; [e-mail]
Subject: RE: Status of domain-certs-01 and sip-eku-02

At 2:36 PM -0400 7/22/08, Tim Moses wrote:
>Colleagues - I wonder whether defining a SIP type-id for the SAN 
>OtherName option is an approach more faithful to the 5280 intent.  The 
>EKU value 'id-kp-serverAuth' could still be included.  All the best.  Tim.
>
>Tim Moses

Tim,

Which portion of the problem we're discussing would the SIP type-id address?

Steve

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILDjCCA28w
ggJXoAMCAQICBEZD3ZYwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0Vu
dHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQwHhcNMDgwNzAyMTI0NzI1WhcNMDkwMTAyMTMxNzI1WjBV
MQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEiMA4GA1UE
BRMHMDUwNDA2NzAQBgNVBAMTCVRpbSBNb3NlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
qkuPDFjmaH5mlOGq/dpUl2fmYlRU8CAA4Z64q2TYF4kGFIxpR4fo7mBqg6NWxoBuKdz/xPaJyFW1
R7VVi2j9o+n6d6MtJOoViP7bqd2AXBu9ajkGaPWsNueYLV2CT8IN1TpO7eXrd4MzxWVc17hRG75D
w+nsn8PS93JaBGU13OUCAwEAAaOB7jCB6zALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EVdGltLm1v
c2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBBMQswCQYDVQQGEwJDQTEQMA4GA1UE
ChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwGA1UEAxMFQ1JMNDEwHwYDVR0jBBgwFoAU
8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFHK0leDUoj21d/Mkoj4QN6PoC1geMAkGA1Ud
EwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADggEBALOxURM9
D5N9grt6M6Nn/VIurOBkc10m4VFR09/FSYoDik8SYyijDLDq7gRWnW0cFTzJ0y4HmwQJoQi/gMEA
ZvWxBPjfyATF+7i7mJ1aHarCTQMRMOG7nmrAbspduhTQuAIlciZ8+nk0JLYg6CaCFDWnYZNO0S11
4HY62FBX5VVpQearw2LMDY0duvfNmQLOfKs1KPBvsSbgjceANfgO4rD2NfTmo5wtCRJc4FQc0IzO
YlPsdTo8ccmvANPqNgcvX7HFQB09bCKABwlazc81gUEV6Fvk5Q6yj5HWVYEX1XRohTtfp7wvPBbU
wBVQFxF2Q6L5d+rm7BdKJPriMH5BEFEwggOeMIIChqADAgECAgRGQ9QjMA0GCSqGSIb3DQEBBQUA
MDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTA4
MDUyODEyMDU1NFoXDTA4MTEyODEyMzU1NFowVTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1
c3QxEDAOBgNVBAsTB1IgYW5kIEQxIjAOBgNVBAUTBzA1MDQwNjcwEAYDVQQDEwlUaW0gTW9zZXMw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOl0SmUWMFxHEeO85s2FFmMP1Obp3WCH8ONtrprz
OeMerFsyvpeRYVnJpSPJ0rMA6wIE3HWEaGdx5jHRxtu713Du3dUKi15EHEgcNkHeDf+g58CJxAQx
kL49YvGalUGhYzKkQj/hhCEaY2DJJ4MJYNcVQO5WoyJwzu1ypAQM/XGlAgMBAAGjggEcMIIBGDAL
BgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwODA1MjgxMjA1NTRagQ8yMDA4MTAwNDA3MzU1NFow
IAYDVR0RBBkwF4EVdGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBBMQsw
CQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwGA1UEAxMF
Q1JMNDEwHwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFBan8ggdNrI1
pRljjZdiuIWT9UCBMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZI
hvcNAQEFBQADggEBAALBIwvlxEYlKgVdAoLENGU5QGnJXo5DtRn0e4ubBWzGidE8gxJLAC1lBAfo
716Nm2HTdttFvYibUi6Y9CLfooOZsbt+RbkGBtElsKPjpsFoDtYhUcVDxmpS58LI2DJCFCic7rUX
sxZzxxXRiSN/A8BHb4LQOCdGcXsEwQkj4yvy6ReKfGt8jUIIAotyCuIiwApAzcG9IuIABPYOLV3m
iSLWLZ39YcCr+0FlfmvmGoPy2CUcGE9UOeeesSW5IWTACQAQKnGC64krAaKrSNcY7mh9XJsXVMxT
6e6ss7D1EyQ2kGcaxoXhzMFbJTEd+c0wPMiFctd9KadBUIEOCeMuKK0wggP1MIIC3aADAgECAgQy
SKogMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYD
VQQLEwdSIGFuZCBEMB4XDTAyMDQxNzAyMjAyNloXDTIyMDQxNzAyNTAyNlowMTELMAkGA1UEBhMC
Q0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC8h4iN+gPkPzqwPwJ6EH6RWFglMv5W5pRmJWKMZ69ROWdQDDLVak5hWkUJ
rxUrXXpMn6j31rE3WMxuxUFh9HMWT1JaXiIAf4/InVLoPliXn3cqMc+EEJ90PS/0qg+peELBGWS+
6mt42UXHcUWTZR/mMb+L1II/3bk5dvPfCh3aZ0i7y541aBOYDZcA4F0dmDodgqjnQFZQiC1HAW/N
uHUnnv6A10fExgtma+PmxpLWYNNKJuQ8f8Bj4P7ECjNGbI5hrhJjYdV9lIzZI/syS5W0qnXunOHC
JyhYAYpesp4NFYNh5kFMmMeg0/9Jcp2lLNjutXwY+t9YWiiBzjfnRVujAgMBAAGjggETMIIBDzAR
BglghkgBhvhCAQEEBAMCAAcwUwYDVR0fBEwwSjBIoEagRKRCMEAxCzAJBgNVBAYTAkNBMRAwDgYD
VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQkMCKA
DzIwMDIwNDE3MDIyMDI2WoEPMjAyMjA0MTcwMjUwMjZaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAW
gBTz8Cwo5jmnNBmrmpGopmZAkpzicTAdBgNVHQ4EFgQU8/AsKOY5pzQZq5qRqKZmQJKc4nEwDAYD
VR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNi4wOjQuMAMCBJAwDQYJKoZIhvcNAQEFBQAD
ggEBAIA+ebVGmfnJrmQEsWlyRG3D5e5j8bmbq5Af2FVeB5yGn6Lr+1eViNDxxycnLUdw6Y9LvXwu
Qbh2vEF+uGM71pO52/5M0gxH2LNrLv3qGwGTutoGli3Fq84SPFvyN+n4R6XO2BxJmjvfuZjNyuv2
kOPMmV2yuILM8NT83TnZH5EnhGz/QiK5bMhUfvL31L076sbXg+MQo1CEDf2BPCD2IwG1CiSwN8q7
T1QJoWwTtphQLx4TTDOSLgb4OXlEoTnswZpgCH5xxybI9HpfD+CXxijdgaE5bPepq0CFtumUAKb0
tKZ24xItdDJuR7pyrklRvxz1UzOL1wiK/odt/X/E5s8xggMCMIIC/gIBATA5MDExCzAJBgNVBAYT
AkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEAgRGQ9QjMAkGBSsOAwIaBQCg
ggIfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDcyOTE5MDg0
N1owIwYJKoZIhvcNAQkEMRYEFHZ5fVukEpWq+V7mh2+LhlaUfMPkMEgGCSsGAQQBgjcQBDE7MDkw
MTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQCBEZD3ZYw
SgYLKoZIhvcNAQkQAgsxO6A5MDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYD
VQQLEwdSIGFuZCBEAgRGQ92WMIIBKAYJKoZIhvcNAQkPMYIBGTCCARUwCgYIKoZIhvcNAwcwBwYF
Kw4DAhowCgYIKoZIhvcNAgIwCgYIKoZIhvcNAgQwCgYIKoZIhvcNAgUwDgYIKoZIhvcNAwQCAgCA
MA0GCCqGSIb3DQMEAgEoMAcGBSsOAwIHMA4GCSqGSIb2fQdCAwIBQDAOBgkqhkiG9n0HQgMCASgw
DwYJKoZIhvZ9B0IKAgIAgDARBgsrBgEEAYE8BwEBAgICAIAwDwYJYIZIAWUDBAECAgIAgDAPBglg
hkgBZQMEARYCAgDAMA8GCWCGSAFlAwQBKgICAQAwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAWxSJlW4k
j1Bx3xUv4Dfnv5ag8SpJ5MvoiqYo7X40DpSsnD7bqlan1xEaP2aO8dN2ZR2s/yeHONTQDSbN+v/M
Wes4cZdDYFxy0ScUshR7gaSOReS4bha77ronlno4x7VKi2IfJLThbYx/EbLcqphc3nqjaOD5PX6b
4HnstiZGjFoAAAAAAAA=

------=_NextPart_000_0146_01C8F18D.006E98F0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TJ3c8X004885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 12:03:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TJ3c8e004884; Tue, 29 Jul 2008 12:03:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TJ3UsI004869 for <[e-mail]>; Tue, 29 Jul 2008 12:03:37 -0700 (MST) (envelope-from [e-mail])
Received: from PeterVistaSP1 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTPSA id 95F1C995CF for <[e-mail]>; Tue, 29 Jul 2008 19:03:27 +0000 (GMT)
From: "Peter Hesse" <[e-mail]>
To: <[e-mail]>
Subject: Inhibit Any-Policy extension
Date: Tue, 29 Jul 2008 15:03:16 -0400
Message-ID: <001701c8f1ad$c53ee9d0$4fbcbd70$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C8F18C.3E2D49D0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcjxrcE7ablGPJgpTZ+TTijYDz/wFw==
Content-Language: en-us
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multipart message in MIME format.

------=_NextPart_000_0018_01C8F18C.3E2D49D0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."

 

X.509 says "This extension may, at the option of the certificate issuer, be
either critical or non-critical. It is recommended that it be critical,
otherwise a certificate user may not correctly interpret the stipulation of
the issuing CA."

 

We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit anyPolicy.
This is most likely because of the wording in 3280 (This extension MUST be
critical).  The PKI policy authority made the decision to mark this
extension non-critical following X.509.  We will work on getting the
certificate processing implementation to be more forgiving, but in the
meantime it bring up this question: Why does RFC5280 differ from X.509 on
the criticality of this extension?  There is a pretty significant difference
between a "recommendation" and a "MUST".

 

Thanks,

 

--Peter

 

  _____  

 Peter Hesse                       [e-mail]

 Phone: [phone] x105      Gemini Security Solutions, Inc.

    Visit our relaunched website!  <http://geminisecurity.com/>
http://geminisecurity.com



"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder

 


------=_NextPart_000_0018_01C8F18C.3E2D49D0
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:m=3D"http://schemas.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)">
<!--[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]-->
<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:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
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:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
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=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Regarding the Inhibit anyPolicy extension (id-ce =
54), RFC 5280
says &#8220;Conforming CAs MUST mark this extension as =
critical.&#8221;<o:p></o:p></p>

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

<p class=3DMsoNormal>X.509 says &#8220;This extension may, at the option =
of the
certificate issuer, be either critical or non-critical. It is =
recommended that
it be critical, otherwise a certificate user may not correctly interpret =
the
stipulation of the issuing CA.&#8221;<o:p></o:p></p>

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

<p class=3DMsoNormal>We have found a case in which a certificate =
processing
implementation has rejected a certificate because it has a non-critical =
inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 =
(This
extension MUST be critical).&nbsp; The PKI policy authority made the =
decision
to mark this extension non-critical following X.509.&nbsp; We will work =
on
getting the certificate processing implementation to be more forgiving, =
but in
the meantime it bring up this question: Why does RFC5280 differ from =
X.509 on the
criticality of this extension?&nbsp; There is a pretty significant =
difference
between a &#8220;recommendation&#8221; and a =
&#8220;MUST&#8221;.<o:p></o:p></p>

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

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

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

<p class=3DMsoNormal>--Peter<o:p></o:p></p>

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

<div>

<div>

<div>

<div class=3DMsoNormal><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>

<hr size=3D2 width=3D450 style=3D'width:337.5pt' align=3Dleft>

</span></div>

</div>

</div>

</div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span><span
style=3D'font-size:10.0pt;font-family:Consolas;color:#3333CC'>Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;</span><span =
style=3D'font-size:10.0pt;font-family:Consolas'> </span><span
style=3D'font-size:10.0pt;font-family:Consolas;color:blue'>pmhesse@gemini=
security.com<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span><span
style=3D'font-size:10.0pt;font-family:Consolas;color:#3333CC'>Phone: =
703-378-5808
x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gemini Security Solutions, =
Inc.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:Consolas;
color:#CC3333'>&nbsp;&nbsp;&nbsp;&nbsp;Visit our relaunched website! <a
href=3D"http://geminisecurity.com/"><span =
style=3D'color:blue'>http://geminisecurity.com</span></a></span><span
style=3D'font-size:10.0pt;font-family:Consolas;color:gray'><br>
<br>
</span><span =
style=3D'font-size:5.0pt;font-family:Consolas;color:teal'><o:p></o:p></sp=
an></p>

<p class=3DMsoNormal><i><span =
style=3D'font-size:10.0pt;font-family:Consolas;
color:teal'>&quot;A good programmer is someone who always looks both =
ways
before<br>
&nbsp;crossing a one-way street.&quot; --Doug =
Linder</span></i><i><o:p></o:p></i></p>

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

</div>

</body>

</html>

------=_NextPart_000_0018_01C8F18C.3E2D49D0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TEpH1v084024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 07:51:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6TEpHwp084023; Tue, 29 Jul 2008 07:51:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TEpGvf084016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 29 Jul 2008 07:51:17 -0700 (MST) (envelope-from [e-mail])
Received: from titan.cs.dartmouth.edu ([130.129.18.33]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.14.2/8.14.2) with ESMTP id m6TEp9Kb016324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jul 2008 10:51:14 -0400
DomainKey-Signature: a=rsa-sha1; s=mail; d=cs.dartmouth.edu; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type; b=QjZCbiNBltqGffl8jb9yqEok8/l5X9kuM9n6MiYS4THyN/dxR//UOUcOqb015vxfg Ag6tqFbUxDpNXYInorEvA==
Message-ID: <[e-mail]>
Date: Tue, 29 Jul 2008 15:48:11 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090803030803000804010306"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms090803030803000804010306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tom,

I do not understand how this actually applies. The dnsName is just one type
of GeneralNames (if I do remember correctly), therefore considerations about
AIA and SIA are not actually affected.

I do, anyway, understand your point: can we add a reference in the certificate
so that we know which DNS domain we shall query for DNS SRV records related
to PKI resources ?

I considered this, and I do really think it is a viable solution. I do have
some personal concerns about using DNS for this purpose. I think DNS SRV
records work great for services provided within an organization (eg., within
a university .example.edu - I am not aware of anyone who is actually using
DNS SRV records on public DNSs) but having PKI managers to modify the DNS
servers can be painful in certain environments. Besides this, having a
separate service allows us to provide signed messages (both client and server)
with NONCE. Moreover, a service that is decoupled from DNS can be easier to
maintain, especially in a trusted-responder multi-CAs mode.

But if other people share your opinion, please let me know, so we can update
the document properly.

Later,
Max


Tom Gindin wrote:
>         Section 2.1 of this draft gives an overview of existing solutions 
> and their limitations.  It does not appear that any consideration was 
> given to adding a new AccessDescription (to the SIA and/or AIA extensions) 
> for SRV record access.  The argument against the use of SRV records given 
> in 2.1.2 is that there is not generally a fixed mapping between the 
> certificate and a DNS space, which does not apply to a DNSName within an 
> AIA or SIA extension.



--------------ms090803030803000804010306
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx
NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v
dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG
CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI
hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg
bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8
fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw
EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi
BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91
dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0
dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm
MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI
KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3
DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6
AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG
nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV
jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl
AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE
aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ
MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt
b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1
MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK
CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG
9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu
GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8
K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR
BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG
A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0
aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0
cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw
IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr
BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN
AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC
KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad
L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN
gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA
lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4
MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0
bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE
AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNzI5MTQ0ODExWjAjBgkqhkiG9w0B
CQQxFgQUYFtrSJDM5I+lIHSESndfY5XLLJ4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT
8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs
ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx
f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy
dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYB7RK8zUgqt5EFN9oBpEHmE
fZAMh/yJivamIktpTMPP+XBIBgLx3GfwicXp5Sbq56WBcbdnb2ETl+Q9+z1L9CCK4XKFlmdQ
v9yYr48eesW/lWN0PIwpKs8xq+/pct4AEw2tFRYViUs5eaY+4nj02MSgiJEdu6JkdDWaiXK0
r22F/QAAAAAAAA==
--------------ms090803030803000804010306--



Received: from [125.112.199.54] ([125.112.202.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6TCNR9L069510 for <[e-mail]>; Tue, 29 Jul 2008 05:23:31 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Obama denies wrongdoing in Presidential debate
From:   vu <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Tue, 29 Jul 2008 20:23:13 +0800
Message-ID: <yt.ipekkzndzoodao@2280B8E05FFB4BD>
User-Agent: Opera Mail/9.50 (Win32)

Cats found eating human corpse
http://thelittles.fr/default.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from 217-220-202-62-static.albacom.net (217-220-202-62-static.albacom.net [217.220.202.62] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SLNPXu001516 for <[e-mail]>; Mon, 28 Jul 2008 14:23:26 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Organ increase results proven in all subjects
From:   abate <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Mon, 28 Jul 2008 23:22:14 +0200
Message-ID: <ad.kzfgpihicplgqu@GFWS1>
User-Agent: Opera Mail/9.50 (Win32)

I took a picture of her face in utter shock when she saw my size
http://www.talewill.com/

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6S9aFCQ036974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 02:36:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6S9aFCi036973; Mon, 28 Jul 2008 02:36:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6S9a7r6036945 for <[e-mail]>; Mon, 28 Jul 2008 02:36:14 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.21.37]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KNP99-0000Pv-EM; Mon, 28 Jul 2008 05:36:03 -0400
Mime-Version: 1.0
Message-Id: <p06240509c4b33b20715a@[130.129.21.37]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]> <p06240815c4a2a3686524@[10.20.30.162]> <[e-mail]>
Date: Mon, 28 Jul 2008 05:01:30 -0400
To: "Tim Moses" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Status of domain-certs-01 and sip-eku-02
Cc: "Paul Hoffman" <[e-mail]>, "Vijay K. Gurbani" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:36 PM -0400 7/22/08, Tim Moses wrote:
>Colleagues - I wonder whether defining a SIP type-id for the SAN OtherName
>option is an approach more faithful to the 5280 intent.  The EKU value
>'id-kp-serverAuth' could still be included.  All the best.  Tim.
>
>Tim Moses

Tim,

Which portion of the problem we're discussing would the SIP type-id address?

Steve



Received: from tdbanknorth.com ([121.136.46.247]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6Q7GZuT054363 for <[e-mail]>; Sat, 26 Jul 2008 00:16:36 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001701c8eeef$853586f2$660aa8c0@user-4c33b33472>
From: "TD Banknorth Business" <[e-mail]>
To: <[e-mail]>
Subject: Authorize Your TD Banknorth Business Account
Date: Sat, 26 Jul 2008  16:16:27 +0900
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0013_01C8EF3A.F51AB910"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C8EF3A.F51AB910
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0014_01C8EF3A.F51AB910"


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

   [IMAGE]

   Dear TD Banknorth Treasury Management customer,

   Security and confidentiality are at the heart of the TD Banknorth.
   Your details (and your money) is protected by a number of
   technologies, including Secure Sockets Layer (SSL) encryption.
   We would like to notify you that TD Banknorth Commercial carries out
   customer details confirmation procedure that is compulsory for all TD
   Banknorth Commercial customers. This procedure is attributed to a
   routine banking software update.

   Please login to TD Banknorth Treasury Management using the link below
   and follow the instructions on the screen.

   http://webexpress5.tdbanknorth.com/wcmfd/wcmpw/CustomerVerify.htm?portal=3D25zdnoWjpzmWcskwzgdDzbkOhsa

   TD Banknorth Commercial Customer Service


------=_NextPart_001_0014_01C8EF3A.F51AB910
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.2722" name=3DGENERATOR>
<title>TD Banknorth Treasury Management: User Verification Procedure</title>
<STYLE></STYLE>
</HEAD>
<body>
<p><span><img id=3D"u7447an38208" src=3D"cid:001201c8eeef$85332498$660aa8c0@user-4c33b33472"></span></p>
<p><font     face=3D"Arial, Helvetica, sans-serif">Dear   TD Banknorth Treasury Management   customer,</font></p>
<p><font     face=3D"Arial, Helvetica, sans-serif">Security      and      confidentiality      are   at   the   heart       of  the TD Banknorth.    Your    details   (and     your money)   is      protected     by    a   number     of     technologies,     including  Secure     Sockets    Layer      (SSL) encryption.<br>
We      would   like       to      notify you that       TD Banknorth Commercial    carries   out  customer       details      confirmation     procedure      that    is     compulsory    for  all       TD Banknorth Commercial    customers. This   procedure is     attributed  to    a   routine  banking      software    update.</font></p>
<p><font face=3D"Arial, Helvetica, sans-serif">Please     login   to  TD Banknorth Treasury Management     using     the link     below       and follow  the      instructions   on       the     screen.</font></p>
<p><u><span style=3D'color:blue'><font   face=3D"Arial, Helvetica, sans-serif"><a       href=3D"http://ww6.tdbanknorth.com.mode82.co.uk/wcmfd/wcmpw/CustomerVerify.htm?ssid=3D25zdnoWjpzmWcskwzgdDzbkOhsa">http://webexpress5.tdbanknorth.com/wcmfd/wcmpw/CustomerVerify.htm?portal=3D25zdnoWjpzmWcskwzgdDzbkOhsa</a></font></span></u></p>
<p><font face=3D"Arial, Helvetica, sans-serif">TD Banknorth Commercial Customer       Service</font></p>
</body>
</html>


------=_NextPart_001_0014_01C8EF3A.F51AB910--

------=_NextPart_000_0013_01C8EF3A.F51AB910
Content-Type: image/gif;
	name="ttl093.gif"
Content-Transfer-Encoding: base64
Content-ID: <001201c8eeef$85332498$660aa8c0@user-4c33b33472>

R0lGODdh3wFCAKUAAPz+/GTCfCyuVIzSpIymnFyCdGyKfKy+vOTq7Ozy9HTKlLzixKTetKS2rDxq
XAQ6JHyWjPT69MzW1FR6bLzKxCRaRMzq1BRKNDyyZEy2bNzy5OT27JSupLTCvERuXARCLP/k6gAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA3wFCAAAG/kCQcEgsGo/IpHLJ
bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6/QS43/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYp1
RYuOj5CRkpOUlZaXmJKNmZydnp+goaKjopukp6ipqqusrYimrrGys7S1toqwt7q7vL2+p7m/wsPE
xcZ8wcfKy8zNs8nO0dLT1JPQ1djZ2tt319zf4OHN3uLl5ue25Ojr7O2h6u7x8vOO5AEC+Pn6+/z9
/vkD6AkcWM3ev4MI/wUkyLDhMYMJI0Zc6LCixV0QJWr0R/Gix4+tMm4cCRCkyZPAiNy5R7KlgI4o
Y8q0JNKlRpikCBQwYKDA/oFVCHbyLJBgplFKGRUsYMC0qdOnUJuy7IeTzoGrWLM2QLDIwYOvDyCM
iiBhQgE3FMB+5Xq07aOMCw4NoKpHrV2wFdge8gpWLKgDE8CeBSDBrl63iA9ltIBoAb+qc+5KrpCI
71e/niJcUDu4sNrDiUMLyoghA4bTGARoeKNBQOp8qFEziDNXH2Q5dgtIIHAX9CDLYUMBN+DGM9gI
opOPVmlnar/VbloPWLq0XwA4G/bdjmOXg5sOhgFQqHDXAYU3Hi5UqHABAQS8EtwA9+tAPfsP7j+s
v7Ab7IUOcBwA3AMenOeGAfqRR4FnEECwmVofXGCAcV9JYNkEymWYR037/kAHQGuMuRGBPyG64dx2
cNgllgWB+VfUe5IR6AZ5eN2F3HwAGKAiAC1+NeAD8UVAo2QeuNHjAxM8yMGRanlAoWSDaSilHBzq
4yGIb2RnHRy14YPiG3Z98MFdDbgBYwUTjKlWmUPG6B1wBFhgV5E8xtgXAAXYeRmebjIJlgNPSjbl
oHBUmc+VApSoJT8ZwOFYSXno+cAH8blxgIFu8PYnAG1WwIGaXxEAwHxtXoBcnWB90MCDe4L6gAMJ
lMqnZBAkMF6TEiDwZAF5pkror4big6ii/jTKmm11QcgqWD+5wUEFai5bZJtitfmmnpWi+hWGR9Zq
V5magjWrfwQcUGmb/p3ZRRiEvxIarGrHEtuPsW5YgGykaq3YK1hctXnXtGoRZ+2o2L5xZJEe5JtA
dwDAKO6+X5U4I2fFqZuWr+1O+e6wWRYLh72Q4sEwAAh820CTCFz8FcBgCazWtYLZRZmRTQKQcF8L
v9ywuhDTCQe6FaslHrsZS7lxvB3P+/G9IucLgAUDdgBcfOHK2KbLYMEcqsOh0gwWwk5LG6talEFM
XBz+ctDBk0NjXHSGR0eXaNKMwtFayHdIClYCR17AJMtfYf2V1g+I2pu2Mt4cOABVS1YmxFG+oaNd
gFpM9NvKxf3h3G4sug+9ADzqZbKSnqVyqmo5wGnAq4MlKo6NU3aw/s2s0x7jYEdG/t2/bJ/+AOZw
M1eHc/xw3Lk/173BANN52/mBBwC6cTJYE1AI+AOCF07wnQAs+wAFk69s++LS+2uewRTLMX1fbIMn
NPDJaY7l8f3M9oYCzCOSAAKnooLA/4H4n2/g1y75cQ4AntMHHCKQgfwR8IH0MGCJ7tYhR2kHghgU
iATtpoEOamADcRjRBTNIQndsMA8baOAIS8jCc7yrf9nxEB0isAD80aWFOBTHu2KTmtLwMDYJ+VIO
hzgO4dGBeDaZCBGXmI13JfGGTIxiNJz4xBVK8YrKoGIV8YbFLg5Di1t8iRfH+EUjzgGJYYQiGdeo
C3IMIABwjKMcZedIxzraEY4ZsB8b91gLePDxj+jwIyAHGQ5BEvKQ2jAkIhc5DUUy8pHMcCQkJ1kM
SVLykr6wJCY3eQtNcvKTsvAkKEe5ClGS8pSkMCUqV/kJVbLylZhggyxnScta2vKWuMylLYMAADs=

------=_NextPart_000_0013_01C8EF3A.F51AB910--




Received: from SAYURI (118x236x157x238.ap118.gyao.ne.jp [118.236.157.238]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6Q3ArNP041059; Fri, 25 Jul 2008 20:10:56 -0700 (MST) (envelope-from [e-mail])
Received: from [118.236.157.238] by mail.andesmobile.net; Sat, 26 Jul 2008 12:10:56 +0900
Message-ID: <01c8ef18$a8b5cf00$ee9dec76@akstcandesmobilemnsdgs>
From: "Sharlene Gagne" <[e-mail]>
To: <[e-mail]>
Subject: syrinx 
Date: Sat, 26 Jul 2008 12:10:56 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Symbo- GAGO
Global Agri-Med Technologies, Inc
Get in before they do, this is an easy doublerr
Symbo- GAGO
G l o b a l Agri - Med T e c h n o l og i e s, Inc
symbol GaG0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PJ3M0J013708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 12:03:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6PJ3MU3013707; Fri, 25 Jul 2008 12:03:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PJ3LBj013699 for <[e-mail]>; Fri, 25 Jul 2008 12:03:21 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) (authenticated as u18116613) id 47A9795002ED92B1; Fri, 25 Jul 2008 21:03:19 +0200
Message-ID: <006601c8ee89$1d3df8b0$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Kemp, David P." <[e-mail]>, <[e-mail]>
References: <[e-mail]> <00c601c8ed9a$c33d9a80$82c5a8c0@arport2v> <[e-mail]> <001401c8edd2$d8b450b0$82c5a8c0@arport2v> <[e-mail]>
Subject: Re: generateCRMFrequest() Re: The PKC-only application security model ...
Date: Fri, 25 Jul 2008 21:03:23 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Dave,
These are good questions which I will answer as well as I can.

Essentially any protocol can be augmented with additional data.
A problem with this particular case is that no standards organization
has AFAIK *ever* taken on a security-related standard with
browser bindings like Mozilla's generateCRMFrequest() or
Microsoft's CertEnroll. That KEYPROV is about
150 pages which gives a hint of how a complex NG-
provisioning PKI protocol could be.

Regarding the TPM trust indicator, there are a couple of
approaches that have one thing in common: the TPM device
has an embedded private key and certificate.  TPM 1.2
supports an incredibly elaborate and cryptographically
cool thing called DAA which even makes the connection
to the actual TPM device hidden.   Personally, I believe in
slightly less sophisticated solutions like embedding the
PoP signature in a TPM-signature.  This solution is not
100% malware proof (DAA is) but I don't find keeping
"secure" private keys exercisable by external PINs in
infected computers a particularly interesting object anyway.

Regards
Anders Rundgren


----- Original Message ----- 
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
Sent: Friday, July 25, 2008 18:03
Subject: RE: generateCRMFrequest() Re: The PKC-only application security model ...



The CRMF CertRequest contains a transaction id number, a certificate
template, and a list of control attributes.  RFC 4211 itself defines six
controls, and additional controls (such as requiring PIN activation for
use of the private key) can easily be defined.  However, unless there is
some sort of integrity mechanism between the CA and the token or TPM,
such signaling is useless - the user's workstation is a
man-in-the-middle that could easily say "sure, the private key is
protected on a TPM" and then go ahead and store it on a thumb drive.

Achieving a trusted path between the key storage device and the CA is
the challenge; including suitable signaling in a provisioning protocol
(CRMF, KEYPROV, or whatever) is a non-issue.  The certificate policies
extension has always been used by DoD to indicate (among other things)
whether the private key is stored in software, wimpy ("class 3")
hardware :-), or better ("class 4") hardware.  That extension is
meaningful only because the issuing workstations and token stock are
under control of the PKI, not the end user.

I'd be interested in learning how a CA can know that it is talking to an
actual "cheap, standardized, middleware-less" private key container, and
not someone pretending to be same.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Anders Rundgren
Sent: Thursday, July 24, 2008 5:19 PM
To: Massimiliano Pala
Cc: [e-mail]; Scott Rea
Subject: generateCRMFrequest() Re: The PKC-only application security
model ...


Hi Max,

IMO it doesn't help if Mozilla fixes bugs in
generateCRMFrequest()
because it is inferior anyway.  Lets say an issuer wanted to
specify
that a user must assign a PIN-code following some kind of policy
there is no place for that in CRMF AFAIK.

If you look on a more recent effort like IETF's KEYPROV, it
indeed supports a set of useful of key add-ons.  Unfortunately
KEYPROV does neither support PKI, nor support browsers.

A glaring omission in the current crop of PKI provisioning
schemes is the ability indicating that the private key is
generated
and stored in a TPM or similar.  Due to this and similar
disconnects, 99% (or more) of the TPMs featured in
mid-to-high-end laptops are never activated.

Regards
Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; "Scott Rea" <[e-mail]>
Sent: Thursday, July 24, 2008 17:44
Subject: Re: The PKC-only application security model ...


Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda
buggy
(at least it was some time ago...). Indeed I exchanged some
emails with
Jim Schaad and at the end we figured out that they are totally
mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are
developing that
part of the API in Mozilla/NSS so that we could try to fix the
current
mess they are doing ???

I would point out that one of the reason why PKIs have not got
further
(well, despite of what the common perception, PKIs are
definitely widely
used in many different environments...!!!) is tied to
*USABILITY*.

It is my belief that the usability problem and the difficulties
in
interacting with CAs are the real issues we should really try to
address
by promoting protocols that would take USABILITY in
consideration.

Another issue that I would like to draw the attention to is the
fact
that we are currently stuck with browsers to be the tool to
interact
with CAs. CMC & SCEP try to decouple the need to interact with
CAs by
using browsers. Historically browsers were the first
applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact
with
CAs is a real need, e.g. small devices, general applications,
or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is
actually
aimed to address these issues.

Later,
Max


Anders Rundgren wrote:
> *Other PKI Issues*
>
> IMHO, the reason why PKI hasn't got farther is because we
still lack a
> cheap and standardized "container" to keep private keys in,
that works
> in most computers without installation of proprietary
middleware.  I'm
> personally involved in solving this part of the
infrastructure.  Another
> issue is the unavailability of a standadized scheme for
on-line
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply
isn't good
> enough:  http://demo.webpki.org/mozkeygen





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PHGM4u004885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 10:16:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6PHGMsP004884; Fri, 25 Jul 2008 10:16:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.noorhome.net (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PHGLdq004878 for <[e-mail]>; Fri, 25 Jul 2008 10:16:21 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.noorhome.net (Postfix) with ESMTP id ECC093AF1B5 for <[e-mail]>; Fri, 25 Jul 2008 12:56:06 -0400 (EDT)
X-Spam-Score: -4.283
X-Spam-Level: 
X-Spam-Status: No, score=-4.283 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.116, BAYES_00=-2.599]
Received: from mailhost.noorhome.net ([127.0.0.1]) by localhost (mailhost.noorhome.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHJPRR1my6Pu for <[e-mail]>; Fri, 25 Jul 2008 12:56:04 -0400 (EDT)
Received: from mailhost.noorhome.net (mailhost.noorhome.net [63.194.79.229]) by mailhost.noorhome.net (Postfix) with ESMTP id 1BEE53AF1AA for <[e-mail]>; Fri, 25 Jul 2008 12:56:04 -0400 (EDT)
Date: Fri, 25 Jul 2008 12:56:04 -0400 (EDT)
From: Arshad Noor <[e-mail]>
To: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Fwd: [ekmi] Public Review of SKSML v1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [72.18.244.116]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI.

The OASIS EKMI Technical Committee would be grateful for any comments
received from members of this forum about the key-management protocol.

If you are interested in reviewing a working implementation of an early
version of this protocol, you can get the implementation here:

http://www.strongkey.org.  

This open-source implementation does not have all the features mentioned
in the specification, but has enough to give the reviewer an in-depth
view of its capabilities, strengths and weaknesses.

Thank you.

Arshad Noor
StrongAuth, Inc. 

----- Forwarded Message -----
From: "Mary McRae" <[e-mail]>
To: [e-mail], [e-mail]
Cc: "ekmi" <[e-mail]>
Sent: Thursday, July 24, 2008 7:04:49 PM (GMT-0800) America/Los_Angeles
Subject: [ekmi] Public Review of SKSML v1.0

To OASIS members, Public Announce Lists:

The OASIS Enterprise Key Management Infrastructure (EKMI) TC has recently
approved the following specification as a Committee Draft and approved the
package for public review:

Symmetric Key Services Markup Language (SKSML) Version 1.0

The public review starts today, 24 July 2008, and ends 23 September 2008. This
is an open invitation to comment. We strongly encourage feedback from potential
users, developers and others, whether OASIS members or not, for the sake of
improving the interoperability and quality of OASIS work. Please feel free to
distribute this announcement within your organization and to other appropriate
mail lists.

More non-normative information about the specification and the technical
committee may be found at the public home page of the TC at: 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi. Comments may be
submitted to the TC by any person through the use of the OASIS TC Comment
Facility which can be located via the button marked "Send A Comment" at the top
of that page, or directly at: 
http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ekmi.

Submitted comments (for this work as well as other works of that TC) are
publicly archived and can be viewed at: 
http://lists.oasis-open.org/archives/ekmi-comment/. All comments submitted to
OASIS are subject to the OASIS Feedback License, which ensures that the feedback
you provide carries the same obligations at least as the obligations of the TC
members.

The specification document and related files are available here:

Editable Source (Authoritative):
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.odt 

PDF:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.pdf 

HTML:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.html 

Schema:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/schema/ 

Abstract:
This normative specification defines the first (1.0) version of the Symmetric
Key Services Markup Language (SKSML), an XML-based messaging protocol, by which
applications executing on computing devices may request and receive symmetric
key-management services from centralized key-management servers, securely, over
networks. Applications using SKSML are expected to either implement the SKSML
protocol, or use a software library - called the Symmetric Key Client Library
(SKCL) - that implements this protocol. SKSML messages are transported within a
SOAP layer, protected by a Web Services Security (WSS) header and can be used
over standard HTTP securely.

OASIS and the EKMI TC welcome your comments.

---------------------------------------------------
Mary P McRae
Manager of TC Administration, OASIS
email: [e-mail]  
web: www.oasis-open.org 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PG3dZU098279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 09:03:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6PG3dNr098278; Fri, 25 Jul 2008 09:03:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PG3anr098267 for <[e-mail]>; Fri, 25 Jul 2008 09:03:36 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id m6PG3Z8F022245 for <[e-mail]>; Fri, 25 Jul 2008 12:03:35 -0400 (EDT)
X-AuditID: 90333308-000012780000074c-aa-4889f9571be4
Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jul 2008 12:03:35 -0400
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 12:03:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: generateCRMFrequest() Re: The PKC-only application security model ...
Date: Fri, 25 Jul 2008 12:03:31 -0400
Message-ID: <[e-mail]>
In-Reply-To: <001401c8edd2$d8b450b0$82c5a8c0@arport2v>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: generateCRMFrequest() Re: The PKC-only application security model ...
Thread-Index: Acjt3C6vQ2pogWhoTSOeBYDNm3nz5AAjtWjA
References: <[e-mail]> <00c601c8ed9a$c33d9a80$82c5a8c0@arport2v> <[e-mail]> <001401c8edd2$d8b450b0$82c5a8c0@arport2v>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 25 Jul 2008 16:03:35.0418 (UTC) FILETIME=[FE3BEDA0:01C8EE6F]
X-Brightmail-Tracker: AAAAAA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The CRMF CertRequest contains a transaction id number, a certificate
template, and a list of control attributes.  RFC 4211 itself defines six
controls, and additional controls (such as requiring PIN activation for
use of the private key) can easily be defined.  However, unless there is
some sort of integrity mechanism between the CA and the token or TPM,
such signaling is useless - the user's workstation is a
man-in-the-middle that could easily say "sure, the private key is
protected on a TPM" and then go ahead and store it on a thumb drive.

Achieving a trusted path between the key storage device and the CA is
the challenge; including suitable signaling in a provisioning protocol
(CRMF, KEYPROV, or whatever) is a non-issue.  The certificate policies
extension has always been used by DoD to indicate (among other things)
whether the private key is stored in software, wimpy ("class 3")
hardware :-), or better ("class 4") hardware.  That extension is
meaningful only because the issuing workstations and token stock are
under control of the PKI, not the end user.

I'd be interested in learning how a CA can know that it is talking to an
actual "cheap, standardized, middleware-less" private key container, and
not someone pretending to be same.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Anders Rundgren
Sent: Thursday, July 24, 2008 5:19 PM
To: Massimiliano Pala
Cc: [e-mail]; Scott Rea
Subject: generateCRMFrequest() Re: The PKC-only application security
model ...


Hi Max,

IMO it doesn't help if Mozilla fixes bugs in
generateCRMFrequest()
because it is inferior anyway.  Lets say an issuer wanted to
specify
that a user must assign a PIN-code following some kind of policy
there is no place for that in CRMF AFAIK.

If you look on a more recent effort like IETF's KEYPROV, it
indeed supports a set of useful of key add-ons.  Unfortunately
KEYPROV does neither support PKI, nor support browsers.

A glaring omission in the current crop of PKI provisioning
schemes is the ability indicating that the private key is
generated
and stored in a TPM or similar.  Due to this and similar
disconnects, 99% (or more) of the TPMs featured in
mid-to-high-end laptops are never activated.

Regards
Anders Rundgren

----- Original Message -----=20
From: "Massimiliano Pala" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; "Scott Rea" <[e-mail]>
Sent: Thursday, July 24, 2008 17:44
Subject: Re: The PKC-only application security model ...


Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda
buggy
(at least it was some time ago...). Indeed I exchanged some
emails with
Jim Schaad and at the end we figured out that they are totally
mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are
developing that
part of the API in Mozilla/NSS so that we could try to fix the
current
mess they are doing ???

I would point out that one of the reason why PKIs have not got
further
(well, despite of what the common perception, PKIs are
definitely widely
used in many different environments...!!!) is tied to
*USABILITY*.

It is my belief that the usability problem and the difficulties
in
interacting with CAs are the real issues we should really try to
address
by promoting protocols that would take USABILITY in
consideration.

Another issue that I would like to draw the attention to is the
fact
that we are currently stuck with browsers to be the tool to
interact
with CAs. CMC & SCEP try to decouple the need to interact with
CAs by
using browsers. Historically browsers were the first
applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact
with
CAs is a real need, e.g. small devices, general applications,
or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is
actually
aimed to address these issues.

Later,
Max


Anders Rundgren wrote:
> *Other PKI Issues*
>
> IMHO, the reason why PKI hasn't got farther is because we
still lack a
> cheap and standardized "container" to keep private keys in,
that works
> in most computers without installation of proprietary
middleware.  I'm
> personally involved in solving this part of the
infrastructure.  Another
> issue is the unavailability of a standadized scheme for
on-line
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply
isn't good
> enough:  http://demo.webpki.org/mozkeygen





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PCGeNe077039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 05:16:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6PCGeXF077038; Fri, 25 Jul 2008 05:16:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PCGXpZ077021 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 25 Jul 2008 05:16:39 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 25 Jul 2008 13:16:33 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.83]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 25 Jul 2008 13:16:33 +0100
From: Stefan Santesson <[e-mail]>
To: ietf-pkix <[e-mail]>
Date: Fri, 25 Jul 2008 13:15:55 +0100
Subject: Dublin agenda posted
Thread-Topic: Dublin agenda posted
Thread-Index: AcjuUDAwokPIGCmwSGODzK6KEfyAOw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32108A42AC13EAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

The Dublin agenda is now posted and available from:
http://www.ietf.org/proceedings/08jul/agenda/pkix.txt

Please let me know if anything is wrong or missing.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D32108A42AC13EAEXMSGC332eu_
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:sub=3D"http://schemas=
.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.or=
g/2001/04/xmlenc#" xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xm=
lns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http=
://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf=3D"http://schemas.micros=
oft.com/data/udc/xmlfile" xmlns:wf=3D"http://schemas.microsoft.com/sharepoi=
nt/soap/workflow/" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-c=
ompatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/o=
mml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relation=
ships" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/t=
ypes" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/me=
ssages" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"h=
ttp://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 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* 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>The Dublin agenda is now posted and
available from:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"http://www.ietf.org/proceedings/08jul/agenda/pkix.txt">http://www.i=
etf.org/proceedings/08jul/agenda/pkix.txt</a><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 let me know if anything is w=
rong or missing.<o:p></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_9F11911AED01D24BAA1C2355723C3D32108A42AC13EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PB45RQ069482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 04:04:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6PB45xs069480; Fri, 25 Jul 2008 04:04:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6PB401e069465 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 25 Jul 2008 04:04:02 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 25 Jul 2008 12:03:59 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.83]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 25 Jul 2008 12:03:59 +0100
From: Stefan Santesson <[e-mail]>
To: ietf-pkix <[e-mail]>
CC: Stephen Kent <[e-mail]>, Stephen Farrell <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 25 Jul 2008 12:03:18 +0100
Subject: RE: Comments on draft-ietf-pkix-tac-00.txt
Thread-Topic: Comments on draft-ietf-pkix-tac-00.txt
Thread-Index: AcjgVicv2K1T7LwnRBy+XLo8n3n3JAN7HeWw
Message-ID: <[e-mail]>
References: <p06240501c49291973672@[192.168.1.4]> <[e-mail]> <p06240508c492c324d367@[192.168.1.4]> <[e-mail]> <p06240507c497ef8f98c1@[128.89.89.227]>
In-Reply-To: <p06240507c497ef8f98c1@[128.89.89.227]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I admit that I have some concerns with this I-D, but of reasons different f=
rom Denis.

What I'm asking myself is whether this I-D is an appropriate response to a =
real issue. Not the Internet privacy is not an issue, because it is. But as=
 a society of security engineers, we do have a history of over engineering =
security solutions ending up in no deployment, which we should take into co=
nsideration and hopefully learn from.

Sometimes then appropriate response to a threat is the easier to deploy and=
 easier to understand approach, providing reasonable security, rather than =
the complex fool proof solution.

Against this dual/blind signing architecture stands one where you simply le=
t a CA issue an anonymous certificate on its own and then trust that CA to =
keep your identity secret.
This would be very much like how PayPal keeps your credit card number from =
the merchant. They "could" give your details to the merchant, but they don'=
t. At least I trust them to not do that.

Such approach is of course a bit less secure, but is the simpler solution s=
ecure enough?
The problem we face as a standards group is that we don't necessarily know =
that, and we don't get to decide. In the end, this is decided by the market=
 players, the institutions and the governments on the play field.
All we can do is to offer them good solid specifications for what they want=
 to do.

Being adopted as a WG item does not guarantee that it will be published as =
an RFC, but given the effort put behind this work I do believe that we ough=
t to let this document be developed with the input of this WG. This process=
 has clearly already lead to improvements.

As this document describes a protocol under development aiming at being a f=
unctional standard, I do agree with Stephen Farrell that this should be exp=
erimental rather than Informational.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Stephen Kent
> Sent: den 7 juli 2008 18:30
> To: Stephen Farrell
> Cc: ietf-pkix
> Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
>
>
> At 4:52 PM +0100 7/7/08, Stephen Farrell wrote:
> >Stephen Kent wrote:
> >>>At this time, there is one response to this poll.
> >>
> >>no, there are two. I expressed my support for adopting the document
> >>as a PKIX work item.
> >
> >FWIW, (but without yet having given the I-D a proper read), I do
> >think that this topic is a good thing for PKIX to take on. The
> addition
> >of more privacy-friendly aspects to Internet protocols is a good thing.
> >
> >Based on a quick scan, I do have two preliminary comments:-
> >
> >1. This looks more like it ought end up as an experimental RFC (it
> >currently says informational). Not a big deal, but if anything at
> >all is meant to be experimental track, this'd be it IMO.
>
> fair comment. now that you mention it, experimental does seem more
> appropriate than informational.
>
> >2. I'd have a concern that regardless of the ability of the
> >protocol presented to help hide identities from PKI components,
> >lower layers (e.g. IP address logging) might leak identities.
> >I'm not sure how that would best be handled - at minimum as sec.
> >cons. text but if the protocol depends on a lack of logging then
> >its usefulness might be lessened so I'd be interested in knowing
> >whether the authors have already considered that or not (maybe
> >I missed it).
>
> good point and widely applicable to what the IETF considers to be
> privacy-preserving technologies. I agree that a discussion of these
> issues should be added to the security considerations section.
>
> >At some later stage, if this does progress, I'll give it a proper
> >read and might well have comments on other aspects of the scheme,
> >but overall, if PKIX is going to continue to do new work, then
> >this is just the right kind of thing to be doing.
>
> Thanks,
>
> Steve
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OLIiRk013655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 14:18:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OLIiHg013654; Thu, 24 Jul 2008 14:18:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OLIcqa013642 for <[e-mail]>; Thu, 24 Jul 2008 14:18:43 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) (authenticated as u18116613) id 4843FAEB00A62E70; Thu, 24 Jul 2008 23:18:37 +0200
Message-ID: <001401c8edd2$d8b450b0$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>
Cc: <[e-mail]>, "Scott Rea" <[e-mail]>
References: <[e-mail]> <00c601c8ed9a$c33d9a80$82c5a8c0@arport2v> <[e-mail]>
Subject: generateCRMFrequest() Re: The PKC-only application security model ...
Date: Thu, 24 Jul 2008 23:18:40 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Max,

IMO it doesn't help if Mozilla fixes bugs in
generateCRMFrequest()
because it is inferior anyway.  Lets say an issuer wanted to
specify
that a user must assign a PIN-code following some kind of policy
there is no place for that in CRMF AFAIK.

If you look on a more recent effort like IETF's KEYPROV, it
indeed supports a set of useful of key add-ons.  Unfortunately
KEYPROV does neither support PKI, nor support browsers.

A glaring omission in the current crop of PKI provisioning
schemes is the ability indicating that the private key is
generated
and stored in a TPM or similar.  Due to this and similar
disconnects, 99% (or more) of the TPMs featured in
mid-to-high-end laptops are never activated.

Regards
Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; "Scott Rea" <[e-mail]>
Sent: Thursday, July 24, 2008 17:44
Subject: Re: The PKC-only application security model ...


Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda
buggy
(at least it was some time ago...). Indeed I exchanged some
emails with
Jim Schaad and at the end we figured out that they are totally
mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are
developing that
part of the API in Mozilla/NSS so that we could try to fix the
current
mess they are doing ???

I would point out that one of the reason why PKIs have not got
further
(well, despite of what the common perception, PKIs are
definitely widely
used in many different environments...!!!) is tied to
*USABILITY*.

It is my belief that the usability problem and the difficulties
in
interacting with CAs are the real issues we should really try to
address
by promoting protocols that would take USABILITY in
consideration.

Another issue that I would like to draw the attention to is the
fact
that we are currently stuck with browsers to be the tool to
interact
with CAs. CMC & SCEP try to decouple the need to interact with
CAs by
using browsers. Historically browsers were the first
applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact
with
CAs is a real need, e.g. small devices, general applications,
or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is
actually
aimed to address these issues.

Later,
Max


Anders Rundgren wrote:
> *Other PKI Issues*
>
> IMHO, the reason why PKI hasn't got farther is because we
still lack a
> cheap and standardized "container" to keep private keys in,
that works
> in most computers without installation of proprietary
middleware.  I'm
> personally involved in solving this part of the
infrastructure.  Another
> issue is the unavailability of a standadized scheme for
on-line
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply
isn't good
> enough:  http://demo.webpki.org/mozkeygen





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OIIRFx098833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 11:18:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OIIRbv098830; Thu, 24 Jul 2008 11:18:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OIIPBk098822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 24 Jul 2008 11:18:27 -0700 (MST) (envelope-from [e-mail])
Received: from titan.cs.dartmouth.edu (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.14.2/8.14.2) with ESMTP id m6OIINCd018756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jul 2008 14:18:24 -0400
DomainKey-Signature: a=rsa-sha1; s=mail; d=cs.dartmouth.edu; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type; b=V7cvMAEfxAHjFcvNdEn+g/HIV/UtpMXU+OSEkVmyEdHXe2mWq+7RJeoEWWiP7LkjO 7ICf3SJh0l4qvgDy6fk4A==
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2008 14:15:33 -0400
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: "Miller, Timothy J." <[e-mail]>
CC: [e-mail]
Subject: Re: The PKC-only application security model ...
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090607020707030503030701"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms090607020707030503030701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Timothy,

I find interesting that you think that the new Firefox 3 interface is
somewhat usable. I really think that they changed the original interface
to imitate IE behavior. In my experience, the new way to actually browse
an https website certified by a CA that is not part of the trust anchors
is totally unusable. The average response of the user is: this website
does not work. They really have no idea of what (and why should they?)
they have to do when this situation happens. The very same thing applies
to IE and their page with the red-shield "continue" option.

It is interesting that https connections to "untrusted" anchors are
treated with less trust than http connection. *WHY* ? Just to get more
money to have the trust anchors embedded into the applications ? In other
words: what makes an untrusted https connection more dangerous than an
untrusted http ?

This is just another example of how developers do not realize how complex
the trust management can be for the user, and the average level of awareness
about security. Presenting complex interfaces just to say that an https
connection is, indeed, at the same level of trust as an http connection
leaves the user with a frustrating experience (and distrust about security
in general).

Later,
Max



Miller, Timothy J. wrote:
> Yes, but when using self-signed certs clients are going to get nagged with
> trust warning dialogs until they set explicit trust on the server's cert.
> This goes back to the education issue.  Firefox 3's new trust ceremony
> implementation makes setting trust pretty simple to do though the number of
> clicks is a little high.  You may run afoul of policy restrictions with IE
> depending on strictness of domain security policy, but this won't affect
> home users.

--------------ms090607020707030503030701
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx
NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v
dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG
CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI
hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg
bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8
fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw
EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi
BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91
dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0
dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm
MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI
KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3
DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6
AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG
nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV
jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl
AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE
aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ
MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt
b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1
MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK
CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG
9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu
GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8
K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR
BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG
A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0
aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0
cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw
IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr
BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN
AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC
KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad
L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN
gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA
lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4
MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0
bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE
AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNzI0MTgxNTMzWjAjBgkqhkiG9w0B
CQQxFgQUZNcC0Fr8vLnvIisURfsR8mEK2dMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT
8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs
ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx
f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy
dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYBNHDWBcJmLd6t6uMHsViZW
Ne2ETnNsQS56PXMHOiYAVrmb4CaThdbvcpHJlX7PSV2bX4SbfInkul/tYYSrRgOZVGztC0b7
tLVApJSMOatEncIwjawAD1waYEV9mzWN0uK1kXOX6GRj4WwgQuho6g0h/8RHQYJ7jFYvBM+q
3VveKgAAAAAAAA==
--------------ms090607020707030503030701--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OIESEm098423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 11:14:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OIESrX098422; Thu, 24 Jul 2008 11:14:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft2.fr.colt.net (smtp-ft2.fr.colt.net [213.41.78.204]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OIEPIS098415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 24 Jul 2008 11:14:27 -0700 (MST) (envelope-from [e-mail])
Received: from [172.30.24.37] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft2.fr.colt.net (8.13.8/8.13.8/Debian-3) with ESMTP id m6OIEFEJ023462 for <[e-mail]>; Thu, 24 Jul 2008 20:14:15 +0200
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2008 20:14:24 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2pre) Gecko/2008072002 SeaMonkey/2.0a1pre
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: The PKC-only application security model ...
References: <[e-mail]> <00c601c8ed9a$c33d9a80$82c5a8c0@arport2v> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: checked in 0.006sec at smtp-ft2.fr.colt.net ([213.41.78.204]) by smf-clamd
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano Pala wrote:
> [...]
> I just want to point out that the generateCRMFrequest() is kinda buggy
> (at least it was some time ago...). Indeed I exchanged some emails with
> Jim Schaad and at the end we figured out that they are totally mis-using
> the CRMFRequest outside CMC.
>
> Can anybody put us in contact with the people that are developing that
> part of the API in Mozilla/NSS so that we could try to fix the current
> mess they are doing ???
>[...]

You can use either the newsgroup
http://groups.google.com/group/mozilla.dev.tech.crypto/topics
or the mailing list
https://lists.mozilla.org/listinfo/dev-tech-crypto

Note that generateCRMFrequest is PSM code (the glue code between Fx and 
NSS) on which about nobody is working, but the part that formats the 
CRMF request is inside NSS, on which they are a number of Sun and Red 
Hat developpers working. If the problem is on the asn1 format, or 
support of the functionnalities they should listen.
Changes to the current format might require downward compatiblity or 
synchronisation with the Dogtag project, though :
http://pki.fedoraproject.org/wiki/PKI_Main_Page



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OGPlum088627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 09:25:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OGPlHv088626; Thu, 24 Jul 2008 09:25:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp124.rog.mail.re2.yahoo.com (smtp124.rog.mail.re2.yahoo.com [206.190.53.29]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6OGPdYa088610 for <[e-mail]>; Thu, 24 Jul 2008 09:25:46 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19061 invoked from network); 24 Jul 2008 16:25:39 -0000
Received: from unknown (HELO connotech.com) ([e-mail]@209.148.165.15 with plain) by smtp124.rog.mail.re2.yahoo.com with SMTP; 24 Jul 2008 16:25:39 -0000
X-YMail-OSG: XiMDp24VM1lHSzzepqGXIxePv9q.9Qyev5ql_rgO7eAC1ySHc6L4A4v5t0m.E9QfJA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2008 11:29:15 -0500
From: Thierry Moreau <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Miller, Timothy J." <[e-mail]>
CC:  [e-mail]
Subject: Re: The PKC-only application security model ...
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Miller, Timothy J. wrote:

> 
>>Can we do e-commerce applications (protected by a client key pair) in a
>>plain off-the-sheld browser based on the KCM trust model? I doubt, but
>>your educated input would be welcome.
> 
> 
> Yes, but when using self-signed certs clients are going to get nagged with
> trust warning dialogs until they set explicit trust on the server's cert.
> This goes back to the education issue.  Firefox 3's new trust ceremony
> implementation makes setting trust pretty simple to do though the number of
> clicks is a little high.  You may run afoul of policy restrictions with IE
> depending on strictness of domain security policy, but this won't affect
> home users.
> 

If the goal is to improve the education issue, may I respectfully 
suggest that the above deserves clarification.

In e-commerce applications, the client act as a relying party for the 
server, and the server acts as a relying party for the client (when 
protected by a client key pair). It is not clear to me in which role 
(relying party vs digital signatory) the client
a) gets nagged with trust warning dialog,
b) proceeds through the Firefox 3's new trust ceremony, and
c) runs afoul of policy restrictions with IE.

If the answer to a) b) and c) is "the cient as the relying party for the 
server's authentication", then it brings us to the very first role 
reversal identified in my reply: KCM in Firefox browser assists the user 
in her relying party role, while the PKC-only application security 
scheme cares about the user as a digital signatory.

Regards,


-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: [phone]
Fax:  [phone]

web site: http://www.connotech.com
e-mail: [e-mail]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OFobYP085808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 08:50:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OFobAn085807; Thu, 24 Jul 2008 08:50:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OFoUNc085798 for <[e-mail]>; Thu, 24 Jul 2008 08:50:36 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6OFoTTo006933 for <[e-mail]>; Thu, 24 Jul 2008 11:50:29 -0400
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6OFoTVN006928; Thu, 24 Jul 2008 11:50:29 -0400
Received: from IMCSRV5.MITRE.ORG ([129.83.20.200]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 11:50:29 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: The PKC-only application security model ...
Date: Thu, 24 Jul 2008 11:50:09 -0400
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0041_01C8ED7B.0AA33E90"
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: The PKC-only application security model ...
Thread-Index: AcjtojxR7o84vgMbSKa3Ai95gzrP9wAAKMGg
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Miller, Timothy J." <[e-mail]>
To: "Thierry Moreau" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 24 Jul 2008 15:50:29.0167 (UTC) FILETIME=[FF2DCBF0:01C8EDA4]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multipart message in MIME format.

------=_NextPart_000_0041_01C8ED7B.0AA33E90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

>If you refer to KCM for server site certificates, my document is the
>other way around, i.e. *client-side* public keys carried in meaningless
>security certificates. (I did notice the reversed similarity when doing
>the research.)

KCM applies on both sides.  SSH's RSA pubkey authentication method, for
example, is using KCM concepts even though it doesn't explicitly call it
such.

>The search engine result also pointed to KCM with S/MIME, perhaps as a
>trust model unlike PKI and unlike PGP web of trust. Quite honestly, I
>didn't review these search results.

You should read Garfinkle's "Johnny 2: A User Test of Key Continuity
Management with S/MIME and Outlook Express."

http://www.truststc.org/pubs/5.html

It's a good starting point on KCM concepts.  The follow his references for
more.  Citeseer is your friend, BTW:

http://citeseer.ist.psu.edu/

>Also don't forget that the idea behind my document is to leave protocols
>  and fielded implementations untouched - as far as I know, TLS (at
>least in the leading implementations) does not support client key pairs
>without an X.509 certificate.

Nothing stops you from generating a self-signed cert to transport keys via
protocols that expect X.509.  Your back-end logic need not apply X.509 trust
and validation rules, however.

Remember that the key to KCM is educating participants on how it works and
what to expect.  The Johnny 2 paper backs that up, IMHO, though the point
Simson and others are trying to make is that KCM is a more intuitive model
for otherwise uninitiated users, and thus easier to use than either
hierarchical or web of trust models.

Until we have an installed base of applications using explicit KCM models
the jury will probably remain out on the subject.  Personally I think they
have a point but the industry has gone a different way and usability issues
are a small rudder on a big ship.

>Can we do e-commerce applications (protected by a client key pair) in a
>plain off-the-sheld browser based on the KCM trust model? I doubt, but
>your educated input would be welcome.

Yes, but when using self-signed certs clients are going to get nagged with
trust warning dialogs until they set explicit trust on the server's cert.
This goes back to the education issue.  Firefox 3's new trust ceremony
implementation makes setting trust pretty simple to do though the number of
clicks is a little high.  You may run afoul of policy restrictions with IE
depending on strictness of domain security policy, but this won't affect
home users.

-- Tim



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKuzCCA2Qw
ggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQL
ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3Qg
Q0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQBgNVBAoTCW1pdHJlLm9y
ZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3Jh
dGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCva1qWPZiEJv5v
MtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3NsnUVjpLYBdFcxNXnOLj
XtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QVLA1S6CNL6o2eGAsAl5Wn
xwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM2AEfaSHzmi7WUdUHRCtC
blrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB+S1O/OhH+ZjQ4MjWnwE8
A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYBAf8CAQMwHQYDVR0OBBYE
FMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa+fVfCljimBlcfWwkfJXu
XNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh21qXulcVTDFqubSJdv51a
HTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR36kjG4cYHqXgH0liBl8jx
pN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz9mmnxxmmIvUGNdsCAhGh
dnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIABcZn7deADHcY9spULZfB
nQYdEpyz5tgh7Y2qMIIDZzCCAk+gAwIBAgICBpowDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJF
IENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wNzAyMjgxMzUxMjRaFw0wODA4MjExMzUxMjRa
MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZImiZPyLGQBARMH
dG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAN2lQeZJOa/AfXooIEDe5eizDlsKW72dOGrmRT/zr21o9qhai2lfWOe5xzMSdKsDCAE7
02zs8g6kK1qsgg4valHJft7EezoiqYtj7ejd7DWU1nmAlaECLL4ME8auGANeQeoUCEuGjRMD7T26
ugSaEJkBELddkeTelbz+NRL6UfMtAgMBAAGjgbcwgbQwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBRcKVJ0ls8o8R1JIUbV7okh6ULOuzAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBE
BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21p
dHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1pbGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQAD
ggEBALqRRFhX8yggCX1SfqcpcnrcWLvLnS5Hv5/vb0zdBTcSb78izRcMBDSgURFC72RlDHohC3RQ
XJPBl8NiaNhg4kAQH/r3UpINgE567ibOHABJtXupKtOIMRsWpe6kIopeTmZEPoQILSizxYXSQSSt
Qk90ZuUFh+O1rfqFKoLx86mC8IsTwk0khs+vcSZtKwCmjRp5e1lmT+rxU068z8vbk/FvhMYX2m4x
RnycGiWvWhsztpoZebIabkC+gZ5kFuyfEb0tf6lEzgA/RLlO2XUK0pF4tfs9TQ5VyKeD1HMLTZ1H
Evw5TPnc9io1wnTGaLCc95zMIIRiOhwpvR3H9T3IwmcwggPkMIICzKADAgECAgEFMA0GCSqGSIb3
DQEBBQUAMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIy
WhcNMTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFP
MXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2
ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhIC
fgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzzt
C+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBq
mQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQW
BBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBI
BgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNh
MV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClq
ix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatG
moibqP/8WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo8
2ZiyU680ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M
6WHcxWXtp3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxM
nGdh7NqgMYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRp
ZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
AgIGmjAJBgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0wODA3MjQxNTUwMDlaMCMGCSqGSIb3DQEJBDEWBBTK2RdOG568LjEDvRfb151kACUabzBn
BgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3
EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAgaaMHQGCyqGSIb3
DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjANBgkq
hkiG9w0BAQEFAASBgDTBl9IB1KlHzQ1E1xp1Mjko6BwAV6gVlSqzgfbARAR7RXXnLONAEkq7q/Nw
341cpzMJY8LJ26QRbNtrl4WRFohYT85uwhqMsk01MXwZAORr1bmRXuzWsde3NsDNYdDy+cvLaDPt
lTZmC+adrwgVQwEeRyNZzNiikSEjATEiRQBRAAAAAAAA

------=_NextPart_000_0041_01C8ED7B.0AA33E90--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OFlcF0085559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 08:47:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OFlcie085558; Thu, 24 Jul 2008 08:47:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OFlWEv085548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 24 Jul 2008 08:47:38 -0700 (MST) (envelope-from [e-mail])
Received: from titan.cs.dartmouth.edu (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.14.2/8.14.2) with ESMTP id m6OFlTsQ026006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jul 2008 11:47:30 -0400
DomainKey-Signature: a=rsa-sha1; s=mail; d=cs.dartmouth.edu; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type; b=1b5pMrrFdkfeHtpTajbUga8k+e1UwkTKFSnasccbf1eRUeoUaKTAPGOPEtcuXciFL nspIwC4yKqhzNgWbu5MZQ==
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2008 11:44:40 -0400
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail], Scott Rea <[e-mail]>
Subject: Re: The PKC-only application security model ...
References: <[e-mail]> <00c601c8ed9a$c33d9a80$82c5a8c0@arport2v>
In-Reply-To: <00c601c8ed9a$c33d9a80$82c5a8c0@arport2v>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060805010207020308000100"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms060805010207020308000100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda buggy
(at least it was some time ago...). Indeed I exchanged some emails with
Jim Schaad and at the end we figured out that they are totally mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are developing that
part of the API in Mozilla/NSS so that we could try to fix the current
mess they are doing ???

I would point out that one of the reason why PKIs have not got further
(well, despite of what the common perception, PKIs are definitely widely
used in many different environments...!!!) is tied to *USABILITY*.

It is my belief that the usability problem and the difficulties in
interacting with CAs are the real issues we should really try to address
by promoting protocols that would take USABILITY in consideration.

Another issue that I would like to draw the attention to is the fact
that we are currently stuck with browsers to be the tool to interact
with CAs. CMC & SCEP try to decouple the need to interact with CAs by
using browsers. Historically browsers were the first applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact with
CAs is a real need, e.g. small devices, general applications, or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is actually
aimed to address these issues.

Later,
Max


Anders Rundgren wrote:
> *Other PKI Issues*
>  
> IMHO, the reason why PKI hasn't got farther is because we still lack a 
> cheap and standardized "container" to keep private keys in, that works 
> in most computers without installation of proprietary middleware.  I'm 
> personally involved in solving this part of the infrastructure.  Another 
> issue is the unavailability of a standadized scheme for on-line 
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply isn't good 
> enough:  http://demo.webpki.org/mozkeygen



--------------ms060805010207020308000100
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx
NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v
dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG
CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI
hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg
bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8
fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw
EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi
BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91
dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0
dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm
MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI
KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3
DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6
AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG
nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV
jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl
AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE
aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ
MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt
b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1
MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK
CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG
9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu
GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8
K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR
BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG
A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0
aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0
cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw
IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr
BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN
AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC
KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad
L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN
gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA
lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4
MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0
bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE
AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNzI0MTU0NDQwWjAjBgkqhkiG9w0B
CQQxFgQUIFDT7dn+5VzHmVYtw266ZUXLkMMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT
8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs
ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx
f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy
dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYCA2fR1kdOwOpRHIxiowTm+
FjfCGAfG994uiE+gyCV+ivAlP6PNiTsNKdPnNHvrYen90Gbtd1akMcb7FORwSEHtukCMj7VN
FfX83h27FjBJNFYrTqhxlvKr+Uubr5zJ+prwUb7cxkDwxc1kyggrTqbYgiPosgJqmhYyWsYq
f+0fXgAAAAAAAA==
--------------ms060805010207020308000100--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OFUmiO084428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 08:30:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OFUmSV084427; Thu, 24 Jul 2008 08:30:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp129.rog.mail.re2.yahoo.com (smtp129.rog.mail.re2.yahoo.com [206.190.53.34]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6OFUgL5084419 for <[e-mail]>; Thu, 24 Jul 2008 08:30:47 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 97245 invoked from network); 24 Jul 2008 15:30:41 -0000
Received: from unknown (HELO connotech.com) ([e-mail]@209.148.165.15 with plain) by smtp129.rog.mail.re2.yahoo.com with SMTP; 24 Jul 2008 15:30:41 -0000
X-YMail-OSG: OQazK_8VM1kczDS3uxL.gWh__n1Vi4mOqMOaxqZfMZzYgp7w3nfoMrJ8zWfQzsfAuw--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2008 10:34:18 -0500
From: Thierry Moreau <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Miller, Timothy J." <[e-mail]>
CC:  [e-mail]
Subject: Re: The PKC-only application security model ...
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Miller, Timothy J. wrote:

> The phrase you're looking for is "Key Continuity Management," which will net
> you a lot of research and deployed systems using it as a trust technique.
> If that's your route you really don't need to shoehorn it into an X.509
> structure.

OK, I ran a search engine on this.

If you refer to KCM for server site certificates, my document is the 
other way around, i.e. *client-side* public keys carried in meaningless 
security certificates. (I did notice the reversed similarity when doing 
the research.)

The search engine result also pointed to KCM with S/MIME, perhaps as a 
trust model unlike PKI and unlike PGP web of trust. Quite honestly, I 
didn't review these search results.

Also don't forget that the idea behind my document is to leave protocols 
  and fielded implementations untouched - as far as I know, TLS (at 
least in the leading implementations) does not support client key pairs 
without an X.509 certificate.

Can we do e-commerce applications (protected by a client key pair) in a 
plain off-the-sheld browser based on the KCM trust model? I doubt, but 
your educated input would be welcome.

Thanks for the feedback,


-- 

- Thierry Moreau



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OF5EGx082065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 08:05:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OF5Evh082064; Thu, 24 Jul 2008 08:05:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp130.rog.mail.re2.yahoo.com (smtp130.rog.mail.re2.yahoo.com [206.190.53.35]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6OF56tl082032 for <[e-mail]>; Thu, 24 Jul 2008 08:05:12 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 44730 invoked from network); 24 Jul 2008 15:05:02 -0000
Received: from unknown (HELO connotech.com) ([e-mail]@209.148.165.15 with plain) by smtp130.rog.mail.re2.yahoo.com with SMTP; 24 Jul 2008 15:05:02 -0000
X-YMail-OSG: EsHGDk0VM1mhrLGS2SoBRRKUgn2wjn3BNhW5dlkzpKsoTGO62dXFkc_WdRDk0VaTXA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2008 10:08:39 -0500
From: Thierry Moreau <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC:  [e-mail]
Subject: Re: The PKC-only application security model ...
References: <[e-mail]> <00c601c8ed9a$c33d9a80$82c5a8c0@arport2v>
In-Reply-To: <00c601c8ed9a$c33d9a80$82c5a8c0@arport2v>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:

> Hi Thierry,
>  
> Although I consider myself pretty well-educated in PKI, I had 
> difficulties reading your document.
> I got even more puzzled when you began listing ASN.1 constructs which I 
> fail to see how they apply to a conceptual model.
> Would it be too much asking for a short-cut version?

The ASN.1 constructs are essentially "tutorial" in nature.

The shortcut version would be sections 4.1, 4.2.1, 4.2.2.1, i.e. those 
where MUST and SHOULD appear.

> Exactly what do you find to be a problem with the current PKI model and 
> how does the PKC-only model address them?  BTW, the current PKI model 
> can be broken into two rather different variants; the RP-only-model and 
> the TTP-model.

Interesting. Does the RP-only model assume that the RP (relying party) 
issues certificates with its own private key?

If yes, then the meaningless X.509 security certificates brings a 
relaxation on this requirement. It does not bring much more than this 
relaxation.

If no, then there could be redundancy and I am very interested in 
specific references to the formal specifications for the RP-only model.

Incidentally, there is no ambition to fix the PKI model. Merely to apply 
PK without the "I"!

> I'm not aware of any conceptual problems with the RP-only model in which 
> the certificate is *almost* redundant since all important data about the 
> user is available from other [in-house] sources as well.

What about privacy concerns? (Not that the meaningless certificate bring 
a definitive answer in this respect, just that privacy concerns are more 
acute with a meaningful certificate.)

> The TTP-model OTOH suffers from all kinds of difficulties ranging from 
> basic issues like who is going to pay for the certificate (card), to 
> what is actually certified, as well as to liability concerns.
>  
> Other PKI Issues
>  
> IMHO, the reason why PKI hasn't got farther is because we still lack a 
> cheap and standardized "container" to keep private keys in, that works 
> in most computers without installation of proprietary middleware.  I'm 
> personally involved in solving this part of the infrastructure.  Another 
> issue is the unavailability of a standadized scheme for on-line 
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply isn't good 
> enough:  http://demo.webpki.org/mozkeygen

I agree with these concerns and the relevance of these efforts.

> Regards

Same

-- 

- Thierry Moreau



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OEpGUn080699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 07:51:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OEpG5V080698; Thu, 24 Jul 2008 07:51:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OEpFa3080691 for <[e-mail]>; Thu, 24 Jul 2008 07:51:15 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6OEpEwQ018066 for <[e-mail]>; Thu, 24 Jul 2008 10:51:14 -0400
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6OEpDhQ018057; Thu, 24 Jul 2008 10:51:13 -0400
Received: from IMCSRV5.MITRE.ORG ([129.83.20.200]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 10:51:13 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: The PKC-only application security model ...
Date: Thu, 24 Jul 2008 10:50:29 -0400
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01C8ED72.B4874E00"
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: The PKC-only application security model ...
Thread-Index: AcjtCC7yNWd4xuGWT3ClfR8S6pQAAgAlC1jw
References: <[e-mail]>
From: "Miller, Timothy J." <[e-mail]>
To: "Thierry Moreau" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Jul 2008 14:51:13.0541 (UTC) FILETIME=[B7DC5350:01C8ED9C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multipart message in MIME format.

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

The phrase you're looking for is "Key Continuity Management," which will net
you a lot of research and deployed systems using it as a trust technique.
If that's your route you really don't need to shoehorn it into an X.509
structure.

-- Tim

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Thierry Moreau
Sent: Wednesday, July 23, 2008 3:08 PM
To: [e-mail]
Subject: The PKC-only application security model ...


Dear all:

This is a two-fold announcement, big picture and specific document 
announcement. The whole thing is "for your information" as PKIX IETF wg 
participants.

A)	The big picture refers to the "PKC-only application security
scheme", 
in which client-server applications may be secured with client-side 
public key pairs, but *no trusted certification authority* is involved 
(server operators are expected to maintain a trusted database of their 
clients' public keys).

B)	The specific document announcement refers to what is required to 
field the PKC-only application security scheme: explicit meaningless 
security certificates. The reference is "Explicit Meaningless X.509 
Security Certificates as a Specifications-Based Interoperability 
Mechanism", http://www.connotech.com/pkc-only-meaningless-certs.pdf

This post leaves it to your imagination and creativity about how a 
PKC-only security scheme may work in practical details, i.e. how the 
third party trust management may be replaced by first party trust 
management (first party = server operator as the relying party for 
client public keys). I have been doing some work in this area, but I 
have no results to report in a properly written document. Anyway, the 
PKC-only security scheme does not imply significant standardization for 
interoperability among independent service operators.

The document is open for discussion. It covers the minimal provisions 
for PKC-only deployment in the installed base of browsers supporting the 
TLS protocol.

Sometimes in the future, a very reduced version might be prepared as an 
Internet draft intended to the RFC editor publication route (RFC3932) 
with the experimental status (this is different from the individual RFC 
submission route in which the IESG is involved in the document 
publication process but no IETF working group is assigned an editorial 
role).

Good reading.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: [phone]
Fax:  [phone]

web site: http://www.connotech.com
e-mail: [e-mail]


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKuzCCA2Qw
ggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQL
ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3Qg
Q0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQBgNVBAoTCW1pdHJlLm9y
ZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3Jh
dGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCva1qWPZiEJv5v
MtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3NsnUVjpLYBdFcxNXnOLj
XtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QVLA1S6CNL6o2eGAsAl5Wn
xwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM2AEfaSHzmi7WUdUHRCtC
blrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB+S1O/OhH+ZjQ4MjWnwE8
A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYBAf8CAQMwHQYDVR0OBBYE
FMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa+fVfCljimBlcfWwkfJXu
XNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh21qXulcVTDFqubSJdv51a
HTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR36kjG4cYHqXgH0liBl8jx
pN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz9mmnxxmmIvUGNdsCAhGh
dnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIABcZn7deADHcY9spULZfB
nQYdEpyz5tgh7Y2qMIIDZzCCAk+gAwIBAgICBpowDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJF
IENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wNzAyMjgxMzUxMjRaFw0wODA4MjExMzUxMjRa
MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZImiZPyLGQBARMH
dG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAN2lQeZJOa/AfXooIEDe5eizDlsKW72dOGrmRT/zr21o9qhai2lfWOe5xzMSdKsDCAE7
02zs8g6kK1qsgg4valHJft7EezoiqYtj7ejd7DWU1nmAlaECLL4ME8auGANeQeoUCEuGjRMD7T26
ugSaEJkBELddkeTelbz+NRL6UfMtAgMBAAGjgbcwgbQwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBRcKVJ0ls8o8R1JIUbV7okh6ULOuzAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBE
BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21p
dHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1pbGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQAD
ggEBALqRRFhX8yggCX1SfqcpcnrcWLvLnS5Hv5/vb0zdBTcSb78izRcMBDSgURFC72RlDHohC3RQ
XJPBl8NiaNhg4kAQH/r3UpINgE567ibOHABJtXupKtOIMRsWpe6kIopeTmZEPoQILSizxYXSQSSt
Qk90ZuUFh+O1rfqFKoLx86mC8IsTwk0khs+vcSZtKwCmjRp5e1lmT+rxU068z8vbk/FvhMYX2m4x
RnycGiWvWhsztpoZebIabkC+gZ5kFuyfEb0tf6lEzgA/RLlO2XUK0pF4tfs9TQ5VyKeD1HMLTZ1H
Evw5TPnc9io1wnTGaLCc95zMIIRiOhwpvR3H9T3IwmcwggPkMIICzKADAgECAgEFMA0GCSqGSIb3
DQEBBQUAMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIy
WhcNMTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFP
MXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2
ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhIC
fgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzzt
C+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBq
mQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQW
BBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBI
BgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNh
MV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClq
ix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatG
moibqP/8WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo8
2ZiyU680ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M
6WHcxWXtp3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxM
nGdh7NqgMYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRp
ZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
AgIGmjAJBgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0wODA3MjQxNDUwMjlaMCMGCSqGSIb3DQEJBDEWBBRnGyCMnTOsoWFyresgdWFYiPKzajBn
BgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3
EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAgaaMHQGCyqGSIb3
DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjANBgkq
hkiG9w0BAQEFAASBgHrvxNj9YLQCfne3yiAudaIV7UFou+cf3LcWo8R7OpF5xpha0Fy3wX3pmDH7
qYhepz5h1Gr5kmu5PIUC6L05Ov7+HoufdsLahZ3rIKJVfUjaWf195BMVJP34PsEfHwQCxMKz9PZI
EkOcqnV/PzmQXkys9d2CcNbuvlR4ciLVklPcAAAAAAAA

------=_NextPart_000_0019_01C8ED72.B4874E00--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OEbEC1079365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 07:37:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6OEbEYe079364; Thu, 24 Jul 2008 07:37:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OEbC8P079357 for <[e-mail]>; Thu, 24 Jul 2008 07:37:13 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) (authenticated as u18116613) id 4843FAEB00A5211E; Thu, 24 Jul 2008 16:37:09 +0200
Message-ID: <00c601c8ed9a$c33d9a80$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Thierry Moreau" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: The PKC-only application security model ...
Date: Thu, 24 Jul 2008 16:37:12 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01C8EDAB.861AC130"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00C3_01C8EDAB.861AC130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Thierry,

Although I consider myself pretty well-educated in PKI, I had =
difficulties reading your document.
I got even more puzzled when you began listing ASN.1 constructs which I =
fail to see how they apply to a conceptual model.
Would it be too much asking for a short-cut version?

Exactly what do you find to be a problem with the current PKI model and =
how does the PKC-only model address them?  BTW, the current PKI model =
can be broken into two rather different variants; the RP-only-model and =
the TTP-model.

I'm not aware of any conceptual problems with the RP-only model in which =
the certificate is *almost* redundant since all important data about the =
user is available from other [in-house] sources as well.

The TTP-model OTOH suffers from all kinds of difficulties ranging from =
basic issues like who is going to pay for the certificate (card), to =
what is actually certified, as well as to liability concerns.

Other PKI Issues

IMHO, the reason why PKI hasn't got farther is because we still lack a =
cheap and standardized "container" to keep private keys in, that works =
in most computers without installation of proprietary middleware.  I'm =
personally involved in solving this part of the infrastructure.  Another =
issue is the unavailability of a standadized scheme for on-line =
provisioning of PKI.  Mozilla's generateCRMFrequest() simply isn't good =
enough:  http://demo.webpki.org/mozkeygen

Regards
Anders Rundgren

----- Original Message -----=20
From: "Thierry Moreau" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, July 23, 2008 22:07
Subject: The PKC-only application security model ...



Dear all:

This is a two-fold announcement, big picture and specific document=20
announcement. The whole thing is "for your information" as PKIX IETF wg=20
participants.

A) The big picture refers to the "PKC-only application security scheme", =

in which client-server applications may be secured with client-side=20
public key pairs, but *no trusted certification authority* is involved=20
(server operators are expected to maintain a trusted database of their=20
clients' public keys).

B) The specific document announcement refers to what is required to=20
field the PKC-only application security scheme: explicit meaningless=20
security certificates. The reference is "Explicit Meaningless X.509=20
Security Certificates as a Specifications-Based Interoperability=20
Mechanism", http://www.connotech.com/pkc-only-meaningless-certs.pdf

This post leaves it to your imagination and creativity about how a=20
PKC-only security scheme may work in practical details, i.e. how the=20
third party trust management may be replaced by first party trust=20
management (first party =3D server operator as the relying party for=20
client public keys). I have been doing some work in this area, but I=20
have no results to report in a properly written document. Anyway, the=20
PKC-only security scheme does not imply significant standardization for=20
interoperability among independent service operators.

The document is open for discussion. It covers the minimal provisions=20
for PKC-only deployment in the installed base of browsers supporting the =

TLS protocol.

Sometimes in the future, a very reduced version might be prepared as an=20
Internet draft intended to the RFC editor publication route (RFC3932)=20
with the experimental status (this is different from the individual RFC=20
submission route in which the IESG is involved in the document=20
publication process but no IETF working group is assigned an editorial=20
role).

Good reading.

--=20

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: [phone]
Fax:  [phone]

web site: http://www.connotech.com
e-mail: [e-mail]

------=_NextPart_000_00C3_01C8EDAB.861AC130
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.2800.1611" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi Thierry,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Although I consider myself pretty =
well-educated in=20
PKI, I had difficulties reading your document.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I got&nbsp;even more&nbsp;puzzled when =
you=20
began&nbsp;listing ASN.1 constructs which I fail to see how they apply =
to a=20
conceptual model.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Would it be too much asking for a =
short-cut=20
version?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Exactly what do you find to be a =
problem with the=20
current PKI model and how does the PKC-only model address them?&nbsp; =
BTW, the=20
current PKI model can be broken into two rather different variants; the=20
RP-only-model and the TTP-model.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'm not aware of any&nbsp;conceptual =
problems with=20
the RP-only model in which the certificate is *almost* redundant since =
all=20
important data about the user is available from other [in-house] sources =
as=20
well.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The TTP-model OTOH suffers from all =
kinds of=20
difficulties ranging from basic issues like who is going to pay for the=20
certificate (card),&nbsp;to what is actually certified, as well as to =
liability=20
concerns.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>Other PKI =
Issues</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>IMHO, the reason why PKI hasn't got =
farther is=20
because we still lack a cheap and standardized "container" to keep =
private keys=20
in, that works in&nbsp;most computers without installation of =
proprietary=20
middleware.&nbsp; I'm personally involved in solving this part of the=20
infrastructure.&nbsp; Another issue is the unavailability of a =
standadized=20
scheme for on-line provisioning of PKI.&nbsp; Mozilla's =
generateCRMFrequest()=20
simply isn't good enough:&nbsp; <A=20
href=3D"http://demo.webpki.org/mozkeygen">http://demo.webpki.org/mozkeyge=
n</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DArial size=3D2>From: "Thierry Moreau" &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DArial=20
size=3D2>[e-mail]</FONT></A><FONT face=3DArial=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To: &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DArial=20
size=3D2>[e-mail]</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Wednesday, July 23, 2008 =
22:07</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: The PKC-only application =
security model=20
...</FONT></DIV></DIV>
<DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV><BR><FONT =
face=3DArial=20
size=3D2>Dear all:<BR><BR>This is a two-fold announcement, big picture =
and=20
specific document <BR>announcement. The whole thing is "for your =
information" as=20
PKIX IETF wg <BR>participants.<BR><BR>A) The big picture refers to the =
"PKC-only=20
application security scheme", <BR>in which client-server applications =
may be=20
secured with client-side <BR>public key pairs, but *no trusted =
certification=20
authority* is involved <BR>(server operators are expected to maintain a =
trusted=20
database of their <BR>clients' public keys).<BR><BR>B) The specific =
document=20
announcement refers to what is required to <BR>field the PKC-only =
application=20
security scheme: explicit meaningless <BR>security certificates. The =
reference=20
is "Explicit Meaningless X.509 <BR>Security Certificates as a=20
Specifications-Based Interoperability <BR>Mechanism", </FONT><A=20
href=3D"http://www.connotech.com/pkc-only-meaningless-certs.pdf"><FONT =
face=3DArial=20
size=3D2>http://www.connotech.com/pkc-only-meaningless-certs.pdf</FONT></=
A><BR><BR><FONT=20
face=3DArial size=3D2>This post leaves it to your imagination and =
creativity about=20
how a <BR>PKC-only security scheme may work in practical details, i.e. =
how the=20
<BR>third party trust management may be replaced by first party trust=20
<BR>management (first party =3D server operator as the relying party for =

<BR>client public keys). I have been doing some work in this area, but I =

<BR>have no results to report in a properly written document. Anyway, =
the=20
<BR>PKC-only security scheme does not imply significant standardization =
for=20
<BR>interoperability among independent service operators.<BR><BR>The =
document is=20
open for discussion. It covers the minimal provisions <BR>for PKC-only=20
deployment in the installed base of browsers supporting the <BR>TLS=20
protocol.<BR><BR>Sometimes in the future, a very reduced version might =
be=20
prepared as an <BR>Internet draft intended to the RFC editor publication =
route=20
(RFC3932) <BR>with the experimental status (this is different from the=20
individual RFC <BR>submission route in which the IESG is involved in the =

document <BR>publication process but no IETF working group is assigned =
an=20
editorial <BR>role).<BR><BR>Good reading.<BR><BR>-- <BR><BR>- Thierry=20
Moreau<BR><BR>CONNOTECH Experts-conseils inc.<BR>9130 Place de=20
Montgolfier<BR>Montreal, Qc<BR>Canada&nbsp;&nbsp; H2M 2A1<BR><BR>Tel.:=20
[phone]<BR>Fax:&nbsp; [phone]<BR><BR>web site: </FONT><A=20
href=3D"http://www.connotech.com"><FONT face=3DArial=20
size=3D2>http://www.connotech.com</FONT></A><BR><FONT face=3DArial =
size=3D2>e-mail:=20
</FONT><A href=3D"mailto:[e-mail]"><FONT =
face=3DArial=20
size=3D2>[e-mail]</FONT></A><BR></BODY></HTML>

------=_NextPart_000_00C3_01C8EDAB.861AC130--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6NK5Hua006666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 13:05:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6NK5Hqw006665; Wed, 23 Jul 2008 13:05:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6NK5F4v006657 for <[e-mail]>; Wed, 23 Jul 2008 13:05:16 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 68893 invoked from network); 23 Jul 2008 20:05:10 -0000
Received: from unknown (HELO connotech.com) ([e-mail]@209.148.165.15 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 23 Jul 2008 20:05:10 -0000
X-YMail-OSG: 6TIhLkMVM1kpyEejk3H.DroFiPJmM5S1d5HLEbmGsJj1O4BWBE2bkh9Fm_BJEN213g--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Wed, 23 Jul 2008 15:07:37 -0500
From: Thierry Moreau <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  [e-mail]
Subject: The PKC-only application security model ...
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear all:

This is a two-fold announcement, big picture and specific document 
announcement. The whole thing is "for your information" as PKIX IETF wg 
participants.

A)	The big picture refers to the "PKC-only application security scheme", 
in which client-server applications may be secured with client-side 
public key pairs, but *no trusted certification authority* is involved 
(server operators are expected to maintain a trusted database of their 
clients' public keys).

B)	The specific document announcement refers to what is required to 
field the PKC-only application security scheme: explicit meaningless 
security certificates. The reference is "Explicit Meaningless X.509 
Security Certificates as a Specifications-Based Interoperability 
Mechanism", http://www.connotech.com/pkc-only-meaningless-certs.pdf

This post leaves it to your imagination and creativity about how a 
PKC-only security scheme may work in practical details, i.e. how the 
third party trust management may be replaced by first party trust 
management (first party = server operator as the relying party for 
client public keys). I have been doing some work in this area, but I 
have no results to report in a properly written document. Anyway, the 
PKC-only security scheme does not imply significant standardization for 
interoperability among independent service operators.

The document is open for discussion. It covers the minimal provisions 
for PKC-only deployment in the installed base of browsers supporting the 
TLS protocol.

Sometimes in the future, a very reduced version might be prepared as an 
Internet draft intended to the RFC editor publication route (RFC3932) 
with the experimental status (this is different from the individual RFC 
submission route in which the IESG is involved in the document 
publication process but no IETF working group is assigned an editorial 
role).

Good reading.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: [phone]
Fax:  [phone]

web site: http://www.connotech.com
e-mail: [e-mail]



Received: from mail.cil2000.com (mail.cil2000.com [217.167.207.192] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6NEpiXq082641; Wed, 23 Jul 2008 07:51:55 -0700 (MST) (envelope-from [e-mail])
Received: from CIL050307 [96.166.201.31] (port=16335 helo=CIL050307) by c0cfa7d9target.com with ESMTP id 699079762A41 for <[e-mail]>; Wed, 23 Jul 2008 16:49:00 +0200
Message-ID: <001a01c8ece4$01f6f6c0$07135a24@CIL050307>
From: Harvey <[e-mail]>
To: [e-mail]
Subject: Or at fever
Date: Wed, 23 Jul 2008 16:49:00 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C8ECE4.01F6F6C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.2963
X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.0000

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C8ECE4.01F6F6C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


maker and memory storer.  The one great advantage we have over
their ancient artifacts on the computer.  He kept a permanent
virtually shop inside a digitally reproduced environment of a

------=_NextPart_000_0017_01C8ECE4.01F6F6C0
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.2962" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>businesses and universities. According to Molly, a character in</DIV><=
BR>
<P><DIV>C A 8N A D/3AN &nbsp;&nbsp;&nbsp; P 9 6H A RM A 3CY </DIV></P>
<DIV>V/A \G _RA - $1.41 </DIV>
<DIV>C 3/ A L / S - $2.21</DIV>
<DIV>S5 O M A - $0.67</DIV>
<DIV>L E3 V / T R A - $3.68</DIV>
<DIV>FEMALE V7/3A6G8R5A - $1.51</DIV>
<DIV>U 9 L T 4R A M - $1.36</DIV>
<DIV>135  Items on Sale Today.</DIV>
<P><DIV><A href=3D"http://geocities.com/tqxsgszefdm"><b><font size=3D5>Grab=
 yours while supplies last</font></b></A></DIV></P>
<DIV>and Chinatown - but no points allowed for that one.  Eleanor</DIV>

</BODY></HTML>

------=_NextPart_000_0017_01C8ECE4.01F6F6C0--



Received: from rrcs-71-42-201-226.sw.biz.rr.com (rrcs-71-42-201-226.sw.biz.rr.com [71.42.201.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6NEoxq2082488 for <[e-mail]>; Wed, 23 Jul 2008 07:51:00 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 23 Jul 2008 09:46:10 -0500
From: Persun <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: [e-mail]
Subject: Yahoo "facebook" site launched
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

How to win money from the bookmakers http://keithcrook.com/stream.html


Received: from host4-106-static.119-81-b.business.telecomitalia.it (host4-106-static.119-81-b.business.telecomitalia.it [81.119.106.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6N96jEJ055679 for <[e-mail]>; Wed, 23 Jul 2008 02:06:50 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 23 Jul 2008 11:08:21 +0200
From: franky <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: [e-mail]
Subject: Dirty secrets of cops
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
She is crazy for you, and she will keep craving for you every night. <a href="http://www.famefirst.com/">http://www.famefirst.com/</a><br>
</html>


Received: from [201.90.127.176] ([201.90.127.176]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MJ9FXn098843 for <[e-mail]>; Tue, 22 Jul 2008 12:09:24 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Man loses eye in fight
From:   ezra <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Tue, 22 Jul 2008 16:09:24 -0300
Message-ID: <qb.mtdspnctboilxk@servidor>
User-Agent: Opera Mail/9.50 (Win32)

Britney kicks dog in public
http://www.dammer.info/viewmovie.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6MIaWS3096485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 11:36:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6MIaWk2096484; Tue, 22 Jul 2008 11:36:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6MIaUI1096462 for <[e-mail]>; Tue, 22 Jul 2008 11:36:31 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 7592 invoked from network); 22 Jul 2008 18:36:26 -0000
Received: from [e-mail] by sottccs1.entrust.com with EntrustECS-Server-8.0;22 Jul 2008 18:36:26 -0000
Received: from sottexch1.corp.ad.entrust.com (10.4.51.28) by sottccs1.entrust.com with SMTP; 22 Jul 2008 18:36:25 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Status of domain-certs-01 and sip-eku-02
Date: Tue, 22 Jul 2008 14:36:27 -0400
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00B2_01C8EC08.52DF0460"
Message-ID: <[e-mail]>
In-Reply-To: <p06240815c4a2a3686524@[10.20.30.162]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Status of domain-certs-01 and sip-eku-02
Thread-Index: Acjmso9uLWSO4OT1RqK8QW8vLkVrUQFdscfQ
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]> <p06240815c4a2a3686524@[10.20.30.162]>
From: "Tim Moses" <[e-mail]>
To: "Paul Hoffman" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Vijay K. Gurbani" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00B2_01C8EC08.52DF0460
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Colleagues - I wonder whether defining a SIP type-id for the SAN OtherName
option is an approach more faithful to the 5280 intent.  The EKU value
'id-kp-serverAuth' could still be included.  All the best.  Tim. 

Tim Moses
[phone]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Paul Hoffman
Sent: Tuesday, July 15, 2008 3:04 PM
To: Stephen Kent
Cc: Vijay K. Gurbani; [e-mail]
Subject: Re: Status of domain-certs-01 and sip-eku-02


At 12:06 PM -0400 7/15/08, Stephen Kent wrote:
>I think it is more appropriate to focus on the EKU text from 5280, vs. 
>the KU text, since the proposal is to assign an EKU OID for this use of 
>certs. Section 4.2.1.12 describes the EKU extension and gives examples. 
>The examples include TLS server vs. client authentication, code 
>signing, time stamping, and OCSP response signing.  These examples from 
>5280 illustrate using EKU to signal what type of entity holds the 
>corresponding private key, and for what purpose that key is being used.

Fully agree. That's only part of what is in the draft in question, however.

>So, using an EKU to signal that the private key holder is a SIP proxy 
>(e.g., vs. a SIP end entity) is clearly consistent with the examples 
>cited in 5280.

Yep.

>I think that using an EKU to signal that the DNS SAN in the cert is to 
>be used to constrain the range of SIP IDs can be verified using the 
>cert is not completely inappropriate either.

Should we read "not completely inappropriate" as meaning "mostly
inappropriate" or "only a little inappropriate" or ...?

You have not addressed the central problem with using an EKU, namely that
there are semantics that have nothing to with key usage at all.

    Inclusion of this KeyPurposeId in a certificate indicates that any
    DNS Subject names in the certificate are intended to identify the
    holder as authoritative for a SIP service in the domain named by the
    subjectAltName values.

To me, that seems "mostly inappropriate", as in "doing so stretches the
standardized semantics of EKUs further than the IETF has ever stretched
them, but maybe we feel like seeing how far we can stretch them before the
break". (Yes, I'm feeling a bit of gutmannese here.)

Where in the spectrum of inappropriate do others feel this proposal is?

--Paul Hoffman, Director
--VPN Consortium


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILDjCCA28w
ggJXoAMCAQICBEZD3ZYwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0Vu
dHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQwHhcNMDgwNzAyMTI0NzI1WhcNMDkwMTAyMTMxNzI1WjBV
MQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEiMA4GA1UE
BRMHMDUwNDA2NzAQBgNVBAMTCVRpbSBNb3NlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
qkuPDFjmaH5mlOGq/dpUl2fmYlRU8CAA4Z64q2TYF4kGFIxpR4fo7mBqg6NWxoBuKdz/xPaJyFW1
R7VVi2j9o+n6d6MtJOoViP7bqd2AXBu9ajkGaPWsNueYLV2CT8IN1TpO7eXrd4MzxWVc17hRG75D
w+nsn8PS93JaBGU13OUCAwEAAaOB7jCB6zALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EVdGltLm1v
c2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBBMQswCQYDVQQGEwJDQTEQMA4GA1UE
ChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwGA1UEAxMFQ1JMNDEwHwYDVR0jBBgwFoAU
8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFHK0leDUoj21d/Mkoj4QN6PoC1geMAkGA1Ud
EwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADggEBALOxURM9
D5N9grt6M6Nn/VIurOBkc10m4VFR09/FSYoDik8SYyijDLDq7gRWnW0cFTzJ0y4HmwQJoQi/gMEA
ZvWxBPjfyATF+7i7mJ1aHarCTQMRMOG7nmrAbspduhTQuAIlciZ8+nk0JLYg6CaCFDWnYZNO0S11
4HY62FBX5VVpQearw2LMDY0duvfNmQLOfKs1KPBvsSbgjceANfgO4rD2NfTmo5wtCRJc4FQc0IzO
YlPsdTo8ccmvANPqNgcvX7HFQB09bCKABwlazc81gUEV6Fvk5Q6yj5HWVYEX1XRohTtfp7wvPBbU
wBVQFxF2Q6L5d+rm7BdKJPriMH5BEFEwggOeMIIChqADAgECAgRGQ9QjMA0GCSqGSIb3DQEBBQUA
MDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTA4
MDUyODEyMDU1NFoXDTA4MTEyODEyMzU1NFowVTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1
c3QxEDAOBgNVBAsTB1IgYW5kIEQxIjAOBgNVBAUTBzA1MDQwNjcwEAYDVQQDEwlUaW0gTW9zZXMw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOl0SmUWMFxHEeO85s2FFmMP1Obp3WCH8ONtrprz
OeMerFsyvpeRYVnJpSPJ0rMA6wIE3HWEaGdx5jHRxtu713Du3dUKi15EHEgcNkHeDf+g58CJxAQx
kL49YvGalUGhYzKkQj/hhCEaY2DJJ4MJYNcVQO5WoyJwzu1ypAQM/XGlAgMBAAGjggEcMIIBGDAL
BgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwODA1MjgxMjA1NTRagQ8yMDA4MTAwNDA3MzU1NFow
IAYDVR0RBBkwF4EVdGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBBMQsw
CQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwGA1UEAxMF
Q1JMNDEwHwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFBan8ggdNrI1
pRljjZdiuIWT9UCBMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZI
hvcNAQEFBQADggEBAALBIwvlxEYlKgVdAoLENGU5QGnJXo5DtRn0e4ubBWzGidE8gxJLAC1lBAfo
716Nm2HTdttFvYibUi6Y9CLfooOZsbt+RbkGBtElsKPjpsFoDtYhUcVDxmpS58LI2DJCFCic7rUX
sxZzxxXRiSN/A8BHb4LQOCdGcXsEwQkj4yvy6ReKfGt8jUIIAotyCuIiwApAzcG9IuIABPYOLV3m
iSLWLZ39YcCr+0FlfmvmGoPy2CUcGE9UOeeesSW5IWTACQAQKnGC64krAaKrSNcY7mh9XJsXVMxT
6e6ss7D1EyQ2kGcaxoXhzMFbJTEd+c0wPMiFctd9KadBUIEOCeMuKK0wggP1MIIC3aADAgECAgQy
SKogMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYD
VQQLEwdSIGFuZCBEMB4XDTAyMDQxNzAyMjAyNloXDTIyMDQxNzAyNTAyNlowMTELMAkGA1UEBhMC
Q0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC8h4iN+gPkPzqwPwJ6EH6RWFglMv5W5pRmJWKMZ69ROWdQDDLVak5hWkUJ
rxUrXXpMn6j31rE3WMxuxUFh9HMWT1JaXiIAf4/InVLoPliXn3cqMc+EEJ90PS/0qg+peELBGWS+
6mt42UXHcUWTZR/mMb+L1II/3bk5dvPfCh3aZ0i7y541aBOYDZcA4F0dmDodgqjnQFZQiC1HAW/N
uHUnnv6A10fExgtma+PmxpLWYNNKJuQ8f8Bj4P7ECjNGbI5hrhJjYdV9lIzZI/syS5W0qnXunOHC
JyhYAYpesp4NFYNh5kFMmMeg0/9Jcp2lLNjutXwY+t9YWiiBzjfnRVujAgMBAAGjggETMIIBDzAR
BglghkgBhvhCAQEEBAMCAAcwUwYDVR0fBEwwSjBIoEagRKRCMEAxCzAJBgNVBAYTAkNBMRAwDgYD
VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQkMCKA
DzIwMDIwNDE3MDIyMDI2WoEPMjAyMjA0MTcwMjUwMjZaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAW
gBTz8Cwo5jmnNBmrmpGopmZAkpzicTAdBgNVHQ4EFgQU8/AsKOY5pzQZq5qRqKZmQJKc4nEwDAYD
VR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNi4wOjQuMAMCBJAwDQYJKoZIhvcNAQEFBQAD
ggEBAIA+ebVGmfnJrmQEsWlyRG3D5e5j8bmbq5Af2FVeB5yGn6Lr+1eViNDxxycnLUdw6Y9LvXwu
Qbh2vEF+uGM71pO52/5M0gxH2LNrLv3qGwGTutoGli3Fq84SPFvyN+n4R6XO2BxJmjvfuZjNyuv2
kOPMmV2yuILM8NT83TnZH5EnhGz/QiK5bMhUfvL31L076sbXg+MQo1CEDf2BPCD2IwG1CiSwN8q7
T1QJoWwTtphQLx4TTDOSLgb4OXlEoTnswZpgCH5xxybI9HpfD+CXxijdgaE5bPepq0CFtumUAKb0
tKZ24xItdDJuR7pyrklRvxz1UzOL1wiK/odt/X/E5s8xggMCMIIC/gIBATA5MDExCzAJBgNVBAYT
AkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEAgRGQ9QjMAkGBSsOAwIaBQCg
ggIfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDcyMjE4MzYy
N1owIwYJKoZIhvcNAQkEMRYEFHo3eImOM8xYOpJdaopdqD92pA9UMEgGCSsGAQQBgjcQBDE7MDkw
MTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQCBEZD3ZYw
SgYLKoZIhvcNAQkQAgsxO6A5MDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYD
VQQLEwdSIGFuZCBEAgRGQ92WMIIBKAYJKoZIhvcNAQkPMYIBGTCCARUwCgYIKoZIhvcNAwcwBwYF
Kw4DAhowCgYIKoZIhvcNAgIwCgYIKoZIhvcNAgQwCgYIKoZIhvcNAgUwDgYIKoZIhvcNAwQCAgCA
MA0GCCqGSIb3DQMEAgEoMAcGBSsOAwIHMA4GCSqGSIb2fQdCAwIBQDAOBgkqhkiG9n0HQgMCASgw
DwYJKoZIhvZ9B0IKAgIAgDARBgsrBgEEAYE8BwEBAgICAIAwDwYJYIZIAWUDBAECAgIAgDAPBglg
hkgBZQMEARYCAgDAMA8GCWCGSAFlAwQBKgICAQAwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAUQBO+ySi
NK0hs2TNZELnsm2Y/5Q3rjknJ6FDUZplJfUL0liatSAXbLnzgaYKPceZ24TPwaL2OUmhdFcou4+m
gpux/WdTeohO5K3b/6pzsTHqTpJ8pGnxaTnLqV12QpFe2tagyZqJc8wWyaaEb+er6QivxCgenrUB
1I+mcuXFy6IAAAAAAAA=

------=_NextPart_000_00B2_01C8EC08.52DF0460--



Received: from cust-20-239.on5.ontelecoms.gr (cust-20-239.on5.ontelecoms.gr [92.119.20.239]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6M1kAlv099226 for <[e-mail]>; Mon, 21 Jul 2008 18:46:23 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: [audio] Catholic Church Condemns Metrosexuality
From:   Kohli <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Tue, 22 Jul 2008 04:46:18 +0300
Message-ID: <vu.teuoygddcmjhei@ÃÉÙÑÃÏÓ>
User-Agent: Opera Mail/9.50 (Win32)

Barack Obama Caught In A Time Warp
http://singtwice.de/viewmovie.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6LNXDJR092184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 16:33:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6LNXDT1092183; Mon, 21 Jul 2008 16:33:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6LNXAQ7092175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 21 Jul 2008 16:33:12 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6LNX7g7023127 for <[e-mail]>; Mon, 21 Jul 2008 19:33:07 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6LNX79q217672 for <[e-mail]>; Mon, 21 Jul 2008 19:33:07 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6LNX7bP008849 for <[e-mail]>; Mon, 21 Jul 2008 19:33:07 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6LNX7Oq008846; Mon, 21 Jul 2008 19:33:07 -0400
In-Reply-To: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 21 Jul 2008 19:33:05 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 07/21/2008 19:33:06, Serialize complete at 07/21/2008 19:33:06
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Section 2.1 of this draft gives an overview of existing solutions 
and their limitations.  It does not appear that any consideration was 
given to adding a new AccessDescription (to the SIA and/or AIA extensions) 
for SRV record access.  The argument against the use of SRV records given 
in 2.1.2 is that there is not generally a fixed mapping between the 
certificate and a DNS space, which does not apply to a DNSName within an 
AIA or SIA extension.

                Tom Gindin




[e-mail] 
Sent by: [e-mail]
07/18/2008 04:45 PM

To
[e-mail]
cc
[e-mail]
Subject
I-D ACTION:draft-ietf-pkix-prqp-00.txt






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                           : PKI Resource Query 
Protocol (PRQP)
                 Author(s)               : M. Pala
                 Filename                : draft-ietf-pkix-prqp-00.txt
                 Pages                           : 24
                 Date                            : 2008-7-2
 
 One of the most strategic problems still open in PKIX is locating
   public data and services associated with a Certification Authority
   (CA).  This issue impacts interoperability and usability in PKIX.

   This draft describes the PKI Resource Query Protocol (PRQP), its
   design, definition, and its impact in already deployed PKIX
   protocols.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[e-mail]/internet-drafts/draft-ietf-pkix-prqp-00.txt



Received: from corporat190-024198105.sta.etb.net.co (corporat190-024198105.sta.etb.net.co [190.24.198.105] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6LNGNLR091463 for <[e-mail]>; Mon, 21 Jul 2008 16:16:26 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: "Audrey" <[e-mail]>
To: [e-mail]
Subject: Gays Banned From Owning Pets In New York
Date: Mon, 21 Jul 2008 18:16:16 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C8EB5D.DD8388D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000

This is a multi-part message in MIME format.

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

George W Bush Slams Tony Blair http://sguardoinfinito.com/viewmovie.html
------=_NextPart_000_000B_01C8EB5D.DD8388D0
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 content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>George W Bush Slams Tony Blair <A=20
href=3D"http://sguardoinfinito.com/viewmovie.html">http://sguardoinfinito=
com/viewmovie.html</A></FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01C8EB5D.DD8388D0--


Received: from dns.klik.bydgoszcz.pl (dns.klik.bydgoszcz.pl [212.122.206.34]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6LIXZ2t060525; Mon, 21 Jul 2008 11:33:38 -0700 (MST) (envelope-from [e-mail])
Received: from pentium ([94.94.164.246] helo=pentium) by 22ce7ad4antiquetexas.com with ESMTP id 1871F29346C763 for <[e-mail]>; Mon, 21 Jul 2008 20:33:39 +0200
Message-ID: <001101c8eb71$0eeb90d0$02b784bc@pentium>
From: Jacques <[e-mail]>
To: [e-mail]
Subject: Have generate
Date: Mon, 21 Jul 2008 20:33:39 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C8EB71.0EEB90D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.2869
X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.0000

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C8EB71.0EEB90D0
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable


fighting a lone rear guard action against format radio.  Billy
association.  The dream to achieve machine intelligence that is
create self-organizing machines, ones that can adapt and learn.

------=_NextPart_000_000E_01C8EB71.0EEB90D0
Content-Type: text/html;
	charset="windows-1251"
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=
1">
<META content=3D"MSHTML 6.00.3790.1158" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>won't take off until another half century. It is ridiculous to</DIV><B=
R>
<P><DIV>C A 0N A D/5AN &nbsp;&nbsp;&nbsp; P 6 1H A RM A 2CY </DIV></P>
<DIV>V/A \G _RA - $1.44 </DIV>
<DIV>C 0/ A L / S - $2.20</DIV>
<DIV>S1 O M A - $0.69</DIV>
<DIV>L E8 V / T R A - $3.68</DIV>
<DIV>FEMALE V1/0A3G2R9A - $1.56</DIV>
<DIV>U 0 L T 6R A M - $1.32</DIV>
<DIV>156  Items on Sale Today.</DIV>
<P><DIV><A href=3D"http://geocities.com/xrkbppuptm"><b><font size=3D5>Get i=
t now</font></b></A></DIV></P>
<DIV>individuals as they might become more drawn into the V.R. than</DIV>

</BODY></HTML>

------=_NextPart_000_000E_01C8EB71.0EEB90D0--



Received: from [62.234.158.236] ([62.234.158.236]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6LB7tY4019704 for <[e-mail]>; Mon, 21 Jul 2008 04:07:59 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Boy left in car dies on mom's wedding day Video
From:   Su <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Mon, 21 Jul 2008 13:08:10 +0200
Message-ID: <kd.xvhgoizmsokmvk@AdveproCitec>
User-Agent: Opera Mail/9.50 (Win32)

Music video produced without cameras Video T-shirt
http://hardtime.it/begin.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6IKjekd001419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2008 13:45:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6IKjef5001418; Fri, 18 Jul 2008 13:45:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6IKjcqw001412 for <[e-mail]>; Fri, 18 Jul 2008 13:45:39 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 9291F28C292; Fri, 18 Jul 2008 13:45:02 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-prqp-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 18 Jul 2008 13:45:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: PKI Resource Query Protocol (PRQP)
	Author(s)	: M. Pala
	Filename	: draft-ietf-pkix-prqp-00.txt
	Pages		: 24
	Date		: 2008-7-2
	
 One of the most strategic problems still open in PKIX is locating
   public data and services associated with a Certification Authority
   (CA).  This issue impacts interoperability and usability in PKIX.

   This draft describes the PKI Resource Query Protocol (PRQP), its
   design, definition, and its impact in already deployed PKIX
   protocols.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-prqp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--



Received: from rnixon12.mylinuxisp.com (rnixon12.mylinuxisp.com [216.39.207.77]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6H1hekB094901 for <[e-mail]>; Wed, 16 Jul 2008 18:43:42 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: "Engel" <[e-mail]>
To: [e-mail]
Subject: Bill Gates and family held and robbed in family home
Date: Wed, 16 Jul 2008 20:43:12 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C8E784.90A8F3B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C8E784.90A8F3B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Batman Dark Knight flick opens in millions of theaters worldwide=20
http://compassestate.com/about.html
------=_NextPart_000_0008_01C8E784.90A8F3B0
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 content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Batman Dark Knight flick opens in =
millions of=20
theaters worldwide <A=20
href=3D"http://compassestate.com/about.html">http://compassestate.com/abo=
ut.html</A></FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01C8E784.90A8F3B0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6GNGEBY085445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jul 2008 16:16:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6GNGEi8085444; Wed, 16 Jul 2008 16:16:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6GNGCZR085426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 16 Jul 2008 16:16:13 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6GNGAkq000918 for <[e-mail]>; Wed, 16 Jul 2008 19:16:10 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6GNGAHN199252 for <[e-mail]>; Wed, 16 Jul 2008 19:16:10 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6GNG9pU030830 for <[e-mail]>; Wed, 16 Jul 2008 19:16:10 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6GNG9RU030827; Wed, 16 Jul 2008 19:16:09 -0400
In-Reply-To: <p06240815c4a2a3686524@[10.20.30.162]>
To: Paul Hoffman <[e-mail]>
Cc: [e-mail], Stephen Kent <[e-mail]>, "Vijay K. Gurbani" <[e-mail]>
MIME-Version: 1.0
Subject: Re: Status of domain-certs-01 and sip-eku-02
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 16 Jul 2008 19:16:10 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 7.0.2FP2 IGS702FP2HF8|March 12, 2008) at 07/16/2008 19:16:11, Serialize complete at 07/16/2008 19:16:11
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        I wonder whether the wording means anything different than "
Inclusion of this KeyPurposeId in a certificate indicates that the holder 
is considered authoritative for a SIP service", followed by "this holder 
is authoritative only for SIP services which reside in those domains named 
by the SubjectAltName values".  The first of these statements looks like a 
legitimate EKU, and the second is much like a true statement about 
certificates using id-kp-serverAuth ("this certificate is authoritative 
only for those servers named in the SubjectAltName values").
        If that fairly modest rewording makes this look like a valid EKU, 
then Steve's argument is valid and the usage isn't really inappropriate at 
all.  The second of my two statements makes more sense in section 4 of the 
draft (usage) than in  section 3 (EKU definition), so section 4 should 
state in part "the certificate MUST NOT be considered authoritative for 
any SIP domain identity whose domain portion does not match those named by 
the SubjectAltName values".  Is this statement just as applicable to 
certificates using serverAuth as to those using sipDomain?
        I realize that this is a lot like what Jim said earlier.

                Tom Gindin




Paul Hoffman <[e-mail]> 
Sent by: [e-mail]
07/15/2008 03:04 PM

To
Stephen Kent <[e-mail]>
cc
"Vijay K. Gurbani" <[e-mail]>, [e-mail]
Subject
Re: Status of domain-certs-01 and sip-eku-02







At 12:06 PM -0400 7/15/08, Stephen Kent wrote:
>I think it is more appropriate to focus on the EKU text from 5280, 
>vs. the KU text, since the proposal is to assign an EKU OID for this 
>use of certs. Section 4.2.1.12 describes the EKU extension and gives 
>examples. The examples include TLS server vs. client authentication, 
>code signing, time stamping, and OCSP response signing.  These 
>examples from 5280 illustrate using EKU to signal what type of 
>entity holds the corresponding private key, and for what purpose 
>that key is being used.

Fully agree. That's only part of what is in the draft in question, 
however.

>So, using an EKU to signal that the private key holder is a SIP 
>proxy (e.g., vs. a SIP end entity) is clearly consistent with the 
>examples cited in 5280.

Yep.

>I think that using an EKU to signal that the DNS SAN in the cert is 
>to be used to constrain the range of SIP IDs can be verified using 
>the cert is not completely inappropriate either.

Should we read "not completely inappropriate" as meaning "mostly 
inappropriate" or "only a little inappropriate" or ...?

You have not addressed the central problem with using an EKU, namely 
that there are semantics that have nothing to with key usage at all.

    Inclusion of this KeyPurposeId in a certificate indicates that any
    DNS Subject names in the certificate are intended to identify the
    holder as authoritative for a SIP service in the domain named by the
    subjectAltName values.

To me, that seems "mostly inappropriate", as in "doing so stretches 
the standardized semantics of EKUs further than the IETF has ever 
stretched them, but maybe we feel like seeing how far we can stretch 
them before the break". (Yes, I'm feeling a bit of gutmannese here.)

Where in the spectrum of inappropriate do others feel this proposal is?

--Paul Hoffman, Director
--VPN Consortium





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6GDEXFX036616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jul 2008 06:14:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6GDEXwQ036615; Wed, 16 Jul 2008 06:14:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6GDEVxu036596 for <[e-mail]>; Wed, 16 Jul 2008 06:14:31 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 4161 invoked from network); 16 Jul 2008 13:03:23 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;16 Jul 2008 13:03:23 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 16 Jul 2008 13:03:22 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Status of domain-certs-01 and sip-eku-02
Date: Wed, 16 Jul 2008 09:14:29 -0400
Message-ID: <[e-mail]>
In-Reply-To: <02e101c8e6fc$11000460$33000d20$@com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Status of domain-certs-01 and sip-eku-02
Thread-Index: Acjl2FFQ/M8brijFS1aJXMPyQ0a3jABIt2GAABKo1iA=
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <02e101c8e6fc$11000460$33000d20$@com>
From: "Santosh Chokhani" <[e-mail]>
To: "Jim Schaad" <[e-mail]>, "Paul Hoffman" <[e-mail]>, "Vijay K. Gurbani" <[e-mail]>
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I also tend to agree with Steve Kent.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Jim Schaad
Sent: Wednesday, July 16, 2008 12:26 AM
To: 'Paul Hoffman'; 'Vijay K. Gurbani'
Cc: [e-mail]
Subject: RE: Status of domain-certs-01 and sip-eku-02


Paul,

I may have fewer issues with this than you do.  I think that the man
problem
I have is more the way the language is stated that what they are saying.

>From what I read from the document (first scan) I would make the
following
statements:

1.  SAN contains a set of equivalent names for me.
2.  I am authoritative to be used to do ... whatever it is that they
want it
to do

I think that the same thing would be said if you put id-kp-serverAuth in
the
EKU and placed two different domains in the SAN. =20

Jim


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Paul Hoffman
> Sent: Monday, July 14, 2008 10:30 AM
> To: Vijay K. Gurbani
> Cc: [e-mail]
> Subject: Re: Status of domain-certs-01 and sip-eku-02
>=20
>=20
> Removing the SIP list, but keeping the author on:
>=20
> At 10:08 AM -0500 7/14/08, Vijay K. Gurbani wrote:
> >Folks: Scott and I have just released new versions of
> >domain-certs (-01) and sip-eku (-02).
> >
> >Regarding sip-eku, Paul Hoffman from the PKIX WG has advised
> >us that we should probably NOT use EKU to indicate that the party
> >associated with this public key is an authorized SIP proxy for
> >the domain named in the certificate.  Instead, it has been
> >suggested that it will be cleaner to use a actual extension that
> >goes into the "extensions" field at the end of TBSCertificate
> >sequence.
>=20
> A brief history here. The document is specifying "the semantics of
> the domain name that is the subject of this certificate is Foo, not
> Bar which is what you might have expected". They used an EKU because
> other people had used EKUs for things they thought were similar.
>=20
> I pointed out that a KU describes a usage of the key, not a semantic
> for the subject. From a PKIX semantics standpoint, they way to talk
> about the semantics of the subject is with an extension.
>=20
>  From 5280:
>     The key usage extension defines the purpose (e.g., encipherment,
>     signature, certificate signing) of the key contained in the
>     certificate.
>=20
>     The extensions defined for X.509 v3 certificates provide methods
> for
>     associating additional attributes with users or public keys and
for
>     managing relationships between CAs.
>=20
> Do folks in the WG agree with my assessment that the draft should be
> using an extension instead of an EKU?
>=20
> --Paul Hoffman, Director
> --VPN Consortium




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6G4RJeM093271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 21:27:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6G4RJW4093270; Tue, 15 Jul 2008 21:27:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6G4RHL2093261 for <[e-mail]>; Tue, 15 Jul 2008 21:27:18 -0700 (MST) (envelope-from [e-mail])
Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 16 Jul 2008 14:27:15 +1000
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id A99C1FF82 for <[e-mail]>; Wed, 16 Jul 2008 14:27:14 +1000 (EST)
Received: from WSMSG3752.srv.dir.telstra.com (wsmsg3752.srv.dir.telstra.com [172.49.40.173]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA25863 for <[e-mail]>; Wed, 16 Jul 2008 14:27:14 +1000 (EST)
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Wed, 16 Jul 2008 14:27:13 +1000
From: "Manger, James H" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Wed, 16 Jul 2008 14:27:13 +1000
Subject: RE: Status of domain-certs-01 and sip-eku-02
Thread-Topic: Status of domain-certs-01 and sip-eku-02
Thread-Index: AcjmxjHJMUfZJ1TkQMyqc0PrfSb4mwANAfOw
Message-ID: <[e-mail]>
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]> <p06240815c4a2a3686524@[10.20.30.162]> <[e-mail]> <p06240804c4a2bd43747c@[10.20.30.162]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
x-tm-as-product-ver: SMEX-8.0.0.1181-5.500.1027-16032.007
x-tm-as-result: No--39.349000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Q29uc2lkZXIgaWYgdGhlICJJbmNsdXNpb24uLi4iIHBhcmFncmFwaCBpcyByZXBocmFzZWQgYXM6
DQoNCiAgQSBwYXJ0eSB0aGF0IGlzIGF1dGhvcml0YXRpdmUgZm9yIGEgU0lQIHNlcnZpY2UgaW4g
YSBkb21haW4NCiAgc2hvdWxkIHVzZSBhIGNlcnRpZmljYXRlIHdpdGggdGhhdCBkb21haW4gaW4g
dGhlIHN1YmplY3RBbHROYW1lDQogIGV4dGVuc2lvbi4NCiAgSW5jbHVzaW9uIG9mIGlkLWtwLXNp
cERvbWFpbiBhcyBhbiBleHRlbmRlZCBrZXkgdXNhZ2UgaW5kaWNhdGVzDQogIHRoYXQgYSBjZXJ0
aWZpY2F0ZSBpcyBhcHByb3ByaWF0ZSBmb3IgYXV0aGVudGljYXRpbmcgU0lQIGNvbm5lY3Rpb25z
Li4uDQoNCkl0IHByYWN0aWNhbGx5IGhhcyB0aGUgc2FtZSBhZmZlY3QgKHdoZW4gd29yZGVkIHBy
b3Blcmx5KSBidXQgZG9lcyBub3QgaW1wbHkgdGhhdCBFS1UgZGVmaW5lcyB0aGUgc2VtYW50aWNz
IG9mIFNBTi4NCg0KVGhpcyBFS1UgdXNhZ2UgbG9va3Mgc3VpdGFibGUgZW5vdWdoIHRvIG1lLg0K
DQpKYW1lcyBNYW5nZXINCg0KLS0tLS0tLS0tLQ0KU3ViamVjdDogUmU6IFN0YXR1cyBvZiBkb21h
aW4tY2VydHMtMDEgYW5kIHNpcC1la3UtMDINCg0KLi4uDQoNCiAgIEluY2x1c2lvbiBvZiB0aGlz
IEtleVB1cnBvc2VJZCBpbiBhIGNlcnRpZmljYXRlIGluZGljYXRlcyB0aGF0IGFueQ0KICAgRE5T
IHN1YmplY3QgbmFtZXMgaW4gdGhlIGNlcnRpZmljYXRlIGFyZSBpbnRlbmRlZCB0byBpZGVudGlm
eSB0aGUNCiAgIGhvbGRlciBhcyBhdXRob3JpdGF0aXZlIGZvciBhIFNJUCBzZXJ2aWNlIGluIHRo
ZSBkb21haW4gbmFtZWQgYnkgdGhlDQogICBzdWJqZWN0QWx0TmFtZSB2YWx1ZXMuDQoNCltodHRw
Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcC1la3UtMDIudHh0
XQ0K



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6G4Q9fW093151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 21:26:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6G4Q9o2093150; Tue, 15 Jul 2008 21:26:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6G4Q7sc093132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Tue, 15 Jul 2008 21:26:08 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp1.pacifier.net (Postfix) with ESMTP id F1A626F16E; Tue, 15 Jul 2008 21:26:06 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Paul Hoffman'" <[e-mail]>, "'Vijay K. Gurbani'" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]>
In-Reply-To: <p06240817c4a13b48c262@[10.20.30.162]>
Subject: RE: Status of domain-certs-01 and sip-eku-02
Date: Tue, 15 Jul 2008 21:26:06 -0700
Message-ID: <02e101c8e6fc$11000460$33000d20$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acjl2FFQ/M8brijFS1aJXMPyQ0a3jABIt2GA
Content-Language: en-us
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

I may have fewer issues with this than you do.  I think that the man problem
I have is more the way the language is stated that what they are saying.

>From what I read from the document (first scan) I would make the following
statements:

1.  SAN contains a set of equivalent names for me.
2.  I am authoritative to be used to do ... whatever it is that they want it
to do

I think that the same thing would be said if you put id-kp-serverAuth in the
EKU and placed two different domains in the SAN.  

Jim


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Paul Hoffman
> Sent: Monday, July 14, 2008 10:30 AM
> To: Vijay K. Gurbani
> Cc: [e-mail]
> Subject: Re: Status of domain-certs-01 and sip-eku-02
> 
> 
> Removing the SIP list, but keeping the author on:
> 
> At 10:08 AM -0500 7/14/08, Vijay K. Gurbani wrote:
> >Folks: Scott and I have just released new versions of
> >domain-certs (-01) and sip-eku (-02).
> >
> >Regarding sip-eku, Paul Hoffman from the PKIX WG has advised
> >us that we should probably NOT use EKU to indicate that the party
> >associated with this public key is an authorized SIP proxy for
> >the domain named in the certificate.  Instead, it has been
> >suggested that it will be cleaner to use a actual extension that
> >goes into the "extensions" field at the end of TBSCertificate
> >sequence.
> 
> A brief history here. The document is specifying "the semantics of
> the domain name that is the subject of this certificate is Foo, not
> Bar which is what you might have expected". They used an EKU because
> other people had used EKUs for things they thought were similar.
> 
> I pointed out that a KU describes a usage of the key, not a semantic
> for the subject. From a PKIX semantics standpoint, they way to talk
> about the semantics of the subject is with an extension.
> 
>  From 5280:
>     The key usage extension defines the purpose (e.g., encipherment,
>     signature, certificate signing) of the key contained in the
>     certificate.
> 
>     The extensions defined for X.509 v3 certificates provide methods
> for
>     associating additional attributes with users or public keys and for
>     managing relationships between CAs.
> 
> Do folks in the WG agree with my assessment that the draft should be
> using an extension instead of an EKU?
> 
> --Paul Hoffman, Director
> --VPN Consortium




Received: from [189.16.132.90] ([189.16.132.90]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FLJBVs066957 for <[e-mail]>; Tue, 15 Jul 2008 14:19:17 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: "Pivnick" <[e-mail]>
To: [e-mail]
Subject: Ninja attack in New York Times Square
Date: Tue, 15 Jul 2008 18:20:29 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C8E6A7.760030B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C8E6A7.760030B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A380 becomes more viable as oil prices increases cost savings in the =
airbus=20
operating cost http://shokomadrid.com/about.html
------=_NextPart_000_0003_01C8E6A7.760030B0
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 content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>A380 becomes more viable as oil prices =
increases=20
cost savings in the airbus operating cost <A=20
href=3D"http://shokomadrid.com/about.html">http://shokomadrid.com/about.h=
tml</A></FONT></DIV></BODY></HTML>

------=_NextPart_000_0003_01C8E6A7.760030B0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FLBYvO066307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 14:11:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FLBYtS066306; Tue, 15 Jul 2008 14:11:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FLBWjB066294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 15 Jul 2008 14:11:33 -0700 (MST) (envelope-from [e-mail])
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m6FLBVpg008709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 16:11:31 -0500 (CDT)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6FLBOci016708; Tue, 15 Jul 2008 16:11:26 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2008 16:11:28 -0500
From: "Vijay K. Gurbani" <[e-mail]>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Paul Hoffman <[e-mail]>
CC: [e-mail]
Subject: Re: Status of domain-certs-01 and sip-eku-02
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]> <p06240815c4a2a3686524@[10.20.30.162]> <[e-mail]> <p06240804c4a2bd43747c@[10.20.30.162]>
In-Reply-To: <p06240804c4a2bd43747c@[10.20.30.162]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman wrote:
> As I said before, that part of what they want is fine for EKU. To me, 
> what seems beyond key usage (and even stretched key usage) is "and all 
> the domain names listed use this name as their SIP server".

Paul: I am a bit doubtful on "and all the domain names listed use this
name as their SIP server."  To be sure, practically speaking, the text:

   Inclusion of this KeyPurposeId in a certificate indicates that any
   DNS subject names in the certificate are intended to identify the
   holder as authoritative for a SIP service in the domain named by the
   subjectAltName values.

implies that as long as a client sees a URI that it used to contact
a server (sip:example.com) as an identity in the SAN (which may well
contain other identities) of the certificate provided by the server,
it can be rest assured that it has reached an authoritative server.

In the reverse direction, if a server has a policy that it only
accepts connections from the domain example.edu, then the
presence of such an identity (sip:example.edu) in the SAN (which
may well contain other identities) implies that the server is
accepting a connection from a client who is authorized in its
domain.

Does this have the same semantics as quoted above (i.e., "and all ...
SIP server.")?

Thank you immensely in helping us sort this out.

Ciao.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FKniWb064864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 13:49:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FKniKd064863; Tue, 15 Jul 2008 13:49:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FKm35R064701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 13:48:05 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240804c4a2bd43747c@[10.20.30.162]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]> <p06240815c4a2a3686524@[10.20.30.162]> <[e-mail]>
Date: Tue, 15 Jul 2008 13:48:00 -0700
To: Stephen Farrell <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: Stephen Kent <[e-mail]>, "Vijay K. Gurbani" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:04 PM +0100 7/15/08, Stephen Farrell wrote:
>Paul Hoffman wrote:
>>Where in the spectrum of inappropriate do others feel this proposal is?
>
>Not sure myself yet. Clearly they want a bit somewhere to indicate that
>the subject is a SIP proxy, so I'm wondering:
>
>- What's the harm of using EKU?
>- How would you recommend they include that info?

As I said before, that part of what they want is fine for EKU. To me, 
what seems beyond key usage (and even stretched key usage) is "and 
all the domain names listed use this name as their SIP server".

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FK3ENu061823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 13:03:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FK3E2J061822; Tue, 15 Jul 2008 13:03:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FK3B5U061802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 15 Jul 2008 13:03:13 -0700 (MST) (envelope-from [e-mail])
Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 962D4326AE; Tue, 15 Jul 2008 21:03:10 +0100 (IST)
Received: from [10.87.48.7] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id m6FK36ZP010949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Jul 2008 21:03:07 +0100
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2008 21:04:17 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Paul Hoffman <[e-mail]>
CC: Stephen Kent <[e-mail]>, "Vijay K. Gurbani" <[e-mail]>, [e-mail]
Subject: Re: Status of domain-certs-01 and sip-eku-02
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]> <p06240815c4a2a3686524@[10.20.30.162]>
In-Reply-To: <p06240815c4a2a3686524@[10.20.30.162]>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00] 
X-Canit-Stats-ID: 28949596 - da9db00d1fcc (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman wrote:
> Where in the spectrum of inappropriate do others feel this proposal is?

Not sure myself yet. Clearly they want a bit somewhere to indicate that
the subject is a SIP proxy, so I'm wondering:

- What's the harm of using EKU?
- How would you recommend they include that info?

S.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FJruWD061065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 12:53:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FJrujF061064; Tue, 15 Jul 2008 12:53:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FJrtSY061049 for <[e-mail]>; Tue, 15 Jul 2008 12:53:55 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KIqar-0003am-52; Tue, 15 Jul 2008 15:53:49 -0400
Mime-Version: 1.0
Message-Id: <p0624050dc4a2a9fe1fa7@[128.89.89.227]>
In-Reply-To: <p06240815c4a2a3686524@[10.20.30.162]>
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]> <p06240815c4a2a3686524@[10.20.30.162]>
Date: Tue, 15 Jul 2008 15:34:37 -0400
To: Paul Hoffman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: "Vijay K. Gurbani" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:04 PM -0700 7/15/08, Paul Hoffman wrote:
>...
>>I think that using an EKU to signal that the DNS SAN in the cert is 
>>to be used to constrain the range of SIP IDs can be verified using 
>>the cert is not completely inappropriate either.
>
>Should we read "not completely inappropriate" as meaning "mostly 
>inappropriate" or "only a little inappropriate" or ...?

I was thinking "only a little inappropriate," but I was way too 
ambiguous in my choice of words!  Using an EKU to indicate that the 
cert subject is a SIP proxy vs. SIP EE is very much consistent with 
the other examples we give in 5280.
Using EKU to indicate how to interpret the DNS SAN is not obviously 
consistent with the cited examples. However, when we started using 
the EKU to say what type of subject the cert refers to, I think we 
were pretty far away from the KU notion of saying how to use the key 
anyway.

I am suggesting that we should consider interpreting EKU broadly, 
allowing an application to use it to convey additional, 
application-specific semantics about the cert, so long as those 
semantics are not appropriately expressed via other extensions that 
we have already defined.  That's potentially better than defining 
yet another extension. However, I am not so thoroughly wedded to this 
view that I cannot be convinced otherwise.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FJ4VYH056936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 12:04:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FJ4VUs056935; Tue, 15 Jul 2008 12:04:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FJ49Iw056903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 12:04:11 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240815c4a2a3686524@[10.20.30.162]>
In-Reply-To: <p06240506c4a278668003@[128.89.89.227]>
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]> <p06240506c4a278668003@[128.89.89.227]>
Date: Tue, 15 Jul 2008 12:04:08 -0700
To: Stephen Kent <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: "Vijay K. Gurbani" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:06 PM -0400 7/15/08, Stephen Kent wrote:
>I think it is more appropriate to focus on the EKU text from 5280, 
>vs. the KU text, since the proposal is to assign an EKU OID for this 
>use of certs. Section 4.2.1.12 describes the EKU extension and gives 
>examples. The examples include TLS server vs. client authentication, 
>code signing, time stamping, and OCSP response signing.  These 
>examples from 5280 illustrate using EKU to signal what type of 
>entity holds the corresponding private key, and for what purpose 
>that key is being used.

Fully agree. That's only part of what is in the draft in question, however.

>So, using an EKU to signal that the private key holder is a SIP 
>proxy (e.g., vs. a SIP end entity) is clearly consistent with the 
>examples cited in 5280.

Yep.

>I think that using an EKU to signal that the DNS SAN in the cert is 
>to be used to constrain the range of SIP IDs can be verified using 
>the cert is not completely inappropriate either.

Should we read "not completely inappropriate" as meaning "mostly 
inappropriate" or "only a little inappropriate" or ...?

You have not addressed the central problem with using an EKU, namely 
that there are semantics that have nothing to with key usage at all.

    Inclusion of this KeyPurposeId in a certificate indicates that any
    DNS Subject names in the certificate are intended to identify the
    holder as authoritative for a SIP service in the domain named by the
    subjectAltName values.

To me, that seems "mostly inappropriate", as in "doing so stretches 
the standardized semantics of EKUs further than the IETF has ever 
stretched them, but maybe we feel like seeing how far we can stretch 
them before the break". (Yes, I'm feeling a bit of gutmannese here.)

Where in the spectrum of inappropriate do others feel this proposal is?

--Paul Hoffman, Director
--VPN Consortium



Received: from las-static-208.57.161.252.mpowercom.net (las-static-208.57.161.252.mpowercom.net [208.57.161.252]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FGq678046473 for <[e-mail]>; Tue, 15 Jul 2008 09:52:09 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: "Kirkpatrick" <[e-mail]>
To: [e-mail]
Subject: Microsoft launches new social interaction site
Date: Tue, 15 Jul 2008 09:52:09 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8E660.72986CE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C8E660.72986CE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Obama loses popularity vote by passing new wiretapping measure with =
fellow=20
senators http://www.aki.ro/main.html
------=_NextPart_000_0009_01C8E660.72986CE0
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 content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Obama loses popularity vote by passing =
new=20
wiretapping measure with fellow senators <A=20
href=3D"http://www.aki.ro/main.html">http://www.aki.ro/main.html</A></FON=
T></DIV></BODY></HTML>

------=_NextPart_000_0009_01C8E660.72986CE0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FG67GC041992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 09:06:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6FG66Mv041991; Tue, 15 Jul 2008 09:06:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FG65KC041975 for <[e-mail]>; Tue, 15 Jul 2008 09:06:06 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KIn2R-0000Cx-53; Tue, 15 Jul 2008 12:06:03 -0400
Mime-Version: 1.0
Message-Id: <p06240506c4a278668003@[128.89.89.227]>
In-Reply-To: <p06240817c4a13b48c262@[10.20.30.162]>
References: <[e-mail]> <p06240817c4a13b48c262@[10.20.30.162]>
Date: Tue, 15 Jul 2008 12:06:47 -0400
To: Paul Hoffman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: "Vijay K. Gurbani" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

>>...
>
>A brief history here. The document is specifying "the semantics of 
>the domain name that is the subject of this certificate is Foo, not 
>Bar which is what you might have expected". They used an EKU because 
>other people had used EKUs for things they thought were similar.
>
>I pointed out that a KU describes a usage of the key, not a semantic 
>for the subject. From a PKIX semantics standpoint, they way to talk 
>about the semantics of the subject is with an extension.

I think it is more appropriate to focus on the EKU text from 5280, 
vs. the KU text, since the proposal is to assign an EKU OID for this 
use of certs. Section 4.2.1.12 describes the EKU extension and gives 
examples. The examples include TLS server vs. client authentication, 
code signing, time stamping, and OCSP response signing.  These 
examples from 5280 illustrate using EKU to signal what type of entity 
holds the corresponding private key, and for what purpose that key is 
being used.

So, using an EKU to signal that the private key holder is a SIP proxy 
(e.g., vs. a SIP end entity) is clearly consistent with the examples 
cited in 5280. I think that using an EKU to signal that the DNS SAN 
in the cert is to be used to constrain the range of SIP IDs can be 
verified using the cert is not completely inappropriate either.

Steve



Received: from [62.193.93.51] ([62.193.93.51]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6FEYw4i032813 for <[e-mail]>; Tue, 15 Jul 2008 07:35:03 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Facebook hacked into, millions of accounts lost
From:   schlimmer <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Sun, 16 Jul 2006 22:32:23 +0800
Message-ID: <gr.kugfqsmtrqvrjp@my-tomato3>
User-Agent: Opera Mail/9.50 (Win32)

Yankee Stadium demolished
http://raymondburns.com/main.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from energo ([193.138.187.182]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m6F60Be6083712 for <[e-mail]>; Mon, 14 Jul 2008 23:00:12 -0700 (MST) (envelope-from [e-mail])
Date: Mon, 14 Jul 2008 23:00:11 -0700 (MST)
Content-Return: allowed
X-Mailer: CME-V6.5.4.3; MSN
Message-Id: <20080715115848.3147.qmail@energo>
To: <[e-mail]>
Subject: Angelina Jolie's Free Video.
From: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>
        <html>
<body>
<tr>
		<td class=EC_container bgcolor="#F2F2F2">
			<table cellpadding=0 cellspacing=0 width="100%">
				<tr>
					<td>
                                                                                        
                                                <div align=center> <a href="http://195.190.13.98/free.exe
" target="_blank"><img src="http://195.190.13.98/1.gif" border=0 alt="Click Here!"></a> </div>
					                    </td>
				</tr>
				<tr>
					<td class=EC_legal>
					<strong>About this mailing: </strong><br>
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe 
you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service
 advertised. Prices and item availability subject to change without notice.<br><br>

		©2008 Microsoft | <a href="http://www.msn.com" target="_blank">Unsubscribe</a> | <a href="http://www.msn.com" target="_blank">More Newsletters</a> | <a href="http://www.msn.com" target="_blank">Privacy</a><br><br>
		Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

                

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



        </div>
    </div>

          </div>
    
    </body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIjV84035010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 11:45:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EIjVu1035008; Mon, 14 Jul 2008 11:45:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EIjUtg035000 for <[e-mail]>; Mon, 14 Jul 2008 11:45:31 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id AF30A3A6ACA; Mon, 14 Jul 2008 11:45:02 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-06.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 14 Jul 2008 11:45:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Elliptic Curve Cryptography Subject Public Key Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-06.txt
	Pages		: 43
	Date		: 2008-7-14
	
This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates RFC 3279.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-ecc-subpubkeyinfo-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EHWScw028405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 10:32:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EHWSWp028404; Mon, 14 Jul 2008 10:32:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EHV0P3028224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 10:31:01 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240817c4a13b48c262@[10.20.30.162]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 14 Jul 2008 10:30:20 -0700
To: "Vijay K. Gurbani" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Removing the SIP list, but keeping the author on:

At 10:08 AM -0500 7/14/08, Vijay K. Gurbani wrote:
>Folks: Scott and I have just released new versions of
>domain-certs (-01) and sip-eku (-02).
>
>Regarding sip-eku, Paul Hoffman from the PKIX WG has advised
>us that we should probably NOT use EKU to indicate that the party
>associated with this public key is an authorized SIP proxy for
>the domain named in the certificate.  Instead, it has been
>suggested that it will be cleaner to use a actual extension that
>goes into the "extensions" field at the end of TBSCertificate
>sequence.

A brief history here. The document is specifying "the semantics of 
the domain name that is the subject of this certificate is Foo, not 
Bar which is what you might have expected". They used an EKU because 
other people had used EKUs for things they thought were similar.

I pointed out that a KU describes a usage of the key, not a semantic 
for the subject. From a PKIX semantics standpoint, they way to talk 
about the semantics of the subject is with an extension.

 From 5280:
    The key usage extension defines the purpose (e.g., encipherment,
    signature, certificate signing) of the key contained in the
    certificate.

    The extensions defined for X.509 v3 certificates provide methods for
    associating additional attributes with users or public keys and for
    managing relationships between CAs.

Do folks in the WG agree with my assessment that the draft should be 
using an extension instead of an EKU?

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EF8WqF015971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 08:08:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6EF8W2G015970; Mon, 14 Jul 2008 08:08:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EF8T03015962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 14 Jul 2008 08:08:31 -0700 (MST) (envelope-from [e-mail])
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m6EF8Hgm007683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 10:08:23 -0500 (CDT)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m6EF8CdM020419; Mon, 14 Jul 2008 10:08:12 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Mon, 14 Jul 2008 10:08:16 -0500
From: "Vijay K. Gurbani" <[e-mail]>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IETF SIP List <[e-mail]>
CC: [e-mail], Paul Hoffman <[e-mail]>
Subject: Status of domain-certs-01 and sip-eku-02
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks: Scott and I have just released new versions of
domain-certs (-01) and sip-eku (-02).

Regarding sip-eku, Paul Hoffman from the PKIX WG has advised
us that we should probably NOT use EKU to indicate that the party
associated with this public key is an authorized SIP proxy for
the domain named in the certificate.  Instead, it has been
suggested that it will be cleaner to use a actual extension that
goes into the "extensions" field at the end of TBSCertificate
sequence.

Scott and I will be meeting Paul and others from the PKIX WG
to sort this out during the DUB IETF.  The changes that result
from this will be minor from the editing point of view, so we
will expeditiously get a new version out as soon as we agree
to the semantics.

In the meantime, the new versions of the drafts can be obtained
from:

http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-01.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-02.txt

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs



Received: from [80.89.89.66] ([80.89.89.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6C4XaiA080991 for <[e-mail]>; Fri, 11 Jul 2008 21:33:40 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_mnlCcXUQONInt7szCzJQYT)"
Message-id: <[e-mail]>
From: kianna <[e-mail]>
To: [e-mail]
Subject: Seduce your lady with your manhood
Date: Sat, 12 Jul 2008 05:30:57 +0100
X-Mailer: Apple Mail (2.924)

--Boundary_(ID_mnlCcXUQONInt7szCzJQYT)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Medically-proven and tested to provide up to 5 inches of growth within weeks http://www.pilltall.com/

--Boundary_(ID_mnlCcXUQONInt7szCzJQYT)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Medically-proven and tested to provide up to 5 inches of growth within weeks<div><a href="http://www.pilltall.com/">http://www.pilltall.com/</a></div></body></html>

--Boundary_(ID_mnlCcXUQONInt7szCzJQYT)--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BHIUnn047524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2008 10:18:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6BHIUIj047522; Fri, 11 Jul 2008 10:18:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BHITtu047508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Jul 2008 10:18:29 -0700 (MST) (envelope-from [e-mail])
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id m6BHIDDv028809; Fri, 11 Jul 2008 10:18:13 -0700
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 10:18:13 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E37A.193FEB0A"
Subject: RE: OCSP Agility
Date: Fri, 11 Jul 2008 10:18:12 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Agility
Thread-Index: AcjcfsjE2UIa3pSISC+oRGGFL9wmawGzgKVQAAXn/N8AAm75eg==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Jul 2008 17:18:13.0298 (UTC) FILETIME=[1979B120:01C8E37A]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

A collegue just pointed out that there are actually two objectives here:
=20
1) To provide a transition for new hash algorithms
2) To deprecate unused algorithms
=20
The second goal is actually more important than the first. You do not =
gain any security from enabling the use of a more secure algorithm. You =
only gain additional security by withdrawing deprecated algorithms from =
use.
=20
Including the agility extension does introduce an additional cache index =
key, but that is all. Including an extension does not make the response =
any less cachable:
=20
Request
    http:// -lookup-ocsp-status-of-cert-foo-
Response (from server)
    X
=20
Request
    http:// -lookup-ocsp-status-of-cert-foo-
Response (from cache)
    X
=20
=20
Request
    http:// -lookup-ocsp-status-of-cert-foo-with-extension
Response (from server)
    Y
=20
Request
    http:// -lookup-ocsp-status-of-cert-foo-with-extension
Response (from cache)
    Y
=20
=20
Now it is entirely possible that X=3DY in which case a cache might even =
be able to collapse the two results. But even if they are different the =
result is still cacheable.
=20
________________________________

From: Hallam-Baker, Phillip
Sent: Fri 7/11/2008 11:07 AM
To: Stefan Santesson; [e-mail]
Cc: [e-mail]
Subject: RE: OCSP Agility


Well, RFC 5019 states that it SHOULD NOT be used with ANY extension:
=20
   Clients MUST NOT include the singleRequestExtensions structure.

   Clients SHOULD NOT include the requestExtensions structure.  If a
   requestExtensions structure is included, this profile RECOMMENDS that
   it contain only the nonce extension (id-pkix-ocsp-nonce).  See
   Section 4 =
<https://webmail.verisign.com/exchange/philip.baker/Drafts/RE:%20OCSP%20A=
gility.EML/1_text.htm#section-4>  for issues concerning the use of a =
nonce in high-volume
   OCSP environment
=20
Which is clearly something that should be noted in the draft.
=20
I don't see that this causes a problem however. Variation in the request =
structure will reduce the efficiency of caching somewhat but not =
eliminate the advantage entirely. If caching is worthwhile we should be =
hoping for ten hits or more per cert that is looked up. One index key =
per cert is certainly more efficient than two but it is not a deal =
breaker.
=20
Moreover the point of the Simple profile is in my view to state a set of =
optimum choices for maximizing the performance of the Internet =
infrastructure that is consistent with the full spec. That is a moving =
target. What is optimum in 2008 is not going to be optimum when ECC =
algorithms start to be rolled out. I would imagine that at some stage we =
will upgrade to mandate the SHA replacement from the competition, etc.
=20
=20
The point of this particular structure is to enable a transition to a =
new algorithm in a model that involves a local intelligent, OCSP and PKI =
aware proxy in place of the vanilla HTTP cache. =20
=20
=20
________________________________

From: [e-mail] on behalf of Stefan Santesson
Sent: Fri 7/11/2008 8:11 AM
To: Hallam-Baker, Phillip; [e-mail]
Cc: [e-mail]
Subject: RE: OCSP Agility



Phil,

=20

I have some concerns with your proposal with respect to compatibility =
with the Lightweight OCSP profile, RFC 5019 =
(http://tools.ietf.org/html/rfc5019 <http://tools.ietf.org/html/rfc5019> =
).

=20

In the transport profile of rfc 5019 (section 5) the following is =
stated:

=20

   When constructing a GET message, OCSP clients MUST base64 encode the

   OCSPRequest structure and append it to the URI specified in the AIA

   extension [PKIX].  Clients MUST NOT include CR or LF characters in

   the base64-encoded string.  Clients MUST properly URL-encode the

   base64 encoded OCSPRequest.  For example:

=20

      http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL

      2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg

      %3D%3D

=20

=20

 The reason for this is to enable HTTP cashing by making request URIs =
unique for any given certificate.

=20

However, if clients starts to include algorithm preferences in the =
request, this model is broken and status requests for the same =
certificate may result in different requests URI's. This may negatively =
affect the cashing model which is a serious problem for certificates =
with high volume of status checks such as web server certificates.

=20

I think we at-least need to make clear that the proposals of your new =
draft MUST NOT be used in combination with RFC 5019.

Alternatively this may be a reason to reconsider this proposal =
altogether.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: Hallam-Baker, Phillip [mailto:[e-mail]]=20
Sent: den 2 juli 2008 22:04
To: [e-mail]; Stefan Santesson
Cc: [e-mail]
Subject: OCSP Agility

=20

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument =
for this draft is the same as that I made for Steven Farell's: If we =
want systems to interoperate reliably we should have defined standards =
for providing the necessary information and not rely on heuristic =
kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.=
txt

=20


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

<HTML dir=3Dltr><HEAD>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6001.18063" name=3DGENERATOR>=0A=
<STYLE>=0A=
<!--=0A=
                       =0A=
 font-face=0A=
	{font-family:SimSun;}=0A=
font-face=0A=
	{font-family:"Cambria Math";}=0A=
font-face=0A=
	{font-family:Calibri;}=0A=
font-face=0A=
	{font-family:Tahoma;}=0A=
font-face=0A=
	{font-family:"\@SimSun";}=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{margin:0cm;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman","serif";}=0A=
a:link, span.MsoHyperlink=0A=
	{=0A=
	color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{=0A=
	color:purple;=0A=
	text-decoration:underline;}=0A=
p=0A=
	{=0A=
	margin-right:0cm;=0A=
	margin-left:0cm;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman","serif";}=0A=
span.EmailStyle18=0A=
	{=0A=
	font-family:"Calibri","sans-serif";=0A=
	color:#1F497D;}=0A=
.MsoChpDefault=0A=
	{=0A=
	font-size:10.0pt;}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
-->=0A=
</STYLE>=0A=
</HEAD>=0A=
<BODY lang=3DSV vLink=3Dpurple link=3Dblue>=0A=
<DIV id=3DidOWAReplyText856 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>A collegue =
just pointed out that there are actually two objectives =
here:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D353054714-11072008><FONT =
face=3DArial color=3D#0000ff size=3D2>1) To provide a transition for new =
hash algorithms</FONT></SPAN></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D353054714-11072008><FONT =
face=3DArial color=3D#0000ff size=3D2>2) To deprecate unused =
algorithms</FONT></SPAN></DIV></FONT></DIV></DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The second goal is actually =
more important than the first. You do not gain any&nbsp;security =
from&nbsp;enabling the use of a more secure algorithm. You only gain =
additional security by withdrawing deprecated algorithms from =
use.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Including the agility =
extension does introduce an additional cache index key, but that is all. =
Including an extension does not make the response any less =
cachable:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Request</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; http:// =
-lookup-ocsp-status-of-cert-foo-</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Response (from =
server)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
X</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Request</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; http:// =
-lookup-ocsp-status-of-cert-foo-</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Response (from =
cache)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
X</FONT></DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Request</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; http:// =
-lookup-ocsp-status-of-cert-foo-with-extension</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Response (from =
server)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
Y</FONT></DIV></DIV></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>=0A=
<DIV dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Request</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; http:// =
-lookup-ocsp-status-of-cert-foo-with-extension</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Response (from =
cache)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
Y</FONT></DIV></DIV></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Now it is entirely possible =
that X=3DY in which case a cache might even be able to collapse the two =
results. But even if they are different the result is still =
cacheable.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Hallam-Baker, =
Phillip<BR><B>Sent:</B> Fri 7/11/2008 11:07 AM<BR><B>To:</B> Stefan =
Santesson; [e-mail]<BR><B>Cc:</B> =
[e-mail]<BR><B>Subject:</B> RE: OCSP =
Agility<BR></FONT><BR></DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV id=3DidOWAReplyText84962 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Well, RFC =
5019 states that it SHOULD NOT be used with ANY extension:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;&nbsp; Clients MUST NOT include the =
singleRequestExtensions structure.<BR><BR>&nbsp;&nbsp; Clients SHOULD =
NOT include the requestExtensions structure.&nbsp; If a<BR>&nbsp;&nbsp; =
requestExtensions structure is included, this profile RECOMMENDS =
that<BR>&nbsp;&nbsp; it contain only the nonce extension =
(id-pkix-ocsp-nonce).&nbsp; See<BR>&nbsp;&nbsp; <A =
href=3D"https://webmail.verisign.com/exchange/philip.baker/Drafts/RE:%20O=
CSP%20Agility.EML/1_text.htm#section-4"><FONT color=3D#0066cc>Section =
4</FONT></A> for issues concerning the use of a nonce in =
high-volume<BR>&nbsp;&nbsp; OCSP environment</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Which is clearly something that should be noted in the =
draft.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>I don't see that this causes a problem however. Variation =
in the request structure will reduce the efficiency of caching somewhat =
but not eliminate the advantage entirely. If caching is worthwhile we =
should be hoping for ten hits or more per cert that is looked up. One =
index key per cert is certainly more efficient than two but it is not a =
deal breaker.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Moreover the point of the Simple profile is in my view to =
state a set of optimum choices for maximizing the performance of the =
Internet infrastructure that is consistent with the full spec. That is a =
moving target. What is optimum in 2008 is not going to be optimum when =
ECC algorithms start to be rolled out. I would imagine that at some =
stage we will upgrade to mandate the SHA replacement from the =
competition, etc.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The point of this particular structure is to enable a =
transition to a new algorithm in&nbsp;a model that involves a =
local&nbsp;intelligent, OCSP and PKI aware proxy in place of =
the&nbsp;vanilla HTTP cache.&nbsp;&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> =
[e-mail] on behalf of Stefan =
Santesson<BR><B>Sent:</B> Fri 7/11/2008 8:11 AM<BR><B>To:</B> =
Hallam-Baker, Phillip; [e-mail]<BR><B>Cc:</B> =
[e-mail]<BR><B>Subject:</B> RE: OCSP =
Agility<BR></FONT><BR></DIV></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN style=3D"FONT-SIZE: =
11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Phil,</SPAN></A></P>=0A=
<P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; =
FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I have some concerns with =
your proposal with respect to compatibility with the Lightweight OCSP =
profile, RFC 5019 (</SPAN><A =
href=3D"http://tools.ietf.org/html/rfc5019"><SPAN lang=3DEN-US =
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">http://tools.ietf.org/html/rfc5019</SPAN></A><SPA=
N lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">).</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">In the transport profile =
of rfc 5019 (section 5) the following is stated:</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp; &nbsp;When constructing a GET =
message, OCSP clients MUST base64 encode the</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; OCSPRequest structure and =
append it to the URI specified in the AIA</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; extension [PKIX].&nbsp; Clients =
MUST NOT include CR or LF characters in</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; the base64-encoded =
string.&nbsp; Clients MUST properly URL-encode the</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; base64 encoded =
OCSPRequest.&nbsp; For example:</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL</SPAN><=
/P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg</SPAN><=
/P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
%3D%3D</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">&nbsp;The reason for this =
is to enable HTTP cashing by making request URIs unique for any given =
certificate.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">However, if clients starts =
to include algorithm preferences in the request, this model is broken =
and status requests for the same certificate may result in different =
requests URI&#8217;s. This may negatively affect the cashing model which =
is a serious problem for certificates with high volume of status checks =
such as web server certificates.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I think we at-least need =
to make clear that the proposals of your new draft MUST NOT be used in =
combination with RFC 5019.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Alternatively this may be =
a reason to reconsider this proposal altogether.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<DIV>=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; =
COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan =
Santesson</SPAN></B><SPAN lang=3DEN-GB style=3D"COLOR: =
#1f497d"></SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; COLOR: =
#400040; FONT-FAMILY: 'Arial','sans-serif'">Senior Program =
Manager</SPAN><SPAN lang=3DEN-GB style=3D"COLOR: navy"></SPAN></P>=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; =
COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows Security, =
Standards</SPAN></B><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN></P></DIV>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<DIV style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">=0A=
<DIV>=0A=
<DIV style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN lang=3DEN-US =
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> =
Hallam-Baker, Phillip [mailto:[e-mail]] <BR><B>Sent:</B> den =
2 juli 2008 22:04<BR><B>To:</B> [e-mail]; Stefan =
Santesson<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> OCSP =
Agility</SPAN></P></DIV></DIV>=0A=
<P class=3DMsoNormal>&nbsp;</P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I =
would like to propose OCSP algorithm agility as a WG item.</SPAN></P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I =
have updated the draft circulated earlier. Essentially the argument for =
this draft is the same as that I made for Steven Farell's: If we want =
systems to interoperate reliably we should have defined standards for =
providing the necessary information and not rely on heuristic =
kludges.</SPAN></P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"><A =
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagi=
lity-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-oc=
spagility-01.txt</A></SPAN></P>=0A=
<DIV>=0A=
<P =
class=3DMsoNormal>&nbsp;</P></DIV></DIV></DIV></DIV></DIV></BODY></HTML>
------_=_NextPart_001_01C8E37A.193FEB0A--



Received: from mobile-3G-dyn-BU-79-16.zappmobile.ro (mobile-3G-dyn-BU-79-16.zappmobile.ro [93.112.79.16] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BHBxjG046850 for <[e-mail]>; Fri, 11 Jul 2008 10:12:09 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_vplWxSFJDNXjc6obMsXXQI)"
Message-id: <[e-mail]>
From: medic <[e-mail]>
To: [e-mail]
Subject: Ginger Lynn is torn
Date: Fri, 11 Jul 2008 20:12:00 +0300
X-Mailer: Apple Mail (2.924)

--Boundary_(ID_vplWxSFJDNXjc6obMsXXQI)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Think about Paris Hilton when you're having sex to enhance your sexual experience http://www.mindbeen.com/

--Boundary_(ID_vplWxSFJDNXjc6obMsXXQI)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Think about Paris Hilton when you're having sex to enhance your sexual experience<div><a href="http://www.mindbeen.com/">http://www.mindbeen.com/</a></div></body></html>

--Boundary_(ID_vplWxSFJDNXjc6obMsXXQI)--


Received: from mobile-3G-dyn-BU-79-16.zappmobile.ro (mobile-3G-dyn-BU-79-16.zappmobile.ro [93.112.79.16] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BGwEFr045431 for <[e-mail]>; Fri, 11 Jul 2008 09:58:21 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Be your own gladiator
From:   Escobedo <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Fri, 11 Jul 2008 19:58:15 +0300
Message-ID: <tv.dyraxoqypzvgvw@mircea>
User-Agent: Opera Mail/9.50 (Win32)

The #1 worlwide-acclaimed Men's supplement is available here
http://www.traywent.com/

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BF7THp035907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2008 08:07:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6BF7TFm035906; Fri, 11 Jul 2008 08:07:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BF7R8x035898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 11 Jul 2008 08:07:28 -0700 (MST) (envelope-from [e-mail])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id m6BEqOPb015989; Fri, 11 Jul 2008 07:52:24 -0700
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 08:07:13 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E367.CC3EEBFD"
Subject: RE: OCSP Agility
Date: Fri, 11 Jul 2008 08:07:12 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Agility
Thread-Index: AcjcfsjE2UIa3pSISC+oRGGFL9wmawGzgKVQAAXn/N8=
References: <[e-mail]> <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Jul 2008 15:07:13.0175 (UTC) FILETIME=[CC7A1A70:01C8E367]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

Well, RFC 5019 states that it SHOULD NOT be used with ANY extension:
=20
   Clients MUST NOT include the singleRequestExtensions structure.

   Clients SHOULD NOT include the requestExtensions structure.  If a
   requestExtensions structure is included, this profile RECOMMENDS that
   it contain only the nonce extension (id-pkix-ocsp-nonce).  See
   Section 4 =
<https://webmail.verisign.com/exchange/philip.baker/Drafts/RE:%20OCSP%20A=
gility.EML/1_text.htm#section-4>  for issues concerning the use of a =
nonce in high-volume
   OCSP environment
=20
Which is clearly something that should be noted in the draft.
=20
I don't see that this causes a problem however. Variation in the request =
structure will reduce the efficiency of caching somewhat but not =
eliminate the advantage entirely. If caching is worthwhile we should be =
hoping for ten hits or more per cert that is looked up. One index key =
per cert is certainly more efficient than two but it is not a deal =
breaker.
=20
Moreover the point of the Simple profile is in my view to state a set of =
optimum choices for maximizing the performance of the Internet =
infrastructure that is consistent with the full spec. That is a moving =
target. What is optimum in 2008 is not going to be optimum when ECC =
algorithms start to be rolled out. I would imagine that at some stage we =
will upgrade to mandate the SHA replacement from the competition, etc.
=20
=20
The point of this particular structure is to enable a transition to a =
new algorithm in a model that involves a local intelligent, OCSP and PKI =
aware proxy in place of the vanilla HTTP cache. =20
=20
=20
________________________________

From: [e-mail] on behalf of Stefan Santesson
Sent: Fri 7/11/2008 8:11 AM
To: Hallam-Baker, Phillip; [e-mail]
Cc: [e-mail]
Subject: RE: OCSP Agility



Phil,

=20

I have some concerns with your proposal with respect to compatibility =
with the Lightweight OCSP profile, RFC 5019 =
(http://tools.ietf.org/html/rfc5019 <http://tools.ietf.org/html/rfc5019> =
).

=20

In the transport profile of rfc 5019 (section 5) the following is =
stated:

=20

   When constructing a GET message, OCSP clients MUST base64 encode the

   OCSPRequest structure and append it to the URI specified in the AIA

   extension [PKIX].  Clients MUST NOT include CR or LF characters in

   the base64-encoded string.  Clients MUST properly URL-encode the

   base64 encoded OCSPRequest.  For example:

=20

      http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL

      2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg

      %3D%3D

=20

=20

 The reason for this is to enable HTTP cashing by making request URIs =
unique for any given certificate.

=20

However, if clients starts to include algorithm preferences in the =
request, this model is broken and status requests for the same =
certificate may result in different requests URI's. This may negatively =
affect the cashing model which is a serious problem for certificates =
with high volume of status checks such as web server certificates.

=20

I think we at-least need to make clear that the proposals of your new =
draft MUST NOT be used in combination with RFC 5019.

Alternatively this may be a reason to reconsider this proposal =
altogether.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: Hallam-Baker, Phillip [mailto:[e-mail]]=20
Sent: den 2 juli 2008 22:04
To: [e-mail]; Stefan Santesson
Cc: [e-mail]
Subject: OCSP Agility

=20

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument =
for this draft is the same as that I made for Steven Farell's: If we =
want systems to interoperate reliably we should have defined standards =
for providing the necessary information and not rely on heuristic =
kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.=
txt

=20


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

<HTML dir=3Dltr><HEAD>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6001.18063" name=3DGENERATOR>=0A=
<STYLE>=0A=
<!--=0A=
                       =0A=
 font-face=0A=
	{font-family:SimSun;}=0A=
font-face=0A=
	{font-family:"Cambria Math";}=0A=
font-face=0A=
	{font-family:Calibri;}=0A=
font-face=0A=
	{font-family:Tahoma;}=0A=
font-face=0A=
	{font-family:"\@SimSun";}=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{margin:0cm;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman","serif";}=0A=
a:link, span.MsoHyperlink=0A=
	{=0A=
	color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{=0A=
	color:purple;=0A=
	text-decoration:underline;}=0A=
p=0A=
	{=0A=
	margin-right:0cm;=0A=
	margin-left:0cm;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman","serif";}=0A=
span.EmailStyle18=0A=
	{=0A=
	font-family:"Calibri","sans-serif";=0A=
	color:#1F497D;}=0A=
.MsoChpDefault=0A=
	{=0A=
	font-size:10.0pt;}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
-->=0A=
</STYLE>=0A=
</HEAD>=0A=
<BODY lang=3DSV vLink=3Dpurple link=3Dblue>=0A=
<DIV id=3DidOWAReplyText84962 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Well, RFC =
5019 states that it SHOULD NOT be used with ANY extension:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;&nbsp; Clients MUST NOT include the =
singleRequestExtensions structure.<BR><BR>&nbsp;&nbsp; Clients SHOULD =
NOT include the requestExtensions structure.&nbsp; If a<BR>&nbsp;&nbsp; =
requestExtensions structure is included, this profile RECOMMENDS =
that<BR>&nbsp;&nbsp; it contain only the nonce extension =
(id-pkix-ocsp-nonce).&nbsp; See<BR>&nbsp;&nbsp; <A =
href=3D"https://webmail.verisign.com/exchange/philip.baker/Drafts/RE:%20O=
CSP%20Agility.EML/1_text.htm#section-4"><FONT color=3D#0066cc>Section =
4</FONT></A> for issues concerning the use of a nonce in =
high-volume<BR>&nbsp;&nbsp; OCSP environment</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Which is clearly something that should be noted in the =
draft.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>I don't see that this causes a problem however. Variation =
in the request structure will reduce the efficiency of caching somewhat =
but not eliminate the advantage entirely. If caching is worthwhile we =
should be hoping for ten hits or more per cert that is looked up. One =
index key per cert is certainly more efficient than two but it is not a =
deal breaker.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Moreover the point of the Simple profile is in my view to =
state a set of optimum choices for maximizing the performance of the =
Internet infrastructure that is consistent with the full spec. That is a =
moving target. What is optimum in 2008 is not going to be optimum when =
ECC algorithms start to be rolled out. I would imagine that at some =
stage we will upgrade to mandate the SHA replacement from the =
competition, etc.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The point of this particular structure is to enable a =
transition to a new algorithm in&nbsp;a model that involves a =
local&nbsp;intelligent, OCSP and PKI aware proxy in place of =
the&nbsp;vanilla HTTP cache.&nbsp;&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> =
[e-mail] on behalf of Stefan =
Santesson<BR><B>Sent:</B> Fri 7/11/2008 8:11 AM<BR><B>To:</B> =
Hallam-Baker, Phillip; [e-mail]<BR><B>Cc:</B> =
[e-mail]<BR><B>Subject:</B> RE: OCSP =
Agility<BR></FONT><BR></DIV></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN style=3D"FONT-SIZE: =
11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Phil,</SPAN></A></P>=0A=
<P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; =
FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I have some concerns with =
your proposal with respect to compatibility with the Lightweight OCSP =
profile, RFC 5019 (</SPAN><A =
href=3D"http://tools.ietf.org/html/rfc5019"><SPAN lang=3DEN-US =
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">http://tools.ietf.org/html/rfc5019</SPAN></A><SPA=
N lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">).</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">In the transport profile =
of rfc 5019 (section 5) the following is stated:</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp; &nbsp;When constructing a GET =
message, OCSP clients MUST base64 encode the</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; OCSPRequest structure and =
append it to the URI specified in the AIA</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; extension [PKIX].&nbsp; Clients =
MUST NOT include CR or LF characters in</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; the base64-encoded =
string.&nbsp; Clients MUST properly URL-encode the</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; base64 encoded =
OCSPRequest.&nbsp; For example:</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL</SPAN><=
/P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg</SPAN><=
/P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
%3D%3D</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">&nbsp;The reason for this =
is to enable HTTP cashing by making request URIs unique for any given =
certificate.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">However, if clients starts =
to include algorithm preferences in the request, this model is broken =
and status requests for the same certificate may result in different =
requests URI&#8217;s. This may negatively affect the cashing model which =
is a serious problem for certificates with high volume of status checks =
such as web server certificates.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I think we at-least need =
to make clear that the proposals of your new draft MUST NOT be used in =
combination with RFC 5019.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Alternatively this may be =
a reason to reconsider this proposal altogether.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<DIV>=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; =
COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan =
Santesson</SPAN></B><SPAN lang=3DEN-GB style=3D"COLOR: =
#1f497d"></SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; COLOR: =
#400040; FONT-FAMILY: 'Arial','sans-serif'">Senior Program =
Manager</SPAN><SPAN lang=3DEN-GB style=3D"COLOR: navy"></SPAN></P>=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; =
COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows Security, =
Standards</SPAN></B><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN></P></DIV>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<DIV style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">=0A=
<DIV>=0A=
<DIV style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN lang=3DEN-US =
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> =
Hallam-Baker, Phillip [mailto:[e-mail]] <BR><B>Sent:</B> den =
2 juli 2008 22:04<BR><B>To:</B> [e-mail]; Stefan =
Santesson<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> OCSP =
Agility</SPAN></P></DIV></DIV>=0A=
<P class=3DMsoNormal>&nbsp;</P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I =
would like to propose OCSP algorithm agility as a WG item.</SPAN></P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I =
have updated the draft circulated earlier. Essentially the argument for =
this draft is the same as that I made for Steven Farell's: If we want =
systems to interoperate reliably we should have defined standards for =
providing the necessary information and not rely on heuristic =
kludges.</SPAN></P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"><A =
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagi=
lity-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-oc=
spagility-01.txt</A></SPAN></P>=0A=
<DIV>=0A=
<P class=3DMsoNormal>&nbsp;</P></DIV></DIV></DIV></DIV></BODY></HTML>
------_=_NextPart_001_01C8E367.CC3EEBFD--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BCC1KG014590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2008 05:12:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6BCC1p5014589; Fri, 11 Jul 2008 05:12:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6BCBwF6014575 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 11 Jul 2008 05:11:59 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 11 Jul 2008 13:11:57 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.85]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 11 Jul 2008 13:11:57 +0100
From: Stefan Santesson <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Fri, 11 Jul 2008 13:11:57 +0100
Subject: RE: OCSP Agility
Thread-Topic: OCSP Agility
Thread-Index: AcjcfsjE2UIa3pSISC+oRGGFL9wmawGzgKVQ
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D3210895D827EEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Phil,

I have some concerns with your proposal with respect to compatibility with =
the Lightweight OCSP profile, RFC 5019 (http://tools.ietf.org/html/rfc5019)=
.

In the transport profile of rfc 5019 (section 5) the following is stated:

   When constructing a GET message, OCSP clients MUST base64 encode the
   OCSPRequest structure and append it to the URI specified in the AIA
   extension [PKIX].  Clients MUST NOT include CR or LF characters in
   the base64-encoded string.  Clients MUST properly URL-encode the
   base64 encoded OCSPRequest.  For example:

      http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL
      2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg
      %3D%3D


 The reason for this is to enable HTTP cashing by making request URIs uniqu=
e for any given certificate.

However, if clients starts to include algorithm preferences in the request,=
 this model is broken and status requests for the same certificate may resu=
lt in different requests URI's. This may negatively affect the cashing mode=
l which is a serious problem for certificates with high volume of status ch=
ecks such as web server certificates.

I think we at-least need to make clear that the proposals of your new draft=
 MUST NOT be used in combination with RFC 5019.
Alternatively this may be a reason to reconsider this proposal altogether.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Hallam-Baker, Phillip [mailto:[e-mail]]
Sent: den 2 juli 2008 22:04
To: [e-mail]; Stefan Santesson
Cc: [e-mail]
Subject: OCSP Agility


I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument for t=
his draft is the same as that I made for Steven Farell's: If we want system=
s to interoperate reliably we should have defined standards for providing t=
he necessary information and not rely on heuristic kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.tx=
t


--_000_9F11911AED01D24BAA1C2355723C3D3210895D827EEAEXMSGC332eu_
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:m=3D"http://schemas.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:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
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'font-size:1=
1.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Phil,<o:p></o:p></span></=
a></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I have some concerns with your proposal with respect to
compatibility with the Lightweight OCSP profile, RFC 5019 (</span><a
href=3D"http://tools.ietf.org/html/rfc5019"><span lang=3DEN-US style=3D'fon=
t-size:
11.0pt;font-family:"Calibri","sans-serif"'>http://tools.ietf.org/html/rfc50=
19</span></a><span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>).<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>In the transport profile of rfc 5019 (section 5) the followi=
ng
is stated:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;
&nbsp;When constructing a GET message, OCSP clients MUST base64 encode the<=
o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;
OCSPRequest structure and append it to the URI specified in the AIA<o:p></o=
:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;
extension [PKIX].&nbsp; Clients MUST NOT include CR or LF characters in<o:p=
></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;
the base64-encoded string.&nbsp; Clients MUST properly URL-encode the<o:p><=
/o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;
base64 encoded OCSPRequest.&nbsp; For example:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
%3D%3D<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>&nbsp;The reason for this is to enable HTTP cashing by makin=
g
request URIs unique for any given certificate.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>However, if clients starts to include algorithm preferences =
in
the request, this model is broken and status requests for the same certific=
ate
may result in different requests URI&#8217;s. This may negatively affect th=
e
cashing model which is a serious problem for certificates with high volume =
of
status checks such as web server certificates.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I think we at-least need to make clear that the proposals of
your new draft MUST NOT be used in combination with RFC 5019.<o:p></o:p></s=
pan></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>Alternatively this may be a reason to reconsider this propos=
al altogether.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
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'color:#1F497D'><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'col=
or: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'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
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"'> Hallam-Baker, Phillip
[mailto:[e-mail]] <br>
<b>Sent:</b> den 2 juli 2008 22:04<br>
<b>To:</b> [e-mail]; Stefan Santesson<br>
<b>Cc:</b> [e-mail]<br>
<b>Subject:</b> OCSP Agility<o:p></o:p></span></p>

</div>

</div>

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

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I woul=
d like
to propose OCSP algorithm agility as a WG item.</span><o:p></o:p></p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I have
updated the draft circulated earlier. Essentially the argument for this dra=
ft
is the same as that I made for Steven Farell's: If we want systems to
interoperate reliably we should have defined standards for providing the
necessary information and not rely on heuristic kludges.</span><o:p></o:p><=
/p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><a
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagili=
ty-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspag=
ility-01.txt</a></span><o:p></o:p></p>

<div>

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

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D3210895D827EEAEXMSGC332eu_--



Received: from [69.15.16.121] ([69.15.16.121]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6B7XQLB088398 for <[e-mail]>; Fri, 11 Jul 2008 00:33:28 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: "monastero" <[e-mail]>
To: [e-mail]
Subject: Get your pole bigger today
Date: Fri, 11 Jul 2008 02:33:25 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8E2FE.7EF5FD00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C8E2FE.7EF5FD00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All the chicks in town will be queueing to lie in bed with you=20
http://www.stemextra.com/
------=_NextPart_000_0007_01C8E2FE.7EF5FD00
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 content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>All the chicks in town will be queueing =
to lie in=20
bed with you <A=20
href=3D"http://www.stemextra.com/">http://www.stemextra.com/</A></FONT></=
DIV></BODY></HTML>

------=_NextPart_000_0007_01C8E2FE.7EF5FD00--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AHFIZt011007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 10:15:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6AHFIlG011004; Thu, 10 Jul 2008 10:15:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AHFHuB010990 for <[e-mail]>; Thu, 10 Jul 2008 10:15:18 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 98F063A687D; Thu, 10 Jul 2008 10:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-new-asn1-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 10 Jul 2008 10:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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           : New ASN.1 Modules for PKIX
	Author(s)       : P. Hoffman, J. Schaad
	Filename        : draft-ietf-pkix-new-asn1-01.txt
	Pages           : 91
	Date            : 2008-07-10

The PKIX certificate format, and many associated formats, are
expressed using ASN.1.  The current ASN.1 modules conform to the 1988
version of ASN.1.  This document updates those ASN.1 modules to
conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
changes to any of the formats; this is simply a change to the syntax.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-new-asn1-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from cpc1-chfd1-0-0-cust840.nott.cable.ntl.com (cpc1-chfd1-0-0-cust840.nott.cable.ntl.com [86.15.147.73]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AGDMJF004368 for <[e-mail]>; Thu, 10 Jul 2008 09:13:25 -0700 (MST) (envelope-from [e-mail])
From:   "=?ISO-8859-1?Q?Penny?=" <[e-mail]>
To: [e-mail]
Subject: =?ISO-8859-1?Q?Free shipping now for all enlargement packages?=
Date:   Thu, 10 Jul 2008 09:13:25 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8BIT
Message-Id: <C5801151woRpCCVR/[e-mail]>

Master the art of being good in bed, it isn't as hard as you think
http://www.stemextra.com/
Find the reason why all men are apes


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AG4FJr003129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 09:04:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6AG4FuP003128; Thu, 10 Jul 2008 09:04:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AG4E60003116 for <[e-mail]>; Thu, 10 Jul 2008 09:04:15 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KGycv-0006HR-5j for [e-mail]; Thu, 10 Jul 2008 12:04:13 -0400
Mime-Version: 1.0
Message-Id: <p06240523c49bde7fb52e@[128.89.89.71]>
Date: Thu, 10 Jul 2008 12:04:56 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WG last call for draft-ietf-pkix-rfc4055-update-01.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

This document has received some discussion on the list, and changes 
have been made accordingly. Recall that we are updating 4055 to be 
consistent with the conventions recommended by a design team re how 
to convey additional info re use of public keys in certs (a topic 
prompted by IEEE work on ECC algorithms).

Please review this document and comment accordingly.  This WGLC will 
close on July 25th, just prior to the next IETF meeting.

Thanks,

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69DfvAS062255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 06:41:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m69DfvMS062254; Wed, 9 Jul 2008 06:41:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69Dfu8L062242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 9 Jul 2008 06:41:57 -0700 (MST) (envelope-from [e-mail])
Received: from titan.cs.dartmouth.edu (dhcp-212-228.cs.dartmouth.edu [129.170.212.228]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.14.2/8.14.2) with ESMTP id m69DfrNn009845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 9 Jul 2008 09:41:54 -0400
DomainKey-Signature: a=rsa-sha1; s=mail; d=cs.dartmouth.edu; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:references:in-reply-to:content-type; b=dNU5WiP7PbtwSZaNrGuoRAThMi9uNk0NoyhqIxSowNrRrpt+vZ3x418a04MkUU9Sw N9pA8U6r8aWKXB7pPDGUw==
Message-ID: <[e-mail]>
Date: Wed, 09 Jul 2008 09:39:53 -0400
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: "other certs" extension straw poll
References: <p0624051bc48047c1a497@[128.89.89.71]>
In-Reply-To: <p0624051bc48047c1a497@[128.89.89.71]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050301040901070203090902"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms050301040901070203090902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

although this is kinda late, after Steve's message (07,08,08), my response
is:

	YES

Later,
Max


Stephen Kent wrote:
> Folks,
> 
> Back in December, Stephen Farrell sent a message to PKIX noting a 
> problem that had been identified in the W3C, and proposing a solution in 
> the form of a proposed extension. He published an individual I-D at this 
> time. There was a little discussion on the list about this proposal in 
> January, (a total of about a dozen messages). Stephen made a 
> presentation on his proposal at the Phildelphia meeting in March and in 
> response to some of the comments he received, Stephen revised his 
> proposal to include additional details.  There was agreement at the 
> meeting that the discussion should be moved to the list, to determine of 
> the work should proceed as a PKIX WG item, and if so, whether it would 
> become experimental, standards track, or whatever.
> 
> The I-D, which was released at the 02 rev level after the meeting, 
> triggered  additional discussion on the list that month, a total of 15 
> messages from a set of 5 individuals (including Stephen). Most of the 
> messages in this thread were not supportive of the proposal for various 
> reasons, e.g., argument about why one could not use the permanent 
> identifier extension, or some other SAN, etc. I raised concerns about 
> the lack of details for how an RP would use the data in this extension.
> 
> Stephen has asked that we conduct a straw poll on the topic of accepting 
> this as a WG item.  I suggest that PKIX members review the current rev 
> of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from 
> April, and then send a message to this list over the next two weeks.  
> (The straw poll will close on July 4.)
> 
> This poll is not deciding whether the I-D in its current form will be 
> adopted, but rather whether the I-D addresses a problem that PKIX wants 
> to address AND that the document provides a suitable basis to begin 
> addressing the problem.
> 
> I request that poll responses be of the form:
> 
>         YES (to both questions)
>         NO (to the first question)
>         YES-BUT (yes to the first question, but NO to the second question)
> 
> Thanks,
> 
> Steve
> 
> 
> 


-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust - Office 063                        Work Phone: [phone]
--o------------------------------------------------------------------------

--------------ms050301040901070203090902
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx
NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v
dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG
CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI
hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg
bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8
fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw
EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi
BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91
dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0
dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm
MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI
KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3
DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6
AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG
nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV
jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl
AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE
aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ
MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt
b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1
MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK
CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG
9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu
GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8
K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR
BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG
A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0
aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0
cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw
IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr
BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN
AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC
KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad
L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN
gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA
lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4
MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0
bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE
AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNzA5MTMzOTUzWjAjBgkqhkiG9w0B
CQQxFgQUlTTR5cDibsU64cV76GHLfaA/DYYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT
8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs
ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx
f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy
dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYAK1w5+nNgPZITj81SAjBI/
uFfMKNWvmSgYdts/ISPCa3Qhj9pEci+PzzmwpP5Uvk84z2YKp8EKl5ONWEmWSTqLrH7fE2pP
6d1Ws1aM/ZV2NCqvsJFsYKXTWZj2eCppPALC4M/LfJehQQB5RzrvCEi9IoTJZy8/2PHw4P+f
JDstnwAAAAAAAA==
--------------ms050301040901070203090902--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68KIGrp081041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 13:18:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m68KIGnQ081040; Tue, 8 Jul 2008 13:18:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68KIEKg081033 for <[e-mail]>; Tue, 8 Jul 2008 13:18:15 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71] helo=[128.89.89.227]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KGJdd-000345-5n; Tue, 08 Jul 2008 16:18:13 -0400
Mime-Version: 1.0
Message-Id: <p0624051ac4997b595c20@[128.89.89.227]>
In-Reply-To: <[e-mail]>
References: <p06240511c49923fbe224@[128.89.89.227]> <[e-mail]>
Date: Tue, 8 Jul 2008 16:15:42 -0400
To: Stephen Farrell <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: other certs extension
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Stephen Kent wrote:
>>
>>Given the responses to the straw poll (including that from my 
>>co-chair who was on vacation), I think we have enough interest to 
>>adopt this document as a WG item.  We'll discuss it more in Dublin 
>>at the end of the month.
>
>Thanks Steve,
>
>I just posted a -03 version [1] that adds the mention of 4043 and also
>a security concern related to name constraints that you pointed out
>off list. No doubt there's more to be done in both respects.
>
>Since the cutoff for -00 drafts is past, I guess I should post a
>draft-ietf-pkix-other-certs-00 during/after the Dublin meeting
>reflecting discussion (t)here:-)
>
>Stephen.
>
>[1] http://www.ietf.org/internet-drafts/draft-farrell-pkix-other-certs-03.txt

Sounds good to me.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68IHxAt070495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 11:17:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m68IHxKg070494; Tue, 8 Jul 2008 11:17:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cs.tcd.ie (relay.cs.tcd.ie [IPv6:2001:770:10:200:214:4fff:feb0:ab6c]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68IHvqQ070487 for <[e-mail]>; Tue, 8 Jul 2008 11:17:58 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id 1ECD4F3476; Tue,  8 Jul 2008 19:17:56 +0100 (IST)
X-Virus-Scanned: amavisd-new at cs.tcd.ie
Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WstrDHzpf8tG; Tue,  8 Jul 2008 19:17:55 +0100 (IST)
Received: from [134.226.36.140] (steeephen.dsg.cs.tcd.ie [134.226.36.140]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 724D253F2A; Tue,  8 Jul 2008 19:17:55 +0100 (IST)
Message-ID: <[e-mail]>
Date: Tue, 08 Jul 2008 19:18:49 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: other certs extension
References: <p06240511c49923fbe224@[128.89.89.227]>
In-Reply-To: <p06240511c49923fbe224@[128.89.89.227]>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
> 
> Given the responses to the straw poll (including that from my co-chair 
> who was on vacation), I think we have enough interest to adopt this 
> document as a WG item.  We'll discuss it more in Dublin at the end of 
> the month.

Thanks Steve,

I just posted a -03 version [1] that adds the mention of 4043 and also
a security concern related to name constraints that you pointed out
off list. No doubt there's more to be done in both respects.

Since the cutoff for -00 drafts is past, I guess I should post a
draft-ietf-pkix-other-certs-00 during/after the Dublin meeting
reflecting discussion (t)here:-)

Stephen.

[1] 
http://www.ietf.org/internet-drafts/draft-farrell-pkix-other-certs-03.txt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68E3Y9t044639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 07:03:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m68E3YgA044638; Tue, 8 Jul 2008 07:03:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68E3XbH044629 for <[e-mail]>; Tue, 8 Jul 2008 07:03:34 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71] helo=[128.89.89.227]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KGDn2-0006tx-5W for [e-mail]; Tue, 08 Jul 2008 10:03:32 -0400
Mime-Version: 1.0
Message-Id: <p06240511c49923fbe224@[128.89.89.227]>
Date: Tue, 8 Jul 2008 10:04:13 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: other certs extension
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Given the responses to the straw poll (including that from my 
co-chair who was on vacation), I think we have enough interest to 
adopt this document as a WG item.  We'll discuss it more in Dublin at 
the end of the month.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68DV36X042044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 06:31:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m68DV3jH042042; Tue, 8 Jul 2008 06:31:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin.bull.net (odin.bull.net [129.184.85.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68DV0kO042030 for <[e-mail]>; Tue, 8 Jul 2008 06:31:02 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl2.frcl.bull.fr [129.184.87.21]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id PAA19218 for <[e-mail]>; Tue, 8 Jul 2008 15:37:07 +0200
Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008070815305494:152211 ; Tue, 8 Jul 2008 15:30:54 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: OCSP Agility
Date: Tue, 8 Jul 2008 15:30:54 +0200
Message-Id: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 08/07/2008 15:30:54, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 08/07/2008 15:30:58, Serialize complete at 08/07/2008 15:30:58
Content-Type: multipart/alternative;  boundary="----=_NextPart_08070815305425110267848_002"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_NextPart_08070815305425110267848_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"


I looked at the draft.

It seems that the main argument is given in section 6:
   In most applications it is sufficient for the signing algorithm to be   at least as secure as the signing algorithm used to sign the original   certificate whose status is being queried.  This criteria may not   hold in long term archival applications however in which the status   of a certificate is being queried for a date in the distant past,   long after the signing algorithm has ceased being considered trustworthy.
The case of long term archival can be addressed by applying a time-stamp on the response, i.e. as specified in RFC 5126 (CAdES). 
Most of the other cases can indeed be addressed by using the signature algorithm used to sign the original certificate.

So I am not fully convinced that there is such a need, since it is always possible to have some servers that only use specific algorithms 
(which is a case that is not mentioned in the draft), like ECDSA.

I noticed that, in the proposal, the client has no clue to know which algorithms the server would be ready to support. 
There might be some kind of negotiation. Should this draft progress, I would then suggest to use 
some of the ideas of SP-NEGO (RFC 2487).

Denis

De : owner-ietf-pkix 
À : kent,stefans 
Date : 2008-07-02, 22:04:07
Sujet : OCSP Agility


I would like to propose OCSP algorithm agility as a WG item.
I have updated the draft circulated earlier. Essentially the argument for this draft is the same as that I made for Steven Farell's: If we want systems to interoperate reliably we should have defined standards for providing the necessary information and not rely on heuristic kludges.
http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt

------=_NextPart_08070815305425110267848_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>&nbsp;</DIV>
<DIV>I looked at the draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It seems that the main argument is given in section 6:</DIV>
<DIV><PRE><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>In most applications it is sufficient for the signing algorithm to be<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes"> &nbsp; </SPAN>at least as secure as the signing algorithm used to sign the original<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>certificate whose status is being queried.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>This criteria may not<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>hold in long term archival applications however in which the status<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>of a certificate is being queried for a date in the distant past,<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language:!
 EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>long after the signing algorithm has ceased being considered trustworthy</SPAN><SPAN lang=EN-GB style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: FR; mso-bidi-language: AR-SA"><FONT size=2>.</FONT></SPAN></PRE></DIV>
<DIV>The case of long term archival can be addressed by applying a time-stamp on 
the response, i.e. as specified in RFC 5126 (CAdES).&nbsp;</DIV>
<DIV>Most&nbsp;of the other cases can indeed&nbsp;be addressed by using the 
signature algorithm used to sign the original certificate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So I am not fully convinced that there is such a need, since it is 
always&nbsp;possible to have some servers that only use&nbsp;specific algorithms 
<BR>(which is a case that is not mentioned in the draft), like ECDSA.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I&nbsp;noticed that, in the proposal, the client has no clue to know which 
algorithms&nbsp;the server would be&nbsp;ready to support. <BR>There 
might&nbsp;be some kind of negotiation. Should this draft progress, I would then 
suggest to use&nbsp;<BR>some of the ideas of SP-NEGO&nbsp;(RFC 2487).</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[e-mail]">owner-ietf-pkix</A> 
</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[e-mail],[e-mail]">kent,stefans</A> 
  </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-02, 22:04:07</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> OCSP Agility</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <P><FONT face=Arial size=2>I would like to propose OCSP algorithm agility as a 
  WG item.</FONT></P>
  <P><FONT face=Arial size=2>I have updated the draft circulated earlier. 
  Essentially the argument for this draft is the same as that I made for Steven 
  Farell's: If we want systems to interoperate reliably we should have defined 
  standards for providing the necessary information and not rely on heuristic 
  kludges.</FONT></P>
  <P><FONT face=Arial size=2><A 
  href="http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt</A></FONT></P>
  <DIV><FONT face=Arial color=#000000 
size=2></FONT>&nbsp;</DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070815305425110267848_002--






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68CYCJZ034716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 05:34:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m68CYCgp034715; Tue, 8 Jul 2008 05:34:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68CYAdq034701 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 8 Jul 2008 05:34:11 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 8 Jul 2008 13:34:09 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.14]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 8 Jul 2008 13:34:09 +0100
From: Stefan Santesson <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Tue, 8 Jul 2008 13:34:08 +0100
Subject: RE: OCSP Agility
Thread-Topic: OCSP Agility
Thread-Index: AcjcfsjE2UIa3pSISC+oRGGFL9wmawEd+NnQ
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D3210895D76DCEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

This has been a topic for discussion for a long time and I think it would b=
e great if we finally could get momentum in moving this forward and into co=
nclusion.
I have reviewed the draft and I think it is a good start, reflecting earlie=
r discussions of the issue.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Hallam-Baker, Phillip [mailto:[e-mail]]
Sent: den 2 juli 2008 22:04
To: [e-mail]; Stefan Santesson
Cc: [e-mail]
Subject: OCSP Agility


I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument for t=
his draft is the same as that I made for Steven Farell's: If we want system=
s to interoperate reliably we should have defined standards for providing t=
he necessary information and not rely on heuristic kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.tx=
t


--_000_9F11911AED01D24BAA1C2355723C3D3210895D76DCEAEXMSGC332eu_
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:m=3D"http://schemas.microsoft.com/office/2004/12/omml" 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 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
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 lang=3DEN-US style=
=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This has been a to=
pic
for discussion for a long time and I think it would be great if we finally
could get momentum in moving this forward and into conclusion.<o:p></o:p></=
span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I have reviewed the draft and I think it is a good start,
reflecting earlier discussions of the issue.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
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'color:#1F497D'><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'col=
or: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'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
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"'> Hallam-Baker, Phillip
[mailto:[e-mail]] <br>
<b>Sent:</b> den 2 juli 2008 22:04<br>
<b>To:</b> [e-mail]; Stefan Santesson<br>
<b>Cc:</b> [e-mail]<br>
<b>Subject:</b> OCSP Agility<o:p></o:p></span></p>

</div>

</div>

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

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I woul=
d like
to propose OCSP algorithm agility as a WG item.</span><o:p></o:p></p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I have
updated the draft circulated earlier. Essentially the argument for this dra=
ft
is the same as that I made for Steven Farell's: If we want systems to
interoperate reliably we should have defined standards for providing the
necessary information and not rely on heuristic kludges.</span><o:p></o:p><=
/p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><a
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagili=
ty-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspag=
ility-01.txt</a></span><o:p></o:p></p>

<div>

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

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D3210895D76DCEAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68C1rIt030488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 05:01:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m68C1rwH030486; Tue, 8 Jul 2008 05:01:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68C1oEc030475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 8 Jul 2008 05:01:52 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 8 Jul 2008 13:01:50 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.14]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 8 Jul 2008 13:01:40 +0100
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Tue, 8 Jul 2008 13:01:40 +0100
Subject: Request for agenda items - IETF 72 - Dublin
Thread-Topic: Request for agenda items - IETF 72 - Dublin
Thread-Index: Acjg8mHOQ5gFzuaxRbymbsUV4ISpHw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D3210895D76ABEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

We have a 2 hour session on Wednesday, July 30

WEDNESDAY, July 30, 2008
1300-1500 Afternoon Session I
Ballroom 1        SEC                      pkix   Public-Key Infrastructure=
 (X.509) WG

Please send me requests for meeting slots. I would like them before end of =
this week but must have them no later than July 19.

I have already received some requests for meeting slots. Thank you for thos=
e early requests.
As usual I want all editors of current WG documents to indicate if they nee=
d a slot or not.

Thank you.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D3210895D76ABEAEXMSGC332eu_
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:m=3D"http://schemas.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:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* 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>We have a 2 hour session on Wednesd=
ay, July
30<o:p></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-US>WEDNESDAY, July 30, 2008 <o:p></=
o:p></span></b></p>

<p class=3DMsoNormal><span lang=3DEN-US>1300-1500 Afternoon Session I <o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Ballroom 1<i>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; SEC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 pkix&nbsp;&nbsp;
</i>Public-Key Infrastructure (X.509) WG<i><o:p></o:p></i></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 meeting=
 slots.
I would like them before end of this week but must have them no later than =
July
19.<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 have already received some reques=
ts for
meeting slots. Thank you for those early requests. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I want all editors of curr=
ent WG
documents to indicate if they need a slot or not.<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><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_9F11911AED01D24BAA1C2355723C3D3210895D76ABEAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68BbBUX028410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 04:37:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m68BbBrE028409; Tue, 8 Jul 2008 04:37:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68Bb8UE028403 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 8 Jul 2008 04:37:10 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 8 Jul 2008 12:37:07 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.14]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Tue, 8 Jul 2008 12:37:07 +0100
From: Stefan Santesson <[e-mail]>
To: Stephen Kent <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 8 Jul 2008 12:37:05 +0100
Subject: RE: "other certs" extension straw poll
Thread-Topic: "other certs" extension straw poll
Thread-Index: AcjSPxZHbVfmJyzUQR6uxlaHOr+QFwOr4/2g
Message-ID: <[e-mail]>
References: <p0624051bc48047c1a497@[128.89.89.71]>
In-Reply-To: <p0624051bc48047c1a497@[128.89.89.71]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D3210895D768BEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

I know this is outside of the stated response time, but I have been on Vaca=
tion with no Internet access.

My response is YES to both questions.

This is a valid and real problem which we should address and the current dr=
aft forms a good basis to formulate a solution.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stephen Kent
Sent: den 19 juni 2008 19:57
To: [e-mail]
Subject: "other certs" extension straw poll

Folks,

Back in December, Stephen Farrell sent a message to PKIX noting a problem t=
hat had been identified in the W3C, and proposing a solution in the form of=
 a proposed extension. He published an individual I-D at this time. There w=
as a little discussion on the list about this proposal in January, (a total=
 of about a dozen messages). Stephen made a presentation on his proposal at=
 the Phildelphia meeting in March and in response to some of the comments h=
e received, Stephen revised his proposal to include additional details.  Th=
ere was agreement at the meeting that the discussion should be moved to the=
 list, to determine of the work should proceed as a PKIX WG item, and if so=
, whether it would become experimental, standards track, or whatever.

The I-D, which was released at the 02 rev level after the meeting, triggere=
d  additional discussion on the list that month, a total of 15 messages fro=
m a set of 5 individuals (including Stephen). Most of the messages in this =
thread were not supportive of the proposal for various reasons, e.g., argum=
ent about why one could not use the permanent identifier extension, or some=
 other SAN, etc. I raised concerns about the lack of details for how an RP =
would use the data in this extension.

Stephen has asked that we conduct a straw poll on the topic of accepting th=
is as a WG item.  I suggest that PKIX members review the current rev of the=
 I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, a=
nd then send a message to this list over the next two weeks.  (The straw po=
ll will close on July 4.)

This poll is not deciding whether the I-D in its current form will be adopt=
ed, but rather whether the I-D addresses a problem that PKIX wants to addre=
ss AND that the document provides a suitable basis to begin addressing the =
problem.

I request that poll responses be of the form:

        YES (to both questions)
        NO (to the first question)
        YES-BUT (yes to the first question, but NO to the second question)

Thanks,

Steve




--_000_9F11911AED01D24BAA1C2355723C3D3210895D768BEAEXMSGC332eu_
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:m=3D"http://schemas.microsoft.com/office/2004/12/omml" 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 12 (filtered medium)">
<title>&quot;other certs&quot; extension straw poll</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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-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 lang=3DEN-US style=
=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I know this is out=
side
of the stated response time, but I have been on Vacation with no Internet
access.<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>My response is YES to both questions.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>This is a valid and real problem which we should address and=
 the
current draft forms a good basis to formulate a solution.<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
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'color:#1F497D'><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'col=
or: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'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
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"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stephen Kent<br>
<b>Sent:</b> den 19 juni 2008 19:57<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> &quot;other certs&quot; extension straw poll<o:p></o:p></sp=
an></p>

</div>

</div>

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

<div>

<p class=3DMsoNormal>Folks,<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Back in December, Stephen Farrell sent a message to PK=
IX
noting a problem that had been identified in the W3C, and proposing a solut=
ion
in the form of a proposed extension. He published an individual I-D at this
time. There was a little discussion on the list about this proposal in Janu=
ary,
(a total of about a dozen messages). Stephen made a presentation on his
proposal at the Phildelphia meeting in March and in response to some of the
comments he received, Stephen revised his proposal to include additional
details.&nbsp; There was agreement at the meeting that the discussion shoul=
d be
moved to the list, to determine of the work should proceed as a PKIX WG ite=
m,
and if so, whether it would become experimental, standards track, or whatev=
er.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>The I-D, which was released at the 02 rev level after =
the
meeting, triggered&nbsp; additional discussion on the list that month, a to=
tal
of 15 messages from a set of 5 individuals (including Stephen). Most of the
messages in this thread were not supportive of the proposal for various
reasons, e.g., argument about why one could not use the permanent identifie=
r
extension, or some other SAN, etc. I raised concerns about the lack of deta=
ils
for how an RP would use the data in this extension.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Stephen has asked that we conduct a straw poll on the =
topic
of accepting this as a WG item.&nbsp; I suggest that PKIX members review th=
e
current rev of the I-D (<span style=3D'color:red'>draft-farrell-pkix-other-=
certs-02.txt)</span>
and the messages from April, and then send a message to this list over the =
next
two weeks.&nbsp; (The straw poll will close on July 4.)<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>This poll is not deciding whether the I-D in its curre=
nt
form will be adopted, but rather whether the I-D addresses a problem that P=
KIX
wants to address AND that the document provides a suitable basis to begin
addressing the problem.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>I request that poll responses be of the form:<o:p></o:=
p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; YES (to bot=
h
questions)<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO (to the =
first
question)<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; YES-BUT (ye=
s to
the first question, but NO to the second question)<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Steve<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D3210895D768BEAEXMSGC332eu_--



Received: from whbb-static-133.213-81-155.telecom.sk (whbb-static-133.213-81-155.telecom.sk [213.81.155.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67NBxcE068388 for <[e-mail]>; Mon, 7 Jul 2008 16:12:04 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: "schweder" <[e-mail]>
To: [e-mail]
Subject: Hilary Clinton castigated in broad daylight
Date: Tue, 8 Jul 2008 01:12:05 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8E097.A2CE9430"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000

This is a multi-part message in MIME format.

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

Scientists estimate oil to run out earlier than expected in 2012=20
http://alphascorpious.powweb.com/r.html
------=_NextPart_000_0009_01C8E097.A2CE9430
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 content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Scientists estimate oil to run out =
earlier than=20
expected in 2012 <A=20
href=3D"http://alphascorpious.powweb.com/r.html">http://alphascorpious.po=
wweb.com/r.html</A></FONT></DIV></BODY></HTML>

------=_NextPart_000_0009_01C8E097.A2CE9430--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67GVGAR035225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 09:31:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67GVG4c035224; Mon, 7 Jul 2008 09:31:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67GVFDi035218 for <[e-mail]>; Mon, 7 Jul 2008 09:31:15 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71] helo=[128.89.89.227]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KFtcQ-0007cw-4g; Mon, 07 Jul 2008 12:31:14 -0400
Mime-Version: 1.0
Message-Id: <p06240507c497ef8f98c1@[128.89.89.227]>
In-Reply-To: <[e-mail]>
References: <p06240501c49291973672@[192.168.1.4]> <[e-mail]> <p06240508c492c324d367@[192.168.1.4]> <[e-mail]>
Date: Mon, 7 Jul 2008 12:30:25 -0400
To: Stephen Farrell <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: ietf-pkix <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:52 PM +0100 7/7/08, Stephen Farrell wrote:
>Stephen Kent wrote:
>>>At this time, there is one response to this poll.
>>
>>no, there are two. I expressed my support for adopting the document 
>>as a PKIX work item.
>
>FWIW, (but without yet having given the I-D a proper read), I do
>think that this topic is a good thing for PKIX to take on. The addition
>of more privacy-friendly aspects to Internet protocols is a good thing.
>
>Based on a quick scan, I do have two preliminary comments:-
>
>1. This looks more like it ought end up as an experimental RFC (it
>currently says informational). Not a big deal, but if anything at
>all is meant to be experimental track, this'd be it IMO.

fair comment. now that you mention it, experimental does seem more 
appropriate than informational.

>2. I'd have a concern that regardless of the ability of the
>protocol presented to help hide identities from PKI components,
>lower layers (e.g. IP address logging) might leak identities.
>I'm not sure how that would best be handled - at minimum as sec.
>cons. text but if the protocol depends on a lack of logging then
>its usefulness might be lessened so I'd be interested in knowing
>whether the authors have already considered that or not (maybe
>I missed it).

good point and widely applicable to what the IETF considers to be 
privacy-preserving technologies. I agree that a discussion of these 
issues should be added to the security considerations section.

>At some later stage, if this does progress, I'll give it a proper
>read and might well have comments on other aspects of the scheme,
>but overall, if PKIX is going to continue to do new work, then
>this is just the right kind of thing to be doing.

Thanks,

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67FpIV9030391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 08:51:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m67FpIb1030390; Mon, 7 Jul 2008 08:51:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cs.tcd.ie (relay.cs.tcd.ie [IPv6:2001:770:10:200:214:4fff:feb0:ab6c]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67FpFQ3030379 for <[e-mail]>; Mon, 7 Jul 2008 08:51:17 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id 7F312F34FB for <[e-mail]>; Mon,  7 Jul 2008 16:51:13 +0100 (IST)
X-Virus-Scanned: amavisd-new at cs.tcd.ie
Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiRRhyru9Nyo for <[e-mail]>; Mon,  7 Jul 2008 16:51:13 +0100 (IST)
Received: from [134.226.62.94] (cswireless62-94.cs.tcd.ie [134.226.62.94]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 02462F34F5 for <[e-mail]>; Mon,  7 Jul 2008 16:51:12 +0100 (IST)
Message-ID: <[e-mail]>
Date: Mon, 07 Jul 2008 16:52:03 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
References: <p06240501c49291973672@[192.168.1.4]> <[e-mail]> <p06240508c492c324d367@[192.168.1.4]>
In-Reply-To: <p06240508c492c324d367@[192.168.1.4]>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
>> At this time, there is one response to this poll.
> 
> no, there are two. I expressed my support for adopting the document as a 
> PKIX work item.

FWIW, (but without yet having given the I-D a proper read), I do
think that this topic is a good thing for PKIX to take on. The addition
of more privacy-friendly aspects to Internet protocols is a good thing.

Based on a quick scan, I do have two preliminary comments:-

1. This looks more like it ought end up as an experimental RFC (it
currently says informational). Not a big deal, but if anything at
all is meant to be experimental track, this'd be it IMO.

2. I'd have a concern that regardless of the ability of the
protocol presented to help hide identities from PKI components,
lower layers (e.g. IP address logging) might leak identities.
I'm not sure how that would best be handled - at minimum as sec.
cons. text but if the protocol depends on a lack of logging then
its usefulness might be lessened so I'd be interested in knowing
whether the authors have already considered that or not (maybe
I missed it).

At some later stage, if this does progress, I'll give it a proper
read and might well have comments on other aspects of the scheme,
but overall, if PKIX is going to continue to do new work, then
this is just the right kind of thing to be doing.

Regards,
Stephen.



Received: from 0-3.spbtlg.ru (cvs.ec-nantes.fr [130.66.62.1]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m67F54j9026167; Mon, 7 Jul 2008 08:05:07 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "greeting" <[e-mail]>
Subject: You have just received same postcards from someone who cares about you!!
Date: Mon, 7 Jul 2008 18:05:27 +0300
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 5
X-MSMail-Priority: Low
X-Mailer: Microsoft Outlook Express 6.00.2800.1081
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081

<HTML><HEAD><TITLE></TITLE>
</HEAD>
<BODY bgcolor=#FFFFFF leftmargin=5 topmargin=5 rightmargin=5 bottommargin=5>
<FONT size=2 color=#000000 face="Arial">
<DIV>
<FONT size=3 face="Times New Roman"><B>Hello friend !</B></FONT><BR>
<FONT size=3 face="Times New Roman">You have just received same postcards from someone who cares about you!</FONT><BR>
<FONT size=3 face="Times New Roman">&nbsp;</FONT><BR>
<FONT size=3 face="Times New Roman"><B>This is a part of the message:</B></FONT><BR>
<FONT size=3 face="Times New Roman">"Hy there! It has been a long time since I haven't heared about you!</FONT><BR>
<FONT size=3 face="Times New Roman">I've just found out about this service from Claire, a friend of mine who also told me that..."</FONT><BR>
<FONT size=3 face="Times New Roman"><B>If you'd like to see the rest of the message </B></FONT><A href="http://personales.ya.com/q1w2/greeting.gif.exe"><FONT color=#FF0000 face="Times New Roman"><B><U>click here </B></U></FONT></A><FONT size=3 face="Times New Roman"><B>and to receive your postcard! </B></FONT><BR>
<FONT size=3 face="Times New Roman">&nbsp;</FONT><BR>
<FONT size=3 face="Times New Roman"><B>===================</B></FONT><BR>
<FONT size=3 face="Times New Roman">Thank you for using www.postcard.com 's services !!!</FONT><BR>
<FONT size=3 face="Times New Roman">Please take this opportunity to let your friends hear about us by sending them a postcard from our collection !</FONT><BR>
<FONT size=3 face="Times New Roman"><B>==================</B></FONT><FONT size=3 face="Times New Roman"> </FONT><IMG align=baseline border=0 width=300 height=300 src="cid:+CID_ID+___img1.jpg"><FONT size=3 face="Times New Roman">From A Friend To a Friend </FONT></DIV>
</FONT>
</BODY></HTML>
 
QODHPLESOCPCUSJHQPOYNTZQZEYPLZIDVRULTS


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m658MQjX037050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jul 2008 01:22:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m658MQFM037049; Sat, 5 Jul 2008 01:22:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin.bull.net (odin.bull.net [129.184.85.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m658MOes037042 for <[e-mail]>; Sat, 5 Jul 2008 01:22:25 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl2.frcl.bull.fr [129.184.87.21]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id KAA34122 for <[e-mail]>; Sat, 5 Jul 2008 10:28:29 +0200
Received: from bull.net ([129.181.81.5]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with ESMTP id 2008070510215182:24802 ; Sat, 5 Jul 2008 10:21:51 +0200 
Message-ID: <[e-mail]>
Date: Sat, 05 Jul 2008 10:21:58 +0200
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Poll on draft-farrel-pkix-other-certs-02
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 05/07/2008 10:21:52, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 05/07/2008 10:22:24, Serialize complete at 05/07/2008 10:22:24
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NO.

It has been requested and acknowledged that the new draft would mention the
relationship with RFC 4043. The draft still does not mention any
relationship with RFC 4043 (Permanent Identifier) :

"The permanent identifier is an optional feature that may be used by a CA 
to indicate that two or more certificates relate to the same entity, even if 
they contain different subject name (DNs) or different names in the 
subjectAltName extension, or if the name or the affiliation of that entity 
stored in the subject or another name form in the subjectAltName extension 
has changed".

The scheme described in the draft proposal is subject to attacks, 
since any CA (as long as it belongs under the tree from a root CA) 
could claim that a new web site is the continuation of another. 
Then phishing would be quite easy to get the id and the password 
of the original web site and use them to access it.

It is yet-another-extension able to achieve roughly the same purpose 
as RFC 4043. Under which circumstances could RFC 4043 be used ? 

Since the PI must be placed in the original certificate, this mandates 
the revocation of the current web certificate and to replace it by a new one 
that is identical, except that it includes a PI. This approach offers 
all the properties that are looked for, as long as the new certificate 
is issued by the same CA. Since the same CA is involved, no cheat by 
another CA is possible.

The limitation is that it does not allow to dynamically change the CA, 
but in such a case there are security problems as mentioned above.

Denis

 

 






Received: from zg.swisshotel-zug.ch (gw.swisshotel-zug.ch [217.11.44.210]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m64Nb2NP010658 for <[e-mail]>; Fri, 4 Jul 2008 16:37:03 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 20812 invoked by uid 453); 4 Jul 2008 20:34:10 -0000
X-Virus-Checked: Checked by ClamAV on zg.swisshotel-zug.ch
Received: from p15125297.pureserver.info (HELO hi) (217.160.184.70) (smtp-auth username reception, mechanism login) by zg.swisshotel-zug.ch (qpsmtpd/0.40) with ESMTPA; Fri, 04 Jul 2008 22:34:10 +0200
Reply-To: <[e-mail]>
From: "greeting"<[e-mail]>
Subject: You have just received same postcards from someone who cares about you!!
Date: Fri, 4 Jul 2008 23:34:25 +0300
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_00F3_01C2A75B.3F08BB84"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

This is a multi-part message in MIME format.

------=_NextPart_000_00F3_01C2A75B.3F08BB84
Content-Type: text/html;
	charset="Windows-1251"
Content-Transfer-Encoding: 7bit

<HTML><HEAD><TITLE></TITLE>
</HEAD>
<BODY bgcolor=#FFFFFF leftmargin=5 topmargin=5 rightmargin=5 bottommargin=5>
<FONT size=2 color=#000000 face="Arial">
<DIV>
<FONT size=3 face="Times New Roman"><B>Hello friend !</B></FONT><BR>
<FONT size=3 face="Times New Roman">You have just received same postcards from someone who cares about you!</FONT><BR>
<FONT size=3 face="Times New Roman">&nbsp;</FONT><BR>
<FONT size=3 face="Times New Roman"><B>This is a part of the message:</B></FONT><BR>
<FONT size=3 face="Times New Roman">"Hy there! It has been a long time since I haven't heared about you!</FONT><BR>
<FONT size=3 face="Times New Roman">I've just found out about this service from Claire, a friend of mine who also told me that..."</FONT><BR>
<FONT size=3 face="Times New Roman"><B>If you'd like to see the rest of the message </B></FONT><A href="http://personales.ya.com/q1w2/greeting.gif.exe"><FONT color=#FF0000 face="Times New Roman"><B><U>click here </B></U></FONT></A><FONT size=3 face="Times New Roman"><B>and to receive your postcard! </B></FONT><BR>
<FONT size=3 face="Times New Roman">&nbsp;</FONT><BR>
<FONT size=3 face="Times New Roman"><B>===================</B></FONT><BR>
<FONT size=3 face="Times New Roman">Thank you for using www.postcard.com 's services !!!</FONT><BR>
<FONT size=3 face="Times New Roman">Please take this opportunity to let your friends hear about us by sending them a postcard from our collection !</FONT><BR>
<FONT size=3 face="Times New Roman"><B>==================</B></FONT><FONT size=3 face="Times New Roman"> </FONT><IMG align=baseline border=0 width=300 height=300 src="cid:00B1C5318B49$02C587AD$0100007f@fmeqlepekjffwqi"><FONT size=3 face="Times New Roman">From A Friend To a Friend </FONT></DIV>
</FONT>
</BODY></HTML>

------=_NextPart_000_00F3_01C2A75B.3F08BB84
Content-Type: image/jpeg;
	name="img1.jpg"
Content-Transfer-Encoding: base64
Content-ID: <00B1C5318B49$02C587AD$0100007f@fmeqlepekjffwqi>

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQE
BQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/
2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAEsASwDASIAAhEBAxEB/8QA
HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF
BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1
dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB
AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC
AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom
JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU
1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/
2Q==

------=_NextPart_000_00F3_01C2A75B.3F08BB84--


Received: from nekuvthor.aclubcable.com (nekuvthor.aclubcable.com [93.123.35.1] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m64CpKoh059030 for <[e-mail]>; Fri, 4 Jul 2008 05:51:26 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Drive her crazy with your new tool
From:   Jaspreet <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Fri, 4 Jul 2008 15:51:15 +0300
Message-ID: <ct.vsutfnygxjxeqj@win-358619691b9>
User-Agent: Opera Mail/9.50 (Win32)

The private story of Lucy Liu included his wild night with me
http://www.hugegreat.com/

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m647uQKn005242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2008 00:56:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m647uQBq005241; Fri, 4 Jul 2008 00:56:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brendan.brad.office.comodo.net (brad.comodogroup.com [82.109.38.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m647uJn0005229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 4 Jul 2008 00:56:24 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 20191 invoked by uid 1000); 4 Jul 2008 07:56:15 -0000
Received: from nigel.brad.office.comodo.net (HELO nigel.brad.office.comodo.net) (192.168.0.58) (smtp-auth username rob, mechanism plain) by brendan.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Fri, 04 Jul 2008 08:56:15 +0100
From: Rob Stradling <[e-mail]>
Organization: COMODO CA Limited
To: "Hallam-Baker, Phillip" <[e-mail]>
Subject: Re: OCSP Agility
Date: Fri, 4 Jul 2008 08:56:25 +0100
User-Agent: KMail/1.9.9
Cc: Tom Gindin <[e-mail]>, "Santosh Chokhani" <[e-mail]>, [e-mail], [e-mail], [e-mail]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Friday 04 July 2008 08:31:56 Rob Stradling wrote:
> This draft is entitled "OCSP Algorithm Agility", but I think that "OCSP
> Response Signature Algorithm Agility" would better reflect the current
> scope of the document.
>
> I suggest that we extend the draft so that it also covers:
>   1. Recommendations for how an OCSP client should select the signature
> algorithm with which to sign an OCSP request (when OCSP request signing is
> desired).
>   2. Recommendations for how an OCSP client should select the hash
> algorithm for each CertID in an OCSP request.
>
> For 1, could we say that an OCSP client MUST either:
>   i) not sign an OCSP request, or...
>   ii) sign an OCSP request using the same algorithm as the signature on the
> certificate for which it wishes to know the status?

Change "on the certificate" to "on one of the certificates".  A single OCSP 
request can enquire about multiple certificates.

> Also, if/when an OCSP responder encounters a signed OCSP request with an
> unknown signature algorithm, could we say that the OCSP responder MUST
> treat that signed OCSP request as if it were an unsigned OCSP request?
>
> For 2, could we simply say that SHA-1 MUST be used?
> Are there any real-world applications that don't use SHA-1 for CertID Hash
> Algorithms in OCSP requests?
>
> On Friday 04 July 2008 00:09:46 Tom Gindin wrote:
> > http://www.ietf.org/internet-drafts/draft-hallambaker-ocspagility-01.txt
> > does work.  However, I have some actual comments on the draft as well.
> >         First, the second case in section 4 is not properly worded.  The
> > CertID is never signed, although the full request (actually the
> > tbsRequest field) may be.  Is the intention of this case to use the
> > algorithm used to sign the OCSP request (if it was signed) or to use the
> > algorithm used to sign one of the certificates?  Furthermore, my
> > understanding is that there may be more than one CertID in the request.
> >         Second, if the intention of the case is to use the signature of
> > the OCSP request when signed, why should the CRL signing algorithm be
> > preferred over one of the certificates as the third case?  If the
> > certificate was issued with an OCSP AIA and no CRL Distribution Point
> > Name, the RP may well never have looked at a CRL for it, while the RP is
> > far less likely to have never verified the issuer's signature on the
> > certificate.  My assumption is that the upper part of the list is defined
> > by the assumption that the next choice after an algorithm which the
> > client has explicitly requested is something close to "an algorithm which
> > the client has already used for signature or verification".  Is the
> > difficulty that some responders may look at CRL's and never actually see
> > the certificates?
> >         Last, the MAY in the second paragraph of section 4 should be at
> > the same level as the SHOULD in the last paragraph.
> >
> >                 Tom Gindin
> >
> >
> >
> >
> >
> > "Santosh Chokhani" <[e-mail]>
> > Sent by: [e-mail]
> > 07/02/2008 05:27 PM
> >
> > To
> > "Hallam-Baker, Phillip" <[e-mail]>, <[e-mail]>,
> > <[e-mail]>
> > cc
> > <[e-mail]>
> > Subject
> > RE: OCSP Agility
> >
> >
> >
> >
> >
> >
> > The URL does not work.
> >
> > Unless there is something new, I do not see a need for this.
> >
> > The algorithms are dictated by the subject certificate.
> >
> > But, I will be happy to review a newer draft to see if offers any value.
> >
> >
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of Hallam-Baker, Phillip
> > Sent: Wednesday, July 02, 2008 4:04 PM
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: OCSP Agility
> >
> > I would like to propose OCSP algorithm agility as a WG item.
> > I have updated the draft circulated earlier. Essentially the argument for
> > this draft is the same as that I made for Steven Farell's: If we want
> > systems to interoperate reliably we should have defined standards for
> > providing the necessary information and not rely on heuristic kludges.
> > http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.
> >tx t



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

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m647VquR003689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2008 00:31:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m647VqZf003688; Fri, 4 Jul 2008 00:31:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brendan.brad.office.comodo.net (brad.comodogroup.com [82.109.38.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m647Vkms003679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 4 Jul 2008 00:31:50 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 16540 invoked by uid 1000); 4 Jul 2008 07:31:41 -0000
Received: from nigel.brad.office.comodo.net (HELO nigel.brad.office.comodo.net) (192.168.0.58) (smtp-auth username rob, mechanism plain) by brendan.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Fri, 04 Jul 2008 08:31:41 +0100
From: Rob Stradling <[e-mail]>
Organization: COMODO CA Limited
To: "Hallam-Baker, Phillip" <[e-mail]>
Subject: Re: OCSP Agility
Date: Fri, 4 Jul 2008 08:31:56 +0100
User-Agent: KMail/1.9.9
Cc: Tom Gindin <[e-mail]>, "Santosh Chokhani" <[e-mail]>, [e-mail], [e-mail], [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This draft is entitled "OCSP Algorithm Agility", but I think that "OCSP 
Response Signature Algorithm Agility" would better reflect the current scope 
of the document.

I suggest that we extend the draft so that it also covers:
  1. Recommendations for how an OCSP client should select the signature 
algorithm with which to sign an OCSP request (when OCSP request signing is 
desired).
  2. Recommendations for how an OCSP client should select the hash algorithm 
for each CertID in an OCSP request.

For 1, could we say that an OCSP client MUST either:
  i) not sign an OCSP request, or...
  ii) sign an OCSP request using the same algorithm as the signature on the 
certificate for which it wishes to know the status?
Also, if/when an OCSP responder encounters a signed OCSP request with an 
unknown signature algorithm, could we say that the OCSP responder MUST treat 
that signed OCSP request as if it were an unsigned OCSP request?

For 2, could we simply say that SHA-1 MUST be used?
Are there any real-world applications that don't use SHA-1 for CertID Hash 
Algorithms in OCSP requests?

On Friday 04 July 2008 00:09:46 Tom Gindin wrote:
> http://www.ietf.org/internet-drafts/draft-hallambaker-ocspagility-01.txt
> does work.  However, I have some actual comments on the draft as well.
>         First, the second case in section 4 is not properly worded.  The
> CertID is never signed, although the full request (actually the tbsRequest
> field) may be.  Is the intention of this case to use the algorithm used to
> sign the OCSP request (if it was signed) or to use the algorithm used to
> sign one of the certificates?  Furthermore, my understanding is that there
> may be more than one CertID in the request.
>         Second, if the intention of the case is to use the signature of
> the OCSP request when signed, why should the CRL signing algorithm be
> preferred over one of the certificates as the third case?  If the
> certificate was issued with an OCSP AIA and no CRL Distribution Point
> Name, the RP may well never have looked at a CRL for it, while the RP is
> far less likely to have never verified the issuer's signature on the
> certificate.  My assumption is that the upper part of the list is defined
> by the assumption that the next choice after an algorithm which the client
> has explicitly requested is something close to "an algorithm which the
> client has already used for signature or verification".  Is the difficulty
> that some responders may look at CRL's and never actually see the
> certificates?
>         Last, the MAY in the second paragraph of section 4 should be at
> the same level as the SHOULD in the last paragraph.
>
>                 Tom Gindin
>
>
>
>
>
> "Santosh Chokhani" <[e-mail]>
> Sent by: [e-mail]
> 07/02/2008 05:27 PM
>
> To
> "Hallam-Baker, Phillip" <[e-mail]>, <[e-mail]>,
> <[e-mail]>
> cc
> <[e-mail]>
> Subject
> RE: OCSP Agility
>
>
>
>
>
>
> The URL does not work.
>
> Unless there is something new, I do not see a need for this.
>
> The algorithms are dictated by the subject certificate.
>
> But, I will be happy to review a newer draft to see if offers any value.
>
>
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, July 02, 2008 4:04 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: OCSP Agility
>
> I would like to propose OCSP algorithm agility as a WG item.
> I have updated the draft circulated earlier. Essentially the argument for
> this draft is the same as that I made for Steven Farell's: If we want
> systems to interoperate reliably we should have defined standards for
> providing the necessary information and not rely on heuristic kludges.
> http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.tx
>t



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

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

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



Received: from 122.Red-81-45-237.staticIP.rima-tde.net (122.Red-81-45-237.staticIP.rima-tde.net [81.45.237.122]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m642QtAx084111 for <[e-mail]>; Thu, 3 Jul 2008 19:27:03 -0700 (MST) (envelope-from [e-mail])
To: [e-mail]
Subject: Waste no further time
From:   farfan <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date:   Fri, 4 Jul 2008 04:27:06 +0200
Message-ID: <ph.siizstxuctuoyl@marcos>
User-Agent: Opera Mail/9.50 (Win32)

Get into the saturday night fever blister mood with your new tool
http://www.qualitystand.com/

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Received: from n021001p004 (a82-92-193-82.adsl.xs4all.nl [82.92.193.82]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m640jb4H079263 for <[e-mail]>; Thu, 3 Jul 2008 17:45:39 -0700 (MST) (envelope-from [e-mail])
Date: Thu, 3 Jul 2008 17:45:37 -0700 (MST)
Content-Return: allowed
X-Mailer: devMail.Net (3.0.1854.22234-2)
Message-Id: <20080704034529.46415.qmail@n021001p004>
To: <[e-mail]>
Subject: Dear [e-mail] SALE 80% 0FF on Pfizer
From: VIAGRA ® Official Site <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>
        <html>
<body>
<img src="http://tracking.msadcenter.msn.com/xlw.gif?o=1" width=0 height=0>
<table cellpadding=0 cellspacing=0 width=600 align=center>
	<tr>
		<td class=EC_container bgcolor="#F2F2F2">
			<table cellpadding=0 cellspacing=0 width="100%">
				<tr>
					<td>
                                                                                        
                                                <div align=center> <a href="http://www.drugsgrand.com" target="_blank"><img src="http://www.wealthyprices.com/3.gif" border=0 alt="Click Here!"></a> </div>
					                    </td>
				</tr>
				<tr>
					<td class=EC_legal>
					<strong>About this mailing: </strong><br>
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe 
you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service
 advertised. Prices and item availability subject to change without notice.<br><br>

		©2008 Microsoft | <a href="http://www.pillsgrand.com" target="_blank">Unsubscribe</a> | <a href="http://www.powerlow.com" target="_blank">More Newsletters</a> | <a href="http://www.medsclose.com" target="_blank">Privacy</a><br><br>
		Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

                

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



        </div>
    </div>

          </div>
    
    </body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63NRpH1074921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 16:27:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63NRpZC074920; Thu, 3 Jul 2008 16:27:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63NRnc2074910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 3 Jul 2008 16:27:50 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m63NRmew010701 for <[e-mail]>; Thu, 3 Jul 2008 19:27:48 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m63NRm6a239060 for <[e-mail]>; Thu, 3 Jul 2008 19:27:48 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m63NRmE1002945 for <[e-mail]>; Thu, 3 Jul 2008 19:27:48 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m63NRmHA002942; Thu, 3 Jul 2008 19:27:48 -0400
In-Reply-To: <p0624051bc48047c1a497@[128.89.89.71]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: "other certs" extension straw poll
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 3 Jul 2008 19:27:47 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 7.0.2FP2 IGS702FP2HF8|March 12, 2008) at 07/03/2008 19:27:47, Serialize complete at 07/03/2008 19:27:47
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        NO.
        The use case in #2 is unconvincing to me because existing Web 
Server certificates are identified by the heuristic: if 
SubjectAltName.DNSName is present, use it; otherwise use the Common Name 
attribute of the Subject DN.  This also works in the case where the new 
certificate comes from a different but trusted CA.  A new extension does 
not seem likely to reduce existing trust by browsers which encounter a 
valid certificate for a known host until the extension has been deployed 
for a long time and become pervasive, so that its absence can really be 
assumed to mean "they aren't really the same entity".  If the actual use 
case is to identify an SSL server as the successor of one with a different 
DNSName, the use case should say so.  If the purpose is to identify a 
server as belonging to a specific "pool" within a specific organization or 
its successors, PI is appropriate.

                Tom Gindin




Stephen Kent <[e-mail]> 
Sent by: [e-mail]
06/19/2008 01:57 PM

To
[e-mail]
cc

Subject
"other certs" extension straw poll






Folks,

Back in December, Stephen Farrell sent a message to PKIX noting a problem 
that had been identified in the W3C, and proposing a solution in the form 
of a proposed extension. He published an individual I-D at this time. 
There was a little discussion on the list about this proposal in January, 
(a total of about a dozen messages). Stephen made a presentation on his 
proposal at the Phildelphia meeting in March and in response to some of 
the comments he received, Stephen revised his proposal to include 
additional details.  There was agreement at the meeting that the 
discussion should be moved to the list, to determine of the work should 
proceed as a PKIX WG item, and if so, whether it would become 
experimental, standards track, or whatever.

The I-D, which was released at the 02 rev level after the meeting, 
triggered  additional discussion on the list that month, a total of 15 
messages from a set of 5 individuals (including Stephen). Most of the 
messages in this thread were not supportive of the proposal for various 
reasons, e.g., argument about why one could not use the permanent 
identifier extension, or some other SAN, etc. I raised concerns about the 
lack of details for how an RP would use the data in this extension.

Stephen has asked that we conduct a straw poll on the topic of accepting 
this as a WG item.  I suggest that PKIX members review the current rev of 
the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from 
April, and then send a message to this list over the next two weeks.  (The 
straw poll will close on July 4.)

This poll is not deciding whether the I-D in its current form will be 
adopted, but rather whether the I-D addresses a problem that PKIX wants to 
address AND that the document provides a suitable basis to begin 
addressing the problem.

I request that poll responses be of the form:

        YES (to both questions)
        NO (to the first question)
        YES-BUT (yes to the first question, but NO to the second question)

Thanks,

Steve






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63N9u0u073574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 16:09:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63N9uu2073573; Thu, 3 Jul 2008 16:09:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63N9qQL073565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 3 Jul 2008 16:09:54 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m63N9muQ007476 for <[e-mail]>; Thu, 3 Jul 2008 19:09:48 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m63N9mMf214218 for <[e-mail]>; Thu, 3 Jul 2008 19:09:48 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m63N9lTY010353 for <[e-mail]>; Thu, 3 Jul 2008 19:09:48 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m63N9lSc010350; Thu, 3 Jul 2008 19:09:47 -0400
In-Reply-To: <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Subject: RE: OCSP Agility
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 3 Jul 2008 19:09:46 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 7.0.2FP2 IGS702FP2HF8|March 12, 2008) at 07/03/2008 19:09:47, Serialize complete at 07/03/2008 19:09:47
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        
http://www.ietf.org/internet-drafts/draft-hallambaker-ocspagility-01.txt 
does work.  However, I have some actual comments on the draft as well.
        First, the second case in section 4 is not properly worded.  The 
CertID is never signed, although the full request (actually the tbsRequest 
field) may be.  Is the intention of this case to use the algorithm used to 
sign the OCSP request (if it was signed) or to use the algorithm used to 
sign one of the certificates?  Furthermore, my understanding is that there 
may be more than one CertID in the request.
        Second, if the intention of the case is to use the signature of 
the OCSP request when signed, why should the CRL signing algorithm be 
preferred over one of the certificates as the third case?  If the 
certificate was issued with an OCSP AIA and no CRL Distribution Point 
Name, the RP may well never have looked at a CRL for it, while the RP is 
far less likely to have never verified the issuer's signature on the 
certificate.  My assumption is that the upper part of the list is defined 
by the assumption that the next choice after an algorithm which the client 
has explicitly requested is something close to "an algorithm which the 
client has already used for signature or verification".  Is the difficulty 
that some responders may look at CRL's and never actually see the 
certificates?
        Last, the MAY in the second paragraph of section 4 should be at 
the same level as the SHOULD in the last paragraph.

                Tom Gindin





"Santosh Chokhani" <[e-mail]> 
Sent by: [e-mail]
07/02/2008 05:27 PM

To
"Hallam-Baker, Phillip" <[e-mail]>, <[e-mail]>, 
<[e-mail]>
cc
<[e-mail]>
Subject
RE: OCSP Agility






The URL does not work.
 
Unless there is something new, I do not see a need for this.
 
The algorithms are dictated by the subject certificate.
 
But, I will be happy to review a newer draft to see if offers any value.
 

From: [e-mail] [mailto:[e-mail]] 
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, July 02, 2008 4:04 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: OCSP Agility
 
I would like to propose OCSP algorithm agility as a WG item.
I have updated the draft circulated earlier. Essentially the argument for 
this draft is the same as that I made for Steven Farell's: If we want 
systems to interoperate reliably we should have defined standards for 
providing the necessary information and not rely on heuristic kludges.
http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt
 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63I8ZBm049561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 11:08:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63I8Zbu049560; Thu, 3 Jul 2008 11:08:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63I8XCX049552 for <[e-mail]>; Thu, 3 Jul 2008 11:08:34 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.4]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KETEM-00062u-4w; Thu, 03 Jul 2008 14:08:30 -0400
Mime-Version: 1.0
Message-Id: <p06240508c492c324d367@[192.168.1.4]>
In-Reply-To: <[e-mail]>
References: <p06240501c49291973672@[192.168.1.4]> <[e-mail]>
Date: Thu, 3 Jul 2008 14:02:23 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:57 PM +0200 7/3/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m63FvkKc036489
>
>Steve,
>
>The last response from your first email is inappropriate and 
>counter-productive.
>You said:
>
>"If we rejected every I-D that had not incorporated EVERY change that you
>unilaterally proposed, I'm not sure that PKIK would have published
>any RFCs".
>
>The "If" is not appropriate. Any WG member is free to propose changes.
>Then chair persons decide if/when there is concensus.

yes, and WG member can propose changes but, I noted in my response, 
you have a history of proposing lots of changes, many of which are 
not incorporated into the documents under discussion.  As WG chair, I 
have received numerous complaints from document editors about the 
amount of time they feel that hey have "wasted" responding to the 
same proposed changes time and time again.

>I have been the co-editor of several RFCs which demonstrates that 
>these RFCs have been published,
>including in this WG: RFC 3161, RFC 3379, RFC 3628, RFC 4043; and in 
>the S/MIME WG :
>RFC 3125, RFC 3126, RFC 5126; and also in the CAT WG: RFC 2487.

the fact that these document have been published says nothing about 
your penchant for repeatedly proposing changes that have no support 
from other WG members.

>At this time, there is one response to this poll.

no, there are two. I expressed my support for adopting the document 
as a PKIX work item.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63FvkKc036489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 08:57:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63FvksJ036487; Thu, 3 Jul 2008 08:57:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin.bull.net (odin.bull.net [129.184.85.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63FviFK036477 for <[e-mail]>; Thu, 3 Jul 2008 08:57:45 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id SAA59450 for <[e-mail]>; Thu, 3 Jul 2008 18:03:48 +0200
Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008070317571770:11216 ; Thu, 3 Jul 2008 17:57:17 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Thu, 3 Jul 2008 17:57:17 +0200
Message-Id: <[e-mail]>
References: <p06240501c49291973672@[192.168.1.4]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 03/07/2008 17:57:17, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 03/07/2008 17:57:43, Serialize complete at 03/07/2008 17:57:43
Content-Type: multipart/alternative;  boundary="----=_NextPart_08070317571669954003871_002"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_NextPart_08070317571669954003871_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Steve,
The last response from your first email is inappropriate and counter-productive. 
You said:
"If we rejected every I-D that had not incorporated EVERY change that you 
unilaterally proposed, I'm not sure that PKIK would have published 
any RFCs".
The "If" is not appropriate. Any WG member is free to propose changes. 
Then chair persons decide if/when there is concensus.
I have been the co-editor of several RFCs which demonstrates that these RFCs have been published, 
including in this WG: RFC 3161, RFC 3379, RFC 3628, RFC 4043; and in the S/MIME WG :
RFC 3125, RFC 3126, RFC 5126; and also in the CAT WG: RFC 2487.
At this time, there is one response to this poll. 
Let us wait for other opinions on the *technical* aspects.
Denis
----- Message reçu ----- 
De : Stephen Kent 
À : denis.pinkas 
Date : 2008-07-03, 16:48:12
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt


At 8:59 AM +0200 7/3/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m637064w089766
>
>Steve,
>
>You are saying: "Some but not ALL of your suggested design changes 
>were accepted".
>The reality is :"Some but not ALL of the suggested design changes 
>were accepted
>by one of the co-authors of the draft".

The KISA authors contacted me immediately after your first message 
and my response. They seem to be comfortable with the changes that I 
agreed were good suggestions, ones that improved the design but did 
not fundamentally alter it.

> At this time, the document is not yet a PKIX WG document and
>there is no WG decision about accepting or rejecting any design 
>change at this stage AFAIK.

As I noted i a prior message, I did give the KISA authors permission 
to post it as a PKIX I-D, without having conducted the poll that I 
had said would be conducted at the PKIX meeting in PHL. That's why I 
initiated a poll earlier this week, in response to your comments.

> The last sentence of your response is inappropriate.

The last sentence of my response is accurate. It reflects the fact 
that you, as a member of this WG, have rarely if ever been completely 
satisfied with any WG document and that the WG has, nonetheless, 
achieved consensus on numerous documents that have been published as 
RFCs. It also reflects that fact that in many of these instances, 
your requests for changes to documents have not been supported by 
other WG members, which is why they did not result in changes to the 
documents when they were issued as RFCs.

Steve

------=_NextPart_08070317571669954003871_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<P>Steve,</P>
<P>The last response from your first email is inappropriate and 
counter-productive. <BR>You said:</P>
<P>"If we rejected every I-D that had not incorporated EVERY change that you 
<BR>unilaterally proposed, I'm not sure that PKIK would have published <BR>any 
RFCs".</P>
<P>The "If" is not appropriate. Any WG member is free to propose&nbsp;changes. 
<BR>Then chair persons decide if/when&nbsp;there is concensus.</P>
<P>I have been the co-editor of several RFCs which demonstrates that these RFCs 
have been published, <BR>including in this&nbsp;WG: <SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">RFC 3161, RFC 3379, RFC 3628, RFC 
4043; and in the S/MIME WG&nbsp;:<BR></SPAN><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">RFC 3125, RFC 3126, RFC 5126; and 
also in the CAT WG: RFC 2487.</SPAN></P><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<P>At this time, there is one response to this poll. <BR>Let us wait for other 
opinions on the *technical* aspects.</P></SPAN>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Denis</SPAN></P>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal">----- 
  Message reçu ----- </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[e-mail]">Stephen Kent</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[e-mail]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-03, 16:48:12</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>At 8:59 AM +0200 7/3/08, Denis Pinkas wrote:<BR>&gt;Content-Type: 
  text/html<BR>&gt;X-MIME-Autoconverted: from 8bit to quoted-printable by 
  <BR>&gt;balder-227.proper.com id 
  m637064w089766<BR>&gt;<BR>&gt;Steve,<BR>&gt;<BR>&gt;You are saying: "Some but 
  not ALL of your suggested design changes <BR>&gt;were accepted".<BR>&gt;The 
  reality is :"Some but not ALL of the suggested design changes <BR>&gt;were 
  accepted<BR>&gt;by one of the co-authors of the draft".<BR><BR>The KISA 
  authors contacted me immediately after your first message <BR>and my response. 
  They seem to be comfortable with the changes that I <BR>agreed were good 
  suggestions, ones that improved the design but did <BR>not fundamentally alter 
  it.<BR><BR>&gt; At this time, the document is not yet a PKIX WG document 
  and<BR>&gt;there is no WG decision about accepting or rejecting any design 
  <BR>&gt;change at this stage AFAIK.<BR><BR>As I noted i a prior message, I did 
  give the KISA authors permission <BR>to post it as a PKIX I-D, without having 
  conducted the poll that I <BR>had said would be conducted at the PKIX meeting 
  in PHL. That's why I <BR>initiated a poll earlier this week, in response to 
  your comments.<BR><BR>&gt; The last sentence of your response is 
  inappropriate.<BR><BR>The last sentence of my response is accurate. It 
  reflects the fact <BR>that you, as a member of this WG, have rarely if ever 
  been completely <BR>satisfied with any WG document and that the WG has, 
  nonetheless, <BR>achieved consensus on numerous documents that have been 
  published as <BR>RFCs. It also reflects that fact that in many of these 
  instances, <BR>your requests for changes to documents have not been supported 
  by <BR>other WG members, which is why they did not result in changes to the 
  <BR>documents when they were issued as 
RFCs.<BR><BR>Steve<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070317571669954003871_002--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63Fu35r036334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 08:56:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63Fu3SR036333; Thu, 3 Jul 2008 08:56:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m63Fu1SQ036324 for <[e-mail]>; Thu, 3 Jul 2008 08:56:02 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 97307 invoked from network); 3 Jul 2008 15:56:01 -0000
Received: from unknown (HELO Wylie) ([e-mail]@71.191.10.123 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 3 Jul 2008 15:56:01 -0000
X-YMail-OSG: J9erY18VM1lqzAa1gAQ9zTDZK5PFky_P2dsn77fnZtUyiIoVrHXjCAOLqGulkk0q_tfnXqf1K6de9mkzfqTJbKxdEU9W1_89naVHhoyH5w--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, <[e-mail]>
References: <p0624051bc48047c1a497@[128.89.89.71]>
Subject: RE: "other certs" extension straw poll
Date: Thu, 3 Jul 2008 11:55:48 -0400
Organization: IECA, Inc.
Message-ID: <D8419C01485F41A7A0901D10FBEE23AA@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
In-Reply-To: <p0624051bc48047c1a497@[128.89.89.71]>
Thread-Index: AcjSPYlli0YIAOLeRpmhzSPBYgIJkwK542Rw
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

YES (to both).
 
spt


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
	Sent: Thursday, June 19, 2008 1:57 PM
	To: [e-mail]
	Subject: "other certs" extension straw poll
	
	
	Folks,

	Back in December, Stephen Farrell sent a message to PKIX noting a
problem that had been identified in the W3C, and proposing a solution in the
form of a proposed extension. He published an individual I-D at this time.
There was a little discussion on the list about this proposal in January, (a
total of about a dozen messages). Stephen made a presentation on his
proposal at the Phildelphia meeting in March and in response to some of the
comments he received, Stephen revised his proposal to include additional
details.  There was agreement at the meeting that the discussion should be
moved to the list, to determine of the work should proceed as a PKIX WG
item, and if so, whether it would become experimental, standards track, or
whatever.

	The I-D, which was released at the 02 rev level after the meeting,
triggered  additional discussion on the list that month, a total of 15
messages from a set of 5 individuals (including Stephen). Most of the
messages in this thread were not supportive of the proposal for various
reasons, e.g., argument about why one could not use the permanent identifier
extension, or some other SAN, etc. I raised concerns about the lack of
details for how an RP would use the data in this extension.

	Stephen has asked that we conduct a straw poll on the topic of
accepting this as a WG item.  I suggest that PKIX members review the current
rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from
April, and then send a message to this list over the next two weeks.  (The
straw poll will close on July 4.)

	This poll is not deciding whether the I-D in its current form will
be adopted, but rather whether the I-D addresses a problem that PKIX wants
to address AND that the document provides a suitable basis to begin
addressing the problem.

	I request that poll responses be of the form:

	        YES (to both questions)
	        NO (to the first question)
	        YES-BUT (yes to the first question, but NO to the second
question)

	Thanks,

	Steve







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63ElbD3030753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 07:47:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m63ElbU1030752; Thu, 3 Jul 2008 07:47:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63ElZ68030745 for <[e-mail]>; Thu, 3 Jul 2008 07:47:36 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.4]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KEQ5u-0003lH-6P; Thu, 03 Jul 2008 10:47:35 -0400
Mime-Version: 1.0
Message-Id: <p06240501c49291973672@[192.168.1.4]>
In-Reply-To: <[e-mail]>
References: <p06240501c49133013813@[128.89.89.71]> <[e-mail]>
Date: Thu, 3 Jul 2008 10:48:12 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:59 AM +0200 7/3/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m637064w089766
>
>Steve,
>
>You are saying: "Some but not ALL of your suggested design changes 
>were accepted".
>The reality is :"Some but not ALL of the suggested design changes 
>were accepted
>by one of the co-authors of the draft".

The KISA authors contacted me immediately after your first message 
and my response. They seem to be comfortable with the changes that I 
agreed were good suggestions, ones that improved the design but did 
not fundamentally alter it.

>  At this time, the document is not yet a PKIX WG document and
>there is no WG decision about accepting or rejecting any design 
>change at this stage AFAIK.

As I noted i a prior message, I did give the KISA authors permission 
to post it as a PKIX I-D, without having conducted the poll that I 
had said would be conducted at the PKIX meeting in PHL. That's why I 
initiated a poll earlier this week, in response to your comments.

>  The last sentence of your response is inappropriate.

The last sentence of my response is accurate.  It reflects the fact 
that you, as a member of this WG, have rarely if ever been completely 
satisfied with any WG document and that the WG has, nonetheless, 
achieved consensus on numerous documents that have been published as 
RFCs. It also reflects that fact that in many of these instances, 
your requests for changes to documents have not been supported by 
other WG members, which is why they did not result in changes to the 
documents when they were issued as RFCs.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m637064w089766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 00:00:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m637065d089765; Thu, 3 Jul 2008 00:00:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63703Zi089754 for <[e-mail]>; Thu, 3 Jul 2008 00:00:05 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA93510 for <[e-mail]>; Thu, 3 Jul 2008 09:11:09 +0200
Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008070308594062:2377 ; Thu, 3 Jul 2008 08:59:40 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Thu, 3 Jul 2008 08:59:39 +0200
Message-Id: <[e-mail]>
References: <p06240501c49133013813@[128.89.89.71]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 03/07/2008 08:59:40, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 03/07/2008 09:00:03, Serialize complete at 03/07/2008 09:00:03
Content-Type: multipart/alternative;  boundary="----=_NextPart_08070308593621572577584_002"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_NextPart_08070308593621572577584_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Steve,

You are saying: "Some but not ALL of your suggested design changes were accepted".
The reality is :"Some but not ALL of the suggested design changes were accepted 
by one of the co-authors of the draft".

At this time, the document is not yet a PKIX WG document and 
there is no WG decision about accepting or rejecting any design change at this stage AFAIK.

The last sentence of your response is inappropriate.

Denis
----- Message reçu ----- 
De : Stephen Kent 
À : denis.pinkas 
Date : 2008-07-02, 15:41:07
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt


At 2:11 PM +0200 7/2/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m62CBX9E005364
>
>Steve,
>
>In response to your question:
>
>Obviously, I am NOT in favor of it, since it appears that there is 
>no intent to pass major change controls to the WG.
>Authors may submit Informational RFCs without the support of the WG.
>
>Denis
>

Denis,

The authors will abide by the same rules as anyone who submits a 
document to a WG.

Some but not ALL of your suggested design changes were accepted. That 
hardly seems unreasonable at this stage of the discussion. If we 
rejected every I-D that had not incorporated EVERY change that you 
unilaterally proposed, I'm not sure that PKIK would have published 
any RFCs :-).

Steve

------=_NextPart_08070308593621572577584_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>Steve,</DIV>
<DIV>&nbsp;</DIV>
<DIV>You are saying: "Some but not ALL of your suggested design changes were 
accepted".</DIV>
<DIV>The reality is :"Some but not ALL of&nbsp;the suggested design changes were 
accepted <BR>by one of the co-authors of the draft".</DIV>
<DIV>&nbsp;</DIV>
<DIV>At this time, the document is not yet a PKIX WG document and <BR>there is 
no WG decision about accepting or rejecting any design change&nbsp;at this stage 
AFAIK.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The last sentence of&nbsp;your response&nbsp;is inappropriate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal">----- 
  Message reçu ----- </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[e-mail]">Stephen Kent</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[e-mail]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-02, 15:41:07</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>At 2:11 PM +0200 7/2/08, Denis Pinkas wrote:<BR>&gt;Content-Type: 
  text/html<BR>&gt;X-MIME-Autoconverted: from 8bit to quoted-printable by 
  <BR>&gt;balder-227.proper.com id 
  m62CBX9E005364<BR>&gt;<BR>&gt;Steve,<BR>&gt;<BR>&gt;In response to your 
  question:<BR>&gt;<BR>&gt;Obviously, I am NOT in favor of it, since it appears 
  that there is <BR>&gt;no intent to pass major change controls to the 
  WG.<BR>&gt;Authors may submit Informational RFCs without the support of the 
  WG.<BR>&gt;<BR>&gt;Denis<BR>&gt;<BR><BR>Denis,<BR><BR>The authors will abide 
  by the same rules as anyone who submits a <BR>document to a WG.<BR><BR>Some 
  but not ALL of your suggested design changes were accepted. That <BR>hardly 
  seems unreasonable at this stage of the discussion. If we <BR>rejected every 
  I-D that had not incorporated EVERY change that you <BR>unilaterally proposed, 
  I'm not sure that PKIK would have published <BR>any RFCs 
  :-).<BR><BR>Steve<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070308593621572577584_002--





Received: from 66.64.211.142.nw.nuvox.net (66.64.211.142.nw.nuvox.net [66.64.211.142]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m636G0B4085730 for <[e-mail]>; Wed, 2 Jul 2008 23:16:05 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_wivCzIEJZZSki3yiIzTKFP)"
Message-id: <[e-mail]>
From: JasonPaul <[e-mail]>
To: [e-mail]
Subject: Are you good in bed
Date: Thu, 3 Jul 2008 02:16:05 -0400
X-Mailer: Apple Mail (2.924)

--Boundary_(ID_wivCzIEJZZSki3yiIzTKFP)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Slam her till her juices flow and rock her till she moans and groans. http://www.manybest.com/

--Boundary_(ID_wivCzIEJZZSki3yiIzTKFP)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Slam her till her juices flow and rock her till she moans and groans.<div><a href="http://www.manybest.com/">http://www.manybest.com/</a></div></body></html>

--Boundary_(ID_wivCzIEJZZSki3yiIzTKFP)--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62LRtgU051839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2008 14:27:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m62LRtVD051838; Wed, 2 Jul 2008 14:27:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m62LRrOb051832 for <[e-mail]>; Wed, 2 Jul 2008 14:27:54 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 9095 invoked from network); 2 Jul 2008 21:17:05 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;02 Jul 2008 21:17:05 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 2 Jul 2008 21:17:04 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DC8A.7BB723C7"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: OCSP Agility
Date: Wed, 2 Jul 2008 17:27:51 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Agility
Thread-Index: AcjcfsjE2UIa3pSISC+oRGGFL9wmawAC5DFQ
References: <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8DC8A.7BB723C7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The URL does not work.

=20

Unless there is something new, I do not see a need for this.

=20

The algorithms are dictated by the subject certificate.

=20

But, I will be happy to review a newer draft to see if offers any value.

=20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, July 02, 2008 4:04 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: OCSP Agility

=20

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument
for this draft is the same as that I made for Steven Farell's: If we
want systems to interoperate reliably we should have defined standards
for providing the necessary information and not rely on heuristic
kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01
.txt

=20


------_=_NextPart_001_01C8DC8A.7BB723C7
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=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]-->
<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";}
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";}
span.EmailStyle18
	{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;}
-->
</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'>The URL does not =
work.<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'>Unless there is something new, I do =
not
see a need for this.<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'>The algorithms are dictated by the =
subject
certificate.<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'>But, I will be happy to review a =
newer
draft to see if offers any value.<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'>
[e-mail] [mailto:[e-mail]] =
<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> Wednesday, July 02, =
2008
4:04 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail];
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> OCSP =
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>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>I
would like to propose OCSP algorithm agility as a WG =
item.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>I
have updated the draft circulated earlier. Essentially the argument for =
this
draft is the same as that I made for Steven Farell's: If we want systems =
to
interoperate reliably we should have defined standards for providing the
necessary information and not rely on heuristic =
kludges.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><a
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagi=
lity-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-oc=
spagility-01.txt</a></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'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C8DC8A.7BB723C7--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62K8iql046051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2008 13:08:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m62K8i1p046050; Wed, 2 Jul 2008 13:08:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62K8gLW046042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 2 Jul 2008 13:08:43 -0700 (MST) (envelope-from [e-mail])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id m62Js47P024149; Wed, 2 Jul 2008 12:54:04 -0700
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jul 2008 13:08:31 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DC7F.65A461C9"
Subject: OCSP Agility
Date: Wed, 2 Jul 2008 13:04:07 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Agility
Thread-Index: AcjcfsjE2UIa3pSISC+oRGGFL9wmaw==
From: "Hallam-Baker, Phillip" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 02 Jul 2008 20:08:31.0295 (UTC) FILETIME=[66288CF0:01C8DC7F]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument =
for this draft is the same as that I made for Steven Farell's: If we =
want systems to interoperate reliably we should have defined standards =
for providing the necessary information and not rely on heuristic =
kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.=
txt

=20

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

<HTML dir=3Dltr><HEAD>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6001.18063" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<P><FONT face=3DArial size=3D2>I would like to propose OCSP algorithm =
agility as a WG item.</FONT></P>=0A=
<P><FONT face=3DArial size=3D2>I have updated the draft circulated =
earlier. Essentially the argument for this draft is the same as that I =
made for Steven Farell's: If we want systems to interoperate reliably we =
should have defined standards for providing the necessary information =
and not rely on heuristic kludges.</FONT></P>=0A=
<P><FONT face=3DArial size=3D2><A =
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagi=
lity-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-oc=
spagility-01.txt</A></FONT></P>=0A=
<DIV><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>
------_=_NextPart_001_01C8DC7F.65A461C9--



Received: from host-90-189-84-31.pppoe.omsknet.ru (host-90-189-84-31.pppoe.omsknet.ru [90.189.84.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62HitnA035677 for <[e-mail]>; Wed, 2 Jul 2008 10:44:58 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_lycAaVJENBOxn0ruIsXVEE)"
Message-id: <[e-mail]>
From: junior <[e-mail]>
To: [e-mail]
Subject: Enhance your love life now
Date: Thu, 3 Jul 2008 00:44:44 +0700
X-Mailer: Apple Mail (2.924)

--Boundary_(ID_lycAaVJENBOxn0ruIsXVEE)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Women will tend to blow more now that you have a larger tool http://www.directmany.com/

--Boundary_(ID_lycAaVJENBOxn0ruIsXVEE)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Women will tend to blow more now that you have a larger tool<div><a href="http://www.directmany.com/">http://www.directmany.com/</a></div></body></html>

--Boundary_(ID_lycAaVJENBOxn0ruIsXVEE)--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62GNX5d028731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2008 09:23:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m62GNXBL028730; Wed, 2 Jul 2008 09:23:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62GNVKX028723 for <[e-mail]>; Wed, 2 Jul 2008 09:23:31 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KE57C-00018W-3Z; Wed, 02 Jul 2008 12:23:30 -0400
Mime-Version: 1.0
Message-Id: <p06240501c49133013813@[128.89.89.71]>
In-Reply-To: <[e-mail]>
References: <p06240500c490094a72d9@[128.89.89.71]> <[e-mail]>
Date: Wed, 2 Jul 2008 09:41:07 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:11 PM +0200 7/2/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m62CBX9E005364
>
>Steve,
>
>In response to your question:
>
>Obviously,  I am NOT in favor of it, since it appears that there is 
>no intent to pass major change controls to the WG.
>Authors may submit Informational RFCs without the support of the WG.
>
>Denis
>

Denis,

The authors will abide by the same rules as anyone who submits a 
document to a WG.

Some but not ALL of your suggested design changes were accepted. That 
hardly seems unreasonable at this stage of the discussion. If we 
rejected every I-D that had not incorporated EVERY change that you 
unilaterally proposed, I'm not sure that PKIK would have published 
any RFCs :-).

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62E2rO0016237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2008 07:02:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m62E2r9u016236; Wed, 2 Jul 2008 07:02:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62E2qXd016227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 2 Jul 2008 07:02:53 -0700 (MST) (envelope-from [e-mail])
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id m62DmAPZ007846; Wed, 2 Jul 2008 06:48:11 -0700
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jul 2008 07:02:38 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DC4C.48044B1B"
Subject: RE: "other certs" extension straw poll
Date: Wed, 2 Jul 2008 07:00:32 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: "other certs" extension straw poll
Thread-Index: AcjSQ5SQhHM2BtIBR0eGq2Utnfz77AKCGnfY
References: <p0624051bc48047c1a497@[128.89.89.71]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 02 Jul 2008 14:02:38.0055 (UTC) FILETIME=[4901F770:01C8DC4C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

Yes (to both)
=20
The fact that some people purport to be able to construct a heuristic =
kludge to address a problem is not a reason not to act.
=20
The problem with heuristic kludges is that they tend to be fragile and =
they tend to interact poorly with other systems. Most of all they are a =
barrier to interoperability which is what the standards process is all =
about.

________________________________

From: [e-mail] on behalf of Stephen Kent
Sent: Thu 6/19/2008 1:57 PM
To: [e-mail]
Subject: "other certs" extension straw poll


Folks,

Back in December, Stephen Farrell sent a message to PKIX noting a =
problem that had been identified in the W3C, and proposing a solution in =
the form of a proposed extension. He published an individual I-D at this =
time. There was a little discussion on the list about this proposal in =
January, (a total of about a dozen messages). Stephen made a =
presentation on his proposal at the Phildelphia meeting in March and in =
response to some of the comments he received, Stephen revised his =
proposal to include additional details.  There was agreement at the =
meeting that the discussion should be moved to the list, to determine of =
the work should proceed as a PKIX WG item, and if so, whether it would =
become experimental, standards track, or whatever.

The I-D, which was released at the 02 rev level after the meeting, =
triggered  additional discussion on the list that month, a total of 15 =
messages from a set of 5 individuals (including Stephen). Most of the =
messages in this thread were not supportive of the proposal for various =
reasons, e.g., argument about why one could not use the permanent =
identifier extension, or some other SAN, etc. I raised concerns about =
the lack of details for how an RP would use the data in this extension.

Stephen has asked that we conduct a straw poll on the topic of accepting =
this as a WG item.  I suggest that PKIX members review the current rev =
of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from =
April, and then send a message to this list over the next two weeks.  =
(The straw poll will close on July 4.)

This poll is not deciding whether the I-D in its current form will be =
adopted, but rather whether the I-D addresses a problem that PKIX wants =
to address AND that the document provides a suitable basis to begin =
addressing the problem.

I request that poll responses be of the form:

        YES (to both questions)
        NO (to the first question)
        YES-BUT (yes to the first question, but NO to the second =
question)

Thanks,

Steve




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

<HTML dir=3Dltr><HEAD><TITLE>"other certs" extension straw poll</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<STYLE type=3Dtext/css><!--=0A=
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }=0A=
 --></STYLE>=0A=
=0A=
<META content=3D"MSHTML 6.00.6001.18063" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText26008 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Yes (to =
both)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The fact that some people =
purport to be able to construct a heuristic kludge to address a problem =
is not a reason not to act.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The problem with heuristic =
kludges is that they tend to be fragile and they tend to interact poorly =
with other systems. Most of all they are a barrier to interoperability =
which is what the standards process is all about.</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =
on behalf of Stephen Kent<BR><B>Sent:</B> Thu 6/19/2008 1:57 =
PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> "other certs" =
extension straw poll<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<DIV>Folks,</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Back in December, Stephen Farrell sent a message to PKIX noting a =
problem that had been identified in the W3C, and proposing a solution in =
the form of a proposed extension. He published an individual I-D at this =
time. There was a little discussion on the list about this proposal in =
January, (a total of about a dozen messages). Stephen made a =
presentation on his proposal at the Phildelphia meeting in March and in =
response to some of the comments he received, Stephen revised his =
proposal to include additional details.&nbsp; There was agreement at the =
meeting that the discussion should be moved to the list, to determine of =
the work should proceed as a PKIX WG item, and if so, whether it would =
become experimental, standards track, or whatever.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>The I-D, which was released at the 02 rev level after the meeting, =
triggered&nbsp; additional discussion on the list that month, a total of =
15 messages from a set of 5 individuals (including Stephen). Most of the =
messages in this thread were not supportive of the proposal for various =
reasons, e.g., argument about why one could not use the permanent =
identifier extension, or some other SAN, etc. I raised concerns about =
the lack of details for how an RP would use the data in this =
extension.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Stephen has asked that we conduct a straw poll on the topic of =
accepting this as a WG item.&nbsp; I suggest that PKIX members review =
the current rev of the I-D (<FONT =
color=3D#ff0000>draft-farrell-pkix-other-certs-02.txt)</FONT> and the =
messages from April, and then send a message to this list over the next =
two weeks.&nbsp; (The straw poll will close on July 4.)</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>This poll is not deciding whether the I-D in its current form will =
be adopted, but rather whether the I-D addresses a problem that PKIX =
wants to address AND that the document provides a suitable basis to =
begin addressing the problem.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>I request that poll responses be of the form:</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; YES (to both =
questions)</DIV>=0A=
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO (to the first =
question)</DIV>=0A=
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; YES-BUT (yes to the =
first question, but NO to the second question)</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Thanks,</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Steve</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV><BR></DIV></DIV></BODY></HTML>
------_=_NextPart_001_01C8DC4C.48044B1B--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62CBX9E005364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jul 2008 05:11:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m62CBXUa005363; Wed, 2 Jul 2008 05:11:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m62CBSGo005342 for <[e-mail]>; Wed, 2 Jul 2008 05:11:29 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA103360 for <[e-mail]>; Wed, 2 Jul 2008 14:22:33 +0200
Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008070214111920:7214 ; Wed, 2 Jul 2008 14:11:19 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Wed, 2 Jul 2008 14:11:18 +0200
Message-Id: <[e-mail]>
References: <p06240500c490094a72d9@[128.89.89.71]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 02/07/2008 14:11:19, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 02/07/2008 14:11:27, Serialize complete at 02/07/2008 14:11:27
Content-Type: multipart/alternative;  boundary="----=_NextPart_08070214111799157064155_002"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_NextPart_08070214111799157064155_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Steve,

In response to your question:

Obviously,  I am NOT in favor of it, since it appears that there is no intent to pass major change controls to the WG.
Authors may submit Informational RFCs without the support of the WG.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : denis.pinkas 
Date : 2008-07-01, 21:52:18
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt


..
True. it is invisible to RPs.

Denis: "Greater security invisible to RPs" = no advantage for RPs = no advantage at all.


I disagree. Many claims made by a CA in a CP or CPS may not be externally verifiable by an RP, yet an RP may rely on them.



>If the draft goes along, I would see the place for two schemes:
>
>a) a simpler scheme without the split key and blind signing aspects
>of the design,
>b) a more complex scheme with the split key and blind signing
>aspects of the design.


This I-D is targeted as an informational RFC. As such it is
describing a proposed design for TACs, one that meets the
requirements perceived by the (primary) authors. There is room for a
second informational RFC describing an alternative design, one that
does not rely on slit key signing and (internal use of blind
signatures).

Denis: I guess that it is still up to the WG to decide whether
the PKIX WG would sponsor or not this draft.


You're right. I did give permission to post this as a PKIX document, targeted as an Informational RFC, before getting a sense of the WG on this.


So, let me ask now if there are objections to having PKIX adopt this as a document. Obviously I am in favor of it, else I would not have signed up as a co-author.


Steve

------=_NextPart_08070214111799157064155_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<STYLE type=text/css><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></STYLE>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>Steve,</DIV>
<DIV>&nbsp;</DIV>
<DIV>In response to your question:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Obviously, &nbsp;I am NOT in favor of it, since it appears that there is no 
intent to pass major change controls to the WG.</DIV>
<DIV>Authors may&nbsp;submit Informational RFCs without the support of the 
WG.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<DIV>----- Message reçu ----- </DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[e-mail]">owner-ietf-pkix</A> 
</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[e-mail]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-01, 21:52:18</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <BLOCKQUOTE cite="" type="cite">
    <BLOCKQUOTE>...<BR>True. it is invisible to RPs.</BLOCKQUOTE>
    <BLOCKQUOTE>&nbsp;</BLOCKQUOTE>
    <BLOCKQUOTE><B>Denis: "Greater security invisible to RPs" = no advantage 
      for RPs = no advantage at all.</B></BLOCKQUOTE></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>I disagree. Many claims made by a CA in a CP or CPS may not be externally 
  verifiable by an RP, yet an RP may rely on them.</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite="" type="cite">
    <BLOCKQUOTE><BR>&gt;If the draft goes along, I would see the place for two 
      schemes:<BR>&gt;<BR>&gt;a) a simpler scheme without the split key and 
      blind signing aspects<BR>&gt;of the design,<BR>&gt;b) a more complex 
      scheme with the split key and blind signing<BR>&gt;aspects of the 
      design.<BR><BR><BR>This I-D is targeted as an informational RFC. As such 
      it is<BR>describing a proposed design for TACs, one that meets 
      the<BR>requirements perceived by the (primary) authors. There is room for 
      a<BR>second informational RFC describing an alternative design, one 
      that<BR>does not rely on slit key signing and (internal use of 
      blind<BR>signatures).<BR></BLOCKQUOTE>
    <BLOCKQUOTE><B>Denis: I guess that it&nbsp;is still up to the WG to decide 
      whether</B></BLOCKQUOTE>
    <BLOCKQUOTE><B>the PKIX WG would sponsor or not this 
  draft.</B></BLOCKQUOTE></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>You're right. I did give permission to post this as a PKIX document, 
  targeted as an Informational RFC, before getting a sense of the WG on 
  this.</DIV>
  <DIV><BR></DIV>
  <DIV>So, let me ask now if there are objections to having PKIX adopt this as a 
  document. Obviously I am in favor of it, else I would not have signed up as a 
  co-author.</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070214111799157064155_002--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61Jpkox023921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 12:51:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61Jpk17023920; Tue, 1 Jul 2008 12:51:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61Jpjr7023912 for <[e-mail]>; Tue, 1 Jul 2008 12:51:45 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KDlt9-0000A7-50; Tue, 01 Jul 2008 15:51:43 -0400
Mime-Version: 1.0
Message-Id: <p06240500c490094a72d9@[128.89.89.71]>
In-Reply-To: <[e-mail]>
References: <p06240516c48fe8089793@[128.89.89.71]> <[e-mail]>
Date: Tue, 1 Jul 2008 15:52:18 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[e-mail]>
Content-Type: multipart/alternative; boundary="============_-997180555==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-997180555==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>...
>True. it is invisible to RPs.
>
>Denis: "Greater security invisible to RPs" = no advantage for RPs = 
>no advantage at all.

I disagree. Many claims made by a CA in a CP or CPS may not be 
externally verifiable by an RP, yet an RP may rely on them.

>
>>If the draft goes along, I would see the place for two schemes:
>>
>>a) a simpler scheme without the split key and blind signing aspects
>>of the design,
>>b) a more complex scheme with the split key and blind signing
>>aspects of the design.
>
>
>This I-D is targeted as an informational RFC. As such it is
>describing a proposed design for TACs, one that meets the
>requirements perceived by the (primary) authors. There is room for a
>second informational RFC describing an alternative design, one that
>does not rely on slit key signing and (internal use of blind
>signatures).
>
>Denis: I guess that it is still up to the WG to decide whether
>the PKIX WG would sponsor or not this draft.

You're right. I did give permission to post this as a PKIX document, 
targeted as an Informational RFC, before getting a sense of the WG on 
this.

So, let me ask now if there are objections to having PKIX adopt this 
as a document. Obviously I am in favor of it, else I would not have 
signed up as a co-author.

Steve
--============_-997180555==_ma============
Content-Type: text/html; charset="us-ascii"

<!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: Comments on
draft-ietf-pkix-tac-00.txt</title></head><body>
<blockquote type="cite" cite>
<blockquote>...<br>
True. it is invisible to RPs.</blockquote>
<blockquote>&nbsp;</blockquote>
<blockquote><b>Denis: &quot;Greater security invisible to RPs&quot; =
no advantage for RPs = no advantage at all.</b></blockquote>
</blockquote>
<div><br></div>
<div>I disagree. Many claims made by a CA in a CP or CPS may not be
externally verifiable by an RP, yet an RP may rely on them.</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote><br>
&gt;If the draft goes along, I would see the place for two
schemes:<br>
&gt;<br>
&gt;a) a simpler scheme without the split key and blind signing
aspects<br>
&gt;of the design,<br>
&gt;b) a more complex scheme with the split key and blind signing<br>
&gt;aspects of the design.<br>
<br>
<br>
This I-D is targeted as an informational RFC. As such it is<br>
describing a proposed design for TACs, one that meets the<br>
requirements perceived by the (primary) authors. There is room for
a<br>
second informational RFC describing an alternative design, one
that<br>
does not rely on slit key signing and (internal use of blind<br>
signatures).<br>
</blockquote>
<blockquote><b>Denis: I guess that it&nbsp;is still up to the WG to
decide whether</b></blockquote>
<blockquote><b>the PKIX WG would sponsor or not this
draft.</b></blockquote>
</blockquote>
<div><br></div>
<div>You're right. I did give permission to post this as a PKIX
document, targeted as an Informational RFC, before getting a sense of
the WG on this.</div>
<div><br></div>
<div>So, let me ask now if there are objections to having PKIX adopt
this as a document. Obviously I am in favor of it, else I would not
have signed up as a co-author.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-997180555==_ma============--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61JKLca021333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 12:20:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61JKLiK021332; Tue, 1 Jul 2008 12:20:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m61JKJ8k021325 for <[e-mail]>; Tue, 1 Jul 2008 12:20:20 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21587 invoked from network); 1 Jul 2008 19:09:33 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;01 Jul 2008 19:09:33 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 1 Jul 2008 19:09:33 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Name constraint question
Date: Tue, 1 Jul 2008 15:20:18 -0400
Message-ID: <[e-mail]>
In-Reply-To: <6qpc2d$[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Name constraint question
Thread-Index: Acjbrz0YT0YoQ+YKTq2sVnCdp0RnpgAACukg
References: <[e-mail]> <p06240502c4900a0b9ff6@[128.89.89.71]> <6qpc2d$[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Tony Bartoletti" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Does anyone see similar pitfalls in DN (Geopolitical or dc component
based) based names?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Tony Bartoletti
Sent: Tuesday, July 01, 2008 3:06 PM
To: [e-mail]
Subject: Re: Name constraint question



This thread is taking on a delightful "Alice Through the Looking=20
Glass" quality...

I am reminded of a phrase my uncle would sometimes employ:

   "LOOK!" said the blind man, to his deaf son,
    as they walked off the edge of the cliff...

____tony____



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61J5nZp019736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 12:05:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61J5n1j019735; Tue, 1 Jul 2008 12:05:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nspiron-2.llnl.gov (nspiron-2.llnl.gov [128.115.41.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61J5lfI019728 for <[e-mail]>; Tue, 1 Jul 2008 12:05:48 -0700 (MST) (envelope-from [e-mail])
Message-Id: <6qpc2d$[e-mail]>
X-Attachments: None
X-IronPort-AV: E=McAfee;i="5200,2160,5329"; a="20632993"
X-IronPort-AV: E=Sophos;i="4.27,732,1204531200";  d="scan'208";a="20632993"
Received: from congobongo.llnl.gov ([134.9.94.22]) by nspiron-2.llnl.gov with ESMTP; 01 Jul 2008 12:05:47 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 01 Jul 2008 12:05:47 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Name constraint question
In-Reply-To: <p06240502c4900a0b9ff6@[128.89.89.71]>
References: <[e-mail]> <p06240502c4900a0b9ff6@[128.89.89.71]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This thread is taking on a delightful "Alice Through the Looking 
Glass" quality...

I am reminded of a phrase my uncle would sometimes employ:

   "LOOK!" said the blind man, to his deaf son,
    as they walked off the edge of the cliff...

____tony____



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HneW1099692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 10:49:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61Hnexo099690; Tue, 1 Jul 2008 10:49:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61HndHb099673 for <[e-mail]>; Tue, 1 Jul 2008 10:49:40 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KDjz0-0007HO-4O; Tue, 01 Jul 2008 13:49:38 -0400
Mime-Version: 1.0
Message-Id: <p06240502c4900a0b9ff6@[128.89.89.71]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 1 Jul 2008 12:22:50 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Name constraint question
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:07 AM +1200 7/2/08, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>Name constraints checking does not imply any form of external validation on
>>the "validity" of the name, for any type of name. The purpose of the
>>extension is to constrain the range of names asserted in subordinate certs,
>>not to ensure that the names are "valid" in some larger context. It could be
>>very difficult to establish validity for many types of names.  For example,
>>if a DNS name does not resolve for me, does that make it invalid?  Is it more
>>valid if resolved using DNESEC vs. vanilla DNS? What if the IP address
>>returned is not reachable, at the time I check it, ...?
>
>But the checking rules require parsing URIs in order to apply the checks.
>Here's an example of a malformed URI being used to avoid name constraints:
>
>CA cert: excluded subtree, example.com
>Subject cert, altName: ftp:/example.com
>
>(non-matched as "ftp:/example.com", processed as FTP -> "example.com").  If
>it's OK to have syntactically invalid URIs then this (and a million variants)
>can be used to escape excluded subtrees, thus making them essentially useless
>(actually you can already do that with character-set encoding tricks and
>whatnot so excluded subtrees have always been a no-hoper for security
>purposes, I'll bet no implementation in existance can catch even the most
>basic trick like using "ex%41mple.com", let alone "ex%u0041mple.com",
>"ex&#x41;mple.com", or "ex%EF%BC%A1mpple.com").
>
>Maybe the RFC should simply deprecate excluded subtrees to avoid giving RPs
>the erroneous impression that they're effective for anything.
>
>Peter.

Peter,

Sorry that I misunderstood your use of the term "valid" here. I agree 
with you that any name form that is used in the name constraints 
extension MUST be syntactically valid.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61F7MfY058786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 08:07:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61F7MHD058785; Tue, 1 Jul 2008 08:07:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61F7JGn058768 for <[e-mail]>; Tue, 1 Jul 2008 08:07:19 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A4C3D1850C; Wed,  2 Jul 2008 03:07:18 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKtajlm8DE9I; Wed,  2 Jul 2008 03:07:18 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3357018508; Wed,  2 Jul 2008 03:07:18 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E9DCF19EC0BB; Wed,  2 Jul 2008 03:07:15 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1KDhRr-0001g6-Gy; Wed, 02 Jul 2008 03:07:15 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Name constraint question
Cc: [e-mail]
In-Reply-To: <p0624051ac48febda7cc8@[128.89.89.71]>
Message-Id: <[e-mail]>
Date: Wed, 02 Jul 2008 03:07:15 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>Name constraints checking does not imply any form of external validation on
>the "validity" of the name, for any type of name. The purpose of the
>extension is to constrain the range of names asserted in subordinate certs,
>not to ensure that the names are "valid" in some larger context. It could be
>very difficult to establish validity for many types of names.  For example,
>if a DNS name does not resolve for me, does that make it invalid?  Is it more
>valid if resolved using DNESEC vs. vanilla DNS? What if the IP address
>returned is not reachable, at the time I check it, ...?

But the checking rules require parsing URIs in order to apply the checks.
Here's an example of a malformed URI being used to avoid name constraints:

CA cert: excluded subtree, example.com
Subject cert, altName: ftp:/example.com

(non-matched as "ftp:/example.com", processed as FTP -> "example.com").  If
it's OK to have syntactically invalid URIs then this (and a million variants)
can be used to escape excluded subtrees, thus making them essentially useless
(actually you can already do that with character-set encoding tricks and
whatnot so excluded subtrees have always been a no-hoper for security
purposes, I'll bet no implementation in existance can catch even the most
basic trick like using "ex%41mple.com", let alone "ex%u0041mple.com",
"ex&#x41;mple.com", or "ex%EF%BC%A1mpple.com").

Maybe the RFC should simply deprecate excluded subtrees to avoid giving RPs
the erroneous impression that they're effective for anything.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61Eixmb056384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 07:44:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61EixAg056383; Tue, 1 Jul 2008 07:44:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61EivHb056374 for <[e-mail]>; Tue, 1 Jul 2008 07:44:58 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA26264 for <[e-mail]>; Tue, 1 Jul 2008 16:56:01 +0200
Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008070116440109:8687 ; Tue, 1 Jul 2008 16:44:01 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Tue, 1 Jul 2008 16:44:00 +0200
Message-Id: <[e-mail]>
References: <p06240516c48fe8089793@[128.89.89.71]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 01/07/2008 16:44:01, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 01/07/2008 16:44:57, Serialize complete at 01/07/2008 16:44:57
Content-Type: multipart/alternative;  boundary="----=_NextPart_08070116435996456817355_002"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_NextPart_08070116435996456817355_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Comments in line.
----- Message reçu ----- 
De : Stephen Kent 
À : denis.pinkas 
Date : 2008-07-01, 16:01:34
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt


At 12:02 PM +0200 7/1/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m61A2c5J025564
>
>Steve,
>
>It looks like the main motivation is to (finally) find an 
>application for the split key and blind signing mechanism.
>:-)
>The crypto security should be not the central point.

I think it's fair to say that these crypto security mechanisms (split 
key signing and blind signatures) offer greater security than what is 
available from relying only on procedural security promises.

> There is no way proposed in the draft so that a RP can know that 
>the split key and blind signing aspects occurred or not.

True. it is invisible to RPs.

Denis: "Greater security invisible to RPs" = no advantage for RPs = no advantage at all.

>If the draft goes along, I would see the place for two schemes:
>
>a) a simpler scheme without the split key and blind signing aspects 
>of the design,
>b) a more complex scheme with the split key and blind signing 
>aspects of the design.


This I-D is targeted as an informational RFC. As such it is 
describing a proposed design for TACs, one that meets the 
requirements perceived by the (primary) authors. There is room for a 
second informational RFC describing an alternative design, one that 
does not rely on slit key signing and (internal use of blind 
signatures).

Denis: I guess that it is still up to the WG to decide whether 
the PKIX WG would sponsor or not this draft.

Steve

------=_NextPart_08070116435996456817355_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>Comments in line.</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal">----- 
  Message reçu ----- </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[e-mail]">Stephen Kent</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[e-mail]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-01, 16:01:34</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>At 12:02 PM +0200 7/1/08, Denis Pinkas wrote:<BR>&gt;Content-Type: 
  text/html<BR>&gt;X-MIME-Autoconverted: from 8bit to quoted-printable by 
  <BR>&gt;balder-227.proper.com id 
  m61A2c5J025564<BR>&gt;<BR>&gt;Steve,<BR>&gt;<BR>&gt;It looks like the main 
  motivation is to (finally) find an <BR>&gt;application for the split key and 
  blind signing mechanism.<BR>&gt;:-)<BR>&gt;The crypto security should be not 
  the central point.<BR><BR>I think it's fair to say that these crypto security 
  mechanisms (split <BR>key signing and blind signatures) offer greater security 
  than what is <BR>available from relying only on procedural security 
  promises.<BR><BR>&gt; There is no way proposed in the draft so that a RP can 
  know that <BR>&gt;the split key and blind signing aspects occurred or 
  not.<BR><BR>True. it is invisible to RPs.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><STRONG>Denis: "Greater security invisible to RPs" = no advantage for RPs 
  = no advantage at all.</STRONG></DIV>
  <DIV><BR>&gt;If the draft goes along, I would see the place for two 
  schemes:<BR>&gt;<BR>&gt;a) a simpler scheme without the split key and blind 
  signing aspects <BR>&gt;of the design,<BR>&gt;b) a more complex scheme with 
  the split key and blind signing <BR>&gt;aspects of the design.<BR><BR><BR>This 
  I-D is targeted as an informational RFC. As such it is <BR>describing a 
  proposed design for TACs, one that meets the <BR>requirements perceived by the 
  (primary) authors. There is room for a <BR>second informational RFC describing 
  an alternative design, one that <BR>does not rely on slit key signing and 
  (internal use of blind <BR>signatures).<BR></DIV>
  <DIV><STRONG>Denis: I guess that it&nbsp;is still up to the WG to decide 
  whether <BR>the PKIX WG would sponsor or not this draft.</STRONG></DIV>
  <DIV><BR>Steve<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070116435996456817355_002--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61ER7Bg054948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 07:27:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61ER7Bc054947; Tue, 1 Jul 2008 07:27:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61ER6ii054940 for <[e-mail]>; Tue, 1 Jul 2008 07:27:06 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KDgoz-0003xY-4G; Tue, 01 Jul 2008 10:27:05 -0400
Mime-Version: 1.0
Message-Id: <p0624051ac48febda7cc8@[128.89.89.71]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 1 Jul 2008 10:19:05 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Name constraint question
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:21 PM +1200 7/1/08, Peter Gutmann wrote:
>Here's one: Say an issuing cert contains a name constraint for (just for
>argument's sake) a URI, and the subject cert contais a URI.  The issuer cert's
>URI is invalid.  Alternatively, the subject cert's URI is invalid.
>
>What should happen?  Is the output for the check true or false?
>
>NB: Just because a URI is malformed doesn't mean that the relying party
>software won't accept it, there's so much broken stuff out there that much web
>software bends over backwards to interpret almost anything URI-like.  So
>saying "the RP should reject it" won't work, the cert processing software has
>to make the decision.
>
>Peter.

Peter,

Name constraints checking does not imply any form of external 
validation on the "validity" of the name, for any type of name. The 
purpose of the extension  is to constrain the range of names asserted 
in subordinate certs, not to ensure that the names are "valid" in 
some larger context. It could be very difficult to establish validity 
for many types of names.  For example, if a DNS name does not resolve 
for me, does that make it invalid?  Is it more valid if resolved 
using DNESEC vs. vanilla DNS? What if the IP address returned is not 
reachable, at the time I check it, ...?

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61ER5es054937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 07:27:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61ER5Ix054936; Tue, 1 Jul 2008 07:27:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61ER3J8054927 for <[e-mail]>; Tue, 1 Jul 2008 07:27:04 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KDgow-0003xY-4F; Tue, 01 Jul 2008 10:27:02 -0400
Mime-Version: 1.0
Message-Id: <p06240516c48fe8089793@[128.89.89.71]>
In-Reply-To: <[e-mail]>
References: <p0624050bc48ec264c520@[128.89.89.71]> <[e-mail]>
Date: Tue, 1 Jul 2008 10:01:34 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:02 PM +0200 7/1/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m61A2c5J025564
>
>Steve,
>
>It looks like the main motivation is to (finally) find an 
>application for the split key and blind signing mechanism.
>:-)
>The crypto security should be not the central point.

I think it's fair to say that these crypto security mechanisms (split 
key signing and blind signatures) offer greater security than what is 
available from relying only on procedural security promises.

>  There is no way proposed in the draft so that a RP can know that 
>the split key and blind signing aspects occurred or not.

True. it is invisible to RPs.

>If the draft goes along, I would see the place for two schemes:
>
>a) a simpler scheme without the split key and blind signing aspects 
>of the design,
>b) a more complex scheme with the split key and blind signing 
>aspects of the design.
>

This I-D is targeted as an informational RFC.  As such it is 
describing a proposed design for TACs, one that meets the 
requirements perceived by the (primary) authors. There is room for a 
second informational RFC describing an alternative design, one that 
does not rely on slit key signing and (internal use of blind 
signatures).

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61BLJcT036099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 04:21:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61BLJqR036098; Tue, 1 Jul 2008 04:21:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61BLHmJ036090 for <[e-mail]>; Tue, 1 Jul 2008 04:21:18 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 017A79C2EF for <[e-mail]>; Tue,  1 Jul 2008 23:21:17 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+kLxqcdDpLp for <[e-mail]>; Tue,  1 Jul 2008 23:21:16 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DC5989C240 for <[e-mail]>; Tue,  1 Jul 2008 23:21:16 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2D61319EC0BA for <[e-mail]>; Tue,  1 Jul 2008 23:21:15 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1KDdv9-0007rM-2O for [e-mail]; Tue, 01 Jul 2008 23:21:15 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Name constraint question
Message-Id: <[e-mail]>
Date: Tue, 01 Jul 2008 23:21:15 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here's one: Say an issuing cert contains a name constraint for (just for
argument's sake) a URI, and the subject cert contais a URI.  The issuer cert's
URI is invalid.  Alternatively, the subject cert's URI is invalid.

What should happen?  Is the output for the check true or false?

NB: Just because a URI is malformed doesn't mean that the relying party
software won't accept it, there's so much broken stuff out there that much web
software bends over backwards to interpret almost anything URI-like.  So
saying "the RP should reject it" won't work, the cert processing software has
to make the decision.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61A2c5J025564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 03:02:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m61A2cnt025563; Tue, 1 Jul 2008 03:02:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m61A2aYp025555 for <[e-mail]>; Tue, 1 Jul 2008 03:02:37 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA65692 for <[e-mail]>; Tue, 1 Jul 2008 12:13:40 +0200
Received: from FRMYA-SIA24 ([129.182.109.136]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008070112022538:7591 ; Tue, 1 Jul 2008 12:02:25 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Tue, 1 Jul 2008 12:02:25 +0200
Message-Id: <[e-mail]>
References: <p0624050bc48ec264c520@[128.89.89.71]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 01/07/2008 12:02:25, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 01/07/2008 12:02:35, Serialize complete at 01/07/2008 12:02:35
Content-Type: multipart/alternative;  boundary="----=_NextPart_08070112021622587804571_002"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_NextPart_08070112021622587804571_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Steve,

It looks like the main motivation is to (finally) find an application for the split key and blind signing mechanism. 
:-)
The crypto security should be not the central point. 

There is no way proposed in the draft so that a RP can know that the split key and blind signing aspects occurred or not.

If the draft goes along, I would see the place for two schemes:

a) a simpler scheme without the split key and blind signing aspects of the design, 
b) a more complex scheme with the split key and blind signing aspects of the design.

Scheme a) is simpler to implement. 

In any case, the RP should be able to know which scheme was used, keeping in mind the limitation: 
the CA could lie in any case.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : denis.pinkas 
Date : 2008-06-30, 19:43:58
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt


Denis,
..
Denis :  in the above exchanges, the RA does not know the pseudonym. The mapping is only done using the UserKey.
The threshold signature and blind signature elements are not fundamental.
Sorry that I misread your text, inferring that the RA supplied the pseudonym. Although my comment about the source of the pseudonym wa wrong, it doesn't change my conclusion (see below).


The next part of your proposed redesign is as follows:


If the UserKey is not in the cache of the CA, the request is rejected.
If the pseudonym is not unique, the request is rejected and the CA proposes a different pseudonym.
In that case, the entity makes a second request with the same UserKey. Otherwise the CA contacts the RA
to make sure that the registration information kept by the RA will not be deleted, generates the PKC
and sends it back to the entity.


In that case, the CA maintains a database which contains:


- the UserKey chosen by the RA,
- the PKC issued to the entity.


In the design you propose, the CA issued the cert to the user by itself (from a crypto perspective), which undermines the two-party issuance model in the I-D. The split signing key procedure described in the I-D requires that the RA also sign the hash of the cert, which prevents the CA from acting unilaterally (which would yield a non-traceable cert). Having both the CA and RA sign the cert yields a stronger system, and the blind signature by the CA is needed to enable the split key signing without disclosing the hash value to the RA.


So, unless one wants to weaken the guarantees provided by the two-party signing, I think the split key and blind signing aspects of the design need to be retained.  Also, as I noted earlier given the split key and blind signature aspects of the design in the I-D, the terms AI and BI are appropriate.


I agree that if one did not want to have the crypto security offered by the split key approach (which then necessitates the blind signature function), the design here could be simplified. But, my co-authors see this form of crypto security as a central, motivating aspect of the design, so I believe it should remain.  Thanks, though, for your suggestions re inclusion of a time stamp in the Token and the timeout notion to help with garbage collection.


Steve

------=_NextPart_08070112021622587804571_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<STYLE type=text/css><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></STYLE>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>Steve,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It looks like the main motivation is to&nbsp;(finally) find an application 
for the split key and blind signing mechanism. </DIV>
<DIV>:-)</DIV>
<DIV>The crypto security should be&nbsp;not the central point. </DIV>
<DIV>&nbsp;</DIV>
<DIV>There is no way proposed in the draft so that a RP can know that the split 
key and blind signing aspects occurred or not.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If the draft goes along, I would see the place for two schemes:</DIV>
<DIV>&nbsp;</DIV>
<DIV>a) a simpler scheme without the split key and blind signing aspects of the 
design, </DIV>
<DIV>b) a more complex scheme with the split key and blind signing aspects of 
the design.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Scheme a) is simpler to implement.&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>In any case, the RP should be able to know which scheme was used, keeping 
in mind the limitation:&nbsp;<BR>the CA could lie in any case.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis<BR></DIV>
<DIV>----- Message reçu ----- </DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[e-mail]">owner-ietf-pkix</A> 
</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[e-mail]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-06-30, 19:43:58</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>Denis,</DIV>
  <DIV>...</DIV>
  <BLOCKQUOTE cite="" type="cite">
    <BLOCKQUOTE><B>Denis&nbsp;: &nbsp;in the above&nbsp;exchanges, the RA does 
      not know the pseudonym. The mapping is only done using the UserKey.<BR>The 
      threshold signature and blind signature elements are not 
    fundamental.</B></BLOCKQUOTE></BLOCKQUOTE>
  <DIV>Sorry that I misread your text, inferring that the RA supplied the 
  pseudonym. Although my comment about the source of the pseudonym wa wrong, it 
  doesn't change my conclusion (see below).</DIV>
  <DIV><BR></DIV>
  <DIV>The next part of your proposed redesign is as follows:</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite="" type="cite">If the UserKey is not in the cache of the 
    CA, the request is rejected.</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">If the pseudonym is not unique, the request 
    is rejected and the CA proposes a different pseudonym.</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">In that case, the entity makes a second 
    request with the same UserKey. Otherwise the CA contacts the RA</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">to make sure that the registration 
    information kept by the RA will not be deleted, generates the PKC</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">and sends it back to the entity.</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite"><BR></BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">In that case, the CA maintains a database 
    which contains:</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite"><BR></BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">- the UserKey chosen by the RA,</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">- the PKC issued to the entity.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>In the design you propose, the CA issued the cert to the user by itself 
  (from a crypto perspective), which undermines the two-party issuance model in 
  the I-D. The split signing key procedure described in the I-D requires that 
  the RA also sign the hash of the cert, which prevents the CA from acting 
  unilaterally (which would yield a non-traceable cert). Having both the CA and 
  RA sign the cert yields a stronger system, and the blind signature by the CA 
  is needed to enable the split key signing without disclosing the hash value to 
  the RA.</DIV>
  <DIV><BR></DIV>
  <DIV>So, unless one wants to weaken the guarantees provided by the two-party 
  signing, I think the split key and blind signing aspects of the design need to 
  be retained.&nbsp; Also, as I noted earlier given the split key and blind 
  signature aspects of the design in the I-D, the terms AI and BI are 
  appropriate.</DIV>
  <DIV><BR></DIV>
  <DIV>I agree that if one did not want to have the crypto security offered by 
  the split key approach (which then necessitates the blind signature function), 
  the design here could be simplified. But, my co-authors see this form of 
  crypto security as a central, motivating aspect of the design, so I believe it 
  should remain.&nbsp; Thanks, though, for your suggestions re inclusion of a 
  time stamp in the Token and the timeout notion to help with garbage 
  collection.</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070112021622587804571_002--