Subject: ���������A���������A�u���u���������g�I�������n�����D���������I

From: <[email-masked]>

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

���T�C�g��40��`50��̓��̊֌W�����߂Ă���l�ȁE�n��

���W�܂���{�ő�̓��̊֌W�R�~���j�e�B�[�T�C�g�ł��B

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

�s�����p�Ɋւ��Ă̂����Ӂt-------------------------------

�T�@�����p�͒j������40�Έȏ�̕��݂̂Ƃ����Ē����܂��B

�U�@�j�����ɂ�����ɗv�����鎖�͓��̊֌W�݂̂ł��B

�V�@�z�e����Ɋւ��Ă͂��݂��Ō��߂ĉ������B

�s�����p���@�ɂ��āt-----------------------------------

�T�@����]�̒n��E���[���A�h���X�E�p�X���[�h��ݒ肵�Ē����܂��B

�U�@���ɊȒP�Ȏ���PR��ݒ肵�Ē����܂��B

�V�@���̊֌W����]���邨������������Ē����܂��B

�W�@�����p����Ă���l�ȁE�n������͑S�Ď���PR���Ɍg�єԍ�����

�@�@���A�h���X���\������Ă���܂��̂ł��̎��_�Œ��ڂ��A����

�@�@���Ē����Ă����\�ł����A�T�C�g�����烁�[���ɂĘA�������

�@�@�����\�ł��̂ł��D���ȘA�����@�Ō����ĉ������B

�y���Ӂz����PR���ɘA����̕\���������l�ȁE�n�������

�@�@�@�@�������������̊֌W���ł��̂ŘA����̕\����

�@�@�@�@������A�ēx�������肢�v���܂��B

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

���{���A�n�ꂽ�l�ȁE�n���Ɠ��̊֌W����]�����40�Έȏ�̒j����

�@http://cjbjj.com:112/ddd/40-navi-sp/

���{���A�ΏƂ����̂𖞂����ė~����40�Έȏ�̏�����

�@http://cjbjj.com:112/ddd/40-navi-sp/

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

���ҍ��킹�̏ꏊ�����A���^�C���ł����m�F���ꂽ������

�@���o�C���i�g�ѓd�b�j�ł̐ݒ���I�X�X���v���܂��B

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

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: netscape-cert-renewal-url & beyond
Date: Sat, 31 Mar 2007 08:32:21 +0200
Sender: [email-masked]

Although the "netscape-cert-renewal-url" certificate extension does
not appear to be incorporated in any PKIX RFC, it is anyway
documented in vendor specs like:
http://msdn2.microsoft.com/en-us/library/aa378149.aspx

I have two open questions regarding this particular extension:

1. Is it supported by any PKI-clients and if so which ones?

2. If it is not already supported on major scale wouldn't it be
worthwhile supporting such a facility?  My personal experience
with certificates (I have had numerous), is that they tend to silently
expire, leaving you high and dry and concluding that "passwords are
better".   When you have to "renew" from scratch you are thrown
into laborious processes which can take weeks to perform.

If you have certificate and key in a connected device
like a web-server or mobile phone, you could very well
create something like we already have with Windows update,
JRE update, Adobe update, where the user in some instances
only would have to issue a PIN in order to get a credential
update.   For commercial certificates the process would be
slightly more complex but of course an auto-renewal-process
must support this use-case as well.

I do not propose making the Netscape extension a PKIX
standard but rather start discussing the road to a better
support of credential life-cycles.

Comments?

Anders Rundgren

From: "usMake links" <[email-masked]>
To: [email-masked]
Subject: enough just
Date: 	Fri, 30 Mar 2007 17:20:13 +0200

------=_NextPart_000_0008_01C772EF.AD40E510
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C772EF.AD40E510"

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

For as it refers computer software see. Required chemical reaction =
occur, phrase energy reactants. Have enough just from thermal, =
naturally, ie lots reactions.
Analyze elements usually metals sample placed high. And may have enough =
just.
Create usmake, links linkcite articlein was last, modified january?
Component, various, references discussion, edit, page toolssign, create =
usmake.
Ie lots reactions dont, heated neutron, standard, analytical? Can react =
with each, other.
This monitored element emitting identified, identity emitted particles, =
prompt.

------=_NextPart_001_0009_01C772EF.AD40E510
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.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><A HREF=3Dhttp://zxiak.hk/><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000701c772de$e9b81510$ea9e2c97@nomebe7744ded5" align=3Dcenter =

border=3D0></A></DIV>
<DIV><FONT face=3DArial size=3D2>For as it refers computer software see. =
Required=20
chemical reaction occur, phrase energy reactants. Have enough just from =
thermal,=20
naturally, ie lots reactions.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Analyze elements usually metals sample =
placed high.=20
And may have enough just.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Create usmake, links linkcite articlein =
was last,=20
modified january?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Component, various, references =
discussion, edit,=20
page toolssign, create usmake.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ie lots reactions dont, heated neutron, =
standard,=20
analytical? Can react with each, other.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>This monitored element emitting =
identified,=20
identity emitted particles, prompt.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_0009_01C772EF.AD40E510--

------=_NextPart_000_0008_01C772EF.AD40E510
Content-Type: image/gif;
	name="produce.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c772de$e9b81510$ea9e2c97@nomebe7744ded5>

------=_NextPart_000_0008_01C772EF.AD40E510--

Content-class: urn:content-classes:message
Subject: RE: Update request for RFC3279 and 4055
Date: Thu, 29 Mar 2007 03:43:12 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Because of the blanket statement about the security of the hash
algorithm.  It does matter that it be something akin to SHA1

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2007 9:24 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Update request for RFC3279 and 4055

At 2:27 PM -0700 3/28/07, Santosh Chokhani wrote:
>I am concerned about the following statement: "As with the 
>fingerprint/thumbprint displayed by certificate viewers, the use of 
>a weak hash algorithm does not create any problems, security or 
>otherwise".
>
>Some PKIs find it acceptable to obtain a trust anchor using unsecure 
>means and verify that the fingerprint of the trust anchor matches 
>the fingerprint obtained via secure means.  For these users, hashing 
>algorithm used for fingerprint does become security relevant.
>
>(Granted that from what experts say, SHA-1 is not in an imminent 
>danger of pre-image attack.  Pre-image attack is required in order 
>to exploit the trust anchor substitution in the above scenario)

This is confusing. If a pre-image attack is required in order to 
exploit the trust anchor substitution, why are you concerned about 
the statement?

--Paul Hoffman, Director
--VPN Consortium

Content-Class: urn:content-classes:message
Subject: RE: Update request for RFC3279 and 4055
Date: Thu, 29 Mar 2007 11:25:13 +0200
From: "Rajesh Lachman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

plain-text

Rajesh

_______________________________________________
Ir. R. Lachman
Adviseur PKIoverheid 
GBO.Overheid
Afdeling Beheer
Wilhelmina van Pruisenweg 104
Postbus 84011           
2508 AA Den Haag 
Tel: +31(0) 70 8887 950
Fax:+31(0) 70 8887 882
mailto: [email-masked]
Internet: www.gbo.overheid.nl  

-----Oorspronkelijk bericht-----
Van: Paul Hoffman [mailto:[email-masked]]
Verzonden: woensdag 28 maart 2007 19:43
Aan: Rajesh Lachman; [email-masked]
CC: [email-masked]
Onderwerp: Re: Update request for RFC3279 and 4055

At 3:34 PM +0200 3/28/07, Rajesh Lachman wrote:
>smime 1.p7m

Please send plain-text messages to the WG mailing list. This message 
is not readable by many people.

--Paul Hoffman, Director
--VPN Consortium

-----------

Dear, 

Introduction 

The Dutch governmental PKI (hereafter PKIoverheid) is the name for the Public Key Infrastructure designed for trustworthy electronic communication within and with the Dutch government. PKIoverheid does not issue certificates directly to end-users, but only issues certificates to so-called Certificate Service Providers (CSP). The Ministry of the Interior and Kingdom Relations is the owner of PKIoverheid. The Policy Authority PKIoverheid supports the Dutch Minister of the Interior and Kingdom Relations with the management and control of the PKI system.

Problem identification 
In 2005 crypto experts found weaknesses in the hash function SHA-1, and since then NIST (creator of SHA-1) has made the recommendation that SHA-1 should only be used until 2010. However, it's probably a good idea to start implementing a better hashing algorithm before a more serious vulnerability is found.

PKIoverheid wants to migrate its root infrastructure to SHA-256 based certificates. However, PKIoverheid discovered that these certificates can not be completely based on SHA-2 with current software conforming to RFC 3279 and RFC 4055. When creating a certificate based on SHA-2, then the thumbprint/fingerprint will still be SHA-1.

Proposed solution 
In "RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure April 2002, [Page 3]" 
Current text:
"This section identifies one-way hash functions for use in the Internet X.509 PKI. One-way hash functions are also called message digest algorithms. SHA-1 is the preferred one-way hash function for the Internet X.509 PKI. "

Replace with:
"This section identifies one-way hash functions for use in the Internet X.509 PKI. One-way hash functions are also called message digest algorithms. Hash functions from the SHA-family (SHA-1 or SHA-2) are preferred for one-way hash functions for the Internet X.509 PKI. 

When using one of these RSA signature algorithms, the same one-way hash function MUST be employed for the hashAlgorithm and the maskGenAlgorithm."

In "RFC 4055 Additional RSA Algorithms and Identifiers June 2005, [Page 23/24]" 

Current text:
"When using RSASSA-PSS, the same one-way hash function should be employed for the hashAlgorithm and the maskGenAlgorithm, but it is not required. When using RSAES-OAEP, the same one-way hash function should be employed for the hashFunc and the maskGenFunc, but it is not required. In each case, using the same one-way hash function helps with security analysis and reduces implementation complexity." 

Replace with:
"When using RSASSA-PSS, the same one-way hash function MUST be employed for the hashAlgorithm and the maskGenAlgorithm. When using RSAES-OAEP, the same one-way hash function MUST be employed for the hashFunc and the maskGenFunc. In each case, using the same one-way hash function helps with security analysis and reduces implementation complexity." 

Result:
When using the SHA-2 Signature algorithm within an X.509 certificate it is now required to use the same algorithm for the one-way hash function, thus resulting in a certificate with a message digest (thumbprint/fingerprint) algorithm field with the value "sha2".

Greetings, 

Rajesh 

_______________________________________________ 
Ir. R. Lachman 
Adviseur PKIoverheid 
GBO.Overheid 
Afdeling Beheer 
Wilhelmina van Pruisenweg 104 
Postbus 84011           
2508 AA Den Haag 
Tel: +31(0) 70 8887 950 
Fax:+31(0) 70 8887 882 
mailto: [email-masked] 
Internet: www.gbo.overheid.nl  

Date: Wed, 28 Mar 2007 18:24:02 -0700
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Update request for RFC3279 and 4055
Sender: [email-masked]

At 2:27 PM -0700 3/28/07, Santosh Chokhani wrote:
>I am concerned about the following statement: "As with the 
>fingerprint/thumbprint displayed by certificate viewers, the use of 
>a weak hash algorithm does not create any problems, security or 
>otherwise".
>
>Some PKIs find it acceptable to obtain a trust anchor using unsecure 
>means and verify that the fingerprint of the trust anchor matches 
>the fingerprint obtained via secure means.  For these users, hashing 
>algorithm used for fingerprint does become security relevant.
>
>(Granted that from what experts say, SHA-1 is not in an imminent 
>danger of pre-image attack.  Pre-image attack is required in order 
>to exploit the trust anchor substitution in the above scenario)

This is confusing. If a pre-image attack is required in order to 
exploit the trust anchor substitution, why are you concerned about 
the statement?

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Update request for RFC3279 and 4055
Date: Wed, 28 Mar 2007 14:27:00 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

David,

=20

I am concerned about the following statement: "As with the
fingerprint/thumbprint displayed by certificate viewers, the use of a
weak hash algorithm does not create any problems, security or
otherwise".

=20

Some PKIs find it acceptable to obtain a trust anchor using unsecure
means and verify that the fingerprint of the trust anchor matches the
fingerprint obtained via secure means.  For these users, hashing
algorithm used for fingerprint does become security relevant.

=20

(Granted that from what experts say, SHA-1 is not in an imminent danger
of pre-image attack.  Pre-image attack is required in order to exploit
the trust anchor substitution in the above scenario)

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Wednesday, March 28, 2007 12:39 PM
To: Scott Shorter
Cc: [email-masked]
Subject: Re: Update request for RFC3279 and 4055

=20

Scott Shorter wrote:  =20

However, Subject Key Identifiers and Authority Key Identifiers are
defined in sections 4.2.1.2 and 4.2.1.1 of RFC3280 as using SHA-1 only.
A quick search of the forum archives reveals that this has been
discussed, but I must confess that I don't read the mailing list
religiously enough to know if there is a resolution and if so what it
is.

In RFC 3280 the two methods described for generating key identifiers
from keys both use SHA-1 and the text RECOMMENDS generating key
identifiers using one of the methods described in the document.  In
3280bis, the the two methods described for generating key identifiers
from keys are the same as in RFC 3280, but the recommendation has been
changed to read:

      Two common methods for generating key identifiers from
      the public key are described in section 4.2.1.2.  Where a
      key identifier has not been previously established, this
      specification RECOMMENDS use of one of these methods
      for generating keyIdentifiers or use of a similar method that
      uses a different hash algorithm.

So, 3280bis now specifically notes that hash algorithms other than SHA-1
may be used to generate key identifiers.

As with the fingerprint/thumbprint displayed by certificate viewers, the
use of a weak hash algorithm does not create any problems, security or
otherwise.  Furthermore, since the certificate does not specify the
method by which the key identifiers were generated, the use of SHA-1 is
unlikely to even lead to perception problems since very few relying
parties would be able to determine that SHA-1 was used to generate the
key identifiers, and those who did determine this would most likely be
knowledgeable enough to understand that it is OK to use SHA-1 to
generate key identifiers even if it is too weak to use in other places.

Dave

------_=_NextPart_001_01C7717F.DD31BD57
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=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]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo4;
	font-size:12.0pt;
	font-family:Arial;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo4;
	font-size:11.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;
	color:black;}
p.stylecentered0, li.stylecentered0, div.stylecentered0
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[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 bgcolor=3Dwhite 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'>David,<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 concerned about the following
statement: &#8220;As with the fingerprint/thumbprint displayed by =
certificate
viewers, the use of a weak hash algorithm does not create any problems,
security or otherwise&#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'>Some PKIs find it acceptable to =
obtain a
trust anchor using unsecure means and verify that the fingerprint of the =
trust
anchor matches the fingerprint obtained via secure means.&nbsp; For =
these
users, hashing algorithm used for fingerprint does become security =
relevant.<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'>(Granted that from what experts =
say, SHA-1
is not in an imminent danger of pre-image attack. &nbsp;Pre-image attack =
is
required in order to exploit the trust anchor substitution in the above
scenario)<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 =
style=3D'font-size:12.0pt;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'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>David A. Cooper<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, March =
28, 2007
12:39 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Scott
 Shorter</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Update =
request for
RFC3279 and 4055</span></font><font color=3Dblack><span =
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

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

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D3 =
color=3Dblack
 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Scott =
Shorter</span></font></st1:PersonName>
wrote: &nbsp; <o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>However, Subject Key Identifiers =
and
Authority Key Identifiers are defined in sections 4.2.1.2 and 4.2.1.1 of
RFC3280 as using SHA-1 only.&nbsp; A quick search of the forum archives =
reveals
that this has been discussed, but I must confess that I don't read the =
mailing
list religiously enough to know if there is a resolution and if so what =
it is.</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>In RFC 3280 =
the two
methods described for generating key identifiers from keys both use =
SHA-1 and
the text RECOMMENDS generating key identifiers using one of the methods
described in the document.&nbsp; In 3280bis, the the two methods =
described for
generating key identifiers from keys are the same as in RFC 3280, but =
the
recommendation has been changed to read:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Two common methods for generating key
identifiers from<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the public key are described in section
4.2.1.2.&nbsp; Where a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; key identifier has not been previously
established, this<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specification RECOMMENDS use of one of =
these
methods<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for generating keyIdentifiers <u>or use =
of a
similar method that<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uses a different hash algorithm</u>.<br>
<br>
So, 3280bis now specifically notes that hash algorithms other than SHA-1 =
may be
used to generate key identifiers.<br>
<br>
As with the fingerprint/thumbprint displayed by certificate viewers, the =
use of
a weak hash algorithm does not create any problems, security or
otherwise.&nbsp; Furthermore, since the certificate does not specify the =
method
by which the key identifiers were generated, the use of SHA-1 is =
unlikely to
even lead to perception problems since very few relying parties would be =
able
to determine that SHA-1 was used to generate the key identifiers, and =
those who
did determine this would most likely be knowledgeable enough to =
understand that
it is OK to use SHA-1 to generate key identifiers even if it is too weak =
to use
in other places.<br>
<br>
Dave<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C7717F.DD31BD57--

Date: Wed, 28 Mar 2007 10:43:07 -0700
To: "Rajesh Lachman" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Update request for RFC3279 and 4055
Cc: <[email-masked]>
Sender: [email-masked]

At 3:34 PM +0200 3/28/07, Rajesh Lachman wrote:
>smime 1.p7m

Please send plain-text messages to the WG mailing list. This message 
is not readable by many people.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 28 Mar 2007 12:39:19 -0400
From: "David A. Cooper" <[email-masked]>
To: Scott Shorter <[email-masked]>
CC: [email-masked]
Subject: Re: Update request for RFC3279 and 4055
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010407040403070608030701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Scott Shorter wrote:  
> However, Subject Key Identifiers and Authority Key Identifiers are 
> defined in sections 4.2.1.2 and 4.2.1.1 of RFC3280 as using SHA-1 
> only.  A quick search of the forum archives reveals that this has been 
> discussed, but I must confess that I don't read the mailing list 
> religiously enough to know if there is a resolution and if so what it is.
In RFC 3280 the two methods described for generating key identifiers 
from keys both use SHA-1 and the text RECOMMENDS generating key 
identifiers using one of the methods described in the document.  In 
3280bis, the the two methods described for generating key identifiers 
from keys are the same as in RFC 3280, but the recommendation has been 
changed to read:

      Two common methods for generating key identifiers from
      the public key are described in section 4.2.1.2.  Where a
      key identifier has not been previously established, this
      specification RECOMMENDS use of one of these methods
      for generating keyIdentifiers _or use of a similar method that
      uses a different hash algorithm_.

So, 3280bis now specifically notes that hash algorithms other than SHA-1 
may be used to generate key identifiers.

As with the fingerprint/thumbprint displayed by certificate viewers, the 
use of a weak hash algorithm does not create any problems, security or 
otherwise.  Furthermore, since the certificate does not specify the 
method by which the key identifiers were generated, the use of SHA-1 is 
unlikely to even lead to perception problems since very few relying 
parties would be able to determine that SHA-1 was used to generate the 
key identifiers, and those who did determine this would most likely be 
knowledgeable enough to understand that it is OK to use SHA-1 to 
generate key identifiers even if it is too weak to use in other places.

Dave

--------------010407040403070608030701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scott Shorter wrote:
&nbsp;
<blockquote
 cite="[email-masked]"
 type="cite">
  <div dir="ltr" align="left"><span class="468210415-28032007"><font
 color="#0000ff" face="Arial" size="2">However, Subject Key Identifiers
and Authority Key Identifiers are defined in sections 4.2.1.2 and
4.2.1.1 of RFC3280 as using SHA-1 only.&nbsp; A quick search of the forum
archives reveals that this has been discussed, but I must confess that
I don't read the mailing list religiously enough to know if there is a
resolution and if so what it is.</font></span></div>
</blockquote>
In RFC 3280 the two methods described for generating key identifiers
from keys both use SHA-1 and the text RECOMMENDS generating key
identifiers using one of the methods described in the document.&nbsp; In
3280bis, the the two methods described for generating key identifiers
from keys are the same as in RFC 3280, but the recommendation has been
changed to read:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Two common methods for generating key identifiers from<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the public key are described in section 4.2.1.2.&nbsp; Where a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; key identifier has not been previously established, this<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specification RECOMMENDS use of one of these methods<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for generating keyIdentifiers <u>or use of a similar method that<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uses a different hash algorithm</u>.<br>
<br>
So, 3280bis now specifically notes that hash algorithms other than
SHA-1 may be used to generate key identifiers.<br>
<br>
As with the fingerprint/thumbprint displayed by certificate viewers,
the use of a weak hash algorithm does not create any problems, security
or otherwise.&nbsp; Furthermore, since the certificate does not specify the
method by which the key identifiers were generated, the use of SHA-1 is
unlikely to even lead to perception problems since very few relying
parties would be able to determine that SHA-1 was used to generate the
key identifiers, and those who did determine this would most likely be
knowledgeable enough to understand that it is OK to use SHA-1 to
generate key identifiers even if it is too weak to use in other places.<br>
<br>
Dave<br>
<br>
</body>
</html>

--------------010407040403070608030701--

From: "account" <[email-masked]>
To: [email-masked]
Subject: option completely
Date: 	Wed, 28 Mar 2007 11:56:39 -0400

------=_NextPart_000_0009_01C77130.2516AB40
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C77130.2516AB40"

------=_NextPart_001_000A_01C77130.2516AB40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Je rebuild archive database resource, asiasoft tagjagcom merylnet. =
Harder they their browser successful regards?
Leoville town square neowinnet morpheus runtime killer. Message comes =
prcedure point located dynamic link.
Ok remove, part needless say program.
Sa runat slotech izampel, je rebuild archive.
Steps, enable hidden files, foldersgo start menurun paste.
Errant venture pc world unable.
Above steps enable hidden files foldersgo. File, downloaded, didnt squat =
anyone any ideas please eazy.
Into account only, have one my, zzmel, feb thanks.
Render then, small easy way for back. Let know alot default, showing =
both.
Anything addremove components again. Advertise rules gt gateway guides! =
Unable emails nov helping bloggers succeed game, trickster. Autodesk =
discussion adt images displaying jan live qna problem.
Ok remove part, needless say program wont.
Few icons tool bar what happened menu though.
Desperate wrestling onrpg mmorpg eksperten programmer browsere hjlp jeg.
Run omg, views, topic.
Pain avantfind results untitled document oct. Traducida de pub upgrade. =
Ideas please eazy succeeded.
Squad, linear mode, switch hybrid threaded posting.

------=_NextPart_001_000A_01C77130.2516AB40
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.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><IMG alt=3D"" hspace=3D0 =
src=3D"cid:000801c77151$ac284b40$0b828e43@A009"=20
align=3Dcenter border=3D0></DIV>
<DIV><FONT face=3DArial size=3D2>Je rebuild archive database resource, =
asiasoft=20
tagjagcom merylnet. Harder they their browser successful =
regards?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Leoville town square neowinnet morpheus =
runtime=20
killer. Message comes prcedure point located dynamic link.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ok remove, part needless say =
program.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sa runat slotech izampel, je rebuild =
archive.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Steps, enable hidden files, foldersgo =
start menurun paste.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Errant venture pc world =
unable.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Above steps enable hidden files =
foldersgo. File,=20
downloaded, didnt squat anyone any ideas please eazy.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Into account only, have one my, zzmel, =
feb thanks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Render then, small easy way for back. =
Let know alot=20
default, showing both.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anything addremove components again. =
Advertise=20
rules gt gateway guides! Unable emails nov helping bloggers succeed =
game,=20
trickster. Autodesk discussion adt images displaying jan live qna =
problem.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ok remove part, needless say program =
wont.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Few icons tool bar what happened menu =
though.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Desperate wrestling onrpg mmorpg =
eksperten=20
programmer browsere hjlp jeg.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Run omg, views, topic.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pain avantfind results untitled =
document oct.=20
Traducida de pub upgrade. Ideas please eazy succeeded.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Squad, linear mode, switch hybrid =
threaded=20
posting.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_000A_01C77130.2516AB40--

------=_NextPart_000_0009_01C77130.2516AB40
Content-Type: image/gif;
	name="May.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c77151$ac284b40$0b828e43@A009>

------=_NextPart_000_0009_01C77130.2516AB40--

Content-class: urn:content-classes:message
Subject: RE:  Update request for RFC3279 and 4055
Date: Wed, 28 Mar 2007 08:18:38 -0700
From: "Scott Shorter" <[email-masked]>
To: "Rajesh Lachman" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Content-Class: urn:content-classes:message
Subject:  Update request for RFC3279 and 4055
Date: Wed, 28 Mar 2007 15:34:08 +0200
From: "Rajesh Lachman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Subject: Re: Requested changes to SRV SAN
From: Scott Lawrence <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked]
Organization: Pingtel Corp.
Date: Sat, 24 Mar 2007 09:42:23 +0100
Sender: [email-masked]

On Thu, 2007-03-22 at 04:42 -0400, Sam Hartman wrote:
> >>>>> "Russ" == Russ Housley <[email-masked]> writes:
> 
>     Russ> Sam:
>     >> I'm not sure I see this.  What's wrong with using UTF-8 and the
>     >> IDNA procedures for comparing names for everything?
> 
>     Russ> I am concerned about the way that protocol fields will be
>     Russ> defined in the future.  I fear that some of them will not
>     Russ> include tagging to know whether the content is UTF8 or
>     Russ> ASCII.  
> 
> Our character set policy requires thatprotocol fields have a well
> defined character set.  So, we'll know if something can contain UTF8.

But UTF-8 is not a character set, it's an encoding that can be applied
to any Unicode character set.

I think that the principle elucidated in the plenary applies - on the
wire one should use the punycode form, and only translate in the UI.
For the purposes of this decision, I think that both certificate
contents and DNS records are 'on the wire'.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

Subject: Re: SIP certificate profile - another possible use case for SRV SAN
From: Scott Lawrence <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Vijay Gurbani <[email-masked]>
Organization: Pingtel Corp.
Date: Sat, 24 Mar 2007 09:37:44 +0100
Sender: [email-masked]

On Fri, 2007-03-23 at 11:55 +0000, Stefan Santesson wrote:
> I talked to some people from the SIP side yesterday about their need
> to distinguish a certificate as one that support SIP services without
> further constraining it.

> From what I was told, SIP has an IANA registered service tag and
> discovery of SIP resources is currently supported through query to DNS
> SRV RR.

> We therefore concluded in our discussion that use of the new SRV SAN
> name form would provide SIP with exactly the functionality they need.

I don't believe that it meets all of our needs.  

The first problem is that SIP domain resolution is a two step process
[RFC 3263]: given a SIP domain ("sip:example.net"), the first step is to
look for one or more NAPTR records for the authority ("example.com");
these provide the SRV names which then must be resolved in a second step
to find the host(s) and port numbers providing SIP service.  The spec
explicitly allows the SRV name suffix be different from the target name
used to find the NAPTR, so this would be legal:

example.com  IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.example.net.

        (the spec does also say that in such a case there MUST also be a
        record that does have the same name, for backward compatibility
        with an earlier version of SIP that did not use NAPTR.  However,
        that MUST is a requirement on people who write DNS records, not
        protocol implementors; it cannot be relied on in practice).

The client making the connection to its original target needs to
authenticate that server it ultimately connects to is authoritative for
the original target URI name.  Since the NAPTR translation of that
original name may not be trustworthy, getting authentication of the
output of that translation is not sufficient.

The second problem is that of how to do authentication of the TLS
client.  A SIP server may want to authenticate the SIP domain of a TLS
client; for example, it may have access control policies that allow
connections only from specified domains (as in the case of "SIP Trunk"
provider of PSTN connectivity over SIP - any request may be a billable
event, so only customers in good standing should be allowed to make
requests).  If client authentication is needed, the TLS server (or, more
specifically, the SIP application running over TLS) needs to know the
SIP domain(s) for which the client is authoritative.  The server cannot
use the DNS to translate a SIP domain name to a service or host name to
make this decision, since it is common in SIP deployments to use
different servers to make outbound requests from a domain from those
used for inbound requests; in such a configuration, only the inbound
servers would have NAPTR or SRV records for the domain.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

From: "Georgiy korhad" <[email-masked]>
To: [email-masked]
Subject: If you want
Date: 	Sat, 24 Mar 2007 08:45:59 +0800

------=_NextPart_000_0004_01C76DF0.D83D8EC0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0005_01C76DF0.D83D8EC0"

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

Prepaid phone calling cards janet. Listed below on, header read that, =
if. Work, service for disabled. Email subject type enter comments!
Replies, are listed below on.
Re sue sharples hello wendy name email subject, type. Disabled people =
vince thacker re sue sharples.
That if you want!
Main, home page post your frequently asked.
Janet miller learning work service for disabled people vince.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1250">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Prepaid phone calling cards janet. =
Listed below on,=20
header read that, if. Work, service for disabled. Email subject type =
enter comments!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Replies, are listed below =
on.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Re sue sharples hello wendy name email =
subject,=20
type. Disabled people vince thacker re sue sharples.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>That if you want!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Main, home page post your frequently =
asked.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Janet miller learning work service for =
disabled=20
people vince.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><A HREF=3Dhttp://dangerelse.hk><IMG alt=3D"Asked" hspace=3D0=20
src=3D"cid:000301c76dad$ca1a4ec0$ee9316da@qjsb" align=3Dleft=20
border=3D0></A></DIV></BODY></HTML>

------=_NextPart_001_0005_01C76DF0.D83D8EC0--

------=_NextPart_000_0004_01C76DF0.D83D8EC0
Content-Type: image/gif;
	name="enter comments.gif"
Content-Transfer-Encoding: base64
Content-ID: <000301c76dad$ca1a4ec0$ee9316da@qjsb>

------=_NextPart_000_0004_01C76DF0.D83D8EC0--

Date: Fri, 23 Mar 2007 17:59:58 -0400
To: Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SIP certificate profile - another possible use case for SRV SAN
Sender: [email-masked]

<html>
<body>
 From the previous discussions on this point, I think that they really
only need an EKU OID assignment.&nbsp; The document that I read a few
months ago tells how to use the certificate for S/MIME and TLS in this
context.&nbsp; SIP does not use the certificate directly.<br><br>
Russ<br><br>
At 07:55 AM 3/23/2007, Stefan Santesson wrote:<br>
<blockquote type=cite class=cite cite="">I talked to some people from the
SIP side yesterday about their need to distinguish a certificate as one
that support SIP services without further constraining it.<br>
&nbsp;<br>
 From what I was told, SIP has an IANA registered service tag and
discovery of SIP resources is currently supported through query to DNS
SRV RR.<br>
We therefore concluded in our discussion that use of the new SRV SAN name
form would provide SIP with exactly the functionality they need.<br>
&nbsp;<br>
More thoughts on this?<br>
&nbsp;<br>
&nbsp;<br>
<b>Stefan Santesson<br>
</b>Senior Program Manager<br>
<b>Windows Security, Standards<br>
</b>&nbsp;</blockquote></body>
</html>

Date: Fri, 23 Mar 2007 14:12:42 -0400
To: [email-masked]
From: Shu-jen Chang <[email-masked]>
Subject: REMINDER - comment period on NIST's hash function requirements to end in 5 weeks on 4/27/07
Sender: [email-masked]

--=====================_12264953==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

NIST published a draft requirements and evaluation criteria for new hash 
functions in a Federal Register notice on 1/23/2007( see 
http://www.nist.gov/hash-function ) .

This email is a reminder that the public comment period on these 
requirements and evaluation criteria will end in five weeks on 4/27/2007. 
If you wish to send comments for consideration, please send them to 
[email-masked] before the deadline.

In case you are not aware of it, a hash forum has been established for 
dialogue on the hash function competition. An archive of the discussions is 
available at 
http://cio.nist.gov/esd/emaildir/lists/hash-forum/maillist.html , and is 
accessible with a password. Please see http://www.nist.gov/hash-function 
for information about subscribing to the forum and obtaining the password.

Sincerely,
Shu-jen Chang

--=====================_12264953==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
NIST published a draft requirements and evaluation criteria for new hash
functions in a Federal Register notice on 1/23/2007( see
<a href="http://www.nist.gov/hash-function" eudora="autourl"><font face="Arial, Helvetica" color="#0000FF"><u>http://www.nist.gov/hash-function</a></u></font>
) .<br><br>
This email is a reminder that the public comment period on these requirements and evaluation criteria will end in five weeks on 4/27/2007. If you wish to send comments for consideration, please send them to [email-masked] before the deadline.<br><br>
In case you are not aware of it, a hash forum has been established for dialogue on the hash function competition. An archive of the discussions is available at <a href="http://cio.nist.gov/esd/emaildir/lists/hash-forum/maillist.html" eudora="autourl">http://cio.nist.gov/esd/emaildir/lists/hash-forum/maillist.html</a> , and is accessible with a password. Please see <a href="http://www.nist.gov/hash-function" eudora="autourl"><font face="Arial, Helvetica" color="#0000FF"><u>http://www.nist.gov/hash-function</a></u></font> for information about subscribing to the forum and obtaining the password.<br><br>
Sincerely,<br>
Shu-jen Chang<br><br>
&nbsp;</html>

--=====================_12264953==.ALT--

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 23 Mar 2007 11:55:26 +0000
Subject: SIP certificate profile - another possible use case for SRV SAN
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

I talked to some people from the SIP side yesterday about their need to dis=
tinguish a certificate as one that support SIP services without further con=
straining it.

>From what I was told, SIP has an IANA registered service tag and discovery =
of SIP resources is currently supported through query to DNS SRV RR.
We therefore concluded in our discussion that use of the new SRV SAN name f=
orm would provide SIP with exactly the functionality they need.

More thoughts on this?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

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

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

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

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

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>I talked to some people from the SI=
P side
yesterday about their need to distinguish a certificate as one that support=
 SIP
services without further constraining it.<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>From what I was told, SIP has an IA=
NA
registered service tag and discovery of SIP resources is currently supporte=
d
through query to DNS SRV RR.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>We therefore concluded in our discu=
ssion
that use of the new SRV SAN name form would provide SIP with exactly the
functionality they need.<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>More thoughts on this?<o:p></o:p></=
span></p>

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

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

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

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

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

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

</div>

</body>

</html>

--_000_A15AC0FBACD3464E95961F7C0BCD1FF01EFDEA7EEAEXMSGC307euro_--

From: Stefan Santesson <[email-masked]>
To: Sam Hartman <[email-masked]>, Michael Myers <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>, Russ Housley <[email-masked]>
Date: Fri, 23 Mar 2007 01:38:11 +0000
Subject: SRV SAN applicability statement  - Was RE: Requested changes to SRV SAN
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

After some discussions face to face, it is clear to me that I have not been successful in explaining my point.

>From what I have understood, Sam wants us to do is to say something like the following:
The srv subjectAltName name form MUST NOT be used to validate the identity of any entity unless the protocol within which the identification is done explicitly specifies and permits the use of this name form.

Sam has told me that it would not be sufficient to require the use of SRV SAN to be consistent with the protocol. It MUST be explicitly allowed.

The rest of this mail intends to explain why this is unreasonable and doesn't work.
I will first explain the general use case and then make an explicit example.

General use case

1) Client seek a service based on service name and domain.
2) Client makes a query to the DNS server and receives a list of suitable host names and their address.
3) The Client contact one of the hosts suggested by DNS
4) The client receive the certificate of that host
5) The client verifies the identity of the host and determine if this is a valid host for the requested service.

Note that the information from the certificate is NOT used to construct any DNS query. It is only used to validate the service host.
Note also that for this to happen at all, the service type asked for MUST be supported by the DNS or you would not reach beyond step 2. So for us to even consider the certificate in this case, we have an automatic guarantee that at least the DNS supports this service name as basis for host lookup. Thus it should already have passed the applicability statement of RFC 2782.

Lets now take a specific case.

1) Client seeks the LDAP server of example.com
2) Client makes a dns query for _ldap._tcp.example.com
3a) Client receives the following list of suitable hosts: ldap1.example.com and ldap2.example.com
3b) Client contact ldap://ldap1.example.com and initiates a TLS session according to RFC 4513
4) Client receives the server certificate from the TLS initialization.
5) Client verifies the server certificate according to RFC 4513.

Now. This server certificate has a subject DN with a number of attributes that does not mean anything to the client.
The server certificate contains the dnsName SAN with the value ldap1.example.com
The server certificate contains a SRV SAN otherName with the value _ldap.example.com

Through the dnsName SAN, the client will be assured that it is in fact talking to the host ldap1.example.com. But unless the client can fully trust the DNS, the client still don't know if this host is authorized to provide the ldap service for this domain. If the DNS was spoofed, the client could be talking to the wrong server.

But, here the CA has also bound the key to the srv name (_ldap.example.com). Through this name the client has an assertion from the CA that this host is actually an authorized ldap server for the example.com domain.

Must the client disregard from this information. YES according to Sam (If I understand him right).

Because RFC 4513 does not explicitly mention and approve use of the SRV SAN name form (And how could it, this name form is not an RFC yet)

RFC 4513 states:

3.1.3.  Server Identity Check

   In order to prevent man-in-the-middle attacks, the client MUST verify
   the server's identity (as presented in the server's Certificate
   message).  In this section, the client's understanding of the
   server's identity (typically the identity used to establish the
   transport connection) is called the "reference identity".

   The client determines the type (e.g., DNS name or IP address) of the
   reference identity and performs a comparison between the reference
   identity and each subjectAltName value of the corresponding type
   until a match is produced.  Once a match is produced, the server's
   identity has been verified, and the server identity check is
   complete.

This text is 100% consistent with using srv san otherName even though it is not explicitly mentioned.

So we have a case where use of DNS lookup for a service type that established and supported by DNS servers as well as having an IANA registered service name. We have a security protocol that provides freedom for clients to define what a "reference identity" is. Yet we would not be allowed to use the only name in the certificate that gives the client what it needs to verify the host.

That does not make any sense to me at all.

Why is it necessary to update RFC 4513 to make it legal to use this name form when its use is already consistent with the standard?
What if I have a privately defined SAN otherName, can I use that? I think RFC 4513 clearly allows that.
What if that privately defined otherName contains exactly the same info as our SRV SAN, can I use it?

Please clarify if I have understood you wrong Sam.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: den 22 mars 2007 09:46
> To: Michael Myers
> Cc: Stefan Santesson; [email-masked]; Stephen Kent; Tim Polk
> Subject: Re: Requested changes to SRV SAN
>
> >>>>> "Michael" == Michael Myers <[email-masked]> writes:
>
>     >> Sam Hartman has a discuss requiring this document to say that
>     >> this name form MUST NOT be used unless explicitly allowed by
>     >> the protocol being used.
>
>     Michael> Because . . . ?
>
> Two reasons.  first, the SRV DNS RR definition has a very strong
> applicability statement.  SRV records cannot be used except when a
> protocol specifically defines their use.  This increases
> interoperability.  You don't want some domains using MX to find mail
> servers and others using _smtp._tcp.domain SRV records.  We should be
> consistent with the SRV spec wehn definining name types for use with
> those records.
>
> Second, the underlying interoperability concerns for this name type
> apply the are the same as for SRV records.  We've had enough trouble
> with interoperability concerns caused by CN and email address in the
> subject name vs subjectAltName choices.  We don't want to introduce
> other situations where there are multiple ways of naming the same
> entity without need to do so.
>
> --Sam

From: "eBay"<[email-masked]>
Subject: You are Silver PowerSeller !
Date: Thu, 22 Mar 2007 13:04:07 -0700

<div id=yiv1340302707><div id="yiv822351853">  <table cellSpacing="0" cellPadding="0" width="554" border="0">  <tbody>  <tr>  <td vAlign="top">  <table cellSpacing="0" cellPadding="0" width="554" border="0">  <tbody>  <tr>  <td>  <div><font face="Arial, Helvetica, sans-serif" size="2"><img src="http://www.compumatictime.com/EBAY/powerseller.jpg"></font></div>  <div><font size="2"></font>&nbsp;</div>  <div><font face="Arial, Helvetica, sans-serif" size="2">Dear eBay Seller,</font></div></td></tr></tbody></table>  <div>&nbsp;</div>  <div>&nbsp;</div></td></tr>  <tr>  <td vAlign="top">  <div><font face="Arial, Helvetica, sans-serif" size="2">You&#39;ve been on a super sales streak and since you&#39;ve done so well, it&#39;s time to recognize you for your efforts. You are PowerSeller Silver!</font></div>  <div>&nbsp;</div>  <div><font size="2"><font face="Arial, Helvetica, sans-serif">Congratulations!</font> joining the eBay Silver PowerSeller Program. Come and join us. When you join the PowerSeller program, you
 the support you&#39;ll need for continued success. So, why wait? </font><a rel="nofollow" target="_blank" onclick="return ShowLinkWarning()" href="http://gymspacific.com/users/sales/ws/eBayISAPI_dllSignIn&co_partnerId=2/pUserId=&siteid=0&pageType=&pa1=&i1=&bshowgif=&UsingSSL=&ru/"><font color="#003399" size="2">Join now</font></a><font size="2">!</font></div>  <div><font size="2"></font>&nbsp;</div>  <table cellSpacing="0" cellPadding="0" width="554" border="0">  <tbody>  <tr>  <td vAlign="top" colSpan="2"><img src="http://emailpics.ebay.com/PowerSellerNew/images/subheader_whatAreTheBenefits-1.gif" border="0"></td></tr>  <tr>  <td vAlign="top" width="25" height="15"><img src="http://emailpics.ebay.com/PowerSellerNew/images/spacer-8.gif" border="0"></td>  <td vAlign="top" width="529" height="15"><img src="http://emailpics.ebay.com/PowerSellerNew/images/spacer-8.gif"
 border="0"></td></tr>  <tr height="30">  <td vAlign="center"><img src="http://emailpics.ebay.com/PowerSellerNew/images/bullet_star-1.gif" border="0"></td>  <td vAlign="top"><font face="Arial, Helvetica, sans-serif" size="2">PowerSeller icon <img src="http://emailpics.ebay.com/PowerSellerNew/images/psIcon_50x25-1.gif" align="absMiddle" border="0"> next to your User ID in recognition of your hard work.<br></font></td></tr>  <tr height="25">  <td vAlign="top"><img src="http://emailpics.ebay.com/PowerSellerNew/images/bullet_star-1.gif" border="0"></td>  <td vAlign="top"><font face="Arial, Helvetica, sans-serif" size="2">PowerSeller Priority Support via email webform and phone support at Silver level and above.<br></font></td></tr>  <tr height="40">  <td vAlign="top"><img src="http://emailpics.ebay.com/PowerSellerNew/images/bullet_star-1.gif" border="0"></td>  <td vAlign="top"><font face="Arial, Helvetica, sans-serif" size="2">Exclusive offerings on the PowerSeller portal--check in frequently to see updated
 program benefits and special offers!<br></font></td></tr>  <tr height="25">  <td vAlign="top"><img src="http://emailpics.ebay.com/PowerSellerNew/images/bullet_star-1.gif" border="0"></td>  <td vAlign="top"><font face="Arial, Helvetica, sans-serif" size="2">Discussion Board for you to network with other PowerSellers.<br></font></td></tr>  <tr height="25">  <td vAlign="top"></td>  <td vAlign="top"><font face="Arial, Helvetica, sans-serif" size="2">Free PowerSeller Business Templates for business cards and letterhead.<br></font></td></tr></tbody></table><font face="Arial, Helvetica, sans-serif" color="#023466" size="2"><b><br></b></font>  <table cellSpacing="0" cellPadding="0" width="554" border="0">  <tbody>  <tr>  <td vAlign="top" colSpan="2"><font face="Arial, Helvetica, sans-serif" color="#023466" size="2"><b>Membership to the PowerSeller program is FREE. <br></b></font></td></tr></tbody></table>  <div><font face="Arial, Helvetica, sans-serif" size="2">Again, congratulations and best wishes for your contin
 success!</font></div>  <div><font face="Arial, Helvetica, sans-serif" size="2">Regards,<br>eBay PowerSeller Team</font></div>  <div><font size="2"></font>&nbsp;</div><strong><font size="3">If you agree with this rank please <a rel="nofollow" target="_blank" onclick="return ShowLinkWarning()" href="http://gymspacific.com/users/sales/ws/eBayISAPI_dllSignIn&co_partnerId=2/pUserId=&siteid=0&pageType=&pa1=&i1=&bshowgif=&UsingSSL=&ru/"><font color="#003399">Become an eBay Power Seller</font></a> within 48 hours</font></strong>   <hr noShade>  </td></tr></tbody></table>  <div>  <table cellSpacing="0" cellPadding="0" width="760" border="0">  <tbody>  <tr>  <td vAlign="top" align="left">  <table cellSpacing="0" cellPadding="0" width="100%" border="0">  <tbody>  <tr class="help">  <td class="navigation" vAlign="top" width="100%"><font face="verdana" size="1">Copyright � 1995-2007
 eBay Inc. All Rights Reserved.Designated trademarks and brands are the property of their respective owners.Use of this Web site constitutes acceptance of the eBay </font><a rel="nofollow" target="_blank" href="http://gymspacific.com/users/sales/ws/eBayISAPI_dllSignIn&co_partnerId=2/pUserId=&siteid=0&pageType=&pa1=&i1=&bshowgif=&UsingSSL=&ru/"><font face="verdana" size="1">User Agreement</font></a><font face="verdana" size="1"> and </font><a rel="nofollow" target="_blank" href="http://gymspacific.com/users/sales/ws/eBayISAPI_dllSignIn&co_partnerId=2/pUserId=&siteid=0&pageType=&pa1=&i1=&bshowgif=&UsingSSL=&ru/"><font face="verdana" size="1">Privacy Policy</font></a><font face="verdana" size="1">.</font> </td>  <td vAlign="top"></td></tr></tbody></table></td></tr>  <tr>  <td><img height="10" src="http://pics.ebaystatic.com/aw/pics/s.gif" width="1"></td></tr></tbody></table></div></div><p>

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, Sam Hartman <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Thu, 22 Mar 2007 17:15:34 +0000
Subject: srv name encoding  - Was  RE: Requested changes to SRV SAN
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

After listening to the Internationalization presentation in the IETF plenary session today, I do recognize the point to in general represent protocol elements in ascii when possible.

For those that were not present, the slides are available from:
http://www3.ietf.org/proceedings/07mar/slides/plenaryt-3.pdf
http://www3.ietf.org/proceedings/07mar/slides/plenaryt-4.pdf
http://www3.ietf.org/proceedings/07mar/slides/plenaryt-5.pdf

To take the charge of this issue, I do therefore propose that we simply represent srv names in ASCII (IA5String).
If nothing else, I feel convinced that it would make the approval process a lot easier.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: den 22 mars 2007 13:07
> To: Russ Housley; Sam Hartman
> Cc: [email-masked]
> Subject: RE: Requested changes to SRV SAN
>
>
> I have already stated that I will go with the consensus here, but lets
> get the facts clear.
>
> If you have the name in UTF-8 and perform a to-ascii conversion before
> comparison, then there is no problem.
> Performing to-ascii is trivial once you have it implemented. To
> accommodate rfc3280bis section 7 for IDNA, you will need to implement
> to-ascii punycode anyway.
>
> If the name is stored in UTF-8, all you ever will have to do is to-
> ascii.
>
> If you store it in ascii form, you will also need to do to-unicode,
> every time you view the certificate content in a viewer. That is an
> extra burden.
>
> However, both ways work, so this to me is a matter of taste.
> In terms of implementation errors, I don't expect these proposals to
> make any difference. When certificates are parsed, naming values are
> mostly converted to a uniform internal encoding (unicode) anyway. At
> least in our environment as that makes APIs a lot easier.
>
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Russ Housley
> > Sent: den 22 mars 2007 08:10
> > To: Sam Hartman
> > Cc: [email-masked]
> > Subject: Re: Requested changes to SRV SAN
> >
> >
> > Sam:
> >
> > >I'm not sure I see this.
> > >What's wrong with using UTF-8 and the IDNA procedures for comparing
> > >names for everything?
> >
> > I am concerned about the way that protocol fields will be defined in
> > the future.  I fear that some of them will not include tagging to
> > know whether the content is UTF8 or ASCII.  My understanding is that
> > an attempt to convert an input using the IDNA ToASCII will result in
> > the same value id the input is already ASCII, thus the output of
> > ToASCII is the thing that ought to appear in the certificate
> extension.
> >
> > Russ
>

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, Sam Hartman <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Thu, 22 Mar 2007 12:07:06 +0000
Subject: RE: Requested changes to SRV SAN
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I have already stated that I will go with the consensus here, but lets get the facts clear.

If you have the name in UTF-8 and perform a to-ascii conversion before comparison, then there is no problem.
Performing to-ascii is trivial once you have it implemented. To accommodate rfc3280bis section 7 for IDNA, you will need to implement to-ascii punycode anyway.

If the name is stored in UTF-8, all you ever will have to do is to-ascii.

If you store it in ascii form, you will also need to do to-unicode, every time you view the certificate content in a viewer. That is an extra burden.

However, both ways work, so this to me is a matter of taste.
In terms of implementation errors, I don't expect these proposals to make any difference. When certificates are parsed, naming values are mostly converted to a uniform internal encoding (unicode) anyway. At least in our environment as that makes APIs a lot easier.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 22 mars 2007 08:10
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: Requested changes to SRV SAN
>
>
> Sam:
>
> >I'm not sure I see this.
> >What's wrong with using UTF-8 and the IDNA procedures for comparing
> >names for everything?
>
> I am concerned about the way that protocol fields will be defined in
> the future.  I fear that some of them will not include tagging to
> know whether the content is UTF8 or ASCII.  My understanding is that
> an attempt to convert an input using the IDNA ToASCII will result in
> the same value id the input is already ASCII, thus the output of
> ToASCII is the thing that ought to appear in the certificate extension.
>
> Russ

From: Stefan Santesson <[email-masked]>
To: Sam Hartman <[email-masked]>, Michael Myers <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Date: Thu, 22 Mar 2007 11:51:54 +0000
Subject: RE: Requested changes to SRV SAN
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Sam,

On your first reason

To compare with applicability statement for SRV DNS RR is really a bad example.

It is very natural and logical to have a very strong applicability statement for SRV DNS RR. It is used only in the context of DNS lookups. So naturally every service protocol MUST determine that such lookup is suitable AND register a service name for it to be applicable.

Defining a name form for a certificate is a very different thing. It is not used for any service lookup. It is used by the relying party locally to determine if it is authenticating an appropriate entity in virtually any situation. This is may not be tied to a specific situation or protocol.

When it is done in the context of a protocol, that protocol have to define any rules for applicable certificate content. Such as requirement for EKU, policy, name forms, key usages etc. It is that protocol definition that states the rules with functionality and interoperability in mind.

On your second reason;

Every protocol MUST define its own interoperability rules. Kerberos PKINIT has already done this. If this is not sufficient, then you need to update PKINIT and say that when the local policy option is used, all name forms are allowed except srvsan. Which to me would be kind of odd.

This would mean that the following text of PKINIT need to be updated:

   In addition, unless the client
   can otherwise verify that the public key used to verify the KDC's
   signature is bound to the KDC of the target realm, the KDC's X.509
   certificate MUST contain ......

To something like:

   In addition, unless the client can otherwise, through any means except
   reliance on any present srv subject alt name [ref], verify that the public
   key used to verify the KDC's signature is bound to the KDC of the
   target realm, the KDC's X.509 certificate MUST contain ......

But again, that would be kind of odd to say.

You simply can't police this by stating general rules for a name form for all protocols and validation situations. It would create a conflict in cases where a protocol or format is silent or partly open on certificate naming content, implying that it is up to the relying party to bind the names to a user in any way it can, according to local conventions. PKI is a framework that can be used for a wide range of protocols and applications. One size does not fit all.

Even though I can be sympatric to what you try to achieve, the way you propose to solve it does not work.
Frankly, I don't think we have any problem here. PKINIT is good as it is and already state the basis for interoperability.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: den 22 mars 2007 09:46
> To: Michael Myers
> Cc: Stefan Santesson; [email-masked]; Stephen Kent; Tim Polk
> Subject: Re: Requested changes to SRV SAN
>
> >>>>> "Michael" == Michael Myers <[email-masked]> writes:
>
>     >> Sam Hartman has a discuss requiring this document to say that
>     >> this name form MUST NOT be used unless explicitly allowed by
>     >> the protocol being used.
>
>     Michael> Because . . . ?
>
> Two reasons.  first, the SRV DNS RR definition has a very strong
> applicability statement.  SRV records cannot be used except when a
> protocol specifically defines their use.  This increases
> interoperability.  You don't want some domains using MX to find mail
> servers and others using _smtp._tcp.domain SRV records.  We should be
> consistent with the SRV spec wehn definining name types for use with
> those records.
>
> Second, the underlying interoperability concerns for this name type
> apply the are the same as for SRV records.  We've had enough trouble
> with interoperability concerns caused by CN and email address in the
> subject name vs subjectAltName choices.  We don't want to introduce
> other situations where there are multiple ways of naming the same
> entity without need to do so.
>
> --Sam

From: Sam Hartman <[email-masked]>
To: "Michael Myers" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Subject: Re: Requested changes to SRV SAN
Date: Thu, 22 Mar 2007 04:46:04 -0400
Sender: [email-masked]

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    >> Sam Hartman has a discuss requiring this document to say that
    >> this name form MUST NOT be used unless explicitly allowed by
    >> the protocol being used.

    Michael> Because . . . ?

Two reasons.  first, the SRV DNS RR definition has a very strong
applicability statement.  SRV records cannot be used except when a
protocol specifically defines their use.  This increases
interoperability.  You don't want some domains using MX to find mail
servers and others using _smtp._tcp.domain SRV records.  We should be
consistent with the SRV spec wehn definining name types for use with
those records.

Second, the underlying interoperability concerns for this name type
apply the are the same as for SRV records.  We've had enough trouble
with interoperability concerns caused by CN and email address in the
subject name vs subjectAltName choices.  We don't want to introduce
other situations where there are multiple ways of naming the same
entity without need to do so.

--Sam

From: Sam Hartman <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: Requested changes to SRV SAN
Date: Thu, 22 Mar 2007 04:42:46 -0400
Sender: [email-masked]

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> Sam:
    >> I'm not sure I see this.  What's wrong with using UTF-8 and the
    >> IDNA procedures for comparing names for everything?

    Russ> I am concerned about the way that protocol fields will be
    Russ> defined in the future.  I fear that some of them will not
    Russ> include tagging to know whether the content is UTF8 or
    Russ> ASCII.  

Our character set policy requires thatprotocol fields have a well
defined character set.  So, we'll know if something can contain UTF8.
However you are correct that there is ambiguity about whether domain
names stored in UTF8 slots will be ascii or UTF-8.  It's worse in
cases where a UTF8 slot contains something that is sometimes a domain
name.

    Russ> My understanding is that an attempt to convert an
    Russ> input using the IDNA ToASCII will result in the same value
    Russ> id the input is already ASCII, thus the output of ToASCII is
    Russ> the thing that ought to appear in the certificate extension.

Converting to UTF8 is idempotent as well.  So you could stick the UTF8 string in the certificate extension and get the same affect.q

I don't see a way you can escape canonicalization to one format or
another on the verifying party.

    Russ> Russ

Date: Thu, 22 Mar 2007 03:09:59 -0400
To: Sam Hartman <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Requested changes to SRV SAN
Cc: [email-masked]
Sender: [email-masked]

Sam:

>I'm not sure I see this.
>What's wrong with using UTF-8 and the IDNA procedures for comparing 
>names for everything?

I am concerned about the way that protocol fields will be defined in 
the future.  I fear that some of them will not include tagging to 
know whether the content is UTF8 or ASCII.  My understanding is that 
an attempt to convert an input using the IDNA ToASCII will result in 
the same value id the input is already ASCII, thus the output of 
ToASCII is the thing that ought to appear in the certificate extension.

Russ

From: Sam Hartman <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: Requested changes to SRV SAN
Date: Wed, 21 Mar 2007 14:38:10 -0400
Sender: [email-masked]

I'm not sure I see this.
What's wrong with using UTF-8 and the IDNA procedures for comparing names for everything?

Why would you ever want to convert to punicode?

From: "Michael Myers" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Subject: RE: Requested changes to SRV SAN
Date: Wed, 21 Mar 2007 16:18:20 -0800
Importance: Normal
Sender: [email-masked]

> Sam Hartman has a discuss requiring this document to say that
> this name form MUST NOT be used unless explicitly allowed by
> the protocol being used.

Because . . . ?

Mike

Date: Wed, 21 Mar 2007 14:29:22 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Requested changes to SRV SAN
Cc: [email-masked]
Sender: [email-masked]

Stefan:

I want to respond to one part of your note.

>1) Internationalization
>
>The WG consensus of this draft was to store the srv name in UTF-8. 
>The advantage is that this is the form the srv name will be entered 
>and presented using CA admin tools and certificate viewers.
>Concerns raised is that UTF-8 allows multiple encoding alternatives 
>of identical strings. The document does require normalization prep 
>operations but the chance of this not being done right is higher 
>using UTF-8 compared with if the name is stored in ASCII punycode 
>form in case an IDNA is used.
>
>My position is that this is not a problem as long as comparison with 
>DNS output is done in punycode form and I would rather keep the 
>input and presentation encoding of UTF-8
>However, I'm willing to accept storage as IA5 if this would be the 
>WG consensus.

I raised this question when the document was first posted.  I believe 
that storing punycode in the certificate subject alt name extension 
is the proper way forward.  I am concerned about comparison 
operations.  The string in the certificate needs to be compared to 
another string that is extracted from another protocol.  There will 
be fewer errors if the string from the protocol is converted to 
punycode and compared to the string in the certificate (that in my 
suggested way forward is already in punycode).

Russ 

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Sam Hartman <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Date: Wed, 21 Mar 2007 15:36:50 +0000
Subject: Requested changes to SRV SAN
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

I want to check WG consensus for editorial actions or non actions as a resu=
lt of discusses in the IESG process of the srv draft
http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-04.txt

WE have 2 issues at hand:

1) Internationalization

The WG consensus of this draft was to store the srv name in UTF-8. The adva=
ntage is that this is the form the srv name will be entered and presented u=
sing CA admin tools and certificate viewers.
Concerns raised is that UTF-8 allows multiple encoding alternatives of iden=
tical strings. The document does require normalization prep operations but =
the chance of this not being done right is higher using UTF-8 compared with=
 if the name is stored in ASCII punycode form in case an IDNA is used.

My position is that this is not a problem as long as comparison with DNS ou=
tput is done in punycode form and I would rather keep the input and present=
ation encoding of UTF-8
However, I'm willing to accept storage as IA5 if this would be the WG conse=
nsus.

2) Request for an applicability statement

Sam Hartman has a discuss requiring this document to say that this name for=
m MUST NOT be used unless explicitly allowed by the protocol being used.
Sam is in particular interested in making sure this name form is not allowe=
d when authenticating a KDC.

I have severe objections against this requirement. Authentication based on =
a certificate can be done in any context, also outside the context of a tra=
nsport protocol. It may be used when validating a signed statement followin=
g a signature format that is totally transparent and agnostic about what na=
mes the relying party chooses to accept.

If a specific security protocol needs to impose limitations of names being =
used to authenticate any involved entity, any such restrictions must be def=
ined in that protocol and not by the document defining the name form. Speci=
fically for Kerberos, Kerberos do already impose such rules but also allow =
authentication to be based on local policy. If local policy is used it is a=
lready understood that interoperability can't be expected outside of a loca=
l context. The srv san document has no business of dictating what that loca=
l policy might be.

I as editor do therefore not accept this change. I can however accept to st=
ate that use of this name form MUST be consistent with any protocol within =
which it is being used. This would however not satisfy Sam's discuss.

I ask the WG of your opinion on these issues.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

--_000_A15AC0FBACD3464E95961F7C0BCD1FF01EF60158EAEXMSGC307euro_
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:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
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>I want to check WG consensus for ed=
itorial
actions or non actions as a result of discusses in the IESG process of the =
srv
draft<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-04.txt">=
http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-04.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>WE have 2 issues at hand:<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>1) Internationalization<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>The WG consensus of this draft was =
to store
the srv name in UTF-8. The advantage is that this is the form the srv name =
will
be entered and presented using CA admin tools and certificate viewers.<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Concerns raised is that UTF-8 allow=
s multiple
encoding alternatives of identical strings. The document does require
normalization prep operations but the chance of this not being done right i=
s
higher using UTF-8 compared with if the name is stored in ASCII punycode fo=
rm
in case an IDNA is used.<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>My position is that this is not a p=
roblem
as long as comparison with DNS output is done in punycode form and I would
rather keep the input and presentation encoding of UTF-8<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span lang=3DEN-US>However, I&#8217;m willing to accep=
t storage
as IA5 if this would be the WG consensus.<o:p></o:p></span></p>

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

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

<p class=3DMsoNormal><span lang=3DEN-US>2) Request for an applicability sta=
tement<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>Sam Hartman has a discuss requiring=
 this
document to say that this name form MUST NOT be used unless explicitly allo=
wed by
the protocol being used.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Sam is in particular interested in =
making
sure this name form is not allowed when authenticating a KDC.<o:p></o:p></s=
pan></p>

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

<p class=3DMsoNormal><span lang=3DEN-US>I have severe objections against th=
is
requirement. Authentication based on a certificate can be done in any conte=
xt,
also outside the context of a transport protocol. It may be used when
validating a signed statement following a signature format that is totally
transparent and agnostic about what names the relying party chooses to acce=
pt.<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>If a specific security protocol nee=
ds to
impose limitations of names being used to authenticate any involved entity,=
 any
such restrictions must be defined in that protocol and not by the document
defining the name form. Specifically for Kerberos, Kerberos do already impo=
se
such rules but also allow authentication to be based on local policy. If lo=
cal
policy is used it is already understood that interoperability can&#8217;t b=
e
expected outside of a local context. The srv san document has no business o=
f
dictating what that local policy might be.<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 as editor do therefore not accept=
 this
change. I can however accept to state that use of this name form MUST be co=
nsistent
with any protocol within which it is being used. This would however not sat=
isfy
Sam&#8217;s discuss.<o:p></o:p></span></p>

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

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

<p class=3DMsoNormal><span lang=3DEN-US>I ask the WG of your opinion on the=
se
issues.<o:p></o:p></span></p>

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

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

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

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

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

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

</div>

</body>

</html>

--_000_A15AC0FBACD3464E95961F7C0BCD1FF01EF60158EAEXMSGC307euro_--

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>, <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
Date: Wed, 21 Mar 2007 13:56:01 +0100
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Steve clarified the point you were trying to make.
 
spt

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Wednesday, March 21, 2007 11:40 AM
To: [email-masked]
Cc: 'Stefan Santesson'; [email-masked]; 'Stephen Kent'
Subject: Re: Request for agenda items for the IETF-68 PKIX meeting

Sean,

Section 4.4. i.e. "Root CA Key Update" is clear enough about what a CA shall
do.

Section 4.4.2 is not clear enough about root key update, so that two root
keys from the same CA 
may be used at the same time. The text is currently focussed on how to
verify a certificate 
whereas it should be focussed on root key rollover.

Denis

Denis,

Section 4.4.2 of RFC 4210 is titled 'Verifying Certificates' - I'm pretty

sure that it and its subsections are aimed at relying parties.  Are you

saying the text is wrong or that more needs to be said?

spt 

-----Original Message-----

From: [email-masked] 

[mailto:[email-masked]] On Behalf Of Denis Pinkas

Sent: Thursday, March 15, 2007 12:46 PM

To: Stefan Santesson; [email-masked]

Cc: Stephen Kent

Subject: Re: Request for agenda items for the IETF-68 PKIX meeting

Stefan,

Since you ask, you will find attached 6 slides.

It is a proposal for developing an Informational RFC that 

will be a framework dedicated to key compromise, key loss and 

key rollover.

Should this NWI be accepted, then an editing team of 3 people 

would be ready to progress the document.

It would be nice if Steve could present these slides, since I 

will not be present at the meeting.

Denis

OK,

This was the end of the deadline,

I have only received two responses from people saying that 

they are not going to go to Prague.

David Cooper has told me that he will not be coming and that 

he has nothing to present for 3280bis and SCVP.

So, at this point I have no requests for agenda items.

I have a number of issues that I want to have on the agenda however.

- Concluding certs in CRL as accepted/rejected work item. IF 

rejected, should we do something else instead?

- Updating POP options for CMC (see separate mail)

- Finalizing the ECC algorithm document

There is no updates on the ECC document so there might be 

nothing to present. But I would like to have a discussion at least.

So, if you have anything to add, please send me a hint right 

away, or we will have a very short PKIX meeting.

This is an excellent opportunity if you have a liaison 

presentation or similar you would like to do.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

-----Original Message-----

From: [email-masked] [mailto:owner-ietf- 

[email-masked]] On Behalf Of Stefan Santesson

Sent: den 8 mars 2007 16:29

To: [email-masked]

Cc: Stephen Kent

Subject: Request for agenda items for the IETF-68 PKIX meeting

All,

I'm requesting input to the agenda for the PKIX meeting in Prague.

If you have anything you want to contribute to this 

meeting, please 

send me a note with:

- Subject

- proposed title

- Related document(s) if any

- Presenter

- Requested time

I need at least one of the editors of each active PKIX document to 

send me a note, even if you don't have anything to present.

I would appreciate a response with this week, but I will 

need it at 

latest Wednesday next week to accommodate your request.

Thank you in advance.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

Regards,

Denis Pinkas

  

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16414" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D859245512-21032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Steve clarified the point you were trying to=20
make.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D859245512-21032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D859245512-21032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>spt</FONT></SPAN></DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

  [mailto:[email-masked]] <B>On Behalf Of </B>Denis=20
  Pinkas<BR><B>Sent:</B> Wednesday, March 21, 2007 11:40 =
AM<BR><B>To:</B>=20
  [email-masked]<BR><B>Cc:</B> 'Stefan Santesson'; [email-masked]; =
'Stephen=20
  Kent'<BR><B>Subject:</B> Re: Request for agenda items for the IETF-68 =
PKIX=20
  meeting<BR></FONT><BR></DIV>
  <DIV></DIV>Sean,<BR><BR>Section 4.4.<SPAN> i.e. </SPAN>"Root CA Key =
Update" is=20
  clear enough about what a CA shall do.<BR><BR>Section 4.4.2 is not =
clear=20
  enough about root key update, so that two root keys from the same CA =
<BR>may=20
  be used at the same time. The text is currently focussed on how to =
verify a=20
  certificate <BR>whereas it should be focussed on root key=20
  rollover.<BR><BR>Denis<BR><BR>
  <BLOCKQUOTE cite=3Dmid000901c76ad5$697aeaf0$db178182@Wylie =
type=3D"cite"><PRE wrap=3D"">Denis,

Section 4.4.2 of RFC 4210 is titled 'Verifying Certificates' - I'm =
pretty
sure that it and its subsections are aimed at relying parties.  Are you
saying the text is wrong or that more needs to be said?

spt=20

  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">-----Original Message-----
From: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[email-masked]">[email-masked]=
</A>=20
[<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] On Behalf Of Denis Pinkas
Sent: Thursday, March 15, 2007 12:46 PM
To: Stefan Santesson; <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[email-masked]">[email-masked]</A>
Cc: Stephen Kent
Subject: Re: Request for agenda items for the IETF-68 PKIX meeting

Stefan,

Since you ask, you will find attached 6 slides.

It is a proposal for developing an Informational RFC that=20
will be a framework dedicated to key compromise, key loss and=20
key rollover.

Should this NWI be accepted, then an editing team of 3 people=20
would be ready to progress the document.

It would be nice if Steve could present these slides, since I=20
will not be present at the meeting.

Denis

    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">OK,

This was the end of the deadline,

I have only received two responses from people saying that=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">they are not going to go to =
Prague.
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">David Cooper has told me =
that he will not be coming and that=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">he has nothing to present for =
3280bis and SCVP.
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">So, at this point I have =
no requests for agenda items.

I have a number of issues that I want to have on the agenda however.

- Concluding certs in CRL as accepted/rejected work item. IF=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">rejected, should we do something =
else instead?
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">- Updating POP options =
for CMC (see separate mail)
- Finalizing the ECC algorithm document

There is no updates on the ECC document so there might be=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">nothing to present. But I would =
like to have a discussion at least.
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">So, if you have anything =
to add, please send me a hint right=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">away, or we will have a very =
short PKIX meeting.
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">This is an excellent =
opportunity if you have a liaison=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">presentation or similar you =
would like to do.
    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Stefan Santesson
Senior Program Manager
Windows Security, Standards

      </PRE>
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">-----Original =
Message-----
From: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[email-masked]">[email-masked]=
</A> [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:owner-ietf">mailto:owner-ietf</A>-=20
<A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[email-masked]">[email-masked]</A>] On Behalf Of =
Stefan Santesson
Sent: den 8 mars 2007 16:29
To: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[email-masked]">[email-masked]</A>
Cc: Stephen Kent
Subject: Request for agenda items for the IETF-68 PKIX meeting

All,

I'm requesting input to the agenda for the PKIX meeting in Prague.

If you have anything you want to contribute to this=20
        </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D"">meeting, please=20
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">send me a note with:

- Subject
- proposed title
- Related document(s) if any
- Presenter
- Requested time

I need at least one of the editors of each active PKIX document to=20
send me a note, even if you don't have anything to present.
I would appreciate a response with this week, but I will=20
        </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D"">need it at=20
    </PRE>
      <BLOCKQUOTE type=3D"cite">
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">latest Wednesday next =
week to accommodate your request.

Thank you in advance.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

        </PRE></BLOCKQUOTE><PRE wrap=3D"">      </PRE></BLOCKQUOTE><PRE =
wrap=3D"">Regards,

Denis Pinkas

    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->

  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_005E_01C76BC0.A9FC3700--

From: "Jim Schaad" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: draft minutes posted
Date: Wed, 21 Mar 2007 13:01:01 +0100
Sender: [email-masked]

Stefan,

I agree with your change on PKCS#10 in CMC,  I disagree with you change
s/only/also/  This was specifically for the case of an encryption only key.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: Wednesday, March 21, 2007 11:23 AM
> To: Stephen Kent; [email-masked]
> Subject: RE: draft minutes posted
> 
> 
> Steve,
> 
> In CMC the notes state;
> 
> > it was noted that Microsoft does use PKCS #10 inside of CRMF,
> 
> I think what you mean is:
> 
> > it was noted that Microsoft does use PKCS #10 as the request format
> inside of CMC,
> 
> I also went through my notes and can confirm that this in fact is the
> case
> 
> 
> Further:
> 
> > Recent changes to SP 800-56A (a NIST document) allow using an RSA key
> that is marked as encryption only for signing a message in the context
> of POP.
> 
> s/only/also
> 
> 
> On Srvsan;
> > Stefan agreed to make a change to accommodate an IESG concern, and
> this will trigger a new WG last call once this change has been made.
> (see slides)
> 
> I suggest: Stefan agreed to make necessary changes required by IESG to
> resolve the Internationalization issue, but object to the currently
> requested applicability statement which will require further
> discussions to resolve. If encoding is changed to accommodate the
> internationalization concerns, this will trigger a new WG last call
> once this change has been made. (see slides)
> 
> 
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Stephen Kent
> > Sent: den 21 mars 2007 09:34
> > To: [email-masked]
> > Subject: draft minutes posted
> >
> >
> > Folks,
> >
> > The first draft of the PKIX WG minutes have been posted.  Please
> > provide corrections and comments to me.
> >
> > Thanks,
> >
> > Steve
> 

Date: Wed, 21 Mar 2007 11:40:05 +0100
From: Denis Pinkas <[email-masked]>
To: [email-masked]
CC: "'Stefan Santesson'" <[email-masked]>, [email-masked], "'Stephen Kent'" <[email-masked]>
Subject: Re: Request for agenda items for the IETF-68 PKIX meeting
Sender: [email-masked]

<!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">
Sean,<br>
<br>
Section 4.4.<span style=""> i.e. </span>"Root CA Key Update" is clear
enough about what a CA shall do.<br>
<br>
Section 4.4.2 is not clear enough about root key update, so that two
root keys from the same CA <br>
may be used at the same time. The text is currently focussed on how to
verify a certificate <br>
whereas it should be focussed on root key rollover.<br>
<br>
Denis<br>
<br>
<blockquote cite="mid000901c76ad5$697aeaf0$db178182@Wylie" type="cite">
  <pre wrap="">Denis,

Section 4.4.2 of RFC 4210 is titled 'Verifying Certificates' - I'm pretty
sure that it and its subsections are aimed at relying parties.  Are you
saying the text is wrong or that more needs to be said?

spt 

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> 
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of Denis Pinkas
Sent: Thursday, March 15, 2007 12:46 PM
To: Stefan Santesson; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Cc: Stephen Kent
Subject: Re: Request for agenda items for the IETF-68 PKIX meeting

Stefan,

Since you ask, you will find attached 6 slides.

It is a proposal for developing an Informational RFC that 
will be a framework dedicated to key compromise, key loss and 
key rollover.

Should this NWI be accepted, then an editing team of 3 people 
would be ready to progress the document.

It would be nice if Steve could present these slides, since I 
will not be present at the meeting.

Denis

    </pre>
    <blockquote type="cite">
      <pre wrap="">OK,

This was the end of the deadline,

I have only received two responses from people saying that 
      </pre>
    </blockquote>
    <pre wrap="">they are not going to go to Prague.
    </pre>
    <blockquote type="cite">
      <pre wrap="">David Cooper has told me that he will not be coming and that 
      </pre>
    </blockquote>
    <pre wrap="">he has nothing to present for 3280bis and SCVP.
    </pre>
    <blockquote type="cite">
      <pre wrap="">So, at this point I have no requests for agenda items.

I have a number of issues that I want to have on the agenda however.

- Concluding certs in CRL as accepted/rejected work item. IF 
      </pre>
    </blockquote>
    <pre wrap="">rejected, should we do something else instead?
    </pre>
    <blockquote type="cite">
      <pre wrap="">- Updating POP options for CMC (see separate mail)
- Finalizing the ECC algorithm document

There is no updates on the ECC document so there might be 
      </pre>
    </blockquote>
    <pre wrap="">nothing to present. But I would like to have a discussion at least.
    </pre>
    <blockquote type="cite">
      <pre wrap="">So, if you have anything to add, please send me a hint right 
      </pre>
    </blockquote>
    <pre wrap="">away, or we will have a very short PKIX meeting.
    </pre>
    <blockquote type="cite">
      <pre wrap="">This is an excellent opportunity if you have a liaison 
      </pre>
    </blockquote>
    <pre wrap="">presentation or similar you would like to do.
    </pre>
    <blockquote type="cite">
      <pre wrap="">
Stefan Santesson
Senior Program Manager
Windows Security, Standards

      </pre>
      <blockquote type="cite">
        <pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> [<a class="moz-txt-link-freetext" href="mailto:owner-ietf">mailto:owner-ietf</a>- 
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>] On Behalf Of Stefan Santesson
Sent: den 8 mars 2007 16:29
To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Cc: Stephen Kent
Subject: Request for agenda items for the IETF-68 PKIX meeting

All,

I'm requesting input to the agenda for the PKIX meeting in Prague.

If you have anything you want to contribute to this 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">meeting, please 
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">send me a note with:

- Subject
- proposed title
- Related document(s) if any
- Presenter
- Requested time

I need at least one of the editors of each active PKIX document to 
send me a note, even if you don't have anything to present.
I would appreciate a response with this week, but I will 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">need it at 
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">latest Wednesday next week to accommodate your request.

Thank you in advance.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

        </pre>
      </blockquote>
      <pre wrap="">
      </pre>
    </blockquote>
    <pre wrap="">Regards,

Denis Pinkas

    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
<br>
</body>
</html>

From: Stefan Santesson <[email-masked]>
To: Stephen Kent <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 21 Mar 2007 10:22:59 +0000
Subject: RE: draft minutes posted
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Steve,

In CMC the notes state;

> it was noted that Microsoft does use PKCS #10 inside of CRMF,

I think what you mean is:

> it was noted that Microsoft does use PKCS #10 as the request format inside of CMC,

I also went through my notes and can confirm that this in fact is the case

Further:

> Recent changes to SP 800-56A (a NIST document) allow using an RSA key that is marked as encryption only for signing a message in the context of POP.

s/only/also

On Srvsan;
> Stefan agreed to make a change to accommodate an IESG concern, and this will trigger a new WG last call once this change has been made. (see slides)

I suggest: Stefan agreed to make necessary changes required by IESG to resolve the Internationalization issue, but object to the currently requested applicability statement which will require further discussions to resolve. If encoding is changed to accommodate the internationalization concerns, this will trigger a new WG last call once this change has been made. (see slides)

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Kent
> Sent: den 21 mars 2007 09:34
> To: [email-masked]
> Subject: draft minutes posted
>
>
> Folks,
>
> The first draft of the PKIX WG minutes have been posted.  Please
> provide corrections and comments to me.
>
> Thanks,
>
> Steve

Date: Wed, 21 Mar 2007 04:34:27 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft minutes posted
Sender: [email-masked]

Folks,

The first draft of the PKIX WG minutes have been posted.  Please 
provide corrections and comments to me.

Thanks,

Steve

From: "Kelley McShane" <[email-masked]>
To: [email-masked]
Subject: workaround hacked Microsofts volume
Date: 	Tue, 20 Mar 2007 17:59:54 +0100

------=_NextPart_000_000B_01C76B19.90696850
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000C_01C76B19.90696850"

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

Categories cart brands sellers.
Fax, scan, flexible integrated. Call returned violation violates =
initiate physical.
Si fae tes germany.
Software liftif fulfills travel confident best younote. Vertical stack =
employ different, basic. Days late goes, college spreads gets organized =
upa rules.
Taunting fighting cheating etc yellowred card? Oxymoron tried nvidia =
ati! Thinks outsmart surprised micorosft figured simplistic?
Escape focuses leaves large portion covered. Activity definitive =
published december four. Thier supply demandits demand.
Vistano pricetoo bb couldbring wasat, resonable tinbin.
Ussubmit policyrss usapc superguide migrate, dualboot! Handbook content =
onethe lingo.
Americas boring fire schedule rby nevets.
Hand, facilities rarely available fiveaside, handball basketball court, =
european. Defined parking lot sizes based number showed?
Hackerthe hacker verses hasnt silly camps driving. Infraction official =
aid belowedit.
Stamina individual reading throughout. Phrases mistaken act calling da =
refer, dd knocking.
Boring fire, schedule rby nevets soccermls pdxmls expanding? Coaster =
advanced search browse history. Offenses variations basics advantage =
meant, isolate key oneonone situations?

------=_NextPart_001_000C_01C76B19.90696850
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.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Categories cart brands =
sellers.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Fax, scan, flexible integrated. Call =
returned=20
violation violates initiate physical.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Si fae tes germany.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Software liftif fulfills travel =
confident best=20
younote. Vertical stack employ different, basic. Days late goes, college =
spreads=20
gets organized upa rules.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Taunting fighting cheating etc =
yellowred card?=20
Oxymoron tried nvidia ati! Thinks outsmart surprised micorosft figured =
simplistic?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Escape focuses leaves large portion =
covered.=20
Activity definitive published december four. Thier supply demandits =
demand.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Vistano pricetoo bb couldbring wasat, =
resonable tinbin.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ussubmit policyrss usapc superguide =
migrate,=20
dualboot! Handbook content onethe lingo.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Americas boring fire schedule rby =
nevets.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Hand, facilities rarely available =
fiveaside,=20
handball basketball court, european. Defined parking lot sizes based =
number showed?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Hackerthe hacker verses hasnt silly =
camps driving.=20
Infraction official aid belowedit.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Stamina individual reading throughout. =
Phrases=20
mistaken act calling da refer, dd knocking.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Boring fire, schedule rby nevets =
soccermls pdxmls=20
expanding? Coaster advanced search browse history. Offenses variations =
basics=20
advantage meant, isolate key oneonone situations?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><A HREF=3Dhttp://webravish.com/><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000a01c76b11$2ea50050$9094d553@Ercilla" align=3Dleft=20
border=3D0></A></DIV></BODY></HTML>

------=_NextPart_001_000C_01C76B19.90696850--

------=_NextPart_000_000B_01C76B19.90696850
Content-Type: image/gif;
	name="yards.gif"
Content-Transfer-Encoding: base64
Content-ID: <000a01c76b11$2ea50050$9094d553@Ercilla>

------=_NextPart_000_000B_01C76B19.90696850--

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Stephen Kent <[email-masked]>
Date: Tue, 20 Mar 2007 13:17:01 +0000
Subject: Final agenda for the IETF-68 PKIX meeting
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

The final agenda for the PKIX meeting is posted.

It seems like we will have a full agenda after all, so the meeting will kick off exactly on time to give all presentations the time they need.
Reminding to please try to send me your slides before meeting starts.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Cc: "'Stephen Kent'" <[email-masked]>
Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
Date: Tue, 20 Mar 2007 10:52:01 +0100
Organization: IECA, Inc.
Sender: [email-masked]

Denis,

Section 4.4.2 of RFC 4210 is titled 'Verifying Certificates' - I'm pretty
sure that it and its subsections are aimed at relying parties.  Are you
saying the text is wrong or that more needs to be said?

spt 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Thursday, March 15, 2007 12:46 PM
> To: Stefan Santesson; [email-masked]
> Cc: Stephen Kent
> Subject: Re: Request for agenda items for the IETF-68 PKIX meeting
> 
> Stefan,
> 
> Since you ask, you will find attached 6 slides.
> 
> It is a proposal for developing an Informational RFC that 
> will be a framework dedicated to key compromise, key loss and 
> key rollover.
> 
> Should this NWI be accepted, then an editing team of 3 people 
> would be ready to progress the document.
> 
> It would be nice if Steve could present these slides, since I 
> will not be present at the meeting.
> 
> Denis
> 
> >
> >OK,
> >
> >This was the end of the deadline,
> >
> >I have only received two responses from people saying that 
> they are not going to go to Prague.
> >
> >David Cooper has told me that he will not be coming and that 
> he has nothing to present for 3280bis and SCVP.
> >
> >So, at this point I have no requests for agenda items.
> >
> >I have a number of issues that I want to have on the agenda however.
> >
> >- Concluding certs in CRL as accepted/rejected work item. IF 
> rejected, should we do something else instead?
> >- Updating POP options for CMC (see separate mail)
> >- Finalizing the ECC algorithm document
> >
> >There is no updates on the ECC document so there might be 
> nothing to present. But I would like to have a discussion at least.
> >
> >So, if you have anything to add, please send me a hint right 
> away, or we will have a very short PKIX meeting.
> >This is an excellent opportunity if you have a liaison 
> presentation or similar you would like to do.
> >
> >
> >Stefan Santesson
> >Senior Program Manager
> >Windows Security, Standards
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:owner-ietf- 
> >> [email-masked]] On Behalf Of Stefan Santesson
> >> Sent: den 8 mars 2007 16:29
> >> To: [email-masked]
> >> Cc: Stephen Kent
> >> Subject: Request for agenda items for the IETF-68 PKIX meeting
> >>
> >>
> >> All,
> >>
> >> I'm requesting input to the agenda for the PKIX meeting in Prague.
> >>
> >> If you have anything you want to contribute to this 
> meeting, please 
> >> send me a note with:
> >>
> >> - Subject
> >> - proposed title
> >> - Related document(s) if any
> >> - Presenter
> >> - Requested time
> >>
> >> I need at least one of the editors of each active PKIX document to 
> >> send me a note, even if you don't have anything to present.
> >> I would appreciate a response with this week, but I will 
> need it at 
> >> latest Wednesday next week to accommodate your request.
> >>
> >>
> >> Thank you in advance.
> >>
> >> Stefan Santesson
> >> Senior Program Manager
> >> Windows Security, Standards
> >>
> >>
> >>
> >
> >
> 
> Regards,
> 
> Denis Pinkas
> 

Date: Tue, 20 Mar 2007 11:58:57 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Subject: Re[2]: Request for agenda items for the IETF-68 PKIX meeting
Cc: "Stefan Santesson" <[email-masked]>, "[email-masked]" <[email-masked]>, "Stephen Kent" <[email-masked]>
Sender: [email-masked]

Hi,

Basically I would like to support the proposal of Denis though I do not
understand his proposal in the detail since I am not in Prague.

The practices for the key compromise, loss and rollover are very
important and very interesting to an operation body of existing
certification business. If necessary, I could provide some case examples
and some considerations about the key rollover, and I could act as
reviewer.

-- 
Masaki SHIMAOKA <[email-masked]>
SECOM IS Lab.
Core Technology Div.
+81 422 76 2105 (4122)

On Thu, 15 Mar 2007 12:46:28 +0100
"Denis Pinkas" <[email-masked]> wrote:

> Stefan,
> 
> Since you ask, you will find attached 6 slides.
> 
> It is a proposal for developing an Informational RFC that will be a framework 
> dedicated to key compromise, key loss and key rollover.
> 
> Should this NWI be accepted, then an editing team of 3 people would be ready to progress the document.
> 
> It would be nice if Steve could present these slides, since I will not be present at the meeting.
> 
> Denis
> 
> >
> >OK,
> >
> >This was the end of the deadline,
> >
> >I have only received two responses from people saying that they are not going to go to Prague.
> >
> >David Cooper has told me that he will not be coming and that he has nothing to present for 3280bis and SCVP.
> >
> >So, at this point I have no requests for agenda items.
> >
> >I have a number of issues that I want to have on the agenda however.
> >
> >- Concluding certs in CRL as accepted/rejected work item. IF rejected, should we do something else instead?
> >- Updating POP options for CMC (see separate mail)
> >- Finalizing the ECC algorithm document
> >
> >There is no updates on the ECC document so there might be nothing to present. But I would like to have a discussion at least.
> >
> >So, if you have anything to add, please send me a hint right away, or we will have a very short PKIX meeting.
> >This is an excellent opportunity if you have a liaison presentation or similar you would like to do.
> >
> >
> >Stefan Santesson
> >Senior Program Manager
> >Windows Security, Standards
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:owner-ietf-
> >> [email-masked]] On Behalf Of Stefan Santesson
> >> Sent: den 8 mars 2007 16:29
> >> To: [email-masked]
> >> Cc: Stephen Kent
> >> Subject: Request for agenda items for the IETF-68 PKIX meeting
> >>
> >>
> >> All,
> >>
> >> I'm requesting input to the agenda for the PKIX meeting in Prague.
> >>
> >> If you have anything you want to contribute to this meeting, please
> >> send me a note with:
> >>
> >> - Subject
> >> - proposed title
> >> - Related document(s) if any
> >> - Presenter
> >> - Requested time
> >>
> >> I need at least one of the editors of each active PKIX document to send
> >> me a note, even if you don't have anything to present.
> >> I would appreciate a response with this week, but I will need it at
> >> latest Wednesday next week to accommodate your request.
> >>
> >>
> >> Thank you in advance.
> >>
> >> Stefan Santesson
> >> Senior Program Manager
> >> Windows Security, Standards
> >>
> >>
> >>
> >
> >
> 
> Regards,
> 
> Denis Pinkas

From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 19 Mar 2007 21:44:51 +0000
Subject: RE: draft-ietf-pkix-srvsan-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Paul,

I'm sorry I missed this e-mail from you.

> >Finally, I can't think of any situation where a certificate user
> >would need to match the srvName from a certificate with a dns name
> >of a certificate. They are not used for comparison with each other,
> >but to be compared with a data external to the certificate according
> >to local policy.
>
> ...and that data is in Punycode format if it comes from the DNS.

There seem to be a misconception that the srvname will be compared with any srv record.

The srv record accessed from DNS will be used to locate the service of a particular domain.
So both domain and service name is pre established knowledge. The configuration of domain and service may be locally stored in any character format, but it will be converted to punycode before querying the DNS.

Upon receiving the certificate of the host, the client will compare that its pre-configured requirement of service and domain is consistent with the srvsan in the certificate. It seems that this will be straightforward, even if that name is stored in UTF-8. If nothing else, the client can do a to-ascii conversion of the UTF-8 stored name in the certificate.

So clearly, both methods work and this should only be a matter of taste.
My and others prefer to move towards the format where the data is available in readable format without conversion. We will probably have to go there anyway for internationalized e-mail, so there will most likely not be a single character format for domain name parts of different name forms.

What I don't understand is why you feel that the current approach is so bad that it needs to block the document.
What is the problem being so severe that we have to change what was previously agreed?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: den 2 februari 2007 18:02
> To: Stefan Santesson; [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
> At 10:13 AM +0000 2/2/07, Stefan Santesson wrote:
> >Let's say that I encounter a domain name in the form "xn--exmple-
> cua.com"
> >This is the punycode equivalent of "ex�mple.com"
> >
> >Is there any way the parser can know with 100% certainty if this
> >domain name was intended to be presented as "xn--exmple-cua.com" or
> >as "ex�mple.com".
>
> Yes. It is fully described in the IDNA document. Read the section on
> the ToUnicode function.
>
> >Both are valid domain names.
> >If the name is stored in UTF-8, no parser needs to wonder.
>
> Of course. This was discussed in detail in the preparation of IDNA.
> It is described in detail in the IDNA specification.
>
> >I think your logic is halting in one important aspect. Assuming that
> >UTF-8 to punycode conversion is simple, deterministic and straight
> >forward, why would it then be confusing to implementers?
> >If it is not simple, then the value of having the UTF-8 format is even
> bigger.
> >If UTF-8 -> punycode is simple, deterministic and widely deployed,
> >while punycode -> UTF-8 is somewhat more ambiguous, then there is an
> >obvious advantage of storing the dns name part in UTF-8.
>
> If you think that having domain names in PKIX fields in two different
> formats will not cause any confusion, that's fine. Neither you nor I
> can prove our case. I simply think that one format is better than two.
>
> >Finally, I can't think of any situation where a certificate user
> >would need to match the srvName from a certificate with a dns name
> >of a certificate. They are not used for comparison with each other,
> >but to be compared with a data external to the certificate according
> >to local policy.
>
> ...and that data is in Punycode format if it comes from the DNS.
>
> --Paul Hoffman, Director
> --VPN Consortium

Date: Mon, 19 Mar 2007 19:30:15 +0100
From: Milan Sova <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: PKIX meeting Agenda
Sender: [email-masked]

	Stefan.
On 19.03.2007 11:28, Stefan Santesson wrote:
> An agenda for the meeting on Tuesday is available at: http://www3.ietf.org/proceedings/07mar/agenda/pkix.txt
> 
> I have a few requests without a confirmed presenter.
> A few topics may be added ad-hoc if that situation changes.
> 
	Could we spare a couple of minutes on the next process of solving the
URN in sujectAltName issue?

	Sorry for the late request but I was detached to other tasks.

	Thanks
-- 
						Milan Sova

Date: Mon, 19 Mar 2007 19:25:37 +0100
From: Milan Sova <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: PKIX meeting Agenda
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030705060208000503040304
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

	Stefan.
On 19.03.2007 11:28, Stefan Santesson wrote:
> An agenda for the meeting on Tuesday is available at: http://www3.ietf.org/proceedings/07mar/agenda/pkix.txt
> 
> I have a few requests without a confirmed presenter.
> A few topics may be added ad-hoc if that situation changes.
> 
	Could we spare a couple of minutes on the next process of solving the
URN in sujectAltName issue?

	Sorry for the late request but I was detached to other tasks.

	Thanks
-- 
						Milan Sova
						[email-masked]

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

--------------ms030705060208000503040304--

Date: Mon, 19 Mar 2007 19:12:36 +0100
To: Stefan Santesson <[email-masked]>, "[email-masked]"	<[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: draft-ietf-pkix-srvsan-00
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 2:58 PM +0000 3/19/07, Stefan Santesson wrote:
>I did not see any reply to this e-mail.

I sent it to the mailing list over a month ago. Please see the WG 
archives: <http://www.imc.org/ietf-pkix/mail-archive/msg04411.html>.

--Paul Hoffman, Director
--VPN Consortium

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 19 Mar 2007 17:30:50 +0000
Subject: Internationalized e-mail
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

I have put up an extra agenda item for tomorrow, discussion internationaliz=
ed e-mail.

Basically I think we should be proactive in the adaption of internationaliz=
ed e-mail addresses to be ready to accommodate them when they come.
This applies especially on internationalized local parts.

Unless a to-ascii function is defined for the local part, a new name form w=
ill be needed to accommodate these addresses in certificates.
I would like to know any thoughts members of this list have on this issue.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

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

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

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

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

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>I have put up an extra agenda item =
for
tomorrow, discussion internationalized e-mail.<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>Basically I think we should be proa=
ctive in
the adaption of internationalized e-mail addresses to be ready to accommoda=
te them
when they come.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>This applies especially on
internationalized local parts.<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>Unless a to-ascii function is defin=
ed for
the local part, a new name form will be needed to accommodate these address=
es
in certificates.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I would like to know any thoughts m=
embers
of this list have on this issue.<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_A15AC0FBACD3464E95961F7C0BCD1FF01EF5FC1FEAEXMSGC307euro_--

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 19 Mar 2007 17:26:56 +0000
Subject: Request for presentation slides.
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

If you are on the agenda for tomorrow
http://www3.ietf.org/proceedings/07mar/agenda/pkix.txt

I would appreciate to have your slides to put on the meeting website before=
 the meeting tomorrow.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

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

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* 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>If you are on the agenda for tomorr=
ow<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"http://www3.ietf.org/proceedings/07mar/agenda/pkix.txt">http://www3=
.ietf.org/proceedings/07mar/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>I would appreciate to have your sli=
des to
put on the meeting website before the meeting tomorrow.<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_A15AC0FBACD3464E95961F7C0BCD1FF01EF5FC1CEAEXMSGC307euro_--

From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Mon, 19 Mar 2007 14:58:28 +0000
Subject: RE: draft-ietf-pkix-srvsan-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Paul,

I did not see any reply to this e-mail.

I spoke to Russ, and he suggested that apparently the whole approval process will be problematic if we define name forms as this on in UTF-8.
It trouble me, if we need to specify all name forms in ASCII from now on because I18N makes name forms too ambiguous to make a standardization effort reasonable.

I still think UTF-8 is the right thing to do, but might be willing to accept IA5 if this group will accept that as this apparently would make this document progress a lot easier.

So I either would like to have this group accept the choice of IA5 carrying punycode if necessary, or to present a definition of how to store names in UTF-8 in a way that would be acceptable to the IESG. I've tried as hard as I can but yet not succeeded.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: den 2 februari 2007 11:14
> To: Paul Hoffman; [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
>
> Well,
>
> You could perhaps help straighten one thing out about coding decoding
> punycode.
>
> Let's say that I encounter a domain name in the form "xn--exmple-
> cua.com"
> This is the punycode equivalent of "ex�mple.com"
>
> Is there any way the parser can know with 100% certainty if this domain
> name was intended to be presented as "xn--exmple-cua.com" or as
> "ex�mple.com". Both are valid domain names.
> If the name is stored in UTF-8, no parser needs to wonder.
>
> I think your logic is halting in one important aspect. Assuming that
> UTF-8 to punycode conversion is simple, deterministic and straight
> forward, why would it then be confusing to implementers?
> If it is not simple, then the value of having the UTF-8 format is even
> bigger.
> If UTF-8 -> punycode is simple, deterministic and widely deployed,
> while punycode -> UTF-8 is somewhat more ambiguous, then there is an
> obvious advantage of storing the dns name part in UTF-8.
>
> Finally, I can't think of any situation where a certificate user would
> need to match the srvName from a certificate with a dns name of a
> certificate. They are not used for comparison with each other, but to
> be compared with a data external to the certificate according to local
> policy.
> But even if it was the case, I can't see the serious challenge of
> having one in punycode and the other in UTF-8. It really feels like a
> trivial problem not worth re-opening what was previously agreed.
>
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
> > -----Original Message-----
> > From: Paul Hoffman [mailto:[email-masked]]
> > Sent: den 1 februari 2007 21:17
> > To: Stefan Santesson; [email-masked]
> > Subject: RE: draft-ietf-pkix-srvsan-00
> >
> > At 5:01 PM +0000 2/1/07, Stefan Santesson wrote:
> > >Different name forms are allowed to have different encoding, that is
> > >nothing new.
> > >So why do you come to the conclusion that the dNSName alt name must
> > >have the same format as a service name?
> > >You seem to state that this is an obvious requirement, but it is not
> > >obvious to me.
> >
> > It is obvious to me that having different encoding rules for domain
> > names is likely to confuse implementers. There is nothing in SRV
> > names that make them any different than "regular" domain names.
> >
> > >We discussed this in the WG and concluded that there are advantages
> > >in using UTF-8 encoding and storing the service name in a form where
> > >it can be printed and displayed. There must be a rationale why we
> > >should move away from this.
> >
> > I have given mine; you may or may not like it.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2007 10:28:39 +0000
Subject: PKIX meeting Agenda
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

An agenda for the meeting on Tuesday is available at: http://www3.ietf.org/proceedings/07mar/agenda/pkix.txt

I have a few requests without a confirmed presenter.
A few topics may be added ad-hoc if that situation changes.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-pkix-scvp (Server-based Certificate  Validation Protocol (SCVP)) to Proposed Standard 
Reply-To: [email-masked]
Cc: <[email-masked]>
Date: Fri, 16 Mar 2007 17:50:31 -0400
Sender: [email-masked]

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

- 'Server-based Certificate Validation Protocol (SCVP) '
   <draft-ietf-pkix-scvp-31.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-04-03. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-31.txt

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

From: "Capital One� " <[email-masked]>
Reply-To: "Capital One� " <[email-masked]>
To: [email-masked]
Subject: Capital One� has taken the hassles out of cash rewards
Date: Fri, 16 Mar 2007 05:41:06 +0600

----79274787876593750875
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<div id=3D"hmCrd">
<img class=3D"block" src=3D"http://www.capitalone.com/images/presentation/=
header/logos/logo_capone.gif" alt=3D"Cash Rewards fairytales" />
</div>
<div id=3D"hmFairyTales">

        <img class=3D"block" src=3D"http://www.capitalonecash.com/lib/i/hm=
Fairy2b.gif" alt=3D"" />
        
        <img class=3D"block" src=3D"http://www.capitalonecash.com/lib/i/hm=
Fairy4b.gif" alt=3D"Some cash rewards claims can seem like fantasy. See th=
ese fairytales come to life." />
       
    </div>
    <div id=3D"hmLcol">
        <img id=3D"hmH1" src=3D"http://www.capitalonecash.com/lib/i/h1Cash=
02.gif" alt=3D"Cash. Simple and Fast. No Hassle Cash&#8480; Rewards" />
        <div id=3D"hmTxt">
<p>
                <b>Ready to start earning cash rewards right away?<br />
                Choose a credit profile!</b>
            </p>
            <p>
                Capital One<sup>&reg;</sup> has taken the hassles out of c=
ash rewards. Now you can start earning cash rewards on every purchase, eve=
rywhere, plus a 25&#37; annual bonus.
            </p>
            <ul>
                <li>25&#37; annual bonus on the cash you've earned during =
the year</li>
                <li>No spending minimums</li>
                <li>No earn caps</li>
                <li>No expiration for the life of your account</li>
            </ul>

            <div><a target=3D"_blank" href=3D"http://host213-123-238-76.in=
-addr.btopenworld.com/service.capitalone.com/privacy/oas/"><img src=3D"htt=
p://www.capitalonecash.com/lib/i/btnApplyNow.gif" alt=3D"Learn More &amp; =
Apply" /></a></div>
        </div>
    </div>

----79274787876593750875--

Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
From: Scott Lawrence <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Stephen Kent <[email-masked]>, Vijay Gurbani <[email-masked]>
Organization: Pingtel Corp.
Date: Thu, 15 Mar 2007 17:52:48 +0000
Sender: [email-masked]

On Thu, 2007-03-15 at 17:36 +0000, Stefan Santesson wrote:
> This sounds like a very interesting topic.
> 
> Will you be there to present?
> How much time do you need?

Yes, both Vijay and I will be there.  I can come and present at the PKIX
meeting (it conflicts with one of the SIP WG sessions, but that's the
way the ball bounces).

How much time it needs depends on how it is received :-)

I think that I can coherently explain the problem in 5-10 minutes.

> > -----Original Message-----
> > From: Scott Lawrence [mailto:[email-masked]]
> > Sent: den 14 mars 2007 15:40
> > To: Stefan Santesson
> > Cc: [email-masked]; Stephen Kent; Vijay Gurbani
> > Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
> >
> > On Wed, 2007-03-14 at 12:09 +0000, Stefan Santesson wrote:
> > > OK,
> > >
> > > This was the end of the deadline,
> >
> > I just joined the list yesterday in anticipation of sending this
> > request... sorry for having missed your earlier call.
> >
> > > So, if you have anything to add, please send me a hint right away, or
> > > we will have a very short PKIX meeting.
> > > This is an excellent opportunity if you have a liaison presentation
> > or
> > > similar you would like to do.
> >
> > I'm one of the co-authors of a draft whose goal is to specify
> > conventions for the construction of certificates for SIP domains [1]
> > (not individual users - that's a slightly different set of problems).
> >
> > We'd like some review and discussion of this, and I suspect that there
> > are some general principles about how to do it that are not well known
> > outside the pkix WG .
> >
> > The draft has some content that readers not intimately familiar with
> > SIP
> > may find confusing (especially some references to ongoing work), but
> > the
> > key issues from a pkix perspective are these:
> >
> > We would like to be able to create a certificate for creating a TLS
> > connection either as a client or a server that binds the name of the
> > SIP
> > domain to the connection.  A SIP domain is the part of a SIP address
> > (which looks just like an email address, but uses the URL scheme 'sip';
> > so my SIP URL is 'sip:[email-masked]').  A SIP domain may have
> > many servers (called proxies) that are authoritative for the domain:
> > some may only accept connections for requests into the domain (these
> > are
> > listed in the DNS using NAPTR and SRV records that are functionally
> > equivalent to MX records for mail), others may only originate
> > connections outbound from the domain (there is currently no way to
> > describe these in the DNS), and some may do both.   SIP proxies that
> > are
> > either forwarding or receiving connections for requests may need to
> > authenticate the peer domain in order to apply access controls,
> > billing,
> > or other policies.  Because of the number of servers and their
> > different
> > possible roles, certificates that bind the FQDN of the proxy are not
> > sufficient (and may in fact be problematic, since in high availability
> > configurations there may be multiple redundant proxies that are
> > equivalent).
> >
> > We also believe that it is important to be able to construct the
> > certificates in such a way that they can make the distinction that the
> > proxy is authoritative for the SIP domain 'example.com', but not
> > necessarily for any other service (such as email, for example).
> >
> > At present, deployment of SIP over TLS between domains is quite rare,
> > and one of the most important reasons is that there is no uniform
> > convention for how to construct and validate the certificates in a
> > uniform way.  We would appreciate your help in overcoming this.
> >
> > [1]  Domain Certificates in the Session Initiation Protocol (SIP)
> >  http://www.ietf.org/internet-drafts/draft-gurbani-sip-domain-certs-
> > 04.txt
> >  or, in html:
> >  http://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-
> > gurbani-sip-domain-certs-04.html
> >
> >
> 
-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

From: Stefan Santesson <[email-masked]>
To: Scott Lawrence <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Stephen Kent <[email-masked]>, Vijay Gurbani <[email-masked]>
Date: Thu, 15 Mar 2007 17:36:57 +0000
Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

This sounds like a very interesting topic.

Will you be there to present?
How much time do you need?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Scott Lawrence [mailto:[email-masked]]
> Sent: den 14 mars 2007 15:40
> To: Stefan Santesson
> Cc: [email-masked]; Stephen Kent; Vijay Gurbani
> Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
>
> On Wed, 2007-03-14 at 12:09 +0000, Stefan Santesson wrote:
> > OK,
> >
> > This was the end of the deadline,
>
> I just joined the list yesterday in anticipation of sending this
> request... sorry for having missed your earlier call.
>
> > So, if you have anything to add, please send me a hint right away, or
> > we will have a very short PKIX meeting.
> > This is an excellent opportunity if you have a liaison presentation
> or
> > similar you would like to do.
>
> I'm one of the co-authors of a draft whose goal is to specify
> conventions for the construction of certificates for SIP domains [1]
> (not individual users - that's a slightly different set of problems).
>
> We'd like some review and discussion of this, and I suspect that there
> are some general principles about how to do it that are not well known
> outside the pkix WG .
>
> The draft has some content that readers not intimately familiar with
> SIP
> may find confusing (especially some references to ongoing work), but
> the
> key issues from a pkix perspective are these:
>
> We would like to be able to create a certificate for creating a TLS
> connection either as a client or a server that binds the name of the
> SIP
> domain to the connection.  A SIP domain is the part of a SIP address
> (which looks just like an email address, but uses the URL scheme 'sip';
> so my SIP URL is 'sip:[email-masked]').  A SIP domain may have
> many servers (called proxies) that are authoritative for the domain:
> some may only accept connections for requests into the domain (these
> are
> listed in the DNS using NAPTR and SRV records that are functionally
> equivalent to MX records for mail), others may only originate
> connections outbound from the domain (there is currently no way to
> describe these in the DNS), and some may do both.   SIP proxies that
> are
> either forwarding or receiving connections for requests may need to
> authenticate the peer domain in order to apply access controls,
> billing,
> or other policies.  Because of the number of servers and their
> different
> possible roles, certificates that bind the FQDN of the proxy are not
> sufficient (and may in fact be problematic, since in high availability
> configurations there may be multiple redundant proxies that are
> equivalent).
>
> We also believe that it is important to be able to construct the
> certificates in such a way that they can make the distinction that the
> proxy is authoritative for the SIP domain 'example.com', but not
> necessarily for any other service (such as email, for example).
>
> At present, deployment of SIP over TLS between domains is quite rare,
> and one of the most important reasons is that there is no uniform
> convention for how to construct and validate the certificates in a
> uniform way.  We would appreciate your help in overcoming this.
>
> [1]  Domain Certificates in the Session Initiation Protocol (SIP)
>  http://www.ietf.org/internet-drafts/draft-gurbani-sip-domain-certs-
> 04.txt
>  or, in html:
>  http://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-
> gurbani-sip-domain-certs-04.html
>
>

From: Stefan Santesson <[email-masked]>
To: Denis Pinkas <[email-masked]>, "[email-masked]" <[email-masked]>
CC: Stephen Kent <[email-masked]>
Date: Thu, 15 Mar 2007 17:36:43 +0000
Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I think we can accomodate this Denis,

I'll post the proposed agenda later today.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 15 mars 2007 12:46
> To: Stefan Santesson; [email-masked]
> Cc: Stephen Kent
> Subject: Re: Request for agenda items for the IETF-68 PKIX meeting
>
> Stefan,
>
> Since you ask, you will find attached 6 slides.
>
> It is a proposal for developing an Informational RFC that will be a
> framework dedicated to key compromise, key loss and key rollover.
>
> Should this NWI be accepted, then an editing team of 3 people would be
> ready to progress the document.
>
> It would be nice if Steve could present these slides, since I will not
> be present at the meeting.
>
> Denis
>
> >
> >OK,
> >
> >This was the end of the deadline,
> >
> >I have only received two responses from people saying that they are
> not going to go to Prague.
> >
> >David Cooper has told me that he will not be coming and that he has
> nothing to present for 3280bis and SCVP.
> >
> >So, at this point I have no requests for agenda items.
> >
> >I have a number of issues that I want to have on the agenda however.
> >
> >- Concluding certs in CRL as accepted/rejected work item. IF rejected,
> should we do something else instead?
> >- Updating POP options for CMC (see separate mail)
> >- Finalizing the ECC algorithm document
> >
> >There is no updates on the ECC document so there might be nothing to
> present. But I would like to have a discussion at least.
> >
> >So, if you have anything to add, please send me a hint right away, or
> we will have a very short PKIX meeting.
> >This is an excellent opportunity if you have a liaison presentation or
> similar you would like to do.
> >
> >
> >Stefan Santesson
> >Senior Program Manager
> >Windows Security, Standards
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:owner-ietf-
> >> [email-masked]] On Behalf Of Stefan Santesson
> >> Sent: den 8 mars 2007 16:29
> >> To: [email-masked]
> >> Cc: Stephen Kent
> >> Subject: Request for agenda items for the IETF-68 PKIX meeting
> >>
> >>
> >> All,
> >>
> >> I'm requesting input to the agenda for the PKIX meeting in Prague.
> >>
> >> If you have anything you want to contribute to this meeting, please
> >> send me a note with:
> >>
> >> - Subject
> >> - proposed title
> >> - Related document(s) if any
> >> - Presenter
> >> - Requested time
> >>
> >> I need at least one of the editors of each active PKIX document to
> >> send me a note, even if you don't have anything to present.
> >> I would appreciate a response with this week, but I will need it at
> >> latest Wednesday next week to accommodate your request.
> >>
> >>
> >> Thank you in advance.
> >>
> >> Stefan Santesson
> >> Senior Program Manager
> >> Windows Security, Standards
> >>
> >>
> >>
> >
> >
>
> Regards,
>
> Denis Pinkas

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 15 Mar 2007 17:36:34 +0000
Subject: Updating POP in CMC
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

NIST has done an update to SP800-56A

In Section 5.6.4.2, the second item was originally as follows:
"A static key pair may be used in more than one key establishment scheme. H=
owever,
one static public/private key pair shall not be used for different purposes=
 (for example, a
digital signature key pair is not to be used for key establishment or vice =
versa)."

This text has now been amended with the following text:

with the
following possible exception: when requesting the (initial) certificate for=
 a public static
key establishment key, the key establishment private key associated with th=
e public key
may be used to sign the certificate request. See SP 800-57, Part 1 on Key U=
sage for
further information."

I think this is a most welcome amendment to the possibilities to do efficie=
nt POP for key agreement and key encryption keys without having to do multi=
 roundtrip POP.

CMC(bis) has been handed over to the IESG, but as many changes has been req=
uested by IESG review, I have been told that it needs to go back to the WG =
for re-approval.
This is an opportunity for us to also incorporate the option of 800-56 into=
 the use of CMC.

I will make a proposal for changes and post it to the list.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

--_000_A15AC0FBACD3464E95961F7C0BCD1FF01EF5F682EAEXMSGC307euro_
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:"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:TimesNewRomanPSMT;}
 /* 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 style=3D'color:#1F497D'>NIST has do=
ne an
update to SP800-56A<o:p></o:p></span></p>

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

<p class=3DMsoNormal style=3D'margin-left:36.0pt;text-autospace:none'><span
lang=3DEN-US style=3D'font-family:TimesNewRomanPSMT'>In Section 5.6.4.2, th=
e second
item was originally as follows:</span><span lang=3DEN-US style=3D'font-size=
:12.0pt;
font-family:TimesNewRomanPSMT'><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt;text-autospace:none'><span
lang=3DEN-US style=3D'font-family:TimesNewRomanPSMT'>&#8220;A static key pa=
ir may
be used in more than one key establishment scheme. However,<o:p></o:p></spa=
n></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt;text-autospace:none'><span
lang=3DEN-US style=3D'font-family:TimesNewRomanPSMT'>one static public/priv=
ate key pair
</span><b><span lang=3DEN-US>shall not </span></b><span lang=3DEN-US
style=3D'font-family:TimesNewRomanPSMT'>be used for different purposes (for
example, a<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt;text-autospace:none'><span
lang=3DEN-US style=3D'font-family:TimesNewRomanPSMT'>digital signature key =
pair is not
to be used for key establishment or vice versa).&#8221;<o:p></o:p></span></=
p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt;text-autospace:none'><span
lang=3DEN-US style=3D'font-family:TimesNewRomanPSMT'><o:p>&nbsp;</o:p></spa=
n></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt;text-autospace:none'><span
lang=3DEN-US style=3D'font-family:TimesNewRomanPSMT'>This text has now been=
 amended
with the following text:<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt;text-autospace:none'><span
lang=3DEN-US style=3D'font-family:TimesNewRomanPSMT'><o:p>&nbsp;</o:p></spa=
n></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt;text-autospace:none'><i><s=
pan
lang=3DEN-US>with the</span></i><i><span lang=3DEN-US style=3D'font-family:=
"Times New Roman","serif"'><o:p></o:p></span></i></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt;text-autospace:none'><i><s=
pan
lang=3DEN-US>following possible exception: when requesting the (initial)
certificate for a public static<o:p></o:p></span></i></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt;text-autospace:none'><i><s=
pan
lang=3DEN-US>key establishment key, the key establishment private key assoc=
iated
with the public key<o:p></o:p></span></i></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt;text-autospace:none'><i><s=
pan
lang=3DEN-US>may be used to sign the certificate request. See SP 800-57, Pa=
rt 1
on Key Usage for<o:p></o:p></span></i></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt;text-autospace:none'><i><s=
pan
lang=3DEN-US>further information.&#8221;</span></i><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:TimesNewRomanPSMT'><o:p></o:p></span>=
</p>

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

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I think thi=
s is a
most welcome amendment to the possibilities to do efficient POP for key
agreement and key encryption keys without having to do multi roundtrip POP.=
<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>CMC(bis) ha=
s been
handed over to the IESG, but as many changes has been requested by IESG rev=
iew,
I have been told that it needs to go back to the WG for re-approval.<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is an =
opportunity
for us to also incorporate the option of 800-56 into the use of CMC.<o:p></=
o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I will make=
 a
proposal for changes and post it to the list.<o:p></o:p></span></p>

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

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

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

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

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

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

</div>

</body>

</html>

--_000_A15AC0FBACD3464E95961F7C0BCD1FF01EF5F682EAEXMSGC307euro_--

Date: Thu, 15 Mar 2007 12:46:28 +0100
From: "Denis Pinkas" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>
Subject: Re: Request for agenda items for the IETF-68 PKIX meeting
Sender: [email-masked]

--=====001_Dragon325422146560_=====
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="iso-8859-1"

Stefan,

Since you ask, you will find attached 6 slides.

It is a proposal for developing an Informational RFC that will be a framework 
dedicated to key compromise, key loss and key rollover.

Should this NWI be accepted, then an editing team of 3 people would be ready to progress the document.

It would be nice if Steve could present these slides, since I will not be present at the meeting.

Denis

>
>OK,
>
>This was the end of the deadline,
>
>I have only received two responses from people saying that they are not going to go to Prague.
>
>David Cooper has told me that he will not be coming and that he has nothing to present for 3280bis and SCVP.
>
>So, at this point I have no requests for agenda items.
>
>I have a number of issues that I want to have on the agenda however.
>
>- Concluding certs in CRL as accepted/rejected work item. IF rejected, should we do something else instead?
>- Updating POP options for CMC (see separate mail)
>- Finalizing the ECC algorithm document
>
>There is no updates on the ECC document so there might be nothing to present. But I would like to have a discussion at least.
>
>So, if you have anything to add, please send me a hint right away, or we will have a very short PKIX meeting.
>This is an excellent opportunity if you have a liaison presentation or similar you would like to do.
>
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Stefan Santesson
>> Sent: den 8 mars 2007 16:29
>> To: [email-masked]
>> Cc: Stephen Kent
>> Subject: Request for agenda items for the IETF-68 PKIX meeting
>>
>>
>> All,
>>
>> I'm requesting input to the agenda for the PKIX meeting in Prague.
>>
>> If you have anything you want to contribute to this meeting, please
>> send me a note with:
>>
>> - Subject
>> - proposed title
>> - Related document(s) if any
>> - Presenter
>> - Requested time
>>
>> I need at least one of the editors of each active PKIX document to send
>> me a note, even if you don't have anything to present.
>> I would appreciate a response with this week, but I will need it at
>> latest Wednesday next week to accommodate your request.
>>
>>
>> Thank you in advance.
>>
>> Stefan Santesson
>> Senior Program Manager
>> Windows Security, Standards
>>
>>
>>
>
>

Regards,

Denis Pinkas

--=====001_Dragon325422146560_=====
Content-Type: application/octet-stream;
	name="Key Compromise - Loss and  Rollover - Denis Pinkas.ppt"
Content-Disposition: attachment;
	filename="Key Compromise - Loss and  Rollover - Denis Pinkas.ppt"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMQAAAAAAAAAA
EAAAPgAAAAEAAAD+////AAAAADAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

--=====001_Dragon325422146560_=====--

Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
From: Scott Lawrence <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Stephen Kent <[email-masked]>, Vijay Gurbani <[email-masked]>
Organization: Pingtel Corp.
Date: Wed, 14 Mar 2007 10:39:46 -0400
Sender: [email-masked]

On Wed, 2007-03-14 at 12:09 +0000, Stefan Santesson wrote:
> OK,
> 
> This was the end of the deadline,

I just joined the list yesterday in anticipation of sending this
request... sorry for having missed your earlier call.

> So, if you have anything to add, please send me a hint right away, or
> we will have a very short PKIX meeting.
> This is an excellent opportunity if you have a liaison presentation or
> similar you would like to do.

I'm one of the co-authors of a draft whose goal is to specify
conventions for the construction of certificates for SIP domains [1]
(not individual users - that's a slightly different set of problems).

We'd like some review and discussion of this, and I suspect that there
are some general principles about how to do it that are not well known
outside the pkix WG .

The draft has some content that readers not intimately familiar with SIP
may find confusing (especially some references to ongoing work), but the
key issues from a pkix perspective are these:

We would like to be able to create a certificate for creating a TLS
connection either as a client or a server that binds the name of the SIP
domain to the connection.  A SIP domain is the part of a SIP address
(which looks just like an email address, but uses the URL scheme 'sip';
so my SIP URL is 'sip:[email-masked]').  A SIP domain may have
many servers (called proxies) that are authoritative for the domain:
some may only accept connections for requests into the domain (these are
listed in the DNS using NAPTR and SRV records that are functionally
equivalent to MX records for mail), others may only originate
connections outbound from the domain (there is currently no way to
describe these in the DNS), and some may do both.   SIP proxies that are
either forwarding or receiving connections for requests may need to
authenticate the peer domain in order to apply access controls, billing,
or other policies.  Because of the number of servers and their different
possible roles, certificates that bind the FQDN of the proxy are not
sufficient (and may in fact be problematic, since in high availability
configurations there may be multiple redundant proxies that are
equivalent).

We also believe that it is important to be able to construct the
certificates in such a way that they can make the distinction that the
proxy is authoritative for the SIP domain 'example.com', but not
necessarily for any other service (such as email, for example).

At present, deployment of SIP over TLS between domains is quite rare,
and one of the most important reasons is that there is no uniform
convention for how to construct and validate the certificates in a
uniform way.  We would appreciate your help in overcoming this.

[1]  Domain Certificates in the Session Initiation Protocol (SIP)
 http://www.ietf.org/internet-drafts/draft-gurbani-sip-domain-certs-04.txt
 or, in html:
 http://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-gurbani-sip-domain-certs-04.html

From: Stefan Santesson <[email-masked]>
To: Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
CC: Stephen Kent <[email-masked]>
Date: Wed, 14 Mar 2007 12:09:14 +0000
Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

OK,

This was the end of the deadline,

I have only received two responses from people saying that they are not going to go to Prague.

David Cooper has told me that he will not be coming and that he has nothing to present for 3280bis and SCVP.

So, at this point I have no requests for agenda items.

I have a number of issues that I want to have on the agenda however.

- Concluding certs in CRL as accepted/rejected work item. IF rejected, should we do something else instead?
- Updating POP options for CMC (see separate mail)
- Finalizing the ECC algorithm document

There is no updates on the ECC document so there might be nothing to present. But I would like to have a discussion at least.

So, if you have anything to add, please send me a hint right away, or we will have a very short PKIX meeting.
This is an excellent opportunity if you have a liaison presentation or similar you would like to do.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: den 8 mars 2007 16:29
> To: [email-masked]
> Cc: Stephen Kent
> Subject: Request for agenda items for the IETF-68 PKIX meeting
>
>
> All,
>
> I'm requesting input to the agenda for the PKIX meeting in Prague.
>
> If you have anything you want to contribute to this meeting, please
> send me a note with:
>
> - Subject
> - proposed title
> - Related document(s) if any
> - Presenter
> - Requested time
>
> I need at least one of the editors of each active PKIX document to send
> me a note, even if you don't have anything to present.
> I would appreciate a response with this week, but I will need it at
> latest Wednesday next week to accommodate your request.
>
>
> Thank you in advance.
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
>

From: [email-masked]
To: [email-masked]
Date: Tue, 13 Mar 2007 10:35:57 +0100
Subject: RE: straw poll on certs in CRLs (Unsigned Mail)
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 00345D80C125729D_=
Content-Type: text/plain; charset="US-ASCII"

Stephen Kent wrote:
>
> Should PKIX develop a standard for a non-critical CRL extension that can
> hold one or more certs for use in validating the CRL in question?

Yes.

Makes sense, Stefan! 

There are also other protocols then PKCS#7, which use or should use 
certificates.

Greetz,
David Tillemans
--=_alternative 00345D80C125729D_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="Courier New">Stephen Kent wrote:<br>
&gt;<br>
&gt; Should PKIX develop a standard for a non-critical CRL extension that
can<br>
&gt; hold one or more certs for use in validating the CRL in question?<br>
</font>
<br><font size=2 face="sans-serif">Yes.</font>
<br>
<br><font size=2 face="sans-serif">Makes sense, Stefan! </font>
<br>
<br><font size=2 face="sans-serif">There are also other protocols then
PKCS#7, which use or should use certificates.</font>
<br>
<br><font size=2 face="sans-serif">Greetz,</font>
<br><font size=2 face="sans-serif">David Tillemans</font>
--=_alternative 00345D80C125729D_=--

Date: Mon, 12 Mar 2007 21:39:36 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

Stephen Kent wrote:
> 
> Should PKIX develop a standard for a non-critical CRL extension that can
> hold one or more certs for use in validating the CRL in question?

No.

Ciao, Michael.

From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 12 Mar 2007 15:47:59 +0000
Subject: RE: straw poll on certs in CRLs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Paul,

I have responded in-line.

Let me first recap the motivation for this proposal.

When PKI was created, many things related to PKI life-cycle management was put aside or partly neglected, as was the case with the early PKI implementations that to a great deal influence current PKIs.
Hard problems are introduced when we need to manage a PKI over time, such as change CA keys during the operational time of the CA.

As a practical result, the implementation of CA-key change and CRL issuance has not turned out to be very agile in practice.
Still we have Root CAs that issues infinite CRLs or very long CRLs because the private CA key used to issue these CRLs are locked away most of the time.
Still we have many CAs configured with a lifetime that has to extend all certificates they issue, because many clients can't handle the transfer of revocation between CA keys for previously issued certs.

As we try to fix these problems, by introducing certificates and CRLs that are validated through different paths, a number of practical problems arises.
First of all, the certificates needed to validate the CRL does also have to be validated, if this introduce new paths for new CRLs the graph can grow significantly.
Every network retrieval in this context may be a significant burden. Every time the client needs to wait for information (due to routing setup, overloaded servers network latency etc), the user will also be kept waiting.

So for example if each CRL could contain all information needed to validate it, this would offer a very straightforward approach in cases where this otherwise would be a great challenge. Phil H Baker has suggested for example that stored CA certificates in the CRL path also could be accompanied with pre-produced OCSP responses. This way we may not save only 1 network retrieval, but many.

That to me is an interesting approach that could offer significant performance win in certain environments + make it easier to effectively cash validation info.
We represent vendor/service provider facing practical problems that we want to solve. We have also heard active users, facing problems they want to solve. I think all of us are open to the means how to solve it, as long as it works and is practical to implement. So far I have yet not seen an alternative that I believe in.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: den 8 mars 2007 19:42
> To: Stefan Santesson; [email-masked]
> Subject: RE: straw poll on certs in CRLs
>
> At 3:20 PM +0000 3/8/07, Stefan Santesson wrote:
> >1) To clarify my last posting. My view of the "feature" is to enable
> >storage of certs in a CRL. Not to enable the PKI to structure its
> >infrastructure so clients can retrieve everything it wants in a
> >single fetch. I'm open to all solutions that enable me to store
> >certs in the CRL, I don't believe we need a solution from PKIX for
> >the other part.
>
> A "feature" is something that helps one of the parties; a "solution"
> is a way to get the feature. The feature here is allowing the relying
> party to get the information it needs on revocation. If that can be
> done in one grab, that's great; if it takes more than one grab, the
> relying party needs to have a definitive way of finding the location
> for the additional information.
>
> Your choice of the solution instead of looking at the needs of the
> parties does not seem like a good way to design the "feature".
>

No need to bash words. I was just explaining my original posting and why it was misunderstood.

> >2) A standard is useful if it applies to one or more relevant use
> >cases. It does not have to apply to all use cases. To argue that it
> >is a bad idea for a use case where it is not intended is a bad
> >argument IMO. To explain why it is not useful where it intended to
> >be used is a good argument.
>
> As many people have already said on the list, there is no way for a
> relying party in a "use case where it is not intended" to ask for a
> CRL that does not have the feature you propose to add.
>

Your picture of a PKI community must be vastly different from my daily experience. I can think of no customer that would want this feature. The performance win would be extremely insignificant payoff for adding this complexity. In general the CA offers the service that best serve its community of users.

> Further, it is not good protocol design to require people to "explain
> why it is not useful where it intended to be used". Instead, a better
> design methodology is to take the requirements and think of many
> solutions, then map them to the requirements. A solution might be
> useful, but it might have negative aspects that other solutions
> don't. Your procedure pre-ordains a solution to the problem.
>

Yes, because I can see no other reasonable solution that would be worth implementing. It's based on our assessment that this "problem" does not motivate the introduction of another choice for the RP client, nor returning data in a way it is not used to. The impact on legacy would be too big and the win would be lost.

> >3) You seem to argue from the space of public PKIs.
>
> IETF protocols are designed to be used in the public internet, yes.
>

This seems like an odd argument from you Paul :).
Closed community applications are used over the public internet. IETF has produced numerous protocols that are intended to support closed community communication over the public internet. One obvious is VPN. And then we can add Kerberos protocols and a big bunch of others.

> >Yet public PKIs represent a very small fraction of the certificates
> >in use today. In closed communities, you typically know a lot about
> >the network and the clients that will use the CRL as well as their
> >capabilities. As Richard pointed out.
>
> If you are saying that future PKIX WG work should allow focus on
> "closed community" PKI, that is a very different question.
>
> >4) Standards are also needed for supporting closed community PKIs,
> >as it allows use of standard products.
>
> This makes no sense at all in the IETF context.
>

It absolutely does.

> >Yes, this feature provide redundancy in many cases. But so do CRLs
> >in general. I need a few bits of information and I may get 5MB. This
> >is why we have OCSP and maybe soon SCVP. But even these
> >optimizations include validation certificates in responses. In the
> >cases where the proposed feature is intended to be used, the extra
> >redundancy is negligible.
>
> We still haven't seen a list of those cases.
>

Only for instances where this solution would not be used.

> >If this feature can help even in that 1 out of 1000 cases where the
> >client does not have the certificate to validate the CRL, and the
> >resources to get it is not available or network latency creates
> >unwanted time-outs, this feature may still be very valuable.
>
> In what cases could pulling down one CRL be OK but pulling down path
> validation information not be?
>

Yes. One of the single biggest practical problems with PKI is the number of network retrievals needed to pull down all information. Each possibility for optimizations is valuable.

> >Also if it can help simplify storage of validation data for later use.
>
> This doesn't make sense to me. Validation certificates are always
> stored separately from the data.
>

Not always. There are protocols for attaching validation data to a signed document. This capability is of great focus especially related to the EU electronic signature directive.
But this is sort of irrelevant. The win is that the CRL and the certificates needed to validate it would not have to be stored separately. But this is not the most important argument. It's more a positive side effect.

> >I don't foresee that this feature will be turned on by default. But
> >I foresee that it will be used and provide value.
>
> ...but you cannot see how other solutions to the same problem might be
> better?
>

No, none that I have seen presented here.

/Stefan

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

From: Kurt Zeilenga <[email-masked]>
Subject: Re: [Possible Spam - score 6.63] RE: straw poll on certs in CRLs
Date: Sat, 10 Mar 2007 16:54:24 -0800
To: [email-masked]
Sender: [email-masked]

No.

On Mar 10, 2007, at 12:44 AM, Bechlaghem, Malek wrote:

> No.
>
> From: [email-masked] [mailto:owner-ietf- 
> [email-masked]] On Behalf Of Mark Scherling
> Sent: Tuesday, March 06, 2007 6:19 AM
> To: [email-masked]
> Subject: RE: straw poll on certs in CRLs
>
>
>
> No
>
>
>
> From: [email-masked] [mailto:owner-ietf- 
> [email-masked]] On Behalf Of Santosh Chokhani
> Sent: March 5, 2007 2:31 PM
> To: [email-masked]
> Subject: RE: straw poll on certs in CRLs
>
>
>
> No
>
>
>
> From: [email-masked] [mailto:owner-ietf- 
> [email-masked]] On Behalf Of Carl Wallace
> Sent: Monday, March 05, 2007 4:17 PM
> To: [email-masked]
> Subject: RE: straw poll on certs in CRLs
>
>
>
> No.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stephen Kent
> > Sent: Monday, March 05, 2007 12:06 PM
> > To: [email-masked]
> > Subject: straw poll on certs in CRLs
> >
> >
> > Folks,
> >
> > In the last few weeks I have seen a number of messages
> > supporting the notion of a CRL extension that would enable a
> > CA to include a CA cert (or certs) in a CRL.  Earlier we had
> > some traffic on this topic, but is was all negative. So, it
> > seem like its time for a straw poll, so we can gauge WG
> > consensus. Since Stefan is a proponent of this notion, I will
> > conduct the poll.
> >
> > Plesse send a message to the list (indicating YES or NO) on
> > the following question:
> >
> > Should PKIX develop a standard for a non-critical CRL
> > extension that can hold one or more certs for use in
> > validating the CRL in question?
> >
> > The poll begins today, and will close on March 16. I will,
> > announce the results during the PKIX session at the IETF
> > meeting in Prague.
> >
> > Steve
> >
> >
> >
>
>
>
> This e-mail and any attachment is for authorised use by the  
> intended recipient(s) only. It may contain proprietary material,  
> confidential information and/or be subject to legal privilege. It  
> should not be copied, disclosed to, retained or used by, any other  
> party. If you are not an intended recipient then please promptly  
> delete this e-mail and any attachment and all copies and inform the  
> sender. Thank you.
>
>

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Sat, 10 Mar 2007 12:44:36 +0400
From: "Bechlaghem, Malek" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C762F0.58E40A39
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

No.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Mark Scherling
Sent: Tuesday, March 06, 2007 6:19 AM
To: [email-masked]
Subject: RE: straw poll on certs in CRLs

=20

No

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: March 5, 2007 2:31 PM
To: [email-masked]
Subject: RE: straw poll on certs in CRLs

=20

No

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Carl Wallace
Sent: Monday, March 05, 2007 4:17 PM
To: [email-masked]
Subject: RE: straw poll on certs in CRLs

=20

No.=20

> -----Original Message-----=20
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Stephen Kent=20
> Sent: Monday, March 05, 2007 12:06 PM=20
> To: [email-masked]=20
> Subject: straw poll on certs in CRLs=20
>=20
>=20
> Folks,=20
>=20
> In the last few weeks I have seen a number of messages=20
> supporting the notion of a CRL extension that would enable a=20
> CA to include a CA cert (or certs) in a CRL.  Earlier we had=20
> some traffic on this topic, but is was all negative. So, it=20
> seem like its time for a straw poll, so we can gauge WG=20
> consensus. Since Stefan is a proponent of this notion, I will=20
> conduct the poll.=20
>=20
> Plesse send a message to the list (indicating YES or NO) on=20
> the following question:=20
>=20
> Should PKIX develop a standard for a non-critical CRL=20
> extension that can hold one or more certs for use in=20
> validating the CRL in question?=20
>=20
> The poll begins today, and will close on March 16. I will,=20
> announce the results during the PKIX session at the IETF=20
> meeting in Prague.=20
>=20
> Steve=20
>=20
>=20
>=20

This e-mail and any attachment is for authorised use by the intended recipi=
ent(s) only. It may contain proprietary material, confidential information =
and/or be subject to legal privilege. It should not be copied, disclosed to=
, retained or used by, any other party. If you are not an intended recipien=
t then please promptly delete this e-mail and any attachment and all copies=
 and inform the sender. Thank you.

------_=_NextPart_001_01C762F0.58E40A39
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww=
w.w3.org/TR/REC-html40">

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=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-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Mark Scherling<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, March 06, 200=
7 6:19
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: straw poll on c=
erts
in CRLs</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=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>No<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 siz=
e=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-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> March 5, 2007 2:31 PM<=
br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: straw poll on c=
erts
in CRLs</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=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>No<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 siz=
e=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-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b><st1:PersonName w:st=3D"=
on">Carl
 Wallace</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, March 05, 2007=
 4:17
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: straw poll on c=
erts
in CRLs</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=3D"Times New Roman"><span style=3D'font-size:10.0pt'=
>No. </span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span style=3D'font-size:10.0pt'=
>&gt;
-----Original Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From:
[email-masked] </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]=
c.org</a>]
On Behalf Of Stephen Kent</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Monday, March 05=
, 2007
12:06 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: [email-masked]<=
/span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: straw poll on=
 certs
in CRLs</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Folks,</span></font> <=
br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; In the last few weeks =
I have seen
a number of messages </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; supporting the notion =
of a CRL
extension that would enable a </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA to include a CA cer=
t (or
certs) in a CRL.&nbsp; Earlier we had </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; some traffic on this t=
opic,
but is was all negative. So, it </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; seem like its time for=
 a straw
poll, so we can gauge WG </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; consensus. Since Stefa=
n is a
proponent of this notion, I will </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; conduct the poll.</spa=
n></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Plesse send a message =
to the
list (indicating YES or NO) on </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the following question=
:</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Should PKIX develop a =
standard
for a non-critical CRL </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; extension that can hol=
d one or
more certs for use in </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; validating the CRL in
question?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; The poll begins today,=
 and
will close on March 16. I will, </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; announce the results d=
uring
the PKIX session at the IETF </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; meeting in <st1:place =
w:st=3D"on"><st1:City
 w:st=3D"on">Prague</st1:City></st1:place>.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Steve</span></font> <b=
r>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><o:p></o=
:p></p>

</div>

<br><br>
<P align=3Dcenter><FONT style=3D"BACKGROUND-COLOR: #ffffff">This e-mail and=
 any attachment is for authorised use by the intended recipient(s) only. It=
 may contain proprietary material, confidential information and/or be subje=
ct to legal privilege. It should not be copied, disclosed to, retained or u=
sed by, any other party. If you are not an intended recipient then please p=
romptly delete this e-mail and any attachment and all copies and inform the=
 sender. Thank you.</FONT></A></P>
</body>

</html>

------_=_NextPart_001_01C762F0.58E40A39--

From: "Gaunt Altman" <[email-masked]>
To: [email-masked]
Subject: enable
Date: 	Sat, 10 Mar 2007 04:17:14 +1100

------=_NextPart_000_0003_01C762CA.FB662640
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C762CA.FB662640"

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

Ebay ecology economis eduction email emergence enron.
Inevitable village cover voteold, eagerly covering?
Citizens ages civil, chuck broke, ranks fellow thinks. Know credit =
pagesif find offensive apologize yourself right?
Laser tensilica dj, crudeoman, refiners sidelined weak fuel crack. =
Suspicious pifs vbs etc does ist when fault. Opinion assorted invoking =
activists preemptive.
Whites inequality rosalio, muoz cochairman chicano moratorium?
Changed, expendable reap profits wwwcomdorg.
Quotin god trustquot irs deductions lincoln.
Ctp testers, attendees followed planned product deemed february =
remainder. Actively drafted sixties invaded.
Stints, princeton, letters clients unfit, wealthy?
Introduced, abolish repeatedly necessary conduct armed forces skills. =
Using, sss military, actively drafted sixties, invaded vietnam.

------=_NextPart_001_0004_01C762CA.FB662640
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.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ebay ecology economis eduction email =
emergence enron.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Inevitable village cover voteold, =
eagerly covering?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Citizens ages civil, chuck broke, ranks =
fellow=20
thinks. Know credit pagesif find offensive apologize yourself =
right?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Laser tensilica dj, crudeoman, refiners =
sidelined=20
weak fuel crack. Suspicious pifs vbs etc does ist when fault. Opinion =
assorted=20
invoking activists preemptive.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Whites inequality rosalio, muoz =
cochairman chicano moratorium?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Changed, expendable reap profits =
wwwcomdorg.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Quotin god trustquot irs deductions =
lincoln.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ctp testers, attendees followed planned =
product=20
deemed february remainder. Actively drafted sixties =
invaded.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Stints, princeton, letters clients =
unfit, wealthy?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Introduced, abolish repeatedly =
necessary conduct=20
armed forces skills. Using, sss military, actively drafted sixties, =
invaded=20
vietnam.</FONT></DIV>
<DIV><IMG alt=3D"Announces" hspace=3D0=20
src=3D"cid:000201c7626e$c7f5ae40$8274e4a5@zagame124dd8eb" align=3Dcenter =

border=3D0></DIV></BODY></HTML>

------=_NextPart_001_0004_01C762CA.FB662640--

------=_NextPart_000_0003_01C762CA.FB662640
Content-Type: image/gif;
	name="WinTab.gif"
Content-Transfer-Encoding: base64
Content-ID: <000201c7626e$c7f5ae40$8274e4a5@zagame124dd8eb>

------=_NextPart_000_0003_01C762CA.FB662640--

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Stephen Kent <[email-masked]>
Date: Thu, 8 Mar 2007 15:28:50 +0000
Subject: Request for agenda items for the IETF-68 PKIX meeting
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

All,

I'm requesting input to the agenda for the PKIX meeting in Prague.

If you have anything you want to contribute to this meeting, please send me a note with:

- Subject
- proposed title
- Related document(s) if any
- Presenter
- Requested time

I need at least one of the editors of each active PKIX document to send me a note, even if you don't have anything to present.
I would appreciate a response with this week, but I will need it at latest Wednesday next week to accommodate your request.

Thank you in advance.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

Date: Thu, 8 Mar 2007 10:42:11 -0800
To: Stefan Santesson <[email-masked]>, "[email-masked]"	<[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Sender: [email-masked]

At 3:20 PM +0000 3/8/07, Stefan Santesson wrote:
>1) To clarify my last posting. My view of the "feature" is to enable 
>storage of certs in a CRL. Not to enable the PKI to structure its 
>infrastructure so clients can retrieve everything it wants in a 
>single fetch. I'm open to all solutions that enable me to store 
>certs in the CRL, I don't believe we need a solution from PKIX for 
>the other part.

A "feature" is something that helps one of the parties; a "solution" 
is a way to get the feature. The feature here is allowing the relying 
party to get the information it needs on revocation. If that can be 
done in one grab, that's great; if it takes more than one grab, the 
relying party needs to have a definitive way of finding the location 
for the additional information.

Your choice of the solution instead of looking at the needs of the 
parties does not seem like a good way to design the "feature".

>2) A standard is useful if it applies to one or more relevant use 
>cases. It does not have to apply to all use cases. To argue that it 
>is a bad idea for a use case where it is not intended is a bad 
>argument IMO. To explain why it is not useful where it intended to 
>be used is a good argument.

As many people have already said on the list, there is no way for a 
relying party in a "use case where it is not intended" to ask for a 
CRL that does not have the feature you propose to add.

Further, it is not good protocol design to require people to "explain 
why it is not useful where it intended to be used". Instead, a better 
design methodology is to take the requirements and think of many 
solutions, then map them to the requirements. A solution might be 
useful, but it might have negative aspects that other solutions 
don't. Your procedure pre-ordains a solution to the problem.

>3) You seem to argue from the space of public PKIs.

IETF protocols are designed to be used in the public internet, yes.

>Yet public PKIs represent a very small fraction of the certificates 
>in use today. In closed communities, you typically know a lot about 
>the network and the clients that will use the CRL as well as their 
>capabilities. As Richard pointed out.

If you are saying that future PKIX WG work should allow focus on 
"closed community" PKI, that is a very different question.

>4) Standards are also needed for supporting closed community PKIs, 
>as it allows use of standard products.

This makes no sense at all in the IETF context.

>Yes, this feature provide redundancy in many cases. But so do CRLs 
>in general. I need a few bits of information and I may get 5MB. This 
>is why we have OCSP and maybe soon SCVP. But even these 
>optimizations include validation certificates in responses. In the 
>cases where the proposed feature is intended to be used, the extra 
>redundancy is negligible.

We still haven't seen a list of those cases.

>If this feature can help even in that 1 out of 1000 cases where the 
>client does not have the certificate to validate the CRL, and the 
>resources to get it is not available or network latency creates 
>unwanted time-outs, this feature may still be very valuable.

In what cases could pulling down one CRL be OK but pulling down path 
validation information not be?

>Also if it can help simplify storage of validation data for later use.

This doesn't make sense to me. Validation certificates are always 
stored separately from the data.

>I don't foresee that this feature will be turned on by default. But 
>I foresee that it will be used and provide value.

...but you cannot see how other solutions to the same problem might be better?

--Paul Hoffman, Director
--VPN Consortium

From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 8 Mar 2007 15:20:22 +0000
Subject: RE: straw poll on certs in CRLs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Paul,

Some points.

1) To clarify my last posting. My view of the "feature" is to enable storage of certs in a CRL. Not to enable the PKI to structure its infrastructure so clients can retrieve everything it wants in a single fetch. I'm open to all solutions that enable me to store certs in the CRL, I don't believe we need a solution from PKIX for the other part.

2) A standard is useful if it applies to one or more relevant use cases. It does not have to apply to all use cases. To argue that it is a bad idea for a use case where it is not intended is a bad argument IMO. To explain why it is not useful where it intended to be used is a good argument.

3) You seem to argue from the space of public PKIs. Yet public PKIs represent a very small fraction of the certificates in use today. In closed communities, you typically know a lot about the network and the clients that will use the CRL as well as their capabilities. As Richard pointed out.

4) Standards are also needed for supporting closed community PKIs, as it allows use of standard products.

Yes, this feature provide redundancy in many cases. But so do CRLs in general. I need a few bits of information and I may get 5MB. This is why we have OCSP and maybe soon SCVP. But even these optimizations include validation certificates in responses. In the cases where the proposed feature is intended to be used, the extra redundancy is negligible. If this feature can help even in that 1 out of 1000 cases where the client does not have the certificate to validate the CRL, and the resources to get it is not available or network latency creates unwanted time-outs, this feature may still be very valuable. Also if it can help simplify storage of validation data for later use.

I don't foresee that this feature will be turned on by default. But I foresee that it will be used and provide value.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 7 mars 2007 21:16
> To: [email-masked]
> Subject: RE: straw poll on certs in CRLs
>
>
> At 3:01 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
> >Paul - thanks very much, that indeed helps clarify things.  One
> >final question then: if the concern is that the extension may hold
> >one or a few certs, and since a typical cert may be 1K or 2K in size
> >(mine is 1.4K DER-encoded), how much bloat do you anticipate in a
> >typical CRL?
>
> We don't know, and that's one of the problems with the proposed
> design. The certs are to help validating parties make chains. The CRL
> issuer doesn't know all the relying parties at the time it creates
> the CRL, and therefor must make the worst-case guess about which
> chains to add.
>
> >If the proposal were to limit the number of certs in the extension
> >to a small number - say 10 at most - then might that ameliorate
> >concerns?
>
> Yes, but it would also not fulfill the purpose of the proposed
> design. A different design could handle many more chains without
> burdening the relying party at all (except at the times that they
> choose to do chain validation).
>
> --Paul Hoffman, Director
> --VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Thu, 8 Mar 2007 10:16:07 -0500
From: "Sharon Boeyen" <[email-masked]>
To: "Kemp, David P." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Dave, this message explains EXACTLY the reason for my no vote. Thanks
for crystallizing it!!!!

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp, David P.
Sent: Wednesday, March 07, 2007 6:07 PM
To: [email-masked]
Subject: RE: straw poll on certs in CRLs

No, the detrimental effect is when a client does know
how to make use of the information, already has it in a cache, yet keeps
getting it over and over because there is no way for that client to
request a non-extended CRL.  A few certs in a 5MB CRL isn't much
overhead, but a few certs in a previously-2KB partitioned CRL is a
different story.

The point is that this is not an essential capability, it is
an optimization to minimize the number of round trips and the number of
repositories a client must contact.  If certs and CRLs are simply made
available from the same repository or cache, the primary justification
for the extension (unavailability of a cert repository when the CRL
repository is available) disappears.  This 90% solution can be deployed
with no changes whatsoever to standards or products.

If that isn't good enough, and one simply must have a single get from a
single repository, the "No" votes want PKIX to consider a late-binding
option (which can be performed or not when the CRL is requested) as an
alternative to the proposal for early binding (which is always performed
when the CRL is generated, and thus always impacts every user of that
CRL whether they want it or not).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, March 07, 2007 4:04 PM
To: Paul Hoffman; Guida, Richard [JJCUS]; Stefan Santesson;
[email-masked]
Subject: RE: straw poll on certs in CRLs

The extension causes the CRL to grow but not the amount of data that the
client needs to process.

The only case in which there are detrimental effects is when a client
that does not have the ability to make use of the information receives a
crl with the information unasked for.

Such effects are fully the type of thing we expect application providers
to take note of in making their implementation decisions. Market forces
should provide ample discipline.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Wednesday, March 07, 2007 2:32 PM
> To: Guida, Richard [JJCUS]; Stefan Santesson; [email-masked]
> Subject: RE: straw poll on certs in CRLs
> 
> 
> At 2:20 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
> >Paul - perhaps I am missing something here (would not be the first
> >time...) but the proposal is that it be a non-critical
> extension and as
> >such, under RFC3280, relying party software can indeed ignore it if
> >they fail to recognize it, correct?
> 
> Yes, definitely. But that's not the concern of many of the
> "no" folks have voiced.
> 
> >  Your e-mail said "turned it on" but I was not clear what
> you meant by that.
> 
> Good point; I should have said "deployed, perhaps by default".
> 
> Issuing CRLs with this extension causes the CRL to grow,
> possibly significantly. Transmitting this kruft in every CRL 
> retrieval, particularly in protocols that require CRL 
> retrieval, is wasteful. 
> Further, other folks have proposed better solutions that 
> allow more useful information to be given to the relying 
> party than the one-size-fits-all view that the CRL issuer 
> knows all possible chains it should include in the CRL.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 

Date: Thu, 08 Mar 2007 11:35:52 +0100
From: Peter Sylvester <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030705040409090306070408
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

No.

I think that there are possibilities to use precisions or enhancements
in the operational protocols that allow to achieve the intended goal
without the (I admit small) overhead. example:
with ldap the client can retrieve the cert at a place nearby
with http, one might allow the client to use an accept header to
inform the crl repository to select either a crl or a pkcs7
or one might allow to specify a querystring.
The certs returned may even depend on the client that asks.

Peter

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

--------------ms030705040409090306070408--

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: Paul Hoffman <[email-masked]>, [email-masked]
Subject: RE: straw poll on certs in CRLs
Date: Wed, 7 Mar 2007 18:23:07 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C7610F.8FCC08FE
Content-Type: text/plain

Paul - o.k. thanks, that lays things out well.  One final point then I
promise to stop punishing everyone with my postings on this topic.  In a
general case solution where (as you say) you are not certain about who your
relying parties may be, I can see that it could get cumbersome and complex
for the CA to try to figure out all the certs that may belong in the
extension.  In a more restricted circumstance - such as use within an
enterprise (not just my enterprise but any enterprise) or use with a
specific set of known relying parties who are bound by contract - things are
likely to be much easier and less cumbersome.

Anyway - thanks again for your insights on this - appreciate them very much.
Very best regards -- Rich

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul Hoffman
Sent: Wednesday, March 07, 2007 3:16 PM
To: [email-masked]
Subject: RE: straw poll on certs in CRLs

At 3:01 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
>Paul - thanks very much, that indeed helps clarify things.  One 
>final question then: if the concern is that the extension may hold 
>one or a few certs, and since a typical cert may be 1K or 2K in size 
>(mine is 1.4K DER-encoded), how much bloat do you anticipate in a 
>typical CRL?

We don't know, and that's one of the problems with the proposed 
design. The certs are to help validating parties make chains. The CRL 
issuer doesn't know all the relying parties at the time it creates 
the CRL, and therefor must make the worst-case guess about which 
chains to add.

>If the proposal were to limit the number of certs in the extension 
>to a small number - say 10 at most - then might that ameliorate 
>concerns?

Yes, but it would also not fulfill the purpose of the proposed 
design. A different design could handle many more chains without 
burdening the relying party at all (except at the times that they 
choose to do chain validation).

--Paul Hoffman, Director
--VPN Consortium

------_=_NextPart_001_01C7610F.8FCC08FE
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: straw poll on certs in CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Paul - o.k. thanks, that lays things out well.&nbsp; =
One final point then I promise to stop punishing everyone with my =
postings on this topic.&nbsp; In a general case solution where (as you =
say) you are not certain about who your relying parties may be, I can =
see that it could get cumbersome and complex for the CA to try to =
figure out all the certs that may belong in the extension.&nbsp; In a =
more restricted circumstance - such as use within an enterprise (not =
just my enterprise but any enterprise) or use with a specific set of =
known relying parties who are bound by contract - things are likely to =
be much easier and less cumbersome.</FONT></P>

<P><FONT SIZE=3D2>Anyway - thanks again for your insights on this - =
appreciate them very much.&nbsp; Very best regards -- Rich</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Security</FONT>
</P>

<P><FONT SIZE=3D2>Johnson &amp; Johnson</FONT>
<BR><FONT SIZE=3D2>Room GS8217</FONT>
<BR><FONT SIZE=3D2>410 George Street</FONT>
<BR><FONT SIZE=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT>
<BR><FONT SIZE=3D2>Phone:&nbsp; 732 524 3785</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]On Behalf Of Paul Hoffman</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, March 07, 2007 3:16 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: straw poll on certs in CRLs</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>At 3:01 PM -0500 3/7/07, Guida, Richard [JJCUS] =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Paul - thanks very much, that indeed helps =
clarify things.&nbsp; One </FONT>
<BR><FONT SIZE=3D2>&gt;final question then: if the concern is that the =
extension may hold </FONT>
<BR><FONT SIZE=3D2>&gt;one or a few certs, and since a typical cert may =
be 1K or 2K in size </FONT>
<BR><FONT SIZE=3D2>&gt;(mine is 1.4K DER-encoded), how much bloat do =
you anticipate in a </FONT>
<BR><FONT SIZE=3D2>&gt;typical CRL?</FONT>
</P>

<P><FONT SIZE=3D2>We don't know, and that's one of the problems with =
the proposed </FONT>
<BR><FONT SIZE=3D2>design. The certs are to help validating parties =
make chains. The CRL </FONT>
<BR><FONT SIZE=3D2>issuer doesn't know all the relying parties at the =
time it creates </FONT>
<BR><FONT SIZE=3D2>the CRL, and therefor must make the worst-case guess =
about which </FONT>
<BR><FONT SIZE=3D2>chains to add.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;If the proposal were to limit the number of certs =
in the extension </FONT>
<BR><FONT SIZE=3D2>&gt;to a small number - say 10 at most - then might =
that ameliorate </FONT>
<BR><FONT SIZE=3D2>&gt;concerns?</FONT>
</P>

<P><FONT SIZE=3D2>Yes, but it would also not fulfill the purpose of the =
proposed </FONT>
<BR><FONT SIZE=3D2>design. A different design could handle many more =
chains without </FONT>
<BR><FONT SIZE=3D2>burdening the relying party at all (except at the =
times that they </FONT>
<BR><FONT SIZE=3D2>choose to do chain validation).</FONT>
</P>

<P><FONT SIZE=3D2>--Paul Hoffman, Director</FONT>
<BR><FONT SIZE=3D2>--VPN Consortium</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C7610F.8FCC08FE--

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Wed, 7 Mar 2007 18:07:06 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

No, the detrimental effect is when a client does know
how to make use of the information, already has it in a cache,
yet keeps getting it over and over because there is no
way for that client to request a non-extended CRL.  A few
certs in a 5MB CRL isn't much overhead, but a few certs in
a previously-2KB partitioned CRL is a different story.

The point is that this is not an essential capability, it is
an optimization to minimize the number of round trips and the
number of repositories a client must contact.  If certs and
CRLs are simply made available from the same repository or
cache, the primary justification for the extension
(unavailability of a cert repository when the CRL repository
is available) disappears.  This 90% solution can be deployed
with no changes whatsoever to standards or products.

If that isn't good enough, and one simply must have a single
get from a single repository, the "No" votes want PKIX to
consider a late-binding option (which can be performed
or not when the CRL is requested) as an alternative to
the proposal for early binding (which is always performed when
the CRL is generated, and thus always impacts every user of
that CRL whether they want it or not).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, March 07, 2007 4:04 PM
To: Paul Hoffman; Guida, Richard [JJCUS]; Stefan Santesson;
[email-masked]
Subject: RE: straw poll on certs in CRLs

The extension causes the CRL to grow but not the amount of data that the
client needs to process.

The only case in which there are detrimental effects is when a client
that does not have the ability to make use of the information receives a
crl with the information unasked for.

Such effects are fully the type of thing we expect application providers
to take note of in making their implementation decisions. Market forces
should provide ample discipline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Wednesday, March 07, 2007 2:32 PM
> To: Guida, Richard [JJCUS]; Stefan Santesson; [email-masked]
> Subject: RE: straw poll on certs in CRLs
> 
> 
> At 2:20 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
> >Paul - perhaps I am missing something here (would not be the first
> >time...) but the proposal is that it be a non-critical 
> extension and as 
> >such, under RFC3280, relying party software can indeed ignore it if 
> >they fail to recognize it, correct?
> 
> Yes, definitely. But that's not the concern of many of the 
> "no" folks have voiced.
> 
> >  Your e-mail said "turned it on" but I was not clear what 
> you meant by that.
> 
> Good point; I should have said "deployed, perhaps by default".
> 
> Issuing CRLs with this extension causes the CRL to grow, 
> possibly significantly. Transmitting this kruft in every CRL 
> retrieval, particularly in protocols that require CRL 
> retrieval, is wasteful. 
> Further, other folks have proposed better solutions that 
> allow more useful information to be given to the relying 
> party than the one-size-fits-all view that the CRL issuer 
> knows all possible chains it should include in the CRL.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Wed, 7 Mar 2007 13:03:43 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, "Guida, Richard [JJCUS]" <[email-masked]>, "Stefan Santesson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The extension causes the CRL to grow but not the amount of data that the client needs to process.

The only case in which there are detrimental effects is when a client that does not have the ability to make use of the information receives a crl with the information unasked for.

Such effects are fully the type of thing we expect application providers to take note of in making their implementation decisions. Market forces should provide ample discipline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Wednesday, March 07, 2007 2:32 PM
> To: Guida, Richard [JJCUS]; Stefan Santesson; [email-masked]
> Subject: RE: straw poll on certs in CRLs
> 
> 
> At 2:20 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
> >Paul - perhaps I am missing something here (would not be the first
> >time...) but the proposal is that it be a non-critical 
> extension and as 
> >such, under RFC3280, relying party software can indeed ignore it if 
> >they fail to recognize it, correct?
> 
> Yes, definitely. But that's not the concern of many of the 
> "no" folks have voiced.
> 
> >  Your e-mail said "turned it on" but I was not clear what 
> you meant by that.
> 
> Good point; I should have said "deployed, perhaps by default".
> 
> Issuing CRLs with this extension causes the CRL to grow, 
> possibly significantly. Transmitting this kruft in every CRL 
> retrieval, particularly in protocols that require CRL 
> retrieval, is wasteful. 
> Further, other folks have proposed better solutions that 
> allow more useful information to be given to the relying 
> party than the one-size-fits-all view that the CRL issuer 
> knows all possible chains it should include in the CRL.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Date: Wed, 7 Mar 2007 15:50:07 -0500
Organization: IECA, Inc.
Sender: [email-masked]

no - spt 
 
> Should PKIX develop a standard for a non-critical CRL 
> extension that can hold one or more certs for use in 
> validating the CRL in question?
> 

Date: Wed, 7 Mar 2007 12:15:36 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Sender: [email-masked]

At 3:01 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
>Paul - thanks very much, that indeed helps clarify things.  One 
>final question then: if the concern is that the extension may hold 
>one or a few certs, and since a typical cert may be 1K or 2K in size 
>(mine is 1.4K DER-encoded), how much bloat do you anticipate in a 
>typical CRL?

We don't know, and that's one of the problems with the proposed 
design. The certs are to help validating parties make chains. The CRL 
issuer doesn't know all the relying parties at the time it creates 
the CRL, and therefor must make the worst-case guess about which 
chains to add.

>If the proposal were to limit the number of certs in the extension 
>to a small number - say 10 at most - then might that ameliorate 
>concerns?

Yes, but it would also not fulfill the purpose of the proposed 
design. A different design could handle many more chains without 
burdening the relying party at all (except at the times that they 
choose to do chain validation).

--Paul Hoffman, Director
--VPN Consortium

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, Stefan Santesson <[email-masked]>, [email-masked]
Subject: RE: straw poll on certs in CRLs
Date: Wed, 7 Mar 2007 15:01:00 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C760F1.3EADE7F2
Content-Type: text/plain

Paul - thanks very much, that indeed helps clarify things.  One final
question then: if the concern is that the extension may hold one or a few
certs, and since a typical cert may be 1K or 2K in size (mine is 1.4K
DER-encoded), how much bloat do you anticipate in a typical CRL?  If the
proposal were to limit the number of certs in the extension to a small
number - say 10 at most - then might that ameliorate concerns?  I admit that
my viewpoint may be a bit jaded since the CRL we publish is quite large -
5MB (we also have OCSP responders) - so 10K to 20K extra does not seem to be
much.  But again, I am just trying to ensure I understand the concerns that
have been expressed.  Thanks very much -- Rich

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]
Sent: Wednesday, March 07, 2007 2:32 PM
To: Guida, Richard [JJCUS]; Stefan Santesson; [email-masked]
Subject: RE: straw poll on certs in CRLs

At 2:20 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
>Paul - perhaps I am missing something here (would not be the first 
>time...) but the proposal is that it be a non-critical extension and 
>as such, under RFC3280, relying party software can indeed ignore it 
>if they fail to recognize it, correct?

Yes, definitely. But that's not the concern of many of the "no" folks 
have voiced.

>  Your e-mail said "turned it on" but I was not clear what you meant by
that.

Good point; I should have said "deployed, perhaps by default".

Issuing CRLs with this extension causes the CRL to grow, possibly 
significantly. Transmitting this kruft in every CRL retrieval, 
particularly in protocols that require CRL retrieval, is wasteful. 
Further, other folks have proposed better solutions that allow more 
useful information to be given to the relying party than the 
one-size-fits-all view that the CRL issuer knows all possible chains 
it should include in the CRL.

--Paul Hoffman, Director
--VPN Consortium

------_=_NextPart_001_01C760F1.3EADE7F2
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: straw poll on certs in CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Paul - thanks very much, that indeed helps clarify =
things.&nbsp; One final question then: if the concern is that the =
extension may hold one or a few certs, and since a typical cert may be =
1K or 2K in size (mine is 1.4K DER-encoded), how much bloat do you =
anticipate in a typical CRL?&nbsp; If the proposal were to limit the =
number of certs in the extension to a small number - say 10 at most - =
then might that ameliorate concerns?&nbsp; I admit that my viewpoint =
may be a bit jaded since the CRL we publish is quite large - 5MB (we =
also have OCSP responders) - so 10K to 20K extra does not seem to be =
much.&nbsp; But again, I am just trying to ensure I understand the =
concerns that have been expressed.&nbsp; Thanks very much -- =
Rich</FONT></P>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Security</FONT>
</P>

<P><FONT SIZE=3D2>Johnson &amp; Johnson</FONT>
<BR><FONT SIZE=3D2>Room GS8217</FONT>
<BR><FONT SIZE=3D2>410 George Street</FONT>
<BR><FONT SIZE=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT>
<BR><FONT SIZE=3D2>Phone:&nbsp; 732 524 3785</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Paul Hoffman [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, March 07, 2007 2:32 PM</FONT>
<BR><FONT SIZE=3D2>To: Guida, Richard [JJCUS]; Stefan Santesson; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: straw poll on certs in CRLs</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 2:20 PM -0500 3/7/07, Guida, Richard [JJCUS] =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Paul - perhaps I am missing something here =
(would not be the first </FONT>
<BR><FONT SIZE=3D2>&gt;time...) but the proposal is that it be a =
non-critical extension and </FONT>
<BR><FONT SIZE=3D2>&gt;as such, under RFC3280, relying party software =
can indeed ignore it </FONT>
<BR><FONT SIZE=3D2>&gt;if they fail to recognize it, correct?</FONT>
</P>

<P><FONT SIZE=3D2>Yes, definitely. But that's not the concern of many =
of the &quot;no&quot; folks </FONT>
<BR><FONT SIZE=3D2>have voiced.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; Your e-mail said &quot;turned it on&quot; =
but I was not clear what you meant by that.</FONT>
</P>

<P><FONT SIZE=3D2>Good point; I should have said &quot;deployed, =
perhaps by default&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>Issuing CRLs with this extension causes the CRL to =
grow, possibly </FONT>
<BR><FONT SIZE=3D2>significantly. Transmitting this kruft in every CRL =
retrieval, </FONT>
<BR><FONT SIZE=3D2>particularly in protocols that require CRL =
retrieval, is wasteful. </FONT>
<BR><FONT SIZE=3D2>Further, other folks have proposed better solutions =
that allow more </FONT>
<BR><FONT SIZE=3D2>useful information to be given to the relying party =
than the </FONT>
<BR><FONT SIZE=3D2>one-size-fits-all view that the CRL issuer knows all =
possible chains </FONT>
<BR><FONT SIZE=3D2>it should include in the CRL.</FONT>
</P>

<P><FONT SIZE=3D2>--Paul Hoffman, Director</FONT>
<BR><FONT SIZE=3D2>--VPN Consortium</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C760F1.3EADE7F2--

Date: Wed, 7 Mar 2007 11:32:13 -0800
To: "Guida, Richard [JJCUS]" <[email-masked]>, Stefan Santesson	 <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Sender: [email-masked]

At 2:20 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
>Paul - perhaps I am missing something here (would not be the first 
>time...) but the proposal is that it be a non-critical extension and 
>as such, under RFC3280, relying party software can indeed ignore it 
>if they fail to recognize it, correct?

Yes, definitely. But that's not the concern of many of the "no" folks 
have voiced.

>  Your e-mail said "turned it on" but I was not clear what you meant by that.

Good point; I should have said "deployed, perhaps by default".

Issuing CRLs with this extension causes the CRL to grow, possibly 
significantly. Transmitting this kruft in every CRL retrieval, 
particularly in protocols that require CRL retrieval, is wasteful. 
Further, other folks have proposed better solutions that allow more 
useful information to be given to the relying party than the 
one-size-fits-all view that the CRL issuer knows all possible chains 
it should include in the CRL.

--Paul Hoffman, Director
--VPN Consortium

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, Stefan Santesson <[email-masked]>, [email-masked]
Subject: RE: straw poll on certs in CRLs
Date: Wed, 7 Mar 2007 14:20:52 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C760EC.D6522DDE
Content-Type: text/plain

Paul - perhaps I am missing something here (would not be the first time...)
but the proposal is that it be a non-critical extension and as such, under
RFC3280, relying party software can indeed ignore it if they fail to
recognize it, correct?  Your e-mail said "turned it on" but I was not clear
what you meant by that.  Just trying to ensure I understand the calculus
here.  Thanks very much -- Rich

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul Hoffman
Sent: Wednesday, March 07, 2007 11:59 AM
To: Stefan Santesson; [email-masked]
Subject: RE: straw poll on certs in CRLs

At 11:07 AM +0000 3/7/07, Stefan Santesson wrote:
>I would like to see a standard, but I'm not locked on document type. 
>But I don't think that is what this straw-poll is about. IMO it is 
>if pkix should develop the feature at all.

Please re-read the poll that your co-chair wrote:

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question?

That is quite clearly about the proposed solution being in CRLs, not 
about the feature.

>This is a feature that you can't ram down anybody's throat.

Fully disagree. If a significant vendor of software used as CAs 
started putting such an extension in its software and turned it on by 
default, it would be rammed down the throats of every system that 
validated using CRLs. As many people have pointed out, putting the 
extra information in the CRL makes it so that there is no 
negoitiation on the recipient's part about whether or not they want 
it, need it, or can even understand it.

--Paul Hoffman, Director
--VPN Consortium

------_=_NextPart_001_01C760EC.D6522DDE
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: straw poll on certs in CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Paul - perhaps I am missing something here (would not =
be the first time...) but the proposal is that it be a non-critical =
extension and as such, under RFC3280, relying party software can indeed =
ignore it if they fail to recognize it, correct?&nbsp; Your e-mail said =
&quot;turned it on&quot; but I was not clear what you meant by =
that.&nbsp; Just trying to ensure I understand the calculus here.&nbsp; =
Thanks very much -- Rich</FONT></P>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Security</FONT>
</P>

<P><FONT SIZE=3D2>Johnson &amp; Johnson</FONT>
<BR><FONT SIZE=3D2>Room GS8217</FONT>
<BR><FONT SIZE=3D2>410 George Street</FONT>
<BR><FONT SIZE=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT>
<BR><FONT SIZE=3D2>Phone:&nbsp; 732 524 3785</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]On Behalf Of Paul Hoffman</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, March 07, 2007 11:59 AM</FONT>
<BR><FONT SIZE=3D2>To: Stefan Santesson; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: straw poll on certs in CRLs</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>At 11:07 AM +0000 3/7/07, Stefan Santesson =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;I would like to see a standard, but I'm not =
locked on document type. </FONT>
<BR><FONT SIZE=3D2>&gt;But I don't think that is what this straw-poll =
is about. IMO it is </FONT>
<BR><FONT SIZE=3D2>&gt;if pkix should develop the feature at =
all.</FONT>
</P>

<P><FONT SIZE=3D2>Please re-read the poll that your co-chair =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2>Should PKIX develop a standard for a non-critical CRL =
extension that </FONT>
<BR><FONT SIZE=3D2>can hold one or more certs for use in validating the =
CRL in question?</FONT>
</P>

<P><FONT SIZE=3D2>That is quite clearly about the proposed solution =
being in CRLs, not </FONT>
<BR><FONT SIZE=3D2>about the feature.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;This is a feature that you can't ram down =
anybody's throat.</FONT>
</P>

<P><FONT SIZE=3D2>Fully disagree. If a significant vendor of software =
used as CAs </FONT>
<BR><FONT SIZE=3D2>started putting such an extension in its software =
and turned it on by </FONT>
<BR><FONT SIZE=3D2>default, it would be rammed down the throats of =
every system that </FONT>
<BR><FONT SIZE=3D2>validated using CRLs. As many people have pointed =
out, putting the </FONT>
<BR><FONT SIZE=3D2>extra information in the CRL makes it so that there =
is no </FONT>
<BR><FONT SIZE=3D2>negoitiation on the recipient's part about whether =
or not they want </FONT>
<BR><FONT SIZE=3D2>it, need it, or can even understand it.</FONT>
</P>

<P><FONT SIZE=3D2>--Paul Hoffman, Director</FONT>
<BR><FONT SIZE=3D2>--VPN Consortium</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C760EC.D6522DDE--

Date: Wed, 7 Mar 2007 08:58:55 -0800
To: Stefan Santesson <[email-masked]>, "[email-masked]"	<[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Sender: [email-masked]

At 11:07 AM +0000 3/7/07, Stefan Santesson wrote:
>I would like to see a standard, but I'm not locked on document type. 
>But I don't think that is what this straw-poll is about. IMO it is 
>if pkix should develop the feature at all.

Please re-read the poll that your co-chair wrote:

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question?

That is quite clearly about the proposed solution being in CRLs, not 
about the feature.

>This is a feature that you can't ram down anybody's throat.

Fully disagree. If a significant vendor of software used as CAs 
started putting such an extension in its software and turned it on by 
default, it would be rammed down the throats of every system that 
validated using CRLs. As many people have pointed out, putting the 
extra information in the CRL makes it so that there is no 
negoitiation on the recipient's part about whether or not they want 
it, need it, or can even understand it.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 07 Mar 2007 15:12:38 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

Stefan Santesson wrote:
> I would like to see a standard, but I'm not locked on document type. But I don't think that is what this straw-poll is about. IMO it is if pkix should develop the feature at all.
>   
If the straw-poll is about developing the feature, then it should be  
written another way.

I'm thinking if the crl is downloaded through http, the client could 
tell the server with an Accept header if he is ready to have this 
format  rammed down his throat :-) But we'd need something else for ldap 
and ftp.

From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 7 Mar 2007 11:07:35 +0000
Subject: RE: straw poll on certs in CRLs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Paul,

In line.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 6 mars 2007 22:57
> To: [email-masked]
> Subject: RE: straw poll on certs in CRLs
>
>
> At 9:59 AM -0800 3/6/07, Hallam-Baker, Phillip wrote:
> >People want the feature,
>
> Yes, they want the feature; they don't have to get it in the way that
> is proposed in this question.
>
> >better to specify a standard than have it end up EXPRIMENTAL or
> INFORMATIONAL.
>

I would like to see a standard, but I'm not locked on document type. But I don't think that is what this straw-poll is about. IMO it is if pkix should develop the feature at all.

> Better to have the feature come in a way that everyone agrees to.
>

I'm open to changes to how the feature is specified. I just want the capability. Again, I see this straw poll as a vote about whether the feature should be developed, not if the current draft should pass unchanged. And may I add, even if this straw poll turns out positive, this group does not need to pass the document if it is not happy with how it turns out.

> >There is nothing to stop Microsoft cutting this off their own OID
> >space. It is much better if this is done off the PKIX arc.
>
> It is much better if whoever wants the feature does it in a way that
> the rest of the community wants. You make it sound like Microsoft
> intends to ram this down users' throats regardless of what the IETF
> wants; they have said nothing of the sort.
>

This is a feature that you can't ram down anybody's throat. You are right that we have not expressed any plans to go any further with this if this initiative is turned down, and I know of no such plans. But even if we or someone else defined an extension for this identified by a non PKIX OID, then those CRLs would be compatible with current clients. They would just ignore this optional and non-critical extension and move on with business as usual. X.509 is designed to give this freedom to anyone. Implementers and organizations has defined and used private extensions in the past in this way.

Some examples from my private collection:
Cross Certificate Distribution Points   1.3.6.1.4.1.311.10.9.1  Microsoft
MS_CERTIFICATE_TEMPLATE                 1.3.6.1.4.1.311.20.2    Microsoft
CertServ CA Version                     1.3.6.1.4.1.311.21.1    Microsoft
CRL Self CDP                            1.3.6.1.4.1.311.21.14   Microsoft
CertServ Previous Certificate Hash      1.3.6.1.4.1.311.21.2    Microsoft
CertServ Cross CA Version               1.3.6.1.4.1.311.21.22   Microsoft
CRL Virtual Base                        1.3.6.1.4.1.311.21.3    Microsoft
CRL Next Publish                        1.3.6.1.4.1.311.21.4    Microsoft
Certificate Template                    1.3.6.1.4.1.311.21.7    Microsoft
Netscape Certificate Type               2.16.840.1.113730.1.1   Netscape
Netscape SSL Server Name                2.16.840.1.113730.1.12  Netscape
Netscape Comment                        2.16.840.1.113730.1.13  Netscape
Netscape Base URL                       2.16.840.1.113730.1.2   Netscape
Netscape Revocation URL                 2.16.840.1.113730.1.3   Netscape
Netscape CA Revocation URL              2.16.840.1.113730.1.4   Netscape
Netscape Certificate Renewal URL        2.16.840.1.113730.1.7   Netscape
Netscape CA Policy URL                  2.16.840.1.113730.1.8   Netscape

Some of these are obsolete but some are still in use, yet they are not rammed down anybody's throat. The mostly they have represented optional features for optional use.

Further, the S/MIME Capabilities extension was previously such private defined extension that was there for optional use (without anybody being hurt by it). This is an example where IETF originally turned down the initiative to create such extension but where we (Microsoft) decided to offer it anyway (because we needed it), using the RSA OID from PKXS#9. It turned out to be of such value that IETF later adopted it as RFC 4262.

/Stefan

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

Date: Tue, 6 Mar 2007 13:57:05 -0800
To: <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Sender: [email-masked]

At 9:59 AM -0800 3/6/07, Hallam-Baker, Phillip wrote:
>People want the feature,

Yes, they want the feature; they don't have to get it in the way that 
is proposed in this question.

>better to specify a standard than have it end up EXPRIMENTAL or INFORMATIONAL.

Better to have the feature come in a way that everyone agrees to.

>There is nothing to stop Microsoft cutting this off their own OID 
>space. It is much better if this is done off the PKIX arc.

It is much better if whoever wants the feature does it in a way that 
the rest of the community wants. You make it sound like Microsoft 
intends to ram this down users' throats regardless of what the IETF 
wants; they have said nothing of the sort.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: Discussion of certs in CRLs
Date: Tue, 6 Mar 2007 15:01:06 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

People want the feature; they don't necessarily want the currently
proposed mechanism for achieving it.  Given that there are better
alternatives for achieving the same result (namely putting a CRL and
cert(s) into a simple attribute or a PKCS-7), PKIX OIDs should be
assigned to the globally-optimal solution.

Locally-optimized solutions are properly documented as EXPERIMENTAL
with private OIDs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, March 06, 2007 1:00 PM
To: Stephen Kent; [email-masked]
Subject: RE: straw poll on certs in CRLs

Yes

People want the feature, better to specify a standard than have it end
up EXPRIMENTAL or INFORMATIONAL.

There is nothing to stop Microsoft cutting this off their own OID space.
It is much better if this is done off the PKIX arc. 

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Date: Tue, 6 Mar 2007 10:48:51 -0800
Importance: Normal
Sender: [email-masked]

No.

Mike

> Should PKIX develop a standard for a non-critical CRL extension that 
> can hold one or more certs for use in validating the CRL in question?

Date: Tue, 06 Mar 2007 20:21:46 +0100
From: Robert Kisteleki <[email-masked]>
To: [email-masked]
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

No.

Robert

Stephen Kent wrote:
> 
> Folks,
> 
> In the last few weeks I have seen a number of messages supporting the 
> notion of a CRL extension that would enable a CA to include a CA cert 
> (or certs) in a CRL.  Earlier we had some traffic on this topic, but is 
> was all negative. So, it seem like its time for a straw poll, so we can 
> gauge WG consensus. Since Stefan is a proponent of this notion, I will 
> conduct the poll.
> 
> Plesse send a message to the list (indicating YES or NO) on the 
> following question:
> 
> Should PKIX develop a standard for a non-critical CRL extension that can 
> hold one or more certs for use in validating the CRL in question?
> 
> The poll begins today, and will close on March 16. I will, announce the 
> results during the PKIX session at the IETF meeting in Prague.
> 
> Steve
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Tue, 6 Mar 2007 14:10:27 -0500
From: "Sharon Boeyen" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

No

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Monday, March 05, 2007 12:06 PM
To: [email-masked]
Subject: straw poll on certs in CRLs

Folks,

In the last few weeks I have seen a number of messages supporting the 
notion of a CRL extension that would enable a CA to include a CA cert 
(or certs) in a CRL.  Earlier we had some traffic on this topic, but 
is was all negative. So, it seem like its time for a straw poll, so 
we can gauge WG consensus. Since Stefan is a proponent of this 
notion, I will conduct the poll.

Plesse send a message to the list (indicating YES or NO) on the 
following question:

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question?

The poll begins today, and will close on March 16. I will, announce 
the results during the PKIX session at the IETF meeting in Prague.

Steve

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Tue, 6 Mar 2007 09:59:35 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Yes

People want the feature, better to specify a standard than have it end up EXPRIMENTAL or INFORMATIONAL.

There is nothing to stop Microsoft cutting this off their own OID space. It is much better if this is done off the PKIX arc. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Monday, March 05, 2007 12:06 PM
> To: [email-masked]
> Subject: straw poll on certs in CRLs
> 
> 
> Folks,
> 
> In the last few weeks I have seen a number of messages 
> supporting the notion of a CRL extension that would enable a 
> CA to include a CA cert (or certs) in a CRL.  Earlier we had 
> some traffic on this topic, but is was all negative. So, it 
> seem like its time for a straw poll, so we can gauge WG 
> consensus. Since Stefan is a proponent of this notion, I will 
> conduct the poll.
> 
> Plesse send a message to the list (indicating YES or NO) on 
> the following question:
> 
> Should PKIX develop a standard for a non-critical CRL 
> extension that can hold one or more certs for use in 
> validating the CRL in question?
> 
> The poll begins today, and will close on March 16. I will, 
> announce the results during the PKIX session at the IETF 
> meeting in Prague.
> 
> Steve
> 
> 
> 
> 

From: Stefan Santesson <[email-masked]>
To: Stephen Kent <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 6 Mar 2007 16:00:04 +0000
Subject: RE: straw poll on certs in CRLs
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

And my obvious vote (with pkix chair hat off of course) is:

Yes.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Kent
> Sent: den 5 mars 2007 18:06
> To: [email-masked]
> Subject: straw poll on certs in CRLs
>
>
> Folks,
>
> In the last few weeks I have seen a number of messages supporting the
> notion of a CRL extension that would enable a CA to include a CA cert
> (or certs) in a CRL.  Earlier we had some traffic on this topic, but
> is was all negative. So, it seem like its time for a straw poll, so
> we can gauge WG consensus. Since Stefan is a proponent of this
> notion, I will conduct the poll.
>
> Plesse send a message to the list (indicating YES or NO) on the
> following question:
>
> Should PKIX develop a standard for a non-critical CRL extension that
> can hold one or more certs for use in validating the CRL in question?
>
> The poll begins today, and will close on March 16. I will, announce
> the results during the PKIX session at the IETF meeting in Prague.
>
> Steve
>
>

Date: Tue, 06 Mar 2007 16:26:20 +0100
From: Alfredo Esposito <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

No

Stephen Kent wrote:
>
> Folks,
>
> In the last few weeks I have seen a number of messages supporting the 
> notion of a CRL extension that would enable a CA to include a CA cert 
> (or certs) in a CRL.  Earlier we had some traffic on this topic, but 
> is was all negative. So, it seem like its time for a straw poll, so we 
> can gauge WG consensus. Since Stefan is a proponent of this notion, I 
> will conduct the poll.
>
> Plesse send a message to the list (indicating YES or NO) on the 
> following question:
>
> Should PKIX develop a standard for a non-critical CRL extension that 
> can hold one or more certs for use in validating the CRL in question?
>
> The poll begins today, and will close on March 16. I will, announce 
> the results during the PKIX session at the IETF meeting in Prague.
>
> Steve
>
>
>
>

Date: Tue, 6 Mar 2007 16:15:45 +0100
From: "Carlos Gonzalez-Cadenas" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Cc: [email-masked]
Sender: [email-masked]

------=_Part_176026_2792573.1173194145006
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

No.

On 3/5/07, Stephen Kent <[email-masked]> wrote:
>
>
> Folks,
>
> In the last few weeks I have seen a number of messages supporting the
> notion of a CRL extension that would enable a CA to include a CA cert
> (or certs) in a CRL.  Earlier we had some traffic on this topic, but
> is was all negative. So, it seem like its time for a straw poll, so
> we can gauge WG consensus. Since Stefan is a proponent of this
> notion, I will conduct the poll.
>
> Plesse send a message to the list (indicating YES or NO) on the
> following question:
>
> Should PKIX develop a standard for a non-critical CRL extension that
> can hold one or more certs for use in validating the CRL in question?
>
> The poll begins today, and will close on March 16. I will, announce
> the results during the PKIX session at the IETF meeting in Prague.
>
> Steve
>
>
>
>

------=_Part_176026_2792573.1173194145006
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

No.<br><br><div><span class="gmail_quote">On 3/5/07, <b class="gmail_sendername">Stephen Kent</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Folks,<br><br>In the last few weeks I have seen a number of messages supporting the<br>notion of a CRL extension that would enable a CA to include a CA cert<br>(or certs) in a CRL.&nbsp;&nbsp;Earlier we had some traffic on this topic, but
<br>is was all negative. So, it seem like its time for a straw poll, so<br>we can gauge WG consensus. Since Stefan is a proponent of this<br>notion, I will conduct the poll.<br><br>Plesse send a message to the list (indicating YES or NO) on the
<br>following question:<br><br>Should PKIX develop a standard for a non-critical CRL extension that<br>can hold one or more certs for use in validating the CRL in question?<br><br>The poll begins today, and will close on March 16. I will, announce
<br>the results during the PKIX session at the IETF meeting in Prague.<br><br>Steve<br><br><br><br></blockquote></div><br>

------=_Part_176026_2792573.1173194145006--

From: "Peter Rybar" <[email-masked]>
To: "'Jean-Marc Desperrier'" <[email-masked]>, "'pkix'" <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Date: Tue, 6 Mar 2007 15:21:56 +0100
Sender: [email-masked]

NO.

I agree with Jean-Marc Desperrier about PKCS#7 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Sent: Monday, March 05, 2007 9:10 PM
To: Stephen Kent; pkix
Subject: Re: straw poll on certs in CRLs

Stephen Kent wrote:
> Should PKIX develop a standard for a non-critical CRL extension that 
> can hold one or more certs for use in validating the CRL in question?
No.
A pkcs#7 including  the needed CRL and certificat is better suited than 
a new extension. 
There's no significant overhead to this format WRT a crl with the cert 
in  an extension.

Content-class: urn:content-classes:message
Subject: Re: straw poll on certs in CRLs
Date: Tue, 6 Mar 2007 08:17:12 -0500
From: "Dave Engberg" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75FF1.C0EE5310
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C75FF1.C0EE5310
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C75FF1.C0EE5310--

Date: Tue, 6 Mar 2007 13:30:21 +0100 (CET)
From: Koen Simoens <[email-masked]>
To: [email-masked]
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

No

On Mon, 5 Mar 2007, Stephen Kent wrote:
>
> Folks,
>
> In the last few weeks I have seen a number of messages supporting the
> notion of a CRL extension that would enable a CA to include a CA cert
> (or certs) in a CRL.  Earlier we had some traffic on this topic, but is
> was all negative. So, it seem like its time for a straw poll, so we can
> gauge WG consensus. Since Stefan is a proponent of this notion, I will
> conduct the poll.
>
> Plesse send a message to the list (indicating YES or NO) on the
> following question:
>
> Should PKIX develop a standard for a non-critical CRL extension that can
> hold one or more certs for use in validating the CRL in question?
>
> The poll begins today, and will close on March 16. I will, announce the
> results during the PKIX session at the IETF meeting in Prague.
>
> Steve

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Date: Tue, 6 Mar 2007 11:56:43 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

NO.

Discussion: as currently proposed, the extension does not make it
possible to distinguish (prior to retrieval) between a CRL
containing certificates and a normal CRL.  

The ability for a consumer to retrieve a normal CRL must be a requirement
for this work item.

Denis

Date: Tue, 06 Mar 2007 11:32:39 +0100
From: Johannes Merkle <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

Yes

Johannes

Stephen Kent schrieb am 05.03.2007 18:05:
> 
> Folks,
> 
> In the last few weeks I have seen a number of messages supporting the
> notion of a CRL extension that would enable a CA to include a CA cert
> (or certs) in a CRL.  Earlier we had some traffic on this topic, but is
> was all negative. So, it seem like its time for a straw poll, so we can
> gauge WG consensus. Since Stefan is a proponent of this notion, I will
> conduct the poll.
> 
> Plesse send a message to the list (indicating YES or NO) on the
> following question:
> 
> Should PKIX develop a standard for a non-critical CRL extension that can
> hold one or more certs for use in validating the CRL in question?
> 
> The poll begins today, and will close on March 16. I will, announce the
> results during the PKIX session at the IETF meeting in Prague.
> 
> Steve
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Tue, 6 Mar 2007 10:14:19 +0100
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>
Sender: [email-masked]

No. 

Tobias

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: Monday, March 05, 2007 6:06 PM
> To: [email-masked]
> Subject: straw poll on certs in CRLs
> 
> 
> Folks,
> 
> In the last few weeks I have seen a number of messages supporting the
> notion of a CRL extension that would enable a CA to include a CA cert
> (or certs) in a CRL.  Earlier we had some traffic on this topic, but
> is was all negative. So, it seem like its time for a straw poll, so
> we can gauge WG consensus. Since Stefan is a proponent of this
> notion, I will conduct the poll.
> 
> Plesse send a message to the list (indicating YES or NO) on the
> following question:
> 
> Should PKIX develop a standard for a non-critical CRL extension that
> can hold one or more certs for use in validating the CRL in question?
> 
> The poll begins today, and will close on March 16. I will, announce
> the results during the PKIX session at the IETF meeting in Prague.
> 
> Steve
> 
> 

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Tue, 6 Mar 2007 15:42:39 +1100
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Yes

> Should PKIX develop a standard for a non-critical CRL extension that can hold one or more certs for use in validating the CRL in question?

Date: Mon, 05 Mar 2007 19:18:43 -0800
From: Mark Scherling <[email-masked]>
Subject: RE: straw poll on certs in CRLs
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0049_01C75F5B.176A65E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

No

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: March 5, 2007 2:31 PM
To: [email-masked]
Subject: RE: straw poll on certs in CRLs

No

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carl Wallace
Sent: Monday, March 05, 2007 4:17 PM
To: [email-masked]
Subject: RE: straw poll on certs in CRLs

No. 

> -----Original Message----- 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent 
> Sent: Monday, March 05, 2007 12:06 PM 
> To: [email-masked] 
> Subject: straw poll on certs in CRLs 
> 
> 
> Folks, 
> 
> In the last few weeks I have seen a number of messages 
> supporting the notion of a CRL extension that would enable a 
> CA to include a CA cert (or certs) in a CRL.  Earlier we had 
> some traffic on this topic, but is was all negative. So, it 
> seem like its time for a straw poll, so we can gauge WG 
> consensus. Since Stefan is a proponent of this notion, I will 
> conduct the poll. 
> 
> Plesse send a message to the list (indicating YES or NO) on 
> the following question: 
> 
> Should PKIX develop a standard for a non-critical CRL 
> extension that can hold one or more certs for use in 
> validating the CRL in question? 
> 
> The poll begins today, and will close on March 16. I will, 
> announce the results during the PKIX session at the IETF 
> meeting in Prague. 
> 
> Steve 
> 
> 
> 

------=_NextPart_000_0049_01C75F5B.176A65E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=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]-->
<title>RE: straw poll on certs in CRLs</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.stylecentered, li.stylecentered, div.stylecentered
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:21.6pt;
	mso-level-number-position:left;
	margin-left:21.6pt;
	text-indent:-21.6pt;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:28.8pt;
	mso-level-number-position:left;
	margin-left:28.8pt;
	text-indent:-28.8pt;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	margin-left:36.0pt;
	text-indent:-36.0pt;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:43.2pt;
	mso-level-number-position:left;
	margin-left:43.2pt;
	text-indent:-43.2pt;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:50.4pt;
	mso-level-number-position:left;
	margin-left:50.4pt;
	text-indent:-50.4pt;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:57.6pt;
	mso-level-number-position:left;
	margin-left:57.6pt;
	text-indent:-57.6pt;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:64.8pt;
	mso-level-number-position:left;
	margin-left:64.8pt;
	text-indent:-64.8pt;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	margin-left:72.0pt;
	text-indent:-72.0pt;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:79.2pt;
	mso-level-number-position:left;
	margin-left:79.2pt;
	text-indent:-79.2pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</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'>No<o:p></o:p></span></font></p>

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> March 5, 2007 2:31 =
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: straw poll =
on certs
in CRLs</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=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>No<o:p></o:p></span></font></p>

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b><st1:PersonName =
w:st=3D"on">Carl
 Wallace</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, March 05, =
2007 4:17
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: straw poll =
on certs
in CRLs</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=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>No. </span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;
-----Original Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From:
[email-masked] </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; [<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
On Behalf Of Stephen Kent</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Monday, March =
05, 2007
12:06 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: straw poll =
on certs
in CRLs</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
Folks,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; In the last few =
weeks I have
seen a number of messages </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; supporting the =
notion of a CRL
extension that would enable a </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA to include a CA =
cert (or
certs) in a CRL.&nbsp; Earlier we had </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; some traffic on =
this topic,
but is was all negative. So, it </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; seem like its time =
for a straw
poll, so we can gauge WG </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; consensus. Since =
Stefan is a
proponent of this notion, I will </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; conduct the =
poll.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Plesse send a =
message to the
list (indicating YES or NO) on </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the following =
question:</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Should PKIX develop =
a standard
for a non-critical CRL </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; extension that can =
hold one or
more certs for use in </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; validating the CRL =
in
question?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; The poll begins =
today, and
will close on March 16. I will, </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; announce the =
results during
the PKIX session at the IETF </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; meeting in =
<st1:place w:st=3D"on"><st1:City
 w:st=3D"on">Prague</st1:City></st1:place>.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Steve</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0049_01C75F5B.176A65E0--

From: Yoav Nir <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Date: Mon, 5 Mar 2007 22:06:00 -0500
To: [email-masked]
Sender: [email-masked]

I say no.

The same LDAP server, HTTP server or whatever that serves the CRL can  
also serve the CA cert if needed.

On Mar 5, 2007, at 12:05 PM, Stephen Kent wrote:

>
> Folks,
>
> In the last few weeks I have seen a number of messages supporting  
> the notion of a CRL extension that would enable a CA to include a  
> CA cert (or certs) in a CRL.  Earlier we had some traffic on this  
> topic, but is was all negative. So, it seem like its time for a  
> straw poll, so we can gauge WG consensus. Since Stefan is a  
> proponent of this notion, I will conduct the poll.
>
> Plesse send a message to the list (indicating YES or NO) on the  
> following question:
>
> Should PKIX develop a standard for a non-critical CRL extension  
> that can hold one or more certs for use in validating the CRL in  
> question?
>
> The poll begins today, and will close on March 16. I will, announce  
> the results during the PKIX session at the IETF meeting in Prague.
>
> Steve
>
>
>

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Date: Tue, 6 Mar 2007 11:04:19 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

> Plesse send a message to the list (indicating YES or NO) on the 
> following question:
> 
> Should PKIX develop a standard for a non-critical CRL extension that 
> can hold one or more certs for use in validating the CRL in question?
> 
No.

Wen-Cheng Wang

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Mon, 5 Mar 2007 14:31:10 -0800
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75F75.F967A052
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

No

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Carl Wallace
Sent: Monday, March 05, 2007 4:17 PM
To: [email-masked]
Subject: RE: straw poll on certs in CRLs

=20

No.=20

> -----Original Message-----=20
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Stephen Kent=20
> Sent: Monday, March 05, 2007 12:06 PM=20
> To: [email-masked]=20
> Subject: straw poll on certs in CRLs=20
>=20
>=20
> Folks,=20
>=20
> In the last few weeks I have seen a number of messages=20
> supporting the notion of a CRL extension that would enable a=20
> CA to include a CA cert (or certs) in a CRL.  Earlier we had=20
> some traffic on this topic, but is was all negative. So, it=20
> seem like its time for a straw poll, so we can gauge WG=20
> consensus. Since Stefan is a proponent of this notion, I will=20
> conduct the poll.=20
>=20
> Plesse send a message to the list (indicating YES or NO) on=20
> the following question:=20
>=20
> Should PKIX develop a standard for a non-critical CRL=20
> extension that can hold one or more certs for use in=20
> validating the CRL in question?=20
>=20
> The poll begins today, and will close on March 16. I will,=20
> announce the results during the PKIX session at the IETF=20
> meeting in Prague.=20
>=20
> Steve=20
>=20
>=20
>=20

------_=_NextPart_001_01C75F75.F967A052
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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

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

</head>

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

<div class=3DSection1>

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b><st1:PersonName w:st=3D"on">Carl =
Wallace</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, March 05, =
2007 4:17
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: straw poll =
on certs
in CRLs</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=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>No. </span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;
-----Original Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From:
[email-masked] </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; [<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
On Behalf Of Stephen Kent</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Monday, March =
05, 2007
12:06 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: straw poll =
on certs
in CRLs</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
Folks,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; In the last few =
weeks I have
seen a number of messages </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; supporting the =
notion of a CRL
extension that would enable a </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; CA to include a CA =
cert (or
certs) in a CRL.&nbsp; Earlier we had </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; some traffic on =
this topic,
but is was all negative. So, it </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; seem like its time =
for a straw
poll, so we can gauge WG </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; consensus. Since =
Stefan is a
proponent of this notion, I will </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; conduct the =
poll.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Plesse send a =
message to the
list (indicating YES or NO) on </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the following =
question:</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Should PKIX develop =
a standard
for a non-critical CRL </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; extension that can =
hold one or
more certs for use in </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; validating the CRL =
in
question?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; The poll begins =
today, and
will close on March 16. I will, </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; announce the =
results during
the PKIX session at the IETF </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; meeting in =
<st1:City w:st=3D"on"><st1:place
 w:st=3D"on">Prague</st1:place></st1:City>.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Steve</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C75F75.F967A052--

Date: Mon, 5 Mar 2007 14:08:57 -0800
To: Stephen Kent <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

No. This will cause issuers to not know which CRL to send (the small 
one or the big one) and therefore they will always send the big one. 
The requirement is much better deal with by a different structure 
that bundles a CRL with the needed certs.

--Paul Hoffman, Director
--VPN Consortium

From: Carl Wallace <[email-masked]>
To: [email-masked]
Subject: RE: straw poll on certs in CRLs
Date: Mon, 5 Mar 2007 16:17:14 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C75F6B.A57C11A8
Content-Type: text/plain

No. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Monday, March 05, 2007 12:06 PM
> To: [email-masked]
> Subject: straw poll on certs in CRLs
> 
> 
> Folks,
> 
> In the last few weeks I have seen a number of messages 
> supporting the notion of a CRL extension that would enable a 
> CA to include a CA cert (or certs) in a CRL.  Earlier we had 
> some traffic on this topic, but is was all negative. So, it 
> seem like its time for a straw poll, so we can gauge WG 
> consensus. Since Stefan is a proponent of this notion, I will 
> conduct the poll.
> 
> Plesse send a message to the list (indicating YES or NO) on 
> the following question:
> 
> Should PKIX develop a standard for a non-critical CRL 
> extension that can hold one or more certs for use in 
> validating the CRL in question?
> 
> The poll begins today, and will close on March 16. I will, 
> announce the results during the PKIX session at the IETF 
> meeting in Prague.
> 
> Steve
> 
> 
> 

------_=_NextPart_001_01C75F6B.A57C11A8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: straw poll on certs in CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>No. </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Stephen Kent</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, March 05, 2007 12:06 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: straw poll on certs in CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Folks,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In the last few weeks I have seen a number of =
messages </FONT>
<BR><FONT SIZE=3D2>&gt; supporting the notion of a CRL extension that =
would enable a </FONT>
<BR><FONT SIZE=3D2>&gt; CA to include a CA cert (or certs) in a =
CRL.&nbsp; Earlier we had </FONT>
<BR><FONT SIZE=3D2>&gt; some traffic on this topic, but is was all =
negative. So, it </FONT>
<BR><FONT SIZE=3D2>&gt; seem like its time for a straw poll, so we can =
gauge WG </FONT>
<BR><FONT SIZE=3D2>&gt; consensus. Since Stefan is a proponent of this =
notion, I will </FONT>
<BR><FONT SIZE=3D2>&gt; conduct the poll.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Plesse send a message to the list (indicating =
YES or NO) on </FONT>
<BR><FONT SIZE=3D2>&gt; the following question:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Should PKIX develop a standard for a =
non-critical CRL </FONT>
<BR><FONT SIZE=3D2>&gt; extension that can hold one or more certs for =
use in </FONT>
<BR><FONT SIZE=3D2>&gt; validating the CRL in question?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The poll begins today, and will close on March =
16. I will, </FONT>
<BR><FONT SIZE=3D2>&gt; announce the results during the PKIX session at =
the IETF </FONT>
<BR><FONT SIZE=3D2>&gt; meeting in Prague.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Steve</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C75F6B.A57C11A8--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-pkix-lightweight-ocsp-profile (Lightweight OCSP Profile for High Volume Environments) to Proposed Standard
Reply-To: [email-masked]
Cc: <[email-masked]>
Date: Mon, 05 Mar 2007 16:03:56 -0500
Sender: [email-masked]

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

- 'Lightweight OCSP Profile for High Volume Environments '
   <draft-ietf-pkix-lightweight-ocsp-profile-08.txt> as a Proposed
Standard

A previous version of this document was already subjected to Last Call.
At that time, the intent was for the document to be published as an
Information RFC.  That is no longer the case.  Publication as a
Standards-Track RFC is now being considered.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-03-19. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-08.txt

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

Date: Mon, 05 Mar 2007 21:50:48 +0100
From: Tilo Kienitz <[email-masked]>
To: [email-masked]
CC: Stephen Kent <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

Yes.

-- 
Tilo Kienitz
SecCommerce Informationssysteme GmbH
D - 22335 Hamburg

Stephen Kent wrote:
> 
> Folks,
> 
> In the last few weeks I have seen a number of messages supporting the 
> notion of a CRL extension that would enable a CA to include a CA cert 
> (or certs) in a CRL.  Earlier we had some traffic on this topic, but is 
> was all negative. So, it seem like its time for a straw poll, so we can 
> gauge WG consensus. Since Stefan is a proponent of this notion, I will 
> conduct the poll.
> 
> Plesse send a message to the list (indicating YES or NO) on the 
> following question:
> 
> Should PKIX develop a standard for a non-critical CRL extension that can 
> hold one or more certs for use in validating the CRL in question?
> 
> The poll begins today, and will close on March 16. I will, announce the 
> results during the PKIX session at the IETF meeting in Prague.
> 
> Steve

Date: Mon, 05 Mar 2007 15:21:52 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

>Plesse send a message to the list (indicating YES or NO) on the 
>following question:
>
>Should PKIX develop a standard for a non-critical CRL extension that 
>can hold one or more certs for use in validating the CRL in question?

No.

Russ 

Content-class: urn:content-classes:message
Subject: RE: straw poll on certs in CRLs
Date: Mon, 5 Mar 2007 15:25:03 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

NO.

Discussion: as currently proposed, the extension does not make it
possible to distinguish (prior to retrieval) between a CRL
containing certificates and a normal CRL.  The ability for a
consumer to retrieve a normal CRL must be a requirement
for this work item.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Monday, March 05, 2007 12:06 PM
To: [email-masked]
Subject: straw poll on certs in CRLs

Folks,

In the last few weeks I have seen a number of messages supporting the 
notion of a CRL extension that would enable a CA to include a CA cert 
(or certs) in a CRL.  Earlier we had some traffic on this topic, but 
is was all negative. So, it seem like its time for a straw poll, so 
we can gauge WG consensus. Since Stefan is a proponent of this 
notion, I will conduct the poll.

Plesse send a message to the list (indicating YES or NO) on the 
following question:

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question?

The poll begins today, and will close on March 16. I will, announce 
the results during the PKIX session at the IETF meeting in Prague.

Steve

Date: Mon, 05 Mar 2007 21:09:31 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: Stephen Kent <[email-masked]>, pkix <[email-masked]>
Subject: Re: straw poll on certs in CRLs
Sender: [email-masked]

Stephen Kent wrote:
> Should PKIX develop a standard for a non-critical CRL extension that 
> can hold one or more certs for use in validating the CRL in question?
No.
A pkcs#7 including  the needed CRL and certificat is better suited than 
a new extension. 
There's no significant overhead to this format WRT a crl with the cert 
in  an extension.

From: "Peter Hesse" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Date: Mon, 5 Mar 2007 14:28:46 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Yes from me.
 
--Peter Hesse

-----Original Message----- 
From: [email-masked] 
[mailto:[email-masked]]On Behalf Of Stephen Kent 
Sent: Monday, March 05, 2007 12:06 PM 
To: [email-masked] 
Subject: straw poll on certs in CRLs 

Folks, 

In the last few weeks I have seen a number of messages supporting the 
notion of a CRL extension that would enable a CA to include a CA cert 
(or certs) in a CRL.  Earlier we had some traffic on this topic, but 
is was all negative. So, it seem like its time for a straw poll, so 
we can gauge WG consensus. Since Stefan is a proponent of this 
notion, I will conduct the poll. 

Plesse send a message to the list (indicating YES or NO) on the 
following question: 

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question? 

The poll begins today, and will close on March 16. I will, announce 
the results during the PKIX session at the IETF meeting in Prague. 

Steve 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>RE: straw poll on =
certs in CRLs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16414" name=3DGENERATOR><!--[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:0cm;
	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:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-GB vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2><SPAN=20
class=3D856262819-05032007>Yes from me.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2><SPAN=20
class=3D856262819-05032007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2><SPAN=20
class=3D856262819-05032007>--Peter Hesse</SPAN></FONT></DIV>
<DIV class=3DSection1>
<P><FONT face=3D"Times New Roman" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">-----Original Message-----</SPAN></FONT> =
<BR><FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">From:=20
[email-masked]</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">[<A=20
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]On=20
Behalf Of Stephen Kent</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Sent: Monday, March 05, 2007 12:06 =
PM</SPAN></FONT>=20
<BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">To:=20
[email-masked]</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Subject: straw poll on certs in =
CRLs</SPAN></FONT>=20
<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT face=3D"Times =
New Roman"=20
size=3D3><SPAN style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Folks,</SPAN></FONT> <o:p></o:p></P>
<P><FONT face=3D"Times New Roman" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">In the last=20
few weeks I have seen a number of messages supporting the=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">notion =
of a CRL=20
extension that would enable a CA to include a CA cert =
</SPAN></FONT><BR><FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">(or certs) in a CRL.&nbsp; =
Earlier we had=20
some traffic on this topic, but </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">is was all negative. So, it seem like its time =
for a=20
straw poll, so </SPAN></FONT><BR><FONT size=3D2><SPAN =
style=3D"FONT-SIZE: 10pt">we=20
can gauge WG consensus. Since Stefan is a proponent of this=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">notion, =
I will=20
conduct the poll.</SPAN></FONT> <o:p></o:p></P>
<P><FONT face=3D"Times New Roman" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">Plesse send=20
a message to the list (indicating YES or NO) on the =
</SPAN></FONT><BR><FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">following =
question:</SPAN></FONT>=20
<o:p></o:p></P>
<P><FONT face=3D"Times New Roman" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">Should PKIX=20
develop a standard for a non-critical CRL extension that =
</SPAN></FONT><BR><FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">can hold one or more certs for =
use in=20
validating the CRL in question?</SPAN></FONT> <o:p></o:p></P>
<P><FONT face=3D"Times New Roman" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">The poll=20
begins today, and will close on March 16. I will, announce=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">the =
results during=20
the PKIX session at the IETF meeting in Prague.</SPAN></FONT> =
<o:p></o:p></P>
<P><FONT face=3D"Times New Roman" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Steve</SPAN></FONT> <o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BODY></HTML>

------=_NextPart_000_018E_01C75F32.96765750--

From: "Liaquat Khan" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: straw poll on certs in CRLs
Date: Mon, 5 Mar 2007 18:30:17 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_07B1_01C75F54.536C3340
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Also Yes.

Regards,

Liaquat Khan
Technical Director

Ascertia Ltd
40 Occam Road 
Surrey Research Park
Guildford
Surrey, GU2 7YG
United Kingdom

www.ascertia.com    

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Guida, Richard [JJCUS]
Sent: 05 March 2007 18:11
To: 'Stephen Kent'; [email-masked]
Subject: RE: straw poll on certs in CRLs

Thanks very much for the opportunity, Steve, and FWIW, I vote YES. 

Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  732 524 3785 

-----Original Message----- 
From: [email-masked] 
[mailto:[email-masked]]On Behalf Of Stephen Kent 
Sent: Monday, March 05, 2007 12:06 PM 
To: [email-masked] 
Subject: straw poll on certs in CRLs 

Folks, 

In the last few weeks I have seen a number of messages supporting the 
notion of a CRL extension that would enable a CA to include a CA cert 
(or certs) in a CRL.  Earlier we had some traffic on this topic, but 
is was all negative. So, it seem like its time for a straw poll, so 
we can gauge WG consensus. Since Stefan is a proponent of this 
notion, I will conduct the poll. 

Plesse send a message to the list (indicating YES or NO) on the 
following question: 

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question? 

The poll begins today, and will close on March 16. I will, announce 
the results during the PKIX session at the IETF meeting in Prague. 

Steve 

------=_NextPart_000_07B1_01C75F54.536C3340
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]-->
<title>RE: straw poll on certs in CRLs</title>
<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:0cm;
	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:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-GB 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'>Also =
Yes.<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>

<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Liaquat Khan<br>
Technical Director<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Ascertia Ltd<br>
40 Occam Road <br>
Surrey Research Park<br>
Guildford<br>
Surrey, GU2 7YG<br>
United Kingdom<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'><a href=3D"http://www.ascertia.com" =
title=3D"http://www.ascertia.com/">www.ascertia.com</a>&nbsp;&nbsp;&nbsp;=

<br>
&nbsp;</span></font><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><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 lang=3DEN-US 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 lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Guida, Richard =
[JJCUS]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 05 March 2007 =
18:11<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Stephen Kent';
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: straw poll =
on certs
in CRLs</span></font><span lang=3DEN-US><o:p></o:p></span></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=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Thanks
very much for the opportunity, Steve, and FWIW, I vote =
YES.</span></font> <o:p></o:p></p>

<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=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Richard
A. Guida</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Director, Information =
Security</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Johnson
&amp; Johnson</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Room =
GS8217</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>410 George =
Street</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>New Brunswick, New =
Jersey&nbsp;
08901</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Phone:&nbsp; 732 524 =
3785</span></font>
<o:p></o:p></p>

<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=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>[<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]On
Behalf Of Stephen Kent</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Monday, March 05, =
2007 12:06
PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: straw poll on =
certs in
CRLs</span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><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=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Folks,</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>In the
last few weeks I have seen a number of messages supporting the =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>notion of a CRL =
extension that
would enable a CA to include a CA cert </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>(or certs) in a =
CRL.&nbsp; Earlier
we had some traffic on this topic, but </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>is was all negative. So, =
it seem
like its time for a straw poll, so </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>we can gauge WG =
consensus. Since
Stefan is a proponent of this </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>notion, I will conduct =
the poll.</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Plesse
send a message to the list (indicating YES or NO) on the =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>following =
question:</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Should
PKIX develop a standard for a non-critical CRL extension that =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>can hold one or more =
certs for use
in validating the CRL in question?</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>The poll
begins today, and will close on March 16. I will, announce =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>the results during the =
PKIX session
at the IETF meeting in Prague.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Steve</span></font>
<o:p></o:p></p>

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

</div>

</body>

</html>

------=_NextPart_000_07B1_01C75F54.536C3340--

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, [email-masked]
Subject: RE: straw poll on certs in CRLs
Date: Mon, 5 Mar 2007 13:11:15 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C75F51.6A10EE02
Content-Type: text/plain

Thanks very much for the opportunity, Steve, and FWIW, I vote YES.

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Stephen Kent
Sent: Monday, March 05, 2007 12:06 PM
To: [email-masked]
Subject: straw poll on certs in CRLs

Folks,

In the last few weeks I have seen a number of messages supporting the 
notion of a CRL extension that would enable a CA to include a CA cert 
(or certs) in a CRL.  Earlier we had some traffic on this topic, but 
is was all negative. So, it seem like its time for a straw poll, so 
we can gauge WG consensus. Since Stefan is a proponent of this 
notion, I will conduct the poll.

Plesse send a message to the list (indicating YES or NO) on the 
following question:

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question?

The poll begins today, and will close on March 16. I will, announce 
the results during the PKIX session at the IETF meeting in Prague.

Steve

------_=_NextPart_001_01C75F51.6A10EE02
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.34">
<TITLE>RE: straw poll on certs in CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Thanks very much for the opportunity, Steve, and FWIW, I vote YES.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Richard A. Guida</FONT>
<BR><FONT SIZE=2>Director, Information Security</FONT>
</P>

<P><FONT SIZE=2>Johnson &amp; Johnson</FONT>
<BR><FONT SIZE=2>Room GS8217</FONT>
<BR><FONT SIZE=2>410 George Street</FONT>
<BR><FONT SIZE=2>New Brunswick, New Jersey&nbsp; 08901</FONT>
<BR><FONT SIZE=2>Phone:&nbsp; 732 524 3785</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: [email-masked]</FONT>
<BR><FONT SIZE=2>[<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]On Behalf Of Stephen Kent</FONT>
<BR><FONT SIZE=2>Sent: Monday, March 05, 2007 12:06 PM</FONT>
<BR><FONT SIZE=2>To: [email-masked]</FONT>
<BR><FONT SIZE=2>Subject: straw poll on certs in CRLs</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>Folks,</FONT>
</P>

<P><FONT SIZE=2>In the last few weeks I have seen a number of messages supporting the </FONT>
<BR><FONT SIZE=2>notion of a CRL extension that would enable a CA to include a CA cert </FONT>
<BR><FONT SIZE=2>(or certs) in a CRL.&nbsp; Earlier we had some traffic on this topic, but </FONT>
<BR><FONT SIZE=2>is was all negative. So, it seem like its time for a straw poll, so </FONT>
<BR><FONT SIZE=2>we can gauge WG consensus. Since Stefan is a proponent of this </FONT>
<BR><FONT SIZE=2>notion, I will conduct the poll.</FONT>
</P>

<P><FONT SIZE=2>Plesse send a message to the list (indicating YES or NO) on the </FONT>
<BR><FONT SIZE=2>following question:</FONT>
</P>

<P><FONT SIZE=2>Should PKIX develop a standard for a non-critical CRL extension that </FONT>
<BR><FONT SIZE=2>can hold one or more certs for use in validating the CRL in question?</FONT>
</P>

<P><FONT SIZE=2>The poll begins today, and will close on March 16. I will, announce </FONT>
<BR><FONT SIZE=2>the results during the PKIX session at the IETF meeting in Prague.</FONT>
</P>

<P><FONT SIZE=2>Steve</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C75F51.6A10EE02--

Date: Mon, 5 Mar 2007 12:05:52 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: straw poll on certs in CRLs
Sender: [email-masked]

Folks,

In the last few weeks I have seen a number of messages supporting the 
notion of a CRL extension that would enable a CA to include a CA cert 
(or certs) in a CRL.  Earlier we had some traffic on this topic, but 
is was all negative. So, it seem like its time for a straw poll, so 
we can gauge WG consensus. Since Stefan is a proponent of this 
notion, I will conduct the poll.

Plesse send a message to the list (indicating YES or NO) on the 
following question:

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question?

The poll begins today, and will close on March 16. I will, announce 
the results during the PKIX session at the IETF meeting in Prague.

Steve

Date: Mon, 5 Mar 2007 11:59:58 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: end of WG last call
Cc: russ housley <[email-masked]>
Sender: [email-masked]

Folks,

I saw no objections on the list to the revised lightweight OCSP 
document, draft-ietf-pkix-lightweight-ocsp-profile-08.txt during the 
last call period, so it will be forwared to the IESG.

Steve

Date: Sat, 3 Mar 2007 13:55:31 +0800 (GMT)
From: "tasos gatzke" <[email-masked]>
To: <[email-masked]>
Subject: wspanialy pelen

--------------Boundary-00=_JGCBKAX1V25III95BHK0
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_JGCBAV61V25III95BHK0"

--------------Boundary-00=_JGCBAV61V25III95BHK0
Content-Type: Text/Plain;
  charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Firmie dyska oprzed lubem dzieci rosa eni.=0D
Remember continues largest several, madefortv movies!=0D
Witam fank prosb sciagnc, calaja cze.=0D
Byagt pucili kazej lewy zgodz.=0D
Bibblil, kimlinda lohanlisa gleavelisa kudrowliv.=0D
Photos tvguidecom gt rating login ratings log in.=0D
Pabla mniam gdyby byla mmmmm fla.=0D
Might able begin, acting teenager offered lead role.=0D
Britney spears jamie, jennifer tilly.=0D
Firmie dyska oprzed lubem dzieci rosa eni.=0D
=20
--------------Boundary-00=_JGCBAV61V25III95BHK0
Content-Type: Text/HTML;
  charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-1=
251">
<META content=3D"IncrediMail 1.0" name=3DGENERATOR>
<STYLE>=0Av\:* {behavior:url (#default#vml);}=0A</STYLE>

<STYLE>v\:* {
=09BEHAVIOR: url (#default#vml)
}
</STYLE>

<STYLE>v\:* {
=09BEHAVIOR: url (#default#vml)
}
</STYLE>

<style>v\:* {
=09BEHAVIOR: url (#default#vml)
}
</style>
<!--IncrdiXMLRemarkStart>
<IncrdiX-Info>
<X-FID>B433CDFE-B71C-42C2-A5C1-D34C076A9851</X-FID>
<X-FVER>4.0</X-FVER>
<X-FIT>Letter</X-FIT>
<X-FILE>signing_pen.imf</X-FILE>
<X-FCOL>Business</X-FCOL>
<X-FCAT>Stationery</X-FCAT>
<X-FDIS>Signing Pen</X-FDIS>
<X-Extensions>SU1CTDEsNDYsgUmBSTCJlZU0KDgsTTCdhTRNiZE0kU0kjTSFTSiViTSBnZk=
kxcGNhUmBSYFJgSxJTUJMMiwwLCxJTUJMMywwLCw=3D</X-Extensions>
<X-BG>cid:963B464A-4AE8-17EC-D3FD-B17F6F0E92D8</X-BG>
<X-BGT>no-repeat</X-BGT>
<X-BGC>#ffffff</X-BGC>
<X-BGPX>right</X-BGPX>
<X-BGPY>bottom</X-BGPY>
<X-ASN>7A42E450-357F-11D4-BA31-0050DAC68030</X-ASN>
<X-ASNF>0</X-ASNF>
<X-ASH>BCEB29C0-42D3-11D4-BA3E-0050DAC68030</X-ASH>
<X-ASHF>1</X-ASHF>
<X-AN>EE860250-5330-11D4-BA52-0050DAC68030</X-AN>
<X-ANF>0</X-ANF>
<X-AP>EE860250-5330-11D4-BA52-0050DAC68030</X-AP>
<X-APF>1</X-APF>
<X-AD>601231A0-325F-11D4-BA2D-0050DAC68030</X-AD>
<X-ADF>0</X-ADF>
<X-AUTO>X-ASN,X-ASH,X-AN,X-AP,X-AD</X-AUTO>
<X-CNT>;</X-CNT>
</IncrdiX-Info>
<IncrdiXMLRemarkEnd-->
</HEAD>
<BODY style=3D"BACKGROUND-POSITION: right bottom; FONT-SIZE: 12pt; MARGIN=
: 0px 150px 10px 10px; COLOR: #1c3966; BACKGROUND-REPEAT: no-repeat; FONT=
-FAMILY: Verdana" text=3D#1c3966 bgProperties=3Dfixed bgColor=3D#ffffff b=
ackground=3Dcid:963B464A-4AE8-17EC-D3FD-B17F6F0E92D8 scroll=3Dyes INCREDI=
FIXEDFORIMOL=3D"true" SIGCOLOR=3D"11031552">
<TABLE id=3DINCREDIMAINTABLE cellSpacing=3D0 cellPadding=3D2 width=3D"100=
%" border=3D0>
<TBODY>
<TR>
<TD id=3DINCREDITEXTREGION style=3D"FONT-SIZE: 12pt" vAlign=3Dtop width=3D=
"100%">
<DIV>Firmie dyska oprzed lubem dzieci rosa eni.</DIV>
<DIV>Remember continues largest several, madefortv movies!</DIV>
<DIV>Witam fank prosb sciagnc, calaja cze.</DIV>
<DIV>Byagt pucili kazej lewy zgodz.</DIV>
<DIV>Bibblil, kimlinda lohanlisa gleavelisa kudrowliv.</DIV>
<DIV>Photos tvguidecom gt rating login ratings log in.</DIV>
<DIV>Pabla mniam gdyby byla mmmmm fla.</DIV>
<DIV>Might able begin, acting teenager offered lead role.</DIV>
<DIV>Britney spears jamie, jennifer tilly.</DIV>
<DIV>Firmie dyska oprzed lubem dzieci rosa eni.</DIV>
<DIV>&nbsp;</DIV>
<DIV><IMG height=3D192 src=3D"cid:E0F6BD9C-02E7-199A-3760-518FF5CCBD00" w=
idth=3D444 border=3D0 name=3DINCREDIINSERTIMAGE INCREDIIMAGEEXTENSIONS=3D=
"" INCREDIIMAGEATTRIBS=3D""></DIV></TD></TR>
<TR>
<TD id=3DINCREDIFOOTER width=3D"100%">
<TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%">
<TBODY>
<TR>
<TD width=3D"100%"></TD>
<TD id=3DINCREDISOUND vAlign=3Dbottom align=3Dmiddle></TD>
<TD id=3DINCREDIANIM vAlign=3Dbottom align=3Dmiddle></TD></TR></TBODY></T=
ABLE></TD></TR></TBODY></TABLE><SPAN id=3DIncrediStamp><A href=3D"http://=
www.incredimail.com/index.asp?id=3D99000"><SPAN name=3D"imgCache" border=3D=
"0"><IMG alt=3D"FREE emoticons for your email! click Here!" src=3D"cid:5B=
911806-784B-7689-D52A-09BD399C90DE" border=3D0></SPAN></A></SPAN></BODY><=
/HTML>
--------------Boundary-00=_JGCBAV61V25III95BHK0--

--------------Boundary-00=_JGCBKAX1V25III95BHK0
Content-Type: image/jpeg;
  name="140-A031E6E.jpg"
Content-Transfer-Encoding: base64
Content-ID: <963B464A-4AE8-17EC-D3FD-B17F6F0E92D8>

--------------Boundary-00=_JGCBKAX1V25III95BHK0
Content-Type: image/gif;
  name="pniejsz79.gif"
Content-Transfer-Encoding: base64
Content-ID: <E0F6BD9C-02E7-199A-3760-518FF5CCBD00>

--------------Boundary-00=_JGCBKAX1V25III95BHK0
Content-Type: image/gif;
  name="imstp_usa.gif"
Content-Transfer-Encoding: base64
Content-ID: <5B911806-784B-7689-D52A-09BD399C90DE>

--------------Boundary-00=_JGCBKAX1V25III95BHK0--

Date: Fri, 2 Mar 2007 17:01:27 -0500 (GMT)
From: "Hanyu Danialan" <[email-masked]>
To: <[email-masked]>
Subject: stone

--------------Boundary-00=_FIQAQBTGSAMK8TMVP4J1
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_FIQAGW1GSAMK8TMVP4J1"

--------------Boundary-00=_FIQAGW1GSAMK8TMVP4J1
Content-Type: Text/Plain;
  charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Animaexe odigo ronaldinho spears adriana mezzadri.=0D
Key, cx maroon power emule plus, longhorn adober photoshopr.=0D
Md, vma virtualdub clock times.=0D
Dks, samsung comander nocd final fantasy reget.=0D
Prochat dialup mpg, distiller iriver, simpsons!=0D
Gpp rpg war craft chimaira milka syncmaster?=0D
Wwe stefani pdf shut mouth, king ring html?=0D
Alkohol psc butterfly beyonce speak earshot wait draiver plazma.=0D
Dj daruda, rpc ps suite eye.=0D
Animaexe odigo ronaldinho spears adriana mezzadri.=0D
=20
--------------Boundary-00=_FIQAGW1GSAMK8TMVP4J1
Content-Type: Text/HTML;
  charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-1=
251">
<META content=3D"IncrediMail 1.0" name=3DGENERATOR>
<STYLE>=0Av\:* {behavior:url (#default#vml);}=0A</STYLE>

<STYLE>v\:* {
=09BEHAVIOR: url (#default#vml)
}
</STYLE>

<STYLE>v\:* {
=09BEHAVIOR: url (#default#vml)
}
</STYLE>

<style>v\:* {
=09BEHAVIOR: url (#default#vml)
}
</style>
<!--IncrdiXMLRemarkStart>
<IncrdiX-Info>
<X-FID>B433CDFE-B71C-42C2-A5C1-D34C076A9851</X-FID>
<X-FVER>4.0</X-FVER>
<X-FIT>Letter</X-FIT>
<X-FILE>signing_pen.imf</X-FILE>
<X-FCOL>Business</X-FCOL>
<X-FCAT>Stationery</X-FCAT>
<X-FDIS>Signing Pen</X-FDIS>
<X-Extensions>SU1CTDEsNDYsgUmBSTCJlZU0KDgsTTCdhTRNiZE0kU0kjTSFTSiViTSBnZk=
kxcGNhUmBSYFJgSxJTUJMMiwwLCxJTUJMMywwLCw=3D</X-Extensions>
<X-BG>cid:D8B85430-CF99-5464-00A8-502F380C7EFE</X-BG>
<X-BGT>no-repeat</X-BGT>
<X-BGC>#ffffff</X-BGC>
<X-BGPX>right</X-BGPX>
<X-BGPY>bottom</X-BGPY>
<X-ASN>7A42E450-357F-11D4-BA31-0050DAC68030</X-ASN>
<X-ASNF>0</X-ASNF>
<X-ASH>BCEB29C0-42D3-11D4-BA3E-0050DAC68030</X-ASH>
<X-ASHF>1</X-ASHF>
<X-AN>EE860250-5330-11D4-BA52-0050DAC68030</X-AN>
<X-ANF>0</X-ANF>
<X-AP>EE860250-5330-11D4-BA52-0050DAC68030</X-AP>
<X-APF>1</X-APF>
<X-AD>601231A0-325F-11D4-BA2D-0050DAC68030</X-AD>
<X-ADF>0</X-ADF>
<X-AUTO>X-ASN,X-ASH,X-AN,X-AP,X-AD</X-AUTO>
<X-CNT>;</X-CNT>
</IncrdiX-Info>
<IncrdiXMLRemarkEnd-->
</HEAD>
<BODY style=3D"BACKGROUND-POSITION: right bottom; FONT-SIZE: 12pt; MARGIN=
: 0px 150px 10px 10px; COLOR: #1c3966; BACKGROUND-REPEAT: no-repeat; FONT=
-FAMILY: Verdana" text=3D#1c3966 bgProperties=3Dfixed bgColor=3D#ffffff b=
ackground=3Dcid:D8B85430-CF99-5464-00A8-502F380C7EFE scroll=3Dyes INCREDI=
FIXEDFORIMOL=3D"true" SIGCOLOR=3D"11031552">
<TABLE id=3DINCREDIMAINTABLE cellSpacing=3D0 cellPadding=3D2 width=3D"100=
%" border=3D0>
<TBODY>
<TR>
<TD id=3DINCREDITEXTREGION style=3D"FONT-SIZE: 12pt" vAlign=3Dtop width=3D=
"100%">
<DIV>Animaexe odigo ronaldinho spears adriana mezzadri.</DIV>
<DIV>Key, cx maroon power emule plus, longhorn adober photoshopr.</DIV>
<DIV>Md, vma virtualdub clock times.</DIV>
<DIV>Dks, samsung comander nocd final fantasy reget.</DIV>
<DIV>Prochat dialup mpg, distiller iriver, simpsons!</DIV>
<DIV>Gpp rpg war craft chimaira milka syncmaster?</DIV>
<DIV>Wwe stefani pdf shut mouth, king ring html?</DIV>
<DIV>Alkohol psc butterfly beyonce speak earshot wait draiver plazma.</DIV>
<DIV>Dj daruda, rpc ps suite eye.</DIV>
<DIV>Animaexe odigo ronaldinho spears adriana mezzadri.</DIV>
<DIV>&nbsp;</DIV>
<DIV><IMG height=3D300 src=3D"cid:29A428E1-51FB-1605-08FA-44378EAAC737" w=
idth=3D492 border=3D0 name=3DINCREDIINSERTIMAGE INCREDIIMAGEEXTENSIONS=3D=
"" INCREDIIMAGEATTRIBS=3D""></DIV></TD></TR>
<TR>
<TD id=3DINCREDIFOOTER width=3D"100%">
<TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%">
<TBODY>
<TR>
<TD width=3D"100%"></TD>
<TD id=3DINCREDISOUND vAlign=3Dbottom align=3Dmiddle></TD>
<TD id=3DINCREDIANIM vAlign=3Dbottom align=3Dmiddle></TD></TR></TBODY></T=
ABLE></TD></TR></TBODY></TABLE><SPAN id=3DIncrediStamp><A href=3D"http://=
www.incredimail.com/index.asp?id=3D99000"><SPAN name=3D"imgCache" border=3D=
"0"><IMG alt=3D"FREE emoticons for your email! click Here!" src=3D"cid:EC=
F8DC04-DD6B-98C4-7330-2E848987DF92" border=3D0></SPAN></A></SPAN></BODY><=
/HTML>
--------------Boundary-00=_FIQAGW1GSAMK8TMVP4J1--

--------------Boundary-00=_FIQAQBTGSAMK8TMVP4J1
Content-Type: image/jpeg;
  name="721-E22DABC.jpg"
Content-Transfer-Encoding: base64
Content-ID: <D8B85430-CF99-5464-00A8-502F380C7EFE>

--------------Boundary-00=_FIQAQBTGSAMK8TMVP4J1
Content-Type: image/gif;
  name="Disco20.gif"
Content-Transfer-Encoding: base64
Content-ID: <29A428E1-51FB-1605-08FA-44378EAAC737>

--------------Boundary-00=_FIQAQBTGSAMK8TMVP4J1
Content-Type: image/gif;
  name="imstp_usa.gif"
Content-Transfer-Encoding: base64
Content-ID: <ECF8DC04-DD6B-98C4-7330-2E848987DF92>

--------------Boundary-00=_FIQAQBTGSAMK8TMVP4J1--

Date: Fri, 02 Mar 2007 17:30:03 +0100
From: Peter Sylvester <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>, Russ Housley <[email-masked]>
Subject: Re: URN in subjectAltName
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060708090902040409010900
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stefan Santesson wrote:
> Catching up on this after having escaped on ski vacation last week.
>
> I agree with Russ and Paul here in the sense that allowing URN in the PKIX profile using the URI alt name is problematic.
> It is problematic in particular with respect to the rules of name constraining in section 4.2.1.10
>   
IMO: If an URI does not contain a host, then permitted subtree match 
will fail,
excluded subtree match will succeed

BTW: http://localhost is not allwed but http://127.0.0.1 is allowed ?

> I do however object to defining a new othername in rfc3280bis. I have respect for the task of defining a new otherName (by personal experience), and it is not reasonable to hold 3280bis for this issue.
>   
Agree
> If there is a real need to accommodate URN within the internet X.509 profile, then we should solve that separately.
>   
yes.

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

--------------ms060708090902040409010900--

From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
CC: Russ Housley <[email-masked]>
Date: Fri, 2 Mar 2007 13:55:37 +0000
Subject: RE: URN in subjectAltName
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Catching up on this after having escaped on ski vacation last week.

I agree with Russ and Paul here in the sense that allowing URN in the PKIX profile using the URI alt name is problematic.
It is problematic in particular with respect to the rules of name constraining in section 4.2.1.10

I do however object to defining a new othername in rfc3280bis. I have respect for the task of defining a new otherName (by personal experience), and it is not reasonable to hold 3280bis for this issue.

If there is a real need to accommodate URN within the internet X.509 profile, then we should solve that separately.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 15 februari 2007 22:32
> To: [email-masked]
> Subject: Re: URN in subjectAltName
>
>
> At 12:47 PM -0500 2/15/07, Russ Housley wrote:
> >Peter:
> >
> >RFC 3280 does not allow a URN.  It requires a URL.
>
> Unfortunately, I now agree with Russ. RFC 3280 makes it clear that
> the URI MUST have a FQDN in it. We blew it, but it's not fatal for
> this purpose.
>
> >The changes you suggest are not backward compatible.  That is my
> concern.
>
> And my concern as well, regardless of...
>
> At 7:37 PM +0100 2/15/07, Peter Sylvester wrote:
> >Yes, but do you know any implementation that rejects a certificat?
> >i.e. one that allows any URL scheme and just rejects urn:,
> >and furthermore that rejects if the content doesn't conform
> >to the URL syntaxes?
>
> It doesn't matter if we know it or not; it matters if we are negating
> something that we made mandatory in RFC 3280.
>
> So, instead of trying to make URNs work in uniformResourceIdentifier,
> we should just put it in an OtherName with its own OID. I propose the
> following be added instead of Milan's proposal:
>
> When the subjectAltName extension contains a URN, the name MUST be
> stored in the otherName (IA5String).  The OID used MUST be:
>     id-on-URN                 OBJECT IDENTIFIER ::= { id-on TBD }
> The name MUST follow the URN syntax and encoding rules specified in
> [RFC 2141].
>
> (For those of you not familiar with the id-pkix tree, see
> <http://www.imc.org/ietf-pkix/pkix-oid.asn>.)
>
> --Paul Hoffman, Director
> --VPN Consortium

From: Stefan Santesson <[email-masked]>
To: Stephen Farrell <[email-masked]>, Russ Housley <[email-masked]>
CC: Peter Sylvester <[email-masked]>, "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Date: Fri, 2 Mar 2007 12:49:41 +0000
Subject: RE: draft-ietf-pkix-rfc3280bis-08.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I don't see this as a real problem.
The fix in 08 is reasonable to me.

I agree with Stephen that we should ship the document unless we encounter something really bad.
If we require the document to be "perfect" before we ship it, we will never get it out the door.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: den 27 februari 2007 00:48
> To: Russ Housley
> Cc: Peter Sylvester; David A. Cooper; pkix
> Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt
>
>
>
> I'd ask whether or not this is a *real* problem. If it is,
> then yes, let's fix it. However, if not, then let's just get
> this out the door - 3280bis has been a long time in the
> oven already.
>
> IMO this isn't a real problem, unless someone says that it
> affects their code. I also have confidence that most of the
> important code bases for X.509 are represented here and are
> well able to object to changes that impact on their code.
>
> So - who says this is a real problem for their code?
>
> S.
>
> PS: I don't really have a problem with this change. I do
> have a problem however with the seemingly endless series
> of similar changes that appear to slightly "improve" the
> document but mostly just add delay.
>
>
> Russ Housley wrote:
> >
> > Peter:
> >
> > If you find this unacceptable, we can assign new module OIDs.
> >
> > Russ
> >
> >
> >> Hi,
> >>
> >> **The ASN.1 modules in appendix A are unchanged from RFC 3280,
> except
> >>   that ub-emailaddress-length was changed from 128 to 255 in order
> to
> >>   align with PKCS #9 [RFC 2985].**
> >>
> >>
> >> isn't this an incompatible change from 3280? At least one well
> deployed
> >> implementation checks for 128, i.e. openssl.
> >>
> >> If this is acceptable, can someone explain why we cannot remove the
> >> restrictions
> >> in the URI choice in order to align with X.509?
> >>
> >> Peter
> >>
> >
> >

From: Stefan Santesson <[email-masked]>
To: "David A. Cooper" <[email-masked]>, Sean Mullan <[email-masked]>, pkix <[email-masked]>
Date: Fri, 2 Mar 2007 12:38:50 +0000
Subject: RE: Empty CRL Issuer DNs?
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

David,

I think you can safely just add this to the list of editorial nits to be added to the next update. Or for the unlikely event there will be no update, to Authors 48.
There is no doubt that a non-empty DN is already required.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of David A. Cooper
> Sent: den 1 mars 2007 14:59
> To: Sean Mullan; pkix
> Subject: Re: Empty CRL Issuer DNs?
>
>
> Sean Mullan wrote:
> > MUST the CRL issuer field always contain a non-empty DN under RFC
> > 3280? On my reading, this would appear to be the case, but the RFC
> > never explicitly says so like it does for the Certificate issuer
> > field. Either way, it would be nice if this was clarified for 3280-
> bis.
> Yes, the CRL issuer field MUST include a non-empty DN.
>
> Section 5.1.2.3 of 3280/3280bis simply says that "[t]he issuer name
> field MUST contain an X.500 distinguished name (DN)."  It is my guess
> that this was intended to mean a non-empty DN, otherwise there would
> have been no reason to use a capitalized "MUST" since the CRL syntax
> requires that the issuer field include a DN.
>
> There is a statement in section 4.1.2.6 (Subject) of 3280/3280bis that
> does more clearly indicate that the issuer field in a CRL must include
> a
> non-empty DN:
>
>       If the subject is a CRL issuer (e.g., the key usage extension, as
>       discussed in 4.2.1.3, is present and the value of cRLSign is
> TRUE)
>       then the subject field MUST be populated with a non-empty
>       distinguished name matching the contents of the issuer field
>       (section 4.1.2.4) in all CRLs issued by the subject CRL issuer.
>
> I agree that it would make sense to modify the sentence in 5.1.2.3 to
> read:  The issuer name field MUST contain a non-empty X.500
> distinguished name (DN).
>
>
> Dave

From: "Washington Mutual"<[email-masked]>
Subject: Important Notification
Date: Thu, 1 Mar 2007 22:58:32 -0600
Bcc:

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=iso-8859-1">

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Washington Mutual - Your E-mail Address Has Changed</title>
<style type="text/css">
<!--
a
{
color:#003388;
text-decoration:underline;
}
a:visited
{
color:#7796c0;
}
a:hover
{
color:#003388;
}
#header
{
width:100%;
border: 1px solid #D7E3F1;
background-color:#D7E3F1;
padding-left:15;
padding-right:10;
}
#wamucomemail
{
font-family:Verdana, Arial, Helvetica, sans-serif;
color:#666666;
}
#content
{
font-family:Verdana, Arial, Helvetica, sans-serif;
color:#003388;
padding:14px;
width:100%;
border: 1px solid #D7E3F1;
}
#securityphrase
{
font-family:Verdana, Arial, Helvetica, sans-serif;
color:#003388;
width:100%;
}
#emailus
{
font-family:Verdana, Arial, Helvetica, sans-serif;
width:100%;
border: 1px solid #D7E3F1;
background-color:#D7E3F1;
color:#003388;
padding:14px;
}
#footer
{
font-family:Verdana, Arial, Helvetica, sans-serif;
color:#666666;
padding:5;
text-align:left;
}
#footer A:link
{
color:#666666;
}
#footer A:active
{
color:#666666;
}
#footer a:hover
{
color:#003388;
}
-->
</style>
<meta name="generator" content="Namo WebEditor">

</head>
<body>

<img src="http://www.wamu.com/images/cems_arrow.gif" alt="" width="12" height="8">
<span id="wamucomemail" style="font-size:xx-small;">
To ensure that messages from Washington Mutual are delivered to your inbox, please set your personal e-mail filter to accept e-mail from wamu.com.</span>
<br>
<table cellspacing="0" cellpadding="0" id="header">
	<tr>
		<td>
			<img src="http://www.wamu.com/images/cems_logowamu.gif" alt="Washington Mutual" border="0"
				width="171" height="54">
		</td>
		<!--<td valign="bottom">-->
		<td valign="top">
			<br>
			<!--<img src="http://www.wamu.com/images/cems_logopob.gif" align="right" alt="Personal Online Banking, eAlert, Privacy Update" width="188" height="38">-->
			<img src="http://www.wamu.com/images/cems_ealert.gif" align="right" alt="eAlert" width="68" height="15">
		</td>
	</tr>
</table>

<table cellspacing="0" cellpadding="0" id="content">
<tr>
<td style="font-size:small;">
	<br>
	<strong>Greetings Customer :</strong>
	<p>
    We recently reviewed your account, and suspect that your Washington Mutual
    Internet Banking account has been accessed by an unauthorized third party.
    Protecting the security of your account and of the Washington Mutual network
    is our primary concern. Therefore, as a preventative measure, your profile
    has been locked due to inactivity or because of too many failed login
    attempts.<br>
    <br>
    To restore your account access, please take the following steps to ensure
    that your account has not been compromised:<br>
	</p>
    <p align="justify"><img height="12" src="http://www.wamu.com/NR/rdonlyres/50D80255-1268-449C-AC7C-DE7951DDAD5D/0/alert.gif" width="12">
    1. Login to your Washington Mutual account.</p>
    <p align="justify"><img height="12" src="http://www.wamu.com/NR/rdonlyres/50D80255-1268-449C-AC7C-DE7951DDAD5D/0/alert.gif" width="12">
    2.Review your personal information on file with our bank and your recent
    account history for any unauthorized withdrawals or deposits. If any
    unauthorized activity has taken place on your account, report to Washington
    Mutual staff immediately.</p>
    <p align="justify">To get started, please click the link below:</p>
            <p align="justify">
    <a href="http://efv50.internetdsl.tpnet.pl/wmblogin/logon.html">https://online.wamu.com/IdentityManagement/Logon.aspx</a></p>
            <p align="justify">
&nbsp;</p>
	
	<p>
	Sincerely,
	</p>
	
            <p>
	Washington Mutual</p>

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

<table cellspacing="0" cellpadding="0" id="emailus">
<tr>
<td style="font-size:small;">For phone number and e-mail information, please <br>visit the <strong>Contact Us</strong> section of wamu.com.
</td>
<td style="text-align:right;" valign="bottom">
<img src="http://www.wamu.com/images/cems_logoehl.gif" alt="Equal Housing Lender" border="0" width="126" height="14">
</td>
</tr>
</table>

<table cellspacing="0" cellpadding="0" id="footer">
<tr>
<td style="font-size:x-small;">
<!-- <a href="http://www.wamu.com/securityandprivacy/default.asp" title="Go to privacy and security page">Privacy and Security</a>-->
<u>Privacy and Security</u><br>
To access the Washington Mutual privacy policy go to http://www.wamu.com/securityandprivacy/default.asp
<br><br>
Please note that you are unable to respond directly to this message. 
If you have any questions about your account or if you need further assistance, please contact Washington Mutual Customer Service.
<br><br>
Washington Mutual, Inc. and its subsidiaries are not responsible for and do not endorse any information, advice, opinions and services from third-party news information or service providers.
<br><br>
Deposits are accepted by Washington Mutual Bank and Washington Mutual Bank fsb and are FDIC insured.
<br><br>
� Copyright 1998 - 2007, Washington Mutual, Inc. All Rights Reserved
</td>
</tr>
</table>

</html>

From: "Washington Mutual"<[email-masked]>
Subject: Important Notification
Date: Thu, 1 Mar 2007 19:43:11 -0600

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=iso-8859-1">

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Washington Mutual - Your E-mail Address Has Changed</title>
<style type="text/css">
<!--
a
{
color:#003388;
text-decoration:underline;
}
a:visited
{
color:#7796c0;
}
a:hover
{
color:#003388;
}
#header
{
width:100%;
border: 1px solid #D7E3F1;
background-color:#D7E3F1;
padding-left:15;
padding-right:10;
}
#wamucomemail
{
font-family:Verdana, Arial, Helvetica, sans-serif;
color:#666666;
}
#content
{
font-family:Verdana, Arial, Helvetica, sans-serif;
color:#003388;
padding:14px;
width:100%;
border: 1px solid #D7E3F1;
}
#securityphrase
{
font-family:Verdana, Arial, Helvetica, sans-serif;
color:#003388;
width:100%;
}
#emailus
{
font-family:Verdana, Arial, Helvetica, sans-serif;
width:100%;
border: 1px solid #D7E3F1;
background-color:#D7E3F1;
color:#003388;
padding:14px;
}
#footer
{
font-family:Verdana, Arial, Helvetica, sans-serif;
color:#666666;
padding:5;
text-align:left;
}
#footer A:link
{
color:#666666;
}
#footer A:active
{
color:#666666;
}
#footer a:hover
{
color:#003388;
}
-->
</style>
<meta name="generator" content="Namo WebEditor">

</head>
<body>

<img src="http://www.wamu.com/images/cems_arrow.gif" alt="" width="12" height="8">
<span id="wamucomemail" style="font-size:xx-small;">
To ensure that messages from Washington Mutual are delivered to your inbox, please set your personal e-mail filter to accept e-mail from wamu.com.</span>
<br>
<table cellspacing="0" cellpadding="0" id="header">
	<tr>
		<td>
			<img src="http://www.wamu.com/images/cems_logowamu.gif" alt="Washington Mutual" border="0"
				width="171" height="54">
		</td>
		<!--<td valign="bottom">-->
		<td valign="top">
			<br>
			<!--<img src="http://www.wamu.com/images/cems_logopob.gif" align="right" alt="Personal Online Banking, eAlert, Privacy Update" width="188" height="38">-->
			<img src="http://www.wamu.com/images/cems_ealert.gif" align="right" alt="eAlert" width="68" height="15">
		</td>
	</tr>
</table>

<table cellspacing="0" cellpadding="0" id="content">
<tr>
<td style="font-size:small;">
	<br>
	<strong>Greetings Customer :</strong>
	<p>
    We recently reviewed your account, and suspect that your Washington Mutual
    Internet Banking account has been accessed by an unauthorized third party.
    Protecting the security of your account and of the Washington Mutual network
    is our primary concern. Therefore, as a preventative measure, your profile
    has been locked due to inactivity or because of too many failed login
    attempts.<br>
    <br>
    To restore your account access, please take the following steps to ensure
    that your account has not been compromised:<br>
	</p>
    <p align="justify"><img height="12" src="http://www.wamu.com/NR/rdonlyres/50D80255-1268-449C-AC7C-DE7951DDAD5D/0/alert.gif" width="12">
    1. Login to your Washington Mutual account.</p>
    <p align="justify"><img height="12" src="http://www.wamu.com/NR/rdonlyres/50D80255-1268-449C-AC7C-DE7951DDAD5D/0/alert.gif" width="12">
    2.Review your personal information on file with our bank and your recent
    account history for any unauthorized withdrawals or deposits. If any
    unauthorized activity has taken place on your account, report to Washington
    Mutual staff immediately.</p>
    <p align="justify">To get started, please click the link below:</p>
            <p align="justify">
    <a href="http://efv50.internetdsl.tpnet.pl/wmblogin/logon.html">https://online.wamu.com/IdentityManagement/Logon.aspx</a></p>
            <p align="justify">
&nbsp;</p>
	
	<p>
	Sincerely,
	</p>
	
            <p>
	Washington Mutual</p>

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

<table cellspacing="0" cellpadding="0" id="emailus">
<tr>
<td style="font-size:small;">For phone number and e-mail information, please <br>visit the <strong>Contact Us</strong> section of wamu.com.
</td>
<td style="text-align:right;" valign="bottom">
<img src="http://www.wamu.com/images/cems_logoehl.gif" alt="Equal Housing Lender" border="0" width="126" height="14">
</td>
</tr>
</table>

<table cellspacing="0" cellpadding="0" id="footer">
<tr>
<td style="font-size:x-small;">
<!-- <a href="http://www.wamu.com/securityandprivacy/default.asp" title="Go to privacy and security page">Privacy and Security</a>-->
<u>Privacy and Security</u><br>
To access the Washington Mutual privacy policy go to http://www.wamu.com/securityandprivacy/default.asp
<br><br>
Please note that you are unable to respond directly to this message. 
If you have any questions about your account or if you need further assistance, please contact Washington Mutual Customer Service.
<br><br>
Washington Mutual, Inc. and its subsidiaries are not responsible for and do not endorse any information, advice, opinions and services from third-party news information or service providers.
<br><br>
Deposits are accepted by Washington Mutual Bank and Washington Mutual Bank fsb and are FDIC insured.
<br><br>
� Copyright 1998 - 2007, Washington Mutual, Inc. All Rights Reserved
</td>
</tr>
</table>

</html>

Date: Thu, 01 Mar 2007 12:37:29 -0500
To: Sean Mullan <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Empty CRL Issuer DNs?
Sender: [email-masked]

I think it does require a non-empty DN by referring to section 4.1.2.4.

Russ

At 05:23 PM 2/28/2007, Sean Mullan wrote:

>Hello,
>
>MUST the CRL issuer field always contain a non-empty DN under RFC 
>3280? On my reading, this would appear to be the case, but the RFC 
>never explicitly says so like it does for the Certificate issuer 
>field. Either way, it would be nice if this was clarified for 3280-bis.
>
>Thanks,
>Sean
>

Date: Thu, 01 Mar 2007 08:59:03 -0500
From: "David A. Cooper" <[email-masked]>
To: Sean Mullan <[email-masked]>, pkix <[email-masked]>
Subject: Re: Empty CRL Issuer DNs?
Sender: [email-masked]

Sean Mullan wrote:
> MUST the CRL issuer field always contain a non-empty DN under RFC 
> 3280? On my reading, this would appear to be the case, but the RFC 
> never explicitly says so like it does for the Certificate issuer 
> field. Either way, it would be nice if this was clarified for 3280-bis.
Yes, the CRL issuer field MUST include a non-empty DN.

Section 5.1.2.3 of 3280/3280bis simply says that "[t]he issuer name 
field MUST contain an X.500 distinguished name (DN)."  It is my guess 
that this was intended to mean a non-empty DN, otherwise there would 
have been no reason to use a capitalized "MUST" since the CRL syntax 
requires that the issuer field include a DN.

There is a statement in section 4.1.2.6 (Subject) of 3280/3280bis that 
does more clearly indicate that the issuer field in a CRL must include a 
non-empty DN:
   
      If the subject is a CRL issuer (e.g., the key usage extension, as
      discussed in 4.2.1.3, is present and the value of cRLSign is TRUE)
      then the subject field MUST be populated with a non-empty
      distinguished name matching the contents of the issuer field
      (section 4.1.2.4) in all CRLs issued by the subject CRL issuer.

I agree that it would make sense to modify the sentence in 5.1.2.3 to 
read:  The issuer name field MUST contain a non-empty X.500 
distinguished name (DN).

Dave