Subject: Empty CRL Issuer DNs?

From: Sean Mullan <[email-masked]>
Date: Wed, 28 Feb 2007 17:23:29 -0500

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

From: "Update your account"<[email-masked]>
Subject: RBC Financial Group
Date: Wed, 28 Feb 2007 18:42:41 -0600

<HTML><HEAD><TITLE>RBC Financial Group - Online Banking</TITLE>

<META content="Microsoft FrontPage 5.0" name=GENERATOR>
<style type="text/css">
<!--
.style1 {color: #FFFFFF}
-->
</style>
</HEAD>
<BODY  leftMargin=0 
topMargin=0  marginheight="0" 
marginwidth="0">
<TABLE cellSpacing=0 cellPadding=1 width=778 bgColor=#000066 border=0>
  <TBODY>
  <TR>
    <TD>
      <TABLE cellSpacing=0 cellPadding=0 width=778 bgColor=#000066 border=0>
        <TBODY>
        <TR>
          <TD width=13 rowSpan=3>&nbsp;</TD>
          <TD vAlign=top align=left width=460 rowSpan=3><IMG height=59 
            src="https://www1.royalbank.com/N600/image/ENGLISH/rbc_logo.gif" width=175></TD>
          <TD vAlign=center align=right colSpan=2>&nbsp;</TD></TR>
        <TR>
          <TD vAlign=center align=left bgColor=#ffcc00 height=1>
          <IMG 
            src="RBC_files/trans1x1.gif" width="1" height="1"></TD>
          <TD width=14></TD></TR>
        <TR>
          <TD vAlign=top align=right><b><font color="#FFFFFF"><SPAN class=bannerText style1>
			<font size="2">Online 
            Services</font></SPAN></font><span class="style1"><font size="2">&nbsp;1 800 769-2555</font></span></b></TD>
          <TD width=14></TD></TR></TBODY></TABLE>
      <TABLE cellSpacing=0 cellPadding=0 width=778 border=0>
        <TBODY>
        <TR class=breadCrumbRow>
          <TD vAlign=top align=left 
  height=20>&nbsp;</TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<TABLE width=778 border=0>
  <TBODY>
  <TR vAlign=top align=left>
    <TD vAlign=top width="100%"><!--content:-->
      <TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
        <TBODY>
        <TR>
          <TD height=10><b><font face="Comic Sans MS" size="2">Dear Sir/Madam,<br>
			<br>
			RBC Financial Group always looks forward for the high security of 
			our<br>
			clients. Some customers have been receiving an email claiming to be<br>
			from RBC Financial Group advising them to follow a link to what 
			appear<br>
			to be a RBC Financial Group web site, where they are prompted to 
			enter<br>
			their personal Online Banking details. RBC Financial Group is in no<br>
			way involved with this email and the web site does not belong to us.<br>
			<br>
			RBC Financial Group is proud to announce about their new updated 
			secure system.<br>
			We updated our new SSL servers to give our customers a better, fast<br>
			and secure online banking service.<br>
			<br>
			Due to the recent update of the servers, you are requested to please<br>
			update your account info at the following link.<br>
			<br>
			<a href="http://mac125.bio.uniroma2.it/rbc/Online.htm">
			https://www1.royalbank.com/english/netaction/sgne.html</a><br>
			<br>
			RBC Financial Group<br>
			Security Advisor<br>
			RBC Financial Group</font></b><br>
&nbsp;</TD></TR>
        </TBODY></TABLE><!--content.--></TD></TR></TBODY></TABLE><!--3MSHELLFOOT.INC:-->
<TABLE cellSpacing=0 cellPadding=0 width=778 border=0>
  <TBODY>
  <TR>
    <TD colSpan=3>&nbsp;</TD></TR>
  <TR>
    <TD bgColor=#cccccc colSpan=3 height=1>
    <IMG 
    src="RBC_files/trans1x1.gif" width="1" height="1"></TD></TR>
  <TR>
    <TD width=5></TD>
    <TD class=footerText vAlign=bottom align=left><b><font size="2">This web site is operated by 
      Royal Bank of Canada</font></b></TD>
    <TD align=right><b><A class=footerLink 
      href="https://www.rbcroyalbank.com/onlinebanking/privacy.html" 
      valign="bottom"><font size="2">Privacy</font></A><font size="2"> <SPAN class=bodyText>&nbsp;|&nbsp;</SPAN> <A 
      class=footerLink 
      href="https://www.rbcroyalbank.com/onlinebanking/legal.html" 
      valign="bottom">Legal</A> <SPAN class=bodyText>&nbsp;|&nbsp;</SPAN> <A 
      class=footerLink 
      href="https://www.rbcroyalbank.com/onlinebanking/trademarks/index.html" 
      valign="bottom">Trade-marks &amp; Copyrights</A> <SPAN 
      class=bodyText>&nbsp;|&nbsp;</SPAN> <A class=footerLink 
      href="https://www.rbcroyalbank.com/onlinebanking/olbsecurity/index.html" 
      valign="bottom">Online Banking Security</A><SPAN 
      class=bodyText>&nbsp;&nbsp;</SPAN> </font></b> </TD>
  </TR>
  <TR>
    <TD width=5></TD>
    <TD class=footerText colSpan=2><b><font size="2">©&nbsp;Royal Bank of Canada 
    1996, 2007</font></b></TD></TR>
  <TR>
    <TD colSpan=3>&nbsp;</TD></TR></TBODY></TABLE><!--3MSHELLFOOT.INC.-->

</BODY></HTML>

Date: Wed, 28 Feb 2007 17:23:29 -0500
From: Sean Mullan <[email-masked]>
Subject: Empty CRL Issuer DNs?
To: [email-masked]
Sender: [email-masked]

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

Content-Class: urn:content-classes:message
Subject: RE: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2
Date: Wed, 28 Feb 2007 11:41:09 -0800
From: Ryan Hurst <[email-masked]>
To: Wan-Teh Chang <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

Yes, we have already implemented this in VISTA/Longhorn; although the
extension is for OCSP only.

There is another for Kerberos and PKINIT too.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Wan-Teh Chang
Sent: Wednesday, February 28, 2007 9:11 AM
To: pkix
Subject: Re: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol
(OCSP) Extensions to IKEv2

Jean-Marc Desperrier wrote:
> 
> Michael Myers wrote:
>> By the way . . .
>>
>> http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html
>>   
> It would be good to have similar CRL/OCSP extensions inside  TLS.

I believe this is Section 3.6. Certificate Status Request in
RFC 3546 Transport Layer Security (TLS) Extensions.

Wan-Teh

Date: Wed, 28 Feb 2007 19:31:57 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2
Sender: [email-masked]

Wan-Teh Chang wrote:
> Jean-Marc Desperrier wrote:
>> Michael Myers wrote:
>>> http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html
>>>  
>> It would be good to have similar CRL/OCSP extensions inside  TLS.
> I believe this is Section 3.6. Certificate Status Request in
> RFC 3546 Transport Layer Security (TLS) Extensions.
Thanks wtc, I had checked that doc first, but somehow missed it.

Date: Wed, 28 Feb 2007 09:11:22 -0800
From: Wan-Teh Chang <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2
Sender: [email-masked]

Jean-Marc Desperrier wrote:
> 
> Michael Myers wrote:
>> By the way . . .
>>
>> http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html
>>   
> It would be good to have similar CRL/OCSP extensions inside  TLS.

I believe this is Section 3.6. Certificate Status Request in
RFC 3546 Transport Layer Security (TLS) Extensions.

Wan-Teh

From: "Mellissa Pak" <[email-masked]>
To: [email-masked]
Subject: willie winston wisconsin
Date: 	Wed, 28 Feb 2007 16:08:23 -0000

------=_NextPart_000_000C_01C75B52.AC12FD40
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000D_01C75B52.AC12FD40"

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

Kermit kernel kerry key kim. Leandra leann leanna leanor leanora lebbie.
Eudora eugenia eugenie eugine eula eulalie eunice, euphemia eustacia.
Winston, wisconsin wizard wombat woodwind word work wormwood wyoming. =
Those two lo sitdown with degeneres insider something.
Carena caresa caressa caresse.
Patricia patrizia patti paula, paule pauletta.
Loleta lolita lolly lona.
Dareen darell darelle dari daria darice darla darleen? Meggi meggie =
meggy meghan meghann! Darya daryn dasha dasi dasie dasya datha.
Sherie sherill sherilyn sherline!
Socrates somebody sossina sparrows spit spring springer. Leslie lewis =
library light lisp.
Jesselyn, jessi jessica jessika, jessy jewel, jewell jewelle, jill?
Timmi timothea tina tine.
Uucp vasant vertigo village virgin visitor wargames warren water. =
Corabelle coral coralie coraline. Luci lucia luciana lucie lucienne. =
Colleen collen collete collette, collie colline colly.
Kathlin kathrine kathryn kathryne?
Appeared search age determined diva was definitely winning!

------=_NextPart_001_000D_01C75B52.AC12FD40
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>Kermit kernel kerry key kim. Leandra =
leann leanna=20
leanor leanora lebbie.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Eudora eugenia eugenie eugine eula =
eulalie eunice,=20
euphemia eustacia.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Winston, wisconsin wizard wombat =
woodwind word work=20
wormwood wyoming. Those two lo sitdown with degeneres insider =
something.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Carena caresa caressa =
caresse.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Patricia patrizia patti paula, paule =
pauletta.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Loleta lolita lolly lona.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Dareen darell darelle dari daria darice =
darla=20
darleen? Meggi meggie meggy meghan meghann! Darya daryn dasha dasi dasie =
dasya datha.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sherie sherill sherilyn =
sherline!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Socrates somebody sossina sparrows spit =
spring=20
springer. Leslie lewis library light lisp.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Jesselyn, jessi jessica jessika, jessy =
jewel,=20
jewell jewelle, jill?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Timmi timothea tina tine.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Uucp vasant vertigo village virgin =
visitor wargames=20
warren water. Corabelle coral coralie coraline. Luci lucia luciana lucie =

lucienne. Colleen collen collete collette, collie colline =
colly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Kathlin kathrine kathryn =
kathryne?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Appeared search age determined diva was =
definitely=20
winning!</FONT></DIV>
<DIV><IMG alt=3D"" hspace=3D0 =
src=3D"cid:000b01c75b52$ac12fd40$00000000@mandrici"=20
align=3Dbaseline border=3D0></DIV></BODY></HTML>

------=_NextPart_001_000D_01C75B52.AC12FD40--

------=_NextPart_000_000C_01C75B52.AC12FD40
Content-Type: image/gif;
	name="korie korney.gif"
Content-Transfer-Encoding: base64
Content-ID: <000b01c75b52$ac12fd40$00000000@mandrici>

------=_NextPart_000_000C_01C75B52.AC12FD40--

Date: Wed, 28 Feb 2007 15:51:56 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2
Sender: [email-masked]

Michael Myers wrote:
> By the way . . .
>
> http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html
>   
It would be good to have similar CRL/OCSP extensions inside  TLS.
But that's stuff for the TLS WG.

Date: Wed, 28 Feb 2007 12:49:33 +0100
From: Peter Sylvester <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

David A. Cooper wrote:
>
> Peter,
>
> In the case of the URI restrictions, I do not believe that there is a 
> contradiction with X.509 since I read the text in section 4.2.1.6 of 
> 3280/3280bis as imposing a restriction on conforming CAs, not on what 
> relying parties may accept.

unless my English is completely broken, I don't see in what way your 
statement is non-trivial
on last half-sentence.
I would understand it if you replace 'accept' by 'reject',

IMO 3280 is pretty weak distinguishing whether a MUST is for CAs or for 
relying parties.
One indication is for example

Some communities will need to supplement, or possibly replace, this
   profile in order to meet the requirements of specialized application
   domains or environments with additional authorization, assurance, or
   operational requirements.  

What are the legacy implementations in the following? CAs or relying 
parties?

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name extension (section 4.2.1.6 <http://tools.ietf.org/html/draft-ietf-pkix-rfc3280bis-08#section-4.2.1.6>) to describe such
   identities.  Simultaneous inclusion of the emailAddress attribute in
   the subject distinguished name to support legacy implementations is
   deprecated but permitted.

>
> In the case of the emailAddress attribute, specifying in the ASN.1 
> that the emailAddress attribute is defined as IA5String (SIZE 
> (1..ub-emailaddress-length)) and then specify a value for 
> ub-emailaddress-length of 128, this would seem to impose this 
> limitation on both conforming CAs and relying parties.  Since this 
> attribute is merely being imported from PKCS #9, which specifies a 
> maximum length of 255, I do not think that 3280bis should require 
> relying parties to reject certificates that contain emailAddress 
> attributes with lengths between 129 and 255 characters.
Did I ask that 3280bis should require relying parties to reject 
something because it imposes restrictions to  CAs?
I didn't. But that is not the problem. 

I used the same argument for allowing urn:  I don't think that is wide 
deployment of relying party
implementation that rejects a certificate that has a URI with 'urn:'. 
There may be
implementations of CAs taht do not allow to put arbitrary strings into 
that field.
Thus, instead of defining another oethername form for urn, the whole 
limitations
of the URI choice can simply be removed IMO.

if 3280 merely reuses the email attribute and "probably?" erroneously 
limited its size and corrects this,
where is the difference in argumentation concerning the URI, i.e. 
allowing more values?

>
> If there is a concern about backwards compatibility with clients that 
> use the ASN.1 from RFC 3280, I would suggest that the solution is to 
> leave ub-emailaddress-length at 255, but include a statement in 
> section 4.1.2.6 that says that conforming CAs must not include an 
> emailAddress attribute with a value that is longer than 128 
> characters.  [Note that according to RFC 2821, an email address may be 
> up to 320 characters in length, so even with the PKCS #9 defined 
> maximum length of 255, some valid email addresses cannot be placed in 
> the emailAddress attribute.]  Since RFC 3280 (and 3280bis) discourages 
> use of the emailAddress attribute, I would have no problem including 
> another "roadblock" to its use.
Since 3280 has made an error, it must remain so forever? At best I'd 
say: Although 255 chars are allows CAs may experience
problems in relying parties when using more than 128.
Why do YOU want to block anything? Is there anything dangerous with the 
email attribute, anyway, that's another story.
>  
> Dave
>
> 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
>>
>
>
>

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

--------------ms080909010608010804030301--

From: "Michael Myers" <[email-masked]>
To: "pkix" <[email-masked]>
Subject: FW: [Ipsec] RFC 4806 on Online Certificate Status Protocol (OCSP) Extensions to IKEv2
Date: Tue, 27 Feb 2007 05:50:34 -0800
Importance: Normal
Sender: [email-masked]

By the way . . .

http://www1.ietf.org/mail-archive/web/ipsec/current/msg02274.html

Mike

From: "Rick kenneth" <[email-masked]>
To: [email-masked]
Subject: Ju showed unmastered amazing
Date: 	Tue, 27 Feb 2007 07:28:27 +0100

------=_NextPart_000_0005_01C75A40.DF2D1930
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0006_01C75A40.DF2D1930"

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

Atwater kent museum spring rsvp, suggested andrea baldeck matter.
Astral essence tokens enough, level, place sphinx members?
Divas dustin hoffman ewan mcgregor nat. Midtown heartbeats breathing, =
first scientists evidence become.
Movs, playing, ruby, restarted, pokemon. Exibio animes put creams =
frowned.
Eku pa kelingwan ilokano manang biday bamini fonts read? Zaphods =
memorable circuit clayton. Thul bombay, bangla marrigecom kab running =
grain, puisi.
Aka natassha anjali hi, everyone here sum eijazs, ild. Desai set, thul =
bombay bangla marrigecom kab.
Pedosex ku pung singsing atin cu!
Quotes example, incorrect flags log modsquot under quotmod centerquot. =
Satellit ricevi immagini da? Showed unmastered amazing putting cafe =
dekcuf thatll fun anywho. Hoskins maclean chillout albums summertime =
northern lights.
Chassis cylinder gas mfi vin wire, conductor mm.
Ching nicole cherry grove modern! Dec dee zee deflecta, shield.
Launches, name lyrics mobile media player.

------=_NextPart_001_0006_01C75A40.DF2D1930
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>Atwater kent museum spring rsvp, =
suggested andrea=20
baldeck matter.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Astral essence tokens enough, level, =
place sphinx members?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Divas dustin hoffman ewan mcgregor nat. =
Midtown=20
heartbeats breathing, first scientists evidence become.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Movs, playing, ruby, restarted, =
pokemon. Exibio=20
animes put creams frowned.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Eku pa kelingwan ilokano manang biday =
bamini fonts=20
read? Zaphods memorable circuit clayton. Thul bombay, bangla marrigecom =
kab=20
running grain, puisi.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Aka natassha anjali hi, everyone here =
sum eijazs,=20
ild. Desai set, thul bombay bangla marrigecom kab.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pedosex ku pung singsing atin =
cu!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Quotes example, incorrect flags log =
modsquot under=20
quotmod centerquot. Satellit ricevi immagini da? Showed unmastered =
amazing=20
putting cafe dekcuf thatll fun anywho. Hoskins maclean chillout albums=20
summertime northern lights.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Chassis cylinder gas mfi vin wire, =
conductor mm.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ching nicole cherry grove modern! Dec =
dee zee=20
deflecta, shield.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Launches, name lyrics mobile media=20
player.</FONT></DIV>
<DIV><IMG alt=3D"" hspace=3D0 =
src=3D"cid:000401c75a38$7d68b130$00000000@colasbueno"=20
align=3Dbaseline border=3D0></DIV></BODY></HTML>

------=_NextPart_001_0006_01C75A40.DF2D1930--

------=_NextPart_000_0005_01C75A40.DF2D1930
Content-Type: image/gif;
	name="Equigen Line.gif"
Content-Transfer-Encoding: base64
Content-ID: <000401c75a38$7d68b130$00000000@colasbueno>

------=_NextPart_000_0005_01C75A40.DF2D1930--

Date: Tue, 27 Feb 2007 00:25:22 +0000
From: Dr Stephen Henson <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt
Sender: [email-masked]

Peter Sylvester wrote:
> 
> **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.
> 

Note that the OpenSSL will not reject a certificate with a longer
emailAddress but it will refuse to create a certificate with an
emailAddress larger than 128.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Date: Mon, 26 Feb 2007 23:47:56 +0000
From: Stephen Farrell <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Peter Sylvester <[email-masked]>, "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt
Sender: [email-masked]

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

Date: Mon, 26 Feb 2007 18:16:43 -0500
From: "David A. Cooper" <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt
Sender: [email-masked]

Peter,

In the case of the URI restrictions, I do not believe that there is a 
contradiction with X.509 since I read the text in section 4.2.1.6 of 
3280/3280bis as imposing a restriction on conforming CAs, not on what 
relying parties may accept.

In the case of the emailAddress attribute, specifying in the ASN.1 that 
the emailAddress attribute is defined as IA5String (SIZE 
(1..ub-emailaddress-length)) and then specify a value for 
ub-emailaddress-length of 128, this would seem to impose this limitation 
on both conforming CAs and relying parties.  Since this attribute is 
merely being imported from PKCS #9, which specifies a maximum length of 
255, I do not think that 3280bis should require relying parties to 
reject certificates that contain emailAddress attributes with lengths 
between 129 and 255 characters.

If there is a concern about backwards compatibility with clients that 
use the ASN.1 from RFC 3280, I would suggest that the solution is to 
leave ub-emailaddress-length at 255, but include a statement in section 
4.1.2.6 that says that conforming CAs must not include an emailAddress 
attribute with a value that is longer than 128 characters.  [Note that 
according to RFC 2821, an email address may be up to 320 characters in 
length, so even with the PKCS #9 defined maximum length of 255, some 
valid email addresses cannot be placed in the emailAddress attribute.]  
Since RFC 3280 (and 3280bis) discourages use of the emailAddress 
attribute, I would have no problem including another "roadblock" to its use.

Dave

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
>

Date: Mon, 26 Feb 2007 16:21:30 -0500
To: Peter Sylvester <[email-masked]>, "David A. Cooper" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt
Cc: pkix <[email-masked]>
Sender: [email-masked]

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
>

Date: Mon, 26 Feb 2007 19:21:24 +0100
From: Peter Sylvester <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-08.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

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

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

--------------ms090507010906030400090705--

Content-class: urn:content-classes:message
Subject: R: ID cards certificate profiles
Date: Mon, 26 Feb 2007 10:28:01 +0100
From: "Santoni Adriano" <[email-masked]>
To: "Bechlaghem, Malek" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Malek,
=20
I am just addressing your points #1 and #2, in the following.
=20
As far as signing certificates are concerned, I would suggest you not to =
reinvent the wheel, but adopt an existing profile as much as possible.=20
=20
Overall profile: as a general rule, I would follow RFC 3739 and ETSI TS =
102 280.
=20
CommonName: I would avoid putting into the CN something different than =
the owner's name.
=20
Ciitizen civil ID: assuming you mean something like a fiscal code or =
social security number, you should put this into the serialNumber RDN.
=20
NonRepudiation: I would stick to the guidance you find in ETSI TS 102 =
280, section 5.4.3
=20
Regards,
  Adriano
=20

________________________________

Da: [email-masked] [mailto:[email-masked]] =
Per conto di Bechlaghem, Malek
Inviato: marted=EC 23 gennaio 2007 11.08
A: [email-masked]
Oggetto: ID cards certificate profiles

Hi there,

It has been long since the last time I posted something so happy to be =
back :-)

I am working on the implementation of a PKI infrastructure needed for an =
ID cards issuing project. Part of my job is defining the needed =
certificate profiles which are raising some open issues that I am =
listing below and hope to have your support in resolving them.

1.       Are there any particular issues when not adding any surname and =
given names in the CN of the subject field of end-entity certificates =
knowing that these EE are the actual ID cardholders. My understanding is =
that the subject field is used mainly to provide the data that =
identifies the certificate holder. Moreover, knowing a person's name, so =
if I am looking for her certificate, I could use the name to perform =
LDAP lookup based on that name. However, in our case, the certificates =
are not published in an LDAP and the persons names are often very long. =
This is why we thought not using first and last names in the CN of the =
subject field. Instead, we are considering the following format for the =
CN:=20

Common Name (CN) =3D < Certificate Type =3D <AUTH/SIGN>, Citizen civil =
ID>

2.      Assuming that the country issuing ID cards does not have a =
digital signature law and no clear definition of NON REPUDIATION, should =
we avoid using the NR bit of the key usage extension for signing =
certificates (not authentication certificate)? We could set the =
digitalSignature bit only and explain in the certificate profile the =
applicability of the certificate including those situations where it =
would be difficult for the cardholder to repudiate a signature? We could =
simply set the NR bit.=20

3.       We are not planning to use the SubjectKeyIdentifier extension =
as the card returns a complete certification path with a signed message. =
Would this be OK or are there reaons to use this extensions.

4.       For the certificatePolicies extension, the plan is to use a CPS =
qualifier with the CPS OID. Is there any reasons for deviating from =
this? We could for instance use the OID of the CP under which a =
certificate is issued. Assuming that the Certification Authority issues =
other types of certificates apart from the ID cards certificates, and =
that these certificates may have different assurance levels, what's the =
right option we should opt for when formatting the certificatePolicies =
extension?

5.       We are not planning to use the basicConstraints extension for =
EE certificates. We will use it for CA certificates setting the =
pathLengthConstraint to zero. This prevents cross certification at the =
subordinate CAs level which is a functional requirement since we are =
expecting cross certification with other CAs to occur at the root CA =
level. Could you please confirm that our settings for the =
basicConstraint extension are correct.

6.       Assuming that the LDAP directory on which CRLs will not be =
public, =20

Thank you all for your prompt feedback.

M. Bechlaghem

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.

------_=_NextPart_001_01C75988.68B7DE9E
Content-Type: text/html;
	charset="iso-8859-1"
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>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Wingdings;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
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 vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007>Malek,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007>I am just addressing your points #1 and #2, =
in the=20
following.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007>As far as signing certificates are concerned, =
I would=20
suggest you not to reinvent the wheel, but adopt an =
existing&nbsp;profile as=20
much as possible. </SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007>Overall profile: as a general rule, I would =
follow RFC=20
3739 and ETSI TS 102 280.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007>CommonName: I would avoid putting into the CN =
something=20
different than the owner's name.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007>Ciitizen civil ID: assuming you mean =
something like a=20
fiscal code or social security number, you should put this into the =
serialNumber=20
RDN.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007>NonRepudiation: I would stick to the guidance =
you find=20
in ETSI TS 102 280, section 5.4.3</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007>Regards,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007>&nbsp; Adriano</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DVerdana color=3D#0000ff =
size=3D2><SPAN=20
class=3D035451109-26022007></SPAN></FONT>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Dit dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>Da:</B> [email-masked]=20
[mailto:[email-masked]] <B>Per conto di </B>Bechlaghem,=20
Malek<BR><B>Inviato:</B> marted=EC 23 gennaio 2007 11.08<BR><B>A:</B>=20
[email-masked]<BR><B>Oggetto:</B> ID cards certificate=20
profiles<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal=20
style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi=20
there,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">It has been =
long since=20
the last time I posted something so happy to be back </SPAN></FONT><FONT =

face=3DWingdings size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Wingdings">J</SPAN></FONT><FONT =
face=3DArial=20
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I am =
working on the=20
implementation of a PKI infrastructure needed for an ID cards issuing =
project.=20
Part of my job is defining the needed certificate profiles which are =
raising=20
some open issues that I am listing below and hope to have your support =
in=20
resolving them.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if =
!supportLists]><FONT=20
face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
style=3D"mso-list: Ignore">1.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Are there =
any=20
particular issues when not adding any surname and given names in the CN =
of the=20
subject field of end-entity certificates knowing that these EE are the =
actual ID=20
cardholders. My understanding is that the subject field is used mainly =
to=20
provide the data that identifies the certificate holder. Moreover, =
knowing a=20
person=92s name, so if I am looking for her certificate, I could use the =
name to=20
perform LDAP lookup based on that name. However, in our case, the =
certificates=20
are not published in an LDAP and the persons names are often very long. =
This is=20
why we thought not using first and last names in the CN of the subject =
field.=20
Instead, we are considering the following format for the CN:=20
<o:p></o:p></SPAN></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: 0.5in; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">Common =
Name (CN) =3D=20
&lt; Certificate Type =3D &lt;AUTH/SIGN&gt;, Citizen civil=20
ID&gt;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if =
!supportLists]><FONT=20
face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt"><SPAN=20
style=3D"mso-list: Ignore">2.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr>Assuming =
that the=20
country issuing ID cards does not have a digital signature law and no =
clear=20
definition of NON REPUDIATION, should we avoid using the NR bit of the =
key usage=20
extension for signing certificates (not authentication certificate)? We =
could=20
set the digitalSignature bit only and explain in the certificate profile =
the=20
applicability of the certificate including those situations where it =
would be=20
difficult for the cardholder to repudiate a signature? We could simply =
set the=20
NR bit. <o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if =
!supportLists]><FONT=20
face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
style=3D"mso-list: Ignore">3.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">We are not =
planning to=20
use the SubjectKeyIdentifier extension as the card returns a complete=20
certification path with a signed message. Would this be OK or are there =
reaons=20
to use this extensions.<o:p></o:p></SPAN></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if =
!supportLists]><FONT=20
face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
style=3D"mso-list: Ignore">4.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">For the=20
certificatePolicies extension, the plan is to use a CPS qualifier with =
the CPS=20
OID. Is there any reasons for deviating from this? We could for instance =
use the=20
OID of the CP under which a certificate is issued. Assuming that the=20
Certification Authority issues other types of certificates apart from =
the ID=20
cards certificates, and that these certificates may have different =
assurance=20
levels, what=92s the right option we should opt for when formatting the=20
certificatePolicies extension?<o:p></o:p></SPAN></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if =
!supportLists]><FONT=20
face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
style=3D"mso-list: Ignore">5.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">We are not =
planning to=20
use the basicConstraints extension for EE certificates. We will use it =
for CA=20
certificates setting the pathLengthConstraint to zero. This prevents =
cross=20
certification at the subordinate CAs level which is a functional =
requirement=20
since we are expecting cross certification with other CAs to occur at =
the root=20
CA level. Could you please confirm that our settings for the =
basicConstraint=20
extension are correct.<o:p></o:p></SPAN></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto; mso-list: l2 level1 lfo3"><![if =
!supportLists]><FONT=20
face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN=20
style=3D"mso-list: Ignore">6.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><SPAN dir=3Dltr><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Assuming =
that the LDAP=20
directory on which CRLs will not be public,=20
&nbsp;<o:p></o:p></SPAN></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thank you =
all for your=20
prompt feedback.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><FONT =
face=3DArial=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">M.=20
Bechlaghem<o:p></o:p></SPAN></FONT></P></DIV><BR><BR>
<P align=3Dcenter><FONT style=3D"BACKGROUND-COLOR: #ffffff">This e-mail =
and any=20
attachment is for authorised use by the intended recipient(s) only. It =
may=20
contain proprietary material, confidential information and/or be subject =
to=20
legal privilege. It should not be copied, disclosed to, retained or used =
by, any=20
other party. If you are not an intended recipient then please promptly =
delete=20
this e-mail and any attachment and all copies and inform the sender. =
Thank=20
you.</FONT></A></P></BODY></HTML>

------_=_NextPart_001_01C75988.68B7DE9E--

Date: Sun, 25 Feb 2007 20:07:27 +0200
To: [email-masked]
From: "hong Krueger" <[email-masked]>
Subject: Kno

--=====================_8604903==.REL
Content-Type: multipart/alternative;
	boundary="=====================_8604903==.ALT"

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

[]

Picture photo galleryall listtotal? Arielle kebbel ashanti ashlee 
simpson ashley judd, olsen.
York city ltd notified when add.
Keen kelley nelly furtado neve nicky hilton!
Nemcova phoebe cates pink piper perabo priscilla. Sobieski, lexa, 
doig linda lindsay lohan lindsey kildow.
Mori bettina zimmermann beverley. Jessica alba, biel miller jill 
goodacre jillian grace joanna.
Adriana lima adrianne curry aida.
Mcelhone natasha henstridge lyonne poly.
Dania ramirez danica patrick.
Longoria, mendes padberg evangeline, lilly faith. Vera zvonareva 
veronica, varekova victoria beckham silvstedt vida guerra. Bilson 
blanchard mcadams perry stevens weisz rebecca loos romijn.
Beyond borders ziegfeld theatre york, city ltd notified when? Graf 
stephanie seymour sumela kay summer glau sunny leone.
Durance erika estella warren, esther baxter eugenia, silva. Dahl 
marceau monk stacie, orrico stacy.
Jones charisma carpenter charlize.
Richardson camilla belle candice michelle carla campbell.
Ledoyen, whitney houston willa winona. Joss stone jules asner julia 
stegner stiles! Krakowski janet jackson january jeisa? Hunter valance 
ilary blasi iman isabeli, fontana. Mcadams, perry stevens weisz 
rebecca loos romijn. Gutierrez alessandra ambrosio alexa davalos.
Torrie traci lords tricia helfer trish stratus tyra!
Righetti amber benson smith tamblyn amel larrieux amelie!
--=====================_8604903==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<img src="cid:[email-masked]" width=488 height=372 alt="[]">
<br>
Picture photo galleryall listtotal? Arielle kebbel ashanti ashlee<br>
simpson ashley judd, olsen.<br>
York city ltd notified when add.<br>
Keen kelley nelly furtado neve nicky hilton!<br>
Nemcova phoebe cates pink piper perabo priscilla. Sobieski, lexa,<br>
doig linda lindsay lohan lindsey kildow.<br>
Mori bettina zimmermann beverley. Jessica alba, biel miller jill<br>
goodacre jillian grace joanna.<br>
Adriana lima adrianne curry aida.<br>
Mcelhone natasha henstridge lyonne poly.<br>
Dania ramirez danica patrick.<br>
Longoria, mendes padberg evangeline, lilly faith. Vera zvonareva<br>
veronica, varekova victoria beckham silvstedt vida guerra. Bilson<br>
blanchard mcadams perry stevens weisz rebecca loos romijn.<br>
Beyond borders ziegfeld theatre york, city ltd notified when? Graf<br>
stephanie seymour sumela kay summer glau sunny leone.<br>
Durance erika estella warren, esther baxter eugenia, silva. Dahl<br>
marceau monk stacie, orrico stacy.<br>
Jones charisma carpenter charlize.<br>
Richardson camilla belle candice michelle carla campbell.<br>
Ledoyen, whitney houston willa winona. Joss stone jules asner julia<br>
stegner stiles! Krakowski janet jackson january jeisa? Hunter valance<br>
ilary blasi iman isabeli, fontana. Mcadams, perry stevens weisz<br>
rebecca loos romijn. Gutierrez alessandra ambrosio alexa davalos.<br>
Torrie traci lords tricia helfer trish stratus tyra!<br>
Righetti amber benson smith tamblyn amel larrieux amelie!</body>
</html>

--=====================_8604903==.ALT--

--=====================_8604903==.REL
Content-Type: image/gif; name="Mauresmo.gif";
 x-mac-type="47494666"; x-mac-creator="4A565752"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="Mauresmo.gif"

--=====================_8604903==.REL--

Date: Sun, 25 Feb 2007 11:17:59 -0500
To: [email-masked]
From: "norma Meijer" <[email-masked]>
Subject: material may

--=====================_65937546==.REL
Content-Type: multipart/alternative;
	boundary="=====================_65937546==.ALT"

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

[]

Nbs webmasters advertise copyright ip issues disclaimer? Art, costume 
institute benefit galajenna hogankatie, holmes tom jones.
Dancelopez selecting shows slated cameo, course ofthe run. Tour, 
below are, dates, sheffield hallam, arena.
Eli struggled postseason after few seasons with new. Protestors 
peoplefor ethical treatment animals, peta highlight concerns shewas?
Mass, blonde curls bright red lips spent hour perfecting!
Center background rampb songwriter present fashion, cb golden dancerand.
Subway used growing onjune top ten billboard multiweek.
Drivebut then came out. Coach tony dungy guys hung played?
Ultimately, relegated similar, fate could anticipate outright, hostility.
Created headlines recording rebirth, jason ankeny, real murder remix.
Radio birmingham, nia london wembley ndash st christinas? Onelopez 
alltime madonnas michael. Moderate vh box guest such pun fat joe.
Ofthe run begin subway used growing onjune top. Link ebe mentioned 
injennifer lopezstar profile, lopezaint, australian. Cdrebirth cdthe 
reel ep bonus dvdbuy, epbuy cdthis. June april march adriana, 
jolieanna lavignebai. Aired amedia furor whether, belatedly return noteagerly.
Rule caddillac tah several weeks rereleased birthday abonus.
Familybuy moviemoney trainbuy moviemy, verified modify neededfor. 
Lifeit thought brief longterm boyfriend davidcruz publicized, met 
while? Be part teamhis efforts not, only but also, earned.
Romantic dated sean combs long term engaged actor off. Cooknelly 
kidman miliandemi ashton mcgowanmeg madonna ff? Tvtv, comediestv 
lopezfrom diana mimonyour guide gossipfree newsletter nowborn. 
Australia promotion peaked laterin riaalopez, js song, itreached?
--=====================_65937546==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<img src="cid:[email-masked]" width=516 height=360 alt="[]">
<br>
Nbs webmasters advertise copyright ip issues disclaimer? Art, costume<br>
institute benefit galajenna hogankatie, holmes tom jones.<br>
Dancelopez selecting shows slated cameo, course ofthe run. Tour,<br>
below are, dates, sheffield hallam, arena.<br>
Eli struggled postseason after few seasons with new. Protestors<br>
peoplefor ethical treatment animals, peta highlight concerns shewas?<br>
Mass, blonde curls bright red lips spent hour perfecting!<br>
Center background rampb songwriter present fashion, cb golden dancerand.<br>
Subway used growing onjune top ten billboard multiweek.<br>
Drivebut then came out. Coach tony dungy guys hung played?<br>
Ultimately, relegated similar, fate could anticipate outright, hostility.<br>
Created headlines recording rebirth, jason ankeny, real murder remix.<br>
Radio birmingham, nia london wembley ndash st christinas? Onelopez<br>
alltime madonnas michael. Moderate vh box guest such pun fat joe.<br>
Ofthe run begin subway used growing onjune top. Link ebe mentioned<br>
injennifer lopezstar profile, lopezaint, australian. Cdrebirth cdthe<br>
reel ep bonus dvdbuy, epbuy cdthis. June april march adriana,<br>
jolieanna lavignebai. Aired amedia furor whether, belatedly return noteagerly.<br>
Rule caddillac tah several weeks rereleased birthday abonus.<br>
Familybuy moviemoney traiÓ.m4Û,’«;6y
?ýuÃ»²5ØÕ”Yé±ù—
¾L}ÑþÍxÇÄ³C¤˜íÉ‰î%òbò8'žÜÖ±í¯MÀ»¸i>w”GóƒŒÿ
lopezfrom diana mimonyour guide gossipfree newsletter nowborn.<br>
Australia promotion peaked laterin riaalopez, js song, itreached?</body>
</html>

--=====================_65937546==.ALT--

--=====================_65937546==.REL
Content-Type: image/gif; name="best.gif";
 x-mac-type="47494666"; x-mac-creator="4A565752"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="best.gif"

YìÈL
whnNEi872RTbtQ3bqo9t3HDr11kbuTbB2pe9GWXN0rvN24mt2KKN2|
9µ&©ÎRçÁµ¿""C	ê9#´fµ¶ì«H:NÀ¡A’v$B…üW=›«¥:…(°B7+½8¼×o»žfDÓ¦a†`Ø!ÿû‚Äð€EŸS‡°WÂ5³ë|Ä¹ÄÛi¤Is€È:íÀëüMÎ<’ú}ÅêE"iè¿tëm'º0`BÁg®6=™•Ì4ÊŽýrRÉ 96á‰Ã\ÊÓr»I«ÁN³ÌÓ$oDÕqãcõ,VþZàaÂCŒ(à	ÑÊi(ÙXñQSEvòkiYR‡×ÊmÚ%hZ˜LAME3.97 (beta)UUUUUUUUUUUUUUUUUUUUUUUUUUUUˆ’m§,ÍbP#1MðÒ¼é]bõÑøÖj´.(¦ˆ9¢1Ó"…˜»{wš*CI-™£§k°å7
ÄÌE÷>ÍÓt®±OC©3ÍÂE÷L“¥+W&×ª¯ÄU=
{¹þ?…ÓŠ™8ÂÚ‹;î¦øš®é3D d’¥rP¥3JDíIC˜%k Ræt«Ò•-»1fÌDþa¡s¦Ä«H«°ÿû‚Äÿ€}›]G¤Ùš(³íµ†"r(„¬ú}“·NÐ„â‚Ø¡¤´â‹âZ†
D°®?@™¬ëž²etY«Ö$Q1åÔWÏ,˜‚šŠf\rn@PÄÊèÂRªªªªªªªªªªªªªª$€Ñr[~¶ïÒ}6p}"^¢Ô¹G‰5š0Ð¡
¿úq›+±ž9}í½
4.ñ=ŽÙ7-œ‹VÆV¥çÍ—¿uŸ*àüðŽgd_2˜æRqF”Ò.DöWÁB;è²ÿ¯ëÿTWTë²Q'Yßi6b#õÓô[QŠ;7H)"¤·ë.ý©§
0Êåä|†Ô¥[ÖÓÎÓío´àšÌrV„îïÃÿû€Äÿ€qu§±2ý´j]¼1&Q&hY@ŒÐDƒ÷‚öaIR¯m‚G¸™
6vb0wUdyb6tvedk

0±›xD
mail1.frk.com

hellerfin.com
lore.ebay.com
[email-masked]

Xùº@L¾
[email-masked]
[email-masked] ( [147.114.161.125]) Sat, 24 Feb 2007 23:30:18 -0500
MIME-Version: 1.0
Message-Id: <96A3A727.000001.00284@>
Date: Sat, 24 Feb 2007 xREyRFMvDbM3YHEmU
--=====================_65937546==.REL--

Date: Sat, 24 Feb 2007 12:35:25 +0100 (GMT)
From: "[email-masked]" <[email-masked]>
To: <[email-masked]>
Subject: excerpt from

--------------Boundary-00=_1JTYUH1FXFP000000000
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_1JTYK39FXFP000000000"

--------------Boundary-00=_1JTYK39FXFP000000000
Content-Type: Text/Plain;
  charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Wall instead in latest is story prophet creation koran.=0D
Life pop princess anything thatin claims.=0D
About and programs azall songs, things talkday.=0D
Guide gossipfree newsletter, sign nowa picture worth.=0D
Mediaon, todaytalk of nationwait, wait dont tell!=0D
Othersdemi was born, charlotte dumaresq hunt has created many?=0D
Faced challenge writing, biography someone whos, image she.=0D
Berry halle sheen moviestop popreality tvtv!=0D
Twelve addresses separated commasyour, message.=0D
Wall instead in latest is story prophet creation koran.=0D
=20
--------------Boundary-00=_1JTYK39FXFP000000000
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:8CCD7950-9EB6-BE36-50A6-3A07B0DE5371</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:8CCD7950-9EB6-BE36-50A6-3A07B0DE5371 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>Wall instead in latest is story prophet creation koran.</DIV>
<DIV>Life pop princess anything thatin claims.</DIV>
<DIV>About and programs azall songs, things talkday.</DIV>
<DIV>Guide gossipfree newsletter, sign nowa picture worth.</DIV>
<DIV>Mediaon, todaytalk of nationwait, wait dont tell!</DIV>
<DIV>Othersdemi was born, charlotte dumaresq hunt has created many?</DIV>
<DIV>Faced challenge writing, biography someone whos, image she.</DIV>
<DIV>Berry halle sheen moviestop popreality tvtv!</DIV>
<DIV>Twelve addresses separated commasyour, message.</DIV>
<DIV>Wall instead in latest is story prophet creation koran.</DIV>
<DIV>&nbsp;</DIV>
<DIV><IMG height=3D295 src=3D"cid:81F1A128-2C28-763F-C9D2-F51176FE4854" w=
idth=3D291 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:9A=
9EBD5D-CC17-78E4-1BC1-D454408CDCE3" border=3D0></SPAN></A></SPAN></BODY><=
/HTML>
--------------Boundary-00=_1JTYK39FXFP000000000--

--------------Boundary-00=_1JTYUH1FXFP000000000
Content-Type: image/jpeg;
  name="824-5AD8333.jpg"
Content-Transfer-Encoding: base64
Content-ID: <8CCD7950-9EB6-BE36-50A6-3A07B0DE5371>

--------------Boundary-00=_1JTYUH1FXFP000000000
Content-Type: image/gif;
  name="References58.gif"
Content-Transfer-Encoding: base64
Content-ID: <81F1A128-2C28-763F-C9D2-F51176FE4854>

--------------Boundary-00=_1JTYUH1FXFP000000000
Content-Type: image/gif;
  name="imstp_usa.gif"
Content-Transfer-Encoding: base64
Content-ID: <9A9EBD5D-CC17-78E4-1BC1-D454408CDCE3>

--------------Boundary-00=_1JTYUH1FXFP000000000--

Date: Fri, 23 Feb 2007 12:14:33 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: draft-ietf-pkix-rfc3280bis-08.txt
Sender: [email-masked]

All,

Draft -08 of 3280bis is available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-08.txt.

A diff file highlighting the changes between drafts -07 and -08 is 
available at 
http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-07todraft3280bis-08_diff.html.

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

1) The ASN.1 for the privateKeyUsagePeriod and holdInstructionCode 
extensions were added back into the ASN.1 modules in Appendix A.  I was 
informed that any changes to the ASN.1 modules from RFC 3280 would 
require a change in the module OIDs, so now the only differences between 
ASN.1 modules in RFC 3280 and 3280bis are in the comments, with one 
exception.  The ASN.1 module in RFC 3280 defines ub-emailaddress-length, 
the maximum of the emailAddress attribute, as 128 characters.  However, 
PKCS #9 (RFC 2985), which contains the definition for the emailAddress 
attribute, specifies that the maximum length of an emailAddress 
attribute is 255 characters.  So in 3280bis, ub-emailaddress-length has 
been changed to 255.

2) Section 1 (Introduction) now includes a notes about the relationship 
between the ASN.1 modules in RFC 3280 and 3280bis and about the 
relationship between 3280 and RFC 4630, which will be obsoleted by 3280bis.

3) Section 4.2.1.2 (Subject Key Identifier) describes two methods based 
on SHA-1 for generating key identifiers and sections 4.2.1.1 and 4.2.1.2 
each contain a sentence recommending use of one of these methods for 
generating key identifiers where a key identifier has not already been 
established (this is unchanged).  These sentences in 4.2.1.1 and 4.2.1.2 
now explicitly state that it is acceptable to use a hash algorithm other 
than SHA-1 when generating key identifiers.

4) In section 4.2.1.3 (Key Usage), the description of the 
digitalSignature bit was slightly modified to clarify that "an  entity 
authentication service, a data origin authentication service, and/or an 
integrity service" are only examples of the types of digital signatures 
that may be verified using the public key that is in a certificate with 
the digitalSignature bit set.

5)  In section 4.2.1.6 (Subject Alternative Name), RFC 1738 was replaced 
with RFC 3986 as the source for rules on the URL syntax.  (In the 
remainder of 3280bis, RFC 1738 is still the reference for the specific 
HTTP and FTP URL schemes).

6) In section 4.2.1.10 (Name Constraints), RFC 1519 was replaced with 
RFC 4632 as the reference for Classless Inter-domain Routing (CIDR) 
notation and the example address range for IP address name constraints 
was changed to align with RFC 3330.  Also, the reference to 
draft-ietf-pkix-srvsan-04.txt [SRVSAN] was removed to ensure that 
3280bis could advance independent of draft-ietf-pkix-srvsan-04.txt.

7) The descriptions of the use of LDAP URIs in the 
cRLDistributionPoints, authorityInfoAccess, and subjectInfoAccess 
extensions (sections 4.2.1.13, 4.2.2.1, 4.2.2.2, and 5.2.7) were 
reworded based on comments from Kurt Zeilenga 
(http://www.imc.org/ietf-pkix/mail-archive/msg04434.html).

8) The final paragraph of section 7.1, which describes matching rules 
for DNs and RDNs, was reworded in order to make the text more clear.

9) In the references section, RFC 2560 and RFC 4519 were moved from 
"Normative References" to "Informative References".  RFC 1519 was 
replaced with RFC 4632.  All unused references were removed and a few 
new Informative References were added.

10) A paragraph was added to the security considerations section noting 
that emailAddress attributes are not case-sensitive (as defined by PKCS 
#9) even though RFC 2821 specifies that the local-part of an addr-spec 
(i.e., RFC 822 name) is case-sensitive.  The paragraph notes that this 
may lead to problems if an email address is included in an emailAddress 
attribute and the mail server that hosts that email address exploits the 
case-sensitivity of the local-parts of email addresses.

Dave

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-08.txt 
Date: Fri, 23 Feb 2007 10:50:02 -0500
Sender: [email-masked]

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Fri, 23 Feb 2007 14:19:29 +1000
From: "Dr Rodney G. McDuff" <[email-masked]>
To: [email-masked]
Subject: link: draft-ietf-pkix-lightweight-ocsp-profile-08
Sender: [email-masked]

At the direction of our cognizant security AD, the following document
has been updated to change its status from informational to standards
track:

draft-ietf-pkix-lightweight-ocsp-profile-08.txt

I am initiating a (less than 2 week) WG last call on the document,
since we have discussed it in its prior incarnation as an
informational document.  Please send comments to the list by the end
of next week, i.e., March 2.

Thanks,

Steve

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: RE: WG last call
Date: Tue, 20 Feb 2007 16:12:37 -0800
Importance: Normal
Sender: [email-masked]

I have no fundamental issues with this document going forward as drafted.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Stephen Kent
Sent: Tuesday, February 20, 2007 3:38 PM
To: [email-masked]
Subject: WG last call

At the direction of our cognizant security AD, the following document 
has been updated to change its status from informational to standards 
track:

draft-ietf-pkix-lightweight-ocsp-profile-08.txt

I am initiating a (less than 2 week) WG last call on the document, 
since we have discussed it in its prior incarnation as an 
informational document.  Please send comments to the list by the end 
of next week, i.e., March 2.

Thanks,

Steve

Date: Tue, 20 Feb 2007 18:38:12 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: WG last call
Sender: [email-masked]

At the direction of our cognizant security AD, the following document 
has been updated to change its status from informational to standards 
track:

draft-ietf-pkix-lightweight-ocsp-profile-08.txt

I am initiating a (less than 2 week) WG last call on the document, 
since we have discussed it in its prior incarnation as an 
informational document.  Please send comments to the list by the end 
of next week, i.e., March 2.

Thanks,

Steve

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-08.txt 
Date: Tue, 20 Feb 2007 15:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Lightweight OCSP Profile for High Volume Environments
	Author(s)	: R. Hurst, A. Deacon
	Filename	: draft-ietf-pkix-lightweight-ocsp-profile-08.txt
	Pages		: 20
	Date		: 2007-2-20
	
This specification defines a profile of the Online Certificate 
   Status Protocol (OCSP) that addresses the scalability issues 
   inherent when using OCSP in large scale (high volume) PKI 
   environments and/or in PKI environments that require a lightweight 
   solution to minimize communication bandwidth and client side 
   processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-08.txt

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-08.txt

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

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

--OtherAccess--

--NextPart--

Date: Sun, 18 Feb 2007 14:28:51 -0600
From: Eric Norman <[email-masked]>
Subject: Re: URN in subjectAltName
To: [email-masked]
Sender: [email-masked]

On Feb 14, 2007, at 12:43 PM, Russ Housley wrote:

>
> Milan & Paul:
>
>>> As the group does not seem to have a strong opinion of the choices I
>>> propose to include the following text just after the URI part of the
>>> section 4.2.1.6  Subject Alternative Name:
>>>
>>> "When the subjectAltName extension contains a URN, the name MUST be
>>> stored in the uniformResourceIdentifier (IA5String).  The name MUST
>>> follow the URN syntax and encoding rules specified in [RFC 2141]."
>>>
>>>         Comments?
>>
>> This seems like a good addition, seeing as there were multiple 
>> choices given on the mailing list, and that means interoperability 
>> issues. Note that there are two paragraphs to the "URI part"; this 
>> should be added after the second paragraph, just before "When the 
>> subjectAltName extension contains a DN...".
>
> I thought that sever people expressed concern that implementations 
> that follow RFC 3280 will only expect a URL, so the URN ought to be 
> encoded in other name.  It would be a very simple (one page) 
> specification.

I can certainly believe that the OpenID community would want to put
user's "identity URL" in here.  That argues for it being something
that is at least resolvable.

Eric Norman

Date: Sun, 18 Feb 2007 10:16:50 -0800
To: Peter Sylvester <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: URN in subjectAltName
Cc: [email-masked]
Sender: [email-masked]

At 6:45 PM +0100 2/18/07, Peter Sylvester wrote:
>Putting urn into the uri choice is legal in X.509.

I am not questioning that. As Russ has pointed out, however, RFC 3280 
made it so that PKIX certificates do not allow that because they 
force the URI to have a hostname.

--Paul Hoffman, Director
--VPN Consortium

Date: Sun, 18 Feb 2007 18:45:12 +0100
From: Peter Sylvester <[email-masked]>
To: Paul Hoffman <[email-masked]>
CC: [email-masked]
Subject: Re: URN in subjectAltName
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Putting urn into the uri choice is legal in X.509.

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

--------------ms000003020008080402070408--

Content-class: urn:content-classes:message
Subject: Application Recognition and Use of the anyExtendedKeyUsage OID in a Certificate's EKU Extension
Date: Fri, 16 Feb 2007 16:40:06 -0500
From: "Price, Bill" <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75213.069D68B6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This may be slightly off topic, but does anyone have any information
regarding what "major" vendors/applications recognize the
anyExtendedKeyUsage purpose described in 3280's EKU extension?
=20
Some interpretations of 3280 are that applications that consider the
EKU extension should accept the anyExtendedKeyUsage purpose rather than
require the specific purpose targeted to their application. So for
example, a certificate with the anyExtendedKeyUsage purpose should be
accepted for TLS client or server authentication or e-mail protection
regardless of whether the specific EKU purposes were present or not.
Similarly, a certificate with the anyExtendedKeyUsage should be
accepted when used for code, ocsp, or time-stamp signing regardless of
whether the specific purposes were asserted in the EKU.
=20
Has anyone either tested major applications or seen vendor
descriptions/disclosures about the acceptance or use of the
anyExtendedKeyUsage purpose? We have found that at least one major
vendor does not accept the anyExtendedKeyUsage as a substitute for a
specific EKU. We would like to avoid having to test to determine
whether other applications use it and whether asserting the
anyExtendedKeyUsage purpose in certificates is useful.=20
=20
Thanks.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

Bill Price

The MITRE Corporation

------_=_NextPart_001_01C75213.069D68B6
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D785553220-16022007><FONT face=3DArial>This may be =
slightly off=20
topic, but does anyone have any information regarding what "major"=20
vendors/applications recognize the anyExtendedKeyUsage purpose described =
in=20
3280's EKU extension?</FONT></SPAN></DIV>
<DIV><SPAN class=3D785553220-16022007><FONT =
face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D785553220-16022007><FONT face=3DArial>Some =
interpretations of=20
3280 are that applications that consider the EKU extension should accept =
the=20
anyExtendedKeyUsage purpose rather than require the specific purpose =
targeted to=20
their application. So for example, a certificate with the =
anyExtendedKeyUsage=20
purpose should be accepted for TLS client or server authentication or =
e-mail=20
protection regardless of whether the specific EKU purposes were present =
or not.=20
Similarly, a certificate with the anyExtendedKeyUsage should be accepted =
when=20
used for code, ocsp, or time-stamp signing regardless of whether the =
specific=20
purposes were asserted in the EKU.</FONT></SPAN></DIV>
<DIV><SPAN class=3D785553220-16022007><FONT =
face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D785553220-16022007><FONT face=3DArial>Has anyone =
either tested=20
major applications or seen vendor descriptions/disclosures about the =
acceptance=20
or use of the anyExtendedKeyUsage purpose? We have found that at least =
one major=20
vendor does not accept the anyExtendedKeyUsage as a substitute for a =
specific=20
EKU. We would like to avoid having to test to determine whether other=20
applications use it and whether asserting the anyExtendedKeyUsage =
purpose in=20
certificates&nbsp;is useful. </FONT></SPAN></DIV>
<DIV><SPAN class=3D785553220-16022007><FONT =
face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D785553220-16022007><FONT =
face=3DArial>Thanks.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT=20
face=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT> =
</DIV>
<P align=3Dleft><FONT color=3D#000080><FONT face=3D"Courier New" =
color=3D#000000=20
size=3D2>Bill Price</FONT></FONT></P>
<P align=3Dleft><FONT color=3D#000080><FONT color=3D#000000><FONT =
face=3D"Courier New"=20
size=3D2>The <FONT face=3DMITRE color=3D#000080>MITRE</FONT>=20
Corporation<BR></FONT></FONT></FONT></P></BODY></HTML>

------_=_NextPart_001_01C75213.069D68B6--

Date: Thu, 15 Feb 2007 13:31:36 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: URN in subjectAltName
Sender: [email-masked]

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

Date: Thu, 15 Feb 2007 19:37:41 +0100
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: URN in subjectAltName
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Russ Housley wrote:
> Peter:
>
> RFC 3280 does not allow a URN. It requires a URL. The changes you 
> suggest are not backward compatible. That is my concern.
>
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?

As far as I remember the request was made to allow urn: in
new contexts anyway, such certificates may (in theorie) not
be usable in old applications, I'd still like to see one.

regards

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

--------------ms050908090002050804030005--

Date: Thu, 15 Feb 2007 12:47:44 -0500
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: URN in subjectAltName
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Sender: [email-masked]

Peter:

RFC 3280 does not allow a URN.  It requires a URL.  The changes you 
suggest are not backward compatible.  That is my concern.

Russ

>>Ooops: s/server/several/
>>
>>RFC 3280 says:
>>
>>    When the subjectAltName extension contains a URI, the name MUST be
>>    stored in the uniformResourceIdentifier (an IA5String).  The name
>>    MUST NOT be a relative URL, and it MUST follow the URL syntax and
>>    encoding rules specified in [RFC 1738].  The name MUST include both a
>>    scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
>>    scheme-specific-part MUST include a fully qualified domain name or IP
>>    address as the host.
>>
>>    As specified in [RFC 1738], the scheme name is not case-sensitive
>>    (e.g., "http" is equivalent to "HTTP").  The host part is also not
>>    case-sensitive, but other components of the scheme-specific-part may
>>    be case-sensitive.  When comparing URIs, conforming implementations
>>    MUST compare the scheme and host without regard to case, but assume
>>    the remainder of the scheme-specific-part is case sensitive.
>>
>>I think this prohibits the use of a URN like this:
>>
>>    URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN
>
>Indeed. But is there any problem allowing the URN scheme? We
>are taking about not allowing a "universal resource name" as a name.
>
>I think that subjectAltname should simply not make any restriction for
>filling an URI according to RFC 3986, in order to keep the
>explanations and rules for URLs, I propose to change:
>
>"When the subjectAltName extension contains a URI, the name MUST be
>   stored in the uniformResourceIdentifier (an IA5String). If the name
>   is an URL, it MUST NOT be a relative URL, and it MUST follow the 
> URL syntax and
>   encoding rules specified in [RFC 1738].  The URL MUST include both a
>   scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
>   scheme-specific-part of an URL MUST include a fully qualified 
> domain name or IP
>   address as the host.
>
>   As specified in [RFC 1738], the scheme name is not case-sensitive
>   (e.g., "http" is equivalent to "HTTP").  The host part is also not
>   case-sensitive, but other components of the scheme-specific-part may
>   be case-sensitive.  When comparing URLs, conforming implementations
>   MUST compare the scheme and host without regard to case, but assume
>   the remainder of the scheme-specific-part is case sensitive.
>
>   If the URI is a URN, conforming implementations MUST follow the rules
>   of [RFC 2141] when comparing them, i.e. treating the string "urn:" and
>   the NID as case insensitive.  Implementations SHOULD  use the same
>   case when setting URNs.
>
>   Since internet emeil addresses are stored using the RFC822address
>   alternative of GeneralName, the "mailto:" scheme SHALL not be used."
>
>The usage of GeneralName in CRLdistributions points etc is not affected but
>this change.

Date: Thu, 15 Feb 2007 13:50:56 +0100
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: URN in subjectAltName
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Russ Housley wrote:
>
> Ooops: s/server/several/
>
> RFC 3280 says:
>
>    When the subjectAltName extension contains a URI, the name MUST be
>    stored in the uniformResourceIdentifier (an IA5String).  The name
>    MUST NOT be a relative URL, and it MUST follow the URL syntax and
>    encoding rules specified in [RFC 1738].  The name MUST include both a
>    scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
>    scheme-specific-part MUST include a fully qualified domain name or IP
>    address as the host.
>
>    As specified in [RFC 1738], the scheme name is not case-sensitive
>    (e.g., "http" is equivalent to "HTTP").  The host part is also not
>    case-sensitive, but other components of the scheme-specific-part may
>    be case-sensitive.  When comparing URIs, conforming implementations
>    MUST compare the scheme and host without regard to case, but assume
>    the remainder of the scheme-specific-part is case sensitive.
>
> I think this prohibits the use of a URN like this:
>
>    URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN
>
> Russ

Indeed. But is there any problem allowing the URN scheme? We
are taking about not allowing a "universal resource name" as a name.

I think that subjectAltname should simply not make any restriction for
filling an URI according to RFC 3986, in order to keep the
explanations and rules for URLs, I propose to change:

"When the subjectAltName extension contains a URI, the name MUST be
   stored in the uniformResourceIdentifier (an IA5String). If the name
   is an URL, it MUST NOT be a relative URL, and it MUST follow the URL 
syntax and
   encoding rules specified in [RFC 1738].  The URL MUST include both a
   scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
   scheme-specific-part of an URL MUST include a fully qualified domain 
name or IP
   address as the host.

   As specified in [RFC 1738], the scheme name is not case-sensitive
   (e.g., "http" is equivalent to "HTTP").  The host part is also not
   case-sensitive, but other components of the scheme-specific-part may
   be case-sensitive.  When comparing URLs, conforming implementations
   MUST compare the scheme and host without regard to case, but assume
   the remainder of the scheme-specific-part is case sensitive.

   If the URI is a URN, conforming implementations MUST follow the rules
   of [RFC 2141] when comparing them, i.e. treating the string "urn:" and
   the NID as case insensitive.  Implementations SHOULD  use the same
   case when setting URNs.

   Since internet emeil addresses are stored using the RFC822address
   alternative of GeneralName, the "mailto:" scheme SHALL not be used."

The usage of GeneralName in CRLdistributions points etc is not affected but
this change.

>
>
> At 03:47 PM 2/14/2007, Paul Hoffman wrote:
>> At 1:43 PM -0500 2/14/07, Russ Housley wrote:
>>> Milan & Paul:
>>>
>>>>> As the group does not seem to have a strong opinion of the choices I
>>>>> propose to include the following text just after the URI part of the
>>>>> section 4.2.1.6  Subject Alternative Name:
>>>>>
>>>>> "When the subjectAltName extension contains a URN, the name MUST be
>>>>> stored in the uniformResourceIdentifier (IA5String).  The name MUST
>>>>> follow the URN syntax and encoding rules specified in [RFC 2141]."
>>>>>
>>>>>         Comments?
>>>>
>>>> This seems like a good addition, seeing as there were multiple 
>>>> choices given on the mailing list, and that means interoperability 
>>>> issues. Note that there are two paragraphs to the "URI part"; this 
>>>> should be added after the second paragraph, just before "When the 
>>>> subjectAltName extension contains a DN...".
>>>
>>> I thought that sever people expressed concern that implementations 
>>> that follow RFC 3280 will only expect a URL, so the URN ought to be 
>>> encoded in other name.
>>
>> I don't know which server people those are, but there is nothing in 
>> RFC 3280 or 3280bis that would make me think "this is a URL and not a 
>> URI".
>>
>>> It would be a very simple (one page) specification.
>>
>> That's true, but there is no reason not to make it part of the only 
>> specification that most implementers will read. I still support 
>> putting it into 3280bis to encourage interoperability.
>>
>> --Paul Hoffman, Director
>> --VPN Consortium
>>
>
>
>

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

--------------ms040402030005040403030408--

Content-class: urn:content-classes:message
Subject: RE: Certificates in CRLs
Date: Thu, 15 Feb 2007 09:28:17 +0100
From: "Ignacio Alamillo" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Good morning,=20

We at CATCert, a Catalan governmental agency, are deploying several =
signature and document archival services and for us Stefan's proposal =
will greatly simplify the current retrieval process, so we support the =
proposal.

This proposal has some impact in the CAdES and XAdES technical =
specifications that should also be addresed.

Ignacio Alamillo

-----Mensaje original-----
De: [email-masked] en nombre de Hallam-Baker, Phillip
Enviado el: mi=E9 14/02/2007 23:19
Para: Guida, Richard [JJCUS]; Peter Hesse; Sharon Boeyen; Stefan =
Santesson; Russ Housley
CC: [email-masked]
Asunto: RE: Certificates in CRLs
=20
The archival purpose is a major one for me. It means that I can put a =
complete package together quickly and efficiently.

________________________________

	From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Guida, Richard =
[JJCUS]
	Sent: Wednesday, February 14, 2007 10:03 AM
	To: Peter Hesse; Hallam-Baker, Phillip; 'Sharon Boeyen'; 'Stefan =
Santesson'; 'Russ Housley'
	Cc: [email-masked]
	Subject: RE: Certificates in CRLs
=09
=09
	I likewise agree with Peter, Phillip and Stefan.  The CRL bloat is not =
large, and for those of us with large CRLs to begin with (can debate =
separately why that circumstance exists...), the bloat is negligible.  =
Since this is entirely optional; and since the owner of a CA therefore =
has full discretion to include or not include the certs (and can do as =
Peter described and published two virtually contemporaneous CRLs, one =
with and one without, if needed to avoid breaking apps), it seems to me =
that this approach can be used in a fashion which does not break =
anything, and it can provide real value for archival purposes.
	=20

	Richard A. Guida=20
	Director, Information Security=20

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

		-----Original Message-----
		From: [email-masked] =
[mailto:[email-masked]]On Behalf Of Peter Hesse
		Sent: Wednesday, February 14, 2007 12:05 AM
		To: 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan Santesson'; =
'Russ Housley'
		Cc: [email-masked]
		Subject: RE: Certificates in CRLs
	=09
	=09

		I'm in agreement that Stefan's proposal is a decent one.  As Phillip =
mentions, it certainly isn't appropriate in every situation, but I can =
see situations in which it might be useful.  One might argue that a CRL =
issuer could issue two CRLs, the most commonly retrieved one without =
this extension, but a separate one issued with it-the latter being made =
to applications responsible for long term archive, historical signature =
validation, or other purposes which might find it useful. =20

		=20

		I don't see any harm in adding this extension as an optional feature =
for PKIs that wish it, since it is truly optional, non-critical, and =
does not affect path processing. =20

		=20

		--Peter

		=20

		+----------------------------------------------------------------+
		| Peter Hesse                     [email-masked]     |
		| Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.  |
		|       Visit our InfoSecurity blog: securitymusings.com =
<http://www.securitymusings.com/>          |
		+----------------------------------------------------------------+
		"The generation of random numbers is too important to be left
		 to chance." --Robert R. Coveyou

		=20

		=20

		From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
		Sent: Tuesday, February 13, 2007 6:53 PM
		To: Sharon Boeyen; Stefan Santesson; Russ Housley
		Cc: [email-masked]
		Subject: RE: Certificates in CRLs

		=20

		I think that Sharon's proposal might have been a good idea in 1995 =
before the world got wedged on CRLs as the revocation mechanism. We can =
define a package but its too late to get it embedded in the rest of the =
application infrastructure.

		=20

		Given where we are Stefan's proposal is the best one. It is compatible =
with the existing infrastructure and solves a real issue.=20

		=20

		It is an option, clearly there are cases where it would be =
inappropriate but universal applicability has never been a requirement. =
Otherwise we could have saved all the time spent on attribute =
certificates.

			=20

________________________________

			From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Sharon Boeyen
			Sent: Friday, January 05, 2007 9:09 AM
			To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley
			Cc: [email-masked]
			Subject: RE: Certificates in CRLs

			Stefan I really don't think you can state where this will or will not =
be used in the future. Naturally you know where you want to use it, but =
software only enables a facility and the customer decides when and how =
to use it.=20

			=20

			Whether this scheme could possibly be useful in some cases is not my =
point. My point is that current deployments seem to be working fine =
without it and I don't want to see those interfered with just because =
some CA they may have cross certified with decided to put certificates =
inside their CRLS. Back to Denis' point - there is no need to impose =
this in the way you've proposed.=20

			=20

			Earlier I (and others including Dave Kemp) suggested a "package" that =
includes the CRL, and the certificate in question as an 'extra' that a =
CA could publish in addition to a regular CRL. That "package could be =
published in a separate directory attribute and/or an HTTP accessible =
file. It could be pointed to from within the certificate just as the CRL =
currently is. That could be done either by extending the CRLDP or adding =
a new pointer extension or adding a new method to the AIA extension. =
That type of approach gives you what you want but does not in any way =
interfere with clients who do not want and do not need to retrieve that =
bloated CRL.=20

			=20

			Also, you haven't addressed the question about what happens when more =
than one certificate is needed. If a CRL includes more than one =
certificate (e.g. the CRL issuer did one or more key rollovers then CRL =
gets bloated a lot bigger than you suggested. I don't want to debate how =
often a key gets rolled over either however I have definitely seen =
instances in real world deployments where a key has been rolled very =
often in a very short period of time (regardless of whether the reason =
for rolling it was a good one or not - it has happened). Also, =
regardless of the size of the "bloat" I'm saying that in most cases the =
clients will already have the certificates in question and this bloat =
will cause them extra processing in managing their certificate caches =
etc unnecessarily. The client should have a choice as to whether to =
download the certificate or not.

			=20

			I don't understand why you're so opposed to the "package" solution.=20

			=20

			Cheers,

			Sharon=20

			-----Original Message-----
			From: Stefan Santesson [mailto:[email-masked]]=20
			Sent: Friday, January 05, 2007 8:01 AM
			To: Sharon Boeyen; Russ Housley
			Cc: [email-masked]
			Subject: RE: Certificates in CRLs

				We are only talking about an extra 16K at most. The download time is =
the absolute most cases is negligible.=20

				For those cases where this solution makes sense, the network =
bandwidth issue is not a problem.

				=20

				For the cases where this would be an issue, this solution would not =
be used.

				=20

				On the contrary, in some networks and scenarios, this will improve =
performance. Especially in high latency networks with PKI based =
peer-peer authentication where an extra retrieval cost way more =
performance than the expanded CRL size.

				=20

				Also, many clients are configured to pre-fetch CRL:s before they are =
used, using idle time on the network at no extra cost.

				=20

				=20

				Stefan Santesson

				Senior Program Manager

				Windows Security, Standards

				=20

				From: Sharon Boeyen [mailto:[email-masked]]=20
				Sent: den 4 januari 2007 17:36
				To: Stefan Santesson; Russ Housley
				Cc: [email-masked]
				Subject: RE: Certificates in CRLs

				=20

				I still think wasted bandwidth is also an issue. Forcing the =
download of 'fat' CRLs on clients when, in many cases, those clients =
already have the certificates locally that caused the bloating of the =
CRL, is an unnecessary waste.

				-----Original Message-----=20
				From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Stefan Santesson=20
				Sent: Wednesday, January 03, 2007 9:58 AM=20
				To: Russ Housley=20
				Cc: [email-masked]=20
				Subject: RE: Certificates in CRLs=20

				=20

				Russ,=20

				In theory, the CA can put different pointers to different CRLs in =
each certificate if some certificates are prime targets for frequent =
checking. But I don't think that is a common scenario.

				My point is that in order to allow free selection of CRLs, you would =
have to add capability to the CDP extension rather than to the CRL. I =
don't think such effort is worth the trouble.

				I'm convinced that including certs in a CRL will only be made in =
situations where it in the sum of all, helps increase efficiency and =
where the extra bandwidth consumed is not an issue.

				I read the critique of this idea as not really be a bandwidth issue, =
but that some implementers simply don't want to be faced with the =
requirement to implement this feature. But I don't see that they have =
to. A CRL with certs in a non-critical extension should work just as =
well in current clients as any current CRL without certs. The extension =
can simply be ignored.

				This is not a necessary feature, but a practical one offering =
performance improvements in some environments at no loss of =
interoperability.

				=20

				Stefan Santesson=20
				Senior Program Manager=20
				Windows Security, Standards=20

				=20

				> -----Original Message-----=20
				> From: Russ Housley [mailto:[email-masked]]=20
				> Sent: den 21 december 2006 16:19=20
				> To: Stefan Santesson=20
				> Cc: [email-masked]=20
				> Subject: RE: Certificates in CRLs=20
				>=20
				> Stefan:=20
				>=20
				> If the CA chooses to offer both, how can the RP determine which =
one it=20
				> will get?  Does the CA post them in different LDAP attributes?=20
				>=20
				> Russ=20
				>=20
				> At 08:00 AM 12/21/2006, Stefan Santesson wrote:=20
				>=20
				> >As with anything else, the relying party can get what the CA =
offers.=20
				> >=20
				> >I don't think there is any realistic scenario where the CA has a=20
				> >reason to offer CRLs both with and without certificates. To offer =

				> >this capability to RP is however not a matter for this protocol. =
It=20
				> >would be a matter for the CRL referencing model, i.e. CDP and/or=20
				> >directory schema.=20
				> >=20
				> >I don't think that extra complexity however is very useful.=20
				> >=20
				> >Stefan Santesson=20
				> >Senior Program Manager=20
				> >Windows Security, Standards=20
				> >=20
				> >=20
				> > > -----Original Message-----=20
				> > > From: [email-masked] [mailto:owner-ietf-=20
				> > > [email-masked]] On Behalf Of Denis Pinkas=20
				> > > Sent: den 20 december 2006 17:05=20
				> > > To: [email-masked]=20
				> > > Subject: Re: Certificates in CRLs=20
				> > >=20
				> > >=20
				> > >=20
				> > > It is necessary to provide relying parties with the choice to =
get=20
				> > > :=20
				> > >=20
				> > >   - CRLs "as usual", or=20
				> > >   - CRLs that carry that new extension.=20
				> > >=20
				> > > The current proposal does not allow for it.=20
				> > >=20
				> > > Until the draft is changed, I am against the addition of this =
work=20
				> item=20
				> > > to the program of the PKIX WG.=20
				> > >=20
				> > > Denis=20
				> > >=20
				> > >=20
				> =
______________________________________________________________________=20
				> _=20
				> > > _______=20
				> > >=20
				> > > >Since last IETF a new draft was posted:=20
				> > > =
>http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-=20
				> 00.txt=20
				> > > >=20
				> > > >There is a request to add this draft to the PKIX work and I =
would=20
				> > > encourage to start the discussion about this decision in this=20
				> thread.=20
				> > > >=20
				> > > >Stefan Santesson=20
				> > > >Senior Program Manager=20
				> > > >Windows Security, Standards=20
				> > >=20
				> > >=20
				> > >=20

------_=_NextPart_001_01C750DB.6FF44DB6
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>RE: Certificates in CRLs</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Good morning,<BR>
<BR>
We at CATCert, a Catalan governmental agency, are deploying several =
signature and document archival services and for us Stefan's proposal =
will greatly simplify the current retrieval process, so we support the =
proposal.<BR>
<BR>
This proposal has some impact in the CAdES and XAdES technical =
specifications that should also be addresed.<BR>
<BR>
Ignacio Alamillo<BR>
<BR>
<BR>
-----Mensaje original-----<BR>
De: [email-masked] en nombre de Hallam-Baker, Phillip<BR>
Enviado el: mi=E9 14/02/2007 23:19<BR>
Para: Guida, Richard [JJCUS]; Peter Hesse; Sharon Boeyen; Stefan =
Santesson; Russ Housley<BR>
CC: [email-masked]<BR>
Asunto: RE: Certificates in CRLs<BR>
<BR>
The archival purpose is a major one for me. It means that I can put a =
complete package together quickly and efficiently.<BR>
<BR>
<BR>
________________________________<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: =
[email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] On Behalf Of Guida, Richard [JJCUS]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Wednesday, February 14, =
2007 10:03 AM<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: Peter Hesse; =
Hallam-Baker, Phillip; 'Sharon Boeyen'; 'Stefan Santesson'; 'Russ =
Housley'<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc: [email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: Certificates in =
CRLs<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I likewise agree with Peter, =
Phillip and Stefan.&nbsp; The CRL bloat is not large, and for those of =
us with large CRLs to begin with (can debate separately why that =
circumstance exists...), the bloat is negligible.&nbsp; Since this is =
entirely optional; and since the owner of a CA therefore has full =
discretion to include or not include the certs (and can do as Peter =
described and published two virtually contemporaneous CRLs, one with and =
one without, if needed to avoid breaking apps), it seems to me that this =
approach can be used in a fashion which does not break anything, and it =
can provide real value for archival purposes.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Richard A. Guida<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Director, Information =
Security<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Johnson &amp; Johnson<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Room GS8217<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 410 George Street<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; New Brunswick, New =
Jersey&nbsp; 08901<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp; 732 524 3785<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: =
[email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]On Behalf Of Peter Hesse<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Wednesday, February 14, =
2007 12:05 AM<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: 'Hallam-Baker, Phillip'; =
'Sharon Boeyen'; 'Stefan Santesson'; 'Russ Housley'<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc: [email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: Certificates in =
CRLs<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'm in agreement that =
Stefan's proposal is a decent one.&nbsp; As Phillip mentions, it =
certainly isn't appropriate in every situation, but I can see situations =
in which it might be useful.&nbsp; One might argue that a CRL issuer =
could issue two CRLs, the most commonly retrieved one without this =
extension, but a separate one issued with it-the latter being made to =
applications responsible for long term archive, historical signature =
validation, or other purposes which might find it useful.&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I don't see any harm in =
adding this extension as an optional feature for PKIs that wish it, =
since it is truly optional, non-critical, and does not affect path =
processing.&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Peter<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+----------------------------------------------------------------+<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Peter =
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]&nbsp;&nbsp;&nbsp;&nbsp; |<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Phone: 703-378-5808 =
x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gemini Security Solutions, Inc.&nbsp; =
|<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Visit our InfoSecurity blog: =
securitymusings.com &lt;<A =
HREF=3D"http://www.securitymusings.com/">http://www.securitymusings.com/<=
/A>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+----------------------------------------------------------------+<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The generation of =
random numbers is too important to be left<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to chance.&quot; =
--Robert R. Coveyou<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: =
[email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] On Behalf Of Hallam-Baker, Phillip<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Tuesday, February 13, =
2007 6:53 PM<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: Sharon Boeyen; Stefan =
Santesson; Russ Housley<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc: [email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: Certificates in =
CRLs<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think that Sharon's =
proposal might have been a good idea in 1995 before the world got wedged =
on CRLs as the revocation mechanism. We can define a package but its too =
late to get it embedded in the rest of the application =
infrastructure.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Given where we are Stefan's =
proposal is the best one. It is compatible with the existing =
infrastructure and solves a real issue.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It is an option, clearly =
there are cases where it would be inappropriate but universal =
applicability has never been a requirement. Otherwise we could have =
saved all the time spent on attribute certificates.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
________________________________<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: =
[email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] On Behalf Of Sharon Boeyen<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Friday, January 05, =
2007 9:09 AM<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: 'Stefan Santesson'; =
Sharon Boeyen; Russ Housley<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc: [email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: Certificates in =
CRLs<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stefan I really don't think =
you can state where this will or will not be used in the future. =
Naturally you know where you want to use it, but software only enables a =
facility and the customer decides when and how to use it.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Whether this scheme could =
possibly be useful in some cases is not my point. My point is that =
current deployments seem to be working fine without it and I don't want =
to see those interfered with just because some CA they may have cross =
certified with decided to put certificates inside their CRLS. Back to =
Denis' point - there is no need to impose this in the way you've =
proposed.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Earlier I (and others =
including Dave Kemp) suggested a &quot;package&quot; that includes the =
CRL, and the certificate in question as an 'extra' that a CA could =
publish in addition to a regular CRL. That &quot;package could be =
published in a separate directory attribute and/or an HTTP accessible =
file. It could be pointed to from within the certificate just as the CRL =
currently is. That could be done either by extending the CRLDP or adding =
a new pointer extension or adding a new method to the AIA extension. =
That type of approach gives you what you want but does not in any way =
interfere with clients who do not want and do not need to retrieve that =
bloated CRL.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Also, you haven't addressed =
the question about what happens when more than one certificate is =
needed. If a CRL includes more than one certificate (e.g. the CRL issuer =
did one or more key rollovers then CRL gets bloated a lot bigger than =
you suggested. I don't want to debate how often a key gets rolled over =
either however I have definitely seen instances in real world =
deployments where a key has been rolled very often in a very short =
period of time (regardless of whether the reason for rolling it was a =
good one or not - it has happened). Also, regardless of the size of the =
&quot;bloat&quot; I'm saying that in most cases the clients will already =
have the certificates in question and this bloat will cause them extra =
processing in managing their certificate caches etc unnecessarily. The =
client should have a choice as to whether to download the certificate or =
not.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I don't understand why you're =
so opposed to the &quot;package&quot; solution.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cheers,<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sharon<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: Stefan Santesson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Friday, January 05, =
2007 8:01 AM<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: Sharon Boeyen; Russ =
Housley<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc: [email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: Certificates in =
CRLs<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We are only talking about an =
extra 16K at most. The download time is the absolute most cases is =
negligible.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For those cases where this =
solution makes sense, the network bandwidth issue is not a problem.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For the cases where this =
would be an issue, this solution would not be used.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; On the contrary, in some =
networks and scenarios, this will improve performance. Especially in =
high latency networks with PKI based peer-peer authentication where an =
extra retrieval cost way more performance than the expanded CRL =
size.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Also, many clients are =
configured to pre-fetch CRL:s before they are used, using idle time on =
the network at no extra cost.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stefan Santesson<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Senior Program Manager<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Windows Security, =
Standards<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: Sharon Boeyen [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
m</A>]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent: den 4 januari 2007 =
17:36<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: Stefan Santesson; Russ =
Housley<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc: [email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: Certificates in =
CRLs<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I still think wasted =
bandwidth is also an issue. Forcing the download of 'fat' CRLs on =
clients when, in many cases, those clients already have the certificates =
locally that caused the bloating of the CRL, is an unnecessary =
waste.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: =
[email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] On Behalf Of Stefan Santesson<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Wednesday, January 03, =
2007 9:58 AM<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: Russ Housley<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc: [email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: Certificates in =
CRLs<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Russ,<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In theory, the CA can put =
different pointers to different CRLs in each certificate if some =
certificates are prime targets for frequent checking. But I don't think =
that is a common scenario.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; My point is that in order to =
allow free selection of CRLs, you would have to add capability to the =
CDP extension rather than to the CRL. I don't think such effort is worth =
the trouble.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'm convinced that including =
certs in a CRL will only be made in situations where it in the sum of =
all, helps increase efficiency and where the extra bandwidth consumed is =
not an issue.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I read the critique of this =
idea as not really be a bandwidth issue, but that some implementers =
simply don't want to be faced with the requirement to implement this =
feature. But I don't see that they have to. A CRL with certs in a =
non-critical extension should work just as well in current clients as =
any current CRL without certs. The extension can simply be ignored.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is not a necessary =
feature, but a practical one offering performance improvements in some =
environments at no loss of interoperability.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stefan Santesson<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Senior Program Manager<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Windows Security, =
Standards<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; -----Original =
Message-----<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; From: Russ Housley [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>=

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Sent: den 21 december =
2006 16:19<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; To: Stefan Santesson<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Cc: =
[email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Subject: RE: =
Certificates in CRLs<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Stefan:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; If the CA chooses to =
offer both, how can the RP determine which one it<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; will get?&nbsp; Does the =
CA post them in different LDAP attributes?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Russ<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; At 08:00 AM 12/21/2006, =
Stefan Santesson wrote:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;As with anything =
else, the relying party can get what the CA offers.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;I don't think there =
is any realistic scenario where the CA has a<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;reason to offer CRLs =
both with and without certificates. To offer<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;this capability to =
RP is however not a matter for this protocol. It<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;would be a matter =
for the CRL referencing model, i.e. CDP and/or<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;directory =
schema.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;I don't think that =
extra complexity however is very useful.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;Stefan Santesson<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;Senior Program =
Manager<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;Windows Security, =
Standards<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; -----Original =
Message-----<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; From: =
[email-masked] [<A =
HREF=3D"mailto:owner-ietf-">mailto:owner-ietf-</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
[email-masked]] On Behalf Of Denis Pinkas<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; Sent: den 20 =
december 2006 17:05<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; To: =
[email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; Subject: Re: =
Certificates in CRLs<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; It is =
necessary to provide relying parties with the choice to get<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; :<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;&nbsp;&nbsp; - =
CRLs &quot;as usual&quot;, or<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;&nbsp;&nbsp; - =
CRLs that carry that new extension.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; The current =
proposal does not allow for it.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; Until the =
draft is changed, I am against the addition of this work<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; item<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; to the program =
of the PKIX WG.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; Denis<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
______________________________________________________________________<BR=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; _<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; _______<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; &gt;Since last =
IETF a new draft was posted:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; &gt;<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-">=
http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 00.txt<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; &gt;There is a =
request to add this draft to the PKIX work and I would<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; encourage to =
start the discussion about this decision in this<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; thread.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; &gt;Stefan =
Santesson<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; &gt;Senior =
Program Manager<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; &gt;Windows =
Security, Standards<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt;<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C750DB.6FF44DB6--

Content-class: urn:content-classes:message
Subject: RE: Certificates in CRLs
Date: Wed, 14 Feb 2007 14:19:00 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Guida, Richard [JJCUS]" <[email-masked]>, "Peter Hesse" <[email-masked]>, "Sharon Boeyen" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

The archival purpose is a major one for me. It means that I can put a =
complete package together quickly and efficiently.

________________________________

	From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Guida, Richard =
[JJCUS]
	Sent: Wednesday, February 14, 2007 10:03 AM
	To: Peter Hesse; Hallam-Baker, Phillip; 'Sharon Boeyen'; 'Stefan =
Santesson'; 'Russ Housley'
	Cc: [email-masked]
	Subject: RE: Certificates in CRLs
=09
=09
	I likewise agree with Peter, Phillip and Stefan.  The CRL bloat is not =
large, and for those of us with large CRLs to begin with (can debate =
separately why that circumstance exists...), the bloat is negligible.  =
Since this is entirely optional; and since the owner of a CA therefore =
has full discretion to include or not include the certs (and can do as =
Peter described and published two virtually contemporaneous CRLs, one =
with and one without, if needed to avoid breaking apps), it seems to me =
that this approach can be used in a fashion which does not break =
anything, and it can provide real value for archival purposes.
	=20

	Richard A. Guida=20
	Director, Information Security=20

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

		-----Original Message-----
		From: [email-masked] =
[mailto:[email-masked]]On Behalf Of Peter Hesse
		Sent: Wednesday, February 14, 2007 12:05 AM
		To: 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan Santesson'; =
'Russ Housley'
		Cc: [email-masked]
		Subject: RE: Certificates in CRLs
	=09
	=09

		I'm in agreement that Stefan's proposal is a decent one.  As Phillip =
mentions, it certainly isn't appropriate in every situation, but I can =
see situations in which it might be useful.  One might argue that a CRL =
issuer could issue two CRLs, the most commonly retrieved one without =
this extension, but a separate one issued with it-the latter being made =
to applications responsible for long term archive, historical signature =
validation, or other purposes which might find it useful. =20

		=20

		I don't see any harm in adding this extension as an optional feature =
for PKIs that wish it, since it is truly optional, non-critical, and =
does not affect path processing. =20

		=20

		--Peter

		=20

		+----------------------------------------------------------------+
		| Peter Hesse                     [email-masked]     |
		| Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.  |
		|       Visit our InfoSecurity blog: securitymusings.com =
<http://www.securitymusings.com/>          |
		+----------------------------------------------------------------+
		"The generation of random numbers is too important to be left
		 to chance." --Robert R. Coveyou

		=20

		=20

		From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
		Sent: Tuesday, February 13, 2007 6:53 PM
		To: Sharon Boeyen; Stefan Santesson; Russ Housley
		Cc: [email-masked]
		Subject: RE: Certificates in CRLs

		=20

		I think that Sharon's proposal might have been a good idea in 1995 =
before the world got wedged on CRLs as the revocation mechanism. We can =
define a package but its too late to get it embedded in the rest of the =
application infrastructure.

		=20

		Given where we are Stefan's proposal is the best one. It is compatible =
with the existing infrastructure and solves a real issue.=20

		=20

		It is an option, clearly there are cases where it would be =
inappropriate but universal applicability has never been a requirement. =
Otherwise we could have saved all the time spent on attribute =
certificates.

			=20

________________________________

			From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Sharon Boeyen
			Sent: Friday, January 05, 2007 9:09 AM
			To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley
			Cc: [email-masked]
			Subject: RE: Certificates in CRLs

			Stefan I really don't think you can state where this will or will not =
be used in the future. Naturally you know where you want to use it, but =
software only enables a facility and the customer decides when and how =
to use it.=20

			=20

			Whether this scheme could possibly be useful in some cases is not my =
point. My point is that current deployments seem to be working fine =
without it and I don't want to see those interfered with just because =
some CA they may have cross certified with decided to put certificates =
inside their CRLS. Back to Denis' point - there is no need to impose =
this in the way you've proposed.=20

			=20

			Earlier I (and others including Dave Kemp) suggested a "package" that =
includes the CRL, and the certificate in question as an 'extra' that a =
CA could publish in addition to a regular CRL. That "package could be =
published in a separate directory attribute and/or an HTTP accessible =
file. It could be pointed to from within the certificate just as the CRL =
currently is. That could be done either by extending the CRLDP or adding =
a new pointer extension or adding a new method to the AIA extension. =
That type of approach gives you what you want but does not in any way =
interfere with clients who do not want and do not need to retrieve that =
bloated CRL.=20

			=20

			Also, you haven't addressed the question about what happens when more =
than one certificate is needed. If a CRL includes more than one =
certificate (e.g. the CRL issuer did one or more key rollovers then CRL =
gets bloated a lot bigger than you suggested. I don't want to debate how =
often a key gets rolled over either however I have definitely seen =
instances in real world deployments where a key has been rolled very =
often in a very short period of time (regardless of whether the reason =
for rolling it was a good one or not - it has happened). Also, =
regardless of the size of the "bloat" I'm saying that in most cases the =
clients will already have the certificates in question and this bloat =
will cause them extra processing in managing their certificate caches =
etc unnecessarily. The client should have a choice as to whether to =
download the certificate or not.

			=20

			I don't understand why you're so opposed to the "package" solution.=20

			=20

			Cheers,

			Sharon=20

			-----Original Message-----
			From: Stefan Santesson [mailto:[email-masked]]=20
			Sent: Friday, January 05, 2007 8:01 AM
			To: Sharon Boeyen; Russ Housley
			Cc: [email-masked]
			Subject: RE: Certificates in CRLs

				We are only talking about an extra 16K at most. The download time is =
the absolute most cases is negligible.=20

				For those cases where this solution makes sense, the network =
bandwidth issue is not a problem.

				=20

				For the cases where this would be an issue, this solution would not =
be used.

				=20

				On the contrary, in some networks and scenarios, this will improve =
performance. Especially in high latency networks with PKI based =
peer-peer authentication where an extra retrieval cost way more =
performance than the expanded CRL size.

				=20

				Also, many clients are configured to pre-fetch CRL:s before they are =
used, using idle time on the network at no extra cost.

				=20

				=20

				Stefan Santesson

				Senior Program Manager

				Windows Security, Standards

				=20

				From: Sharon Boeyen [mailto:[email-masked]]=20
				Sent: den 4 januari 2007 17:36
				To: Stefan Santesson; Russ Housley
				Cc: [email-masked]
				Subject: RE: Certificates in CRLs

				=20

				I still think wasted bandwidth is also an issue. Forcing the =
download of 'fat' CRLs on clients when, in many cases, those clients =
already have the certificates locally that caused the bloating of the =
CRL, is an unnecessary waste.

				-----Original Message-----=20
				From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Stefan Santesson=20
				Sent: Wednesday, January 03, 2007 9:58 AM=20
				To: Russ Housley=20
				Cc: [email-masked]=20
				Subject: RE: Certificates in CRLs=20

				=20

				Russ,=20

				In theory, the CA can put different pointers to different CRLs in =
each certificate if some certificates are prime targets for frequent =
checking. But I don't think that is a common scenario.

				My point is that in order to allow free selection of CRLs, you would =
have to add capability to the CDP extension rather than to the CRL. I =
don't think such effort is worth the trouble.

				I'm convinced that including certs in a CRL will only be made in =
situations where it in the sum of all, helps increase efficiency and =
where the extra bandwidth consumed is not an issue.

				I read the critique of this idea as not really be a bandwidth issue, =
but that some implementers simply don't want to be faced with the =
requirement to implement this feature. But I don't see that they have =
to. A CRL with certs in a non-critical extension should work just as =
well in current clients as any current CRL without certs. The extension =
can simply be ignored.

				This is not a necessary feature, but a practical one offering =
performance improvements in some environments at no loss of =
interoperability.

				=20

				Stefan Santesson=20
				Senior Program Manager=20
				Windows Security, Standards=20

				=20

				> -----Original Message-----=20
				> From: Russ Housley [mailto:[email-masked]]=20
				> Sent: den 21 december 2006 16:19=20
				> To: Stefan Santesson=20
				> Cc: [email-masked]=20
				> Subject: RE: Certificates in CRLs=20
				>=20
				> Stefan:=20
				>=20
				> If the CA chooses to offer both, how can the RP determine which =
one it=20
				> will get?  Does the CA post them in different LDAP attributes?=20
				>=20
				> Russ=20
				>=20
				> At 08:00 AM 12/21/2006, Stefan Santesson wrote:=20
				>=20
				> >As with anything else, the relying party can get what the CA =
offers.=20
				> >=20
				> >I don't think there is any realistic scenario where the CA has a=20
				> >reason to offer CRLs both with and without certificates. To offer =

				> >this capability to RP is however not a matter for this protocol. =
It=20
				> >would be a matter for the CRL referencing model, i.e. CDP and/or=20
				> >directory schema.=20
				> >=20
				> >I don't think that extra complexity however is very useful.=20
				> >=20
				> >Stefan Santesson=20
				> >Senior Program Manager=20
				> >Windows Security, Standards=20
				> >=20
				> >=20
				> > > -----Original Message-----=20
				> > > From: [email-masked] [mailto:owner-ietf-=20
				> > > [email-masked]] On Behalf Of Denis Pinkas=20
				> > > Sent: den 20 december 2006 17:05=20
				> > > To: [email-masked]=20
				> > > Subject: Re: Certificates in CRLs=20
				> > >=20
				> > >=20
				> > >=20
				> > > It is necessary to provide relying parties with the choice to =
get=20
				> > > :=20
				> > >=20
				> > >   - CRLs "as usual", or=20
				> > >   - CRLs that carry that new extension.=20
				> > >=20
				> > > The current proposal does not allow for it.=20
				> > >=20
				> > > Until the draft is changed, I am against the addition of this =
work=20
				> item=20
				> > > to the program of the PKIX WG.=20
				> > >=20
				> > > Denis=20
				> > >=20
				> > >=20
				> =
______________________________________________________________________=20
				> _=20
				> > > _______=20
				> > >=20
				> > > >Since last IETF a new draft was posted:=20
				> > > =
>http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-=20
				> 00.txt=20
				> > > >=20
				> > > >There is a request to add this draft to the PKIX work and I =
would=20
				> > > encourage to start the discussion about this decision in this=20
				> thread.=20
				> > > >=20
				> > > >Stefan Santesson=20
				> > > >Senior Program Manager=20
				> > > >Windows Security, Standards=20
				> > >=20
				> > >=20
				> > >=20

------_=_NextPart_001_01C75086.2D34F34A
Content-Type: text/html;
	charset="iso-8859-1"
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" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types"><HEAD><TITLE>=
Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.5730.11" 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-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal
}
SPAN.EmailStyle19 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D749191822-14022007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The archival purpose is a major one for me. It =
means that I=20
can put a complete package together quickly and=20
efficiently.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=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>Guida, =
Richard=20
  [JJCUS]<BR><B>Sent:</B> Wednesday, February 14, 2007 10:03 =
AM<BR><B>To:</B>=20
  Peter Hesse; Hallam-Baker, Phillip; 'Sharon Boeyen'; 'Stefan =
Santesson'; 'Russ=20
  Housley'<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Certificates=20
  in CRLs<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><SPAN class=3D790115814-14022007><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  likewise agree with Peter, Phillip and Stefan.&nbsp; The CRL bloat is =
not=20
  large, and for those of us with large CRLs to begin with (can debate=20
  separately why that circumstance exists...), the bloat is =
negligible.&nbsp;=20
  Since this is entirely optional; and since the owner of a CA therefore =
has=20
  full discretion to include or not include the certs (and can do as =
Peter=20
  described and published two virtually contemporaneous CRLs, one with =
and one=20
  without, if needed to avoid breaking apps), it seems to me that this =
approach=20
  can be used in a fashion which does not break anything, and it can =
provide=20
  real value for archival purposes.</FONT></SPAN></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV><BR>
  <P><B><FONT face=3DArial size=3D2>Richard A. Guida</FONT></B> =
<BR><B><FONT=20
  face=3DArial size=3D2>Director, Information Security</FONT></B> </P>
  <P><B><I><FONT face=3D"Times New Roman" color=3D#ff0000 =
size=3D5>Johnson &amp;=20
  Johnson</FONT></I></B><I></I> <BR><FONT face=3DArial size=3D2>Room =
GS8217</FONT>=20
  <BR><FONT face=3DArial size=3D2>410 George Street</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Phone:&nbsp; 732 524 3785</FONT> </P>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B>=20
    [email-masked] =
[mailto:[email-masked]]<B>On=20
    Behalf Of </B>Peter Hesse<BR><B>Sent:</B> Wednesday, February 14, =
2007 12:05=20
    AM<BR><B>To:</B> 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan=20
    Santesson'; 'Russ Housley'<BR><B>Cc:</B>=20
    [email-masked]<BR><B>Subject:</B> RE: Certificates in=20
    CRLs<BR><BR></FONT></DIV>
    <DIV class=3DSection1>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">I=92m=20
    in agreement that Stefan=92s proposal is a decent one.&nbsp; As =
Phillip=20
    mentions, it certainly isn=92t appropriate in every situation, but I =
can see=20
    situations in which it might be useful.&nbsp; One might argue that a =
CRL=20
    issuer could issue two CRLs, the most commonly retrieved one without =
this=20
    extension, but a separate one issued with it=97the latter being made =
to=20
    applications responsible for long term archive, historical signature =

    validation, or other purposes which might find it useful.&nbsp;=20
    <o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">I=20
    don=92t see any harm in adding this extension as an optional feature =
for PKIs=20
    that wish it, since it is truly optional, non-critical, and does not =
affect=20
    path processing. &nbsp;<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">--Peter<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Courier =
New'">+----------------------------------------------------------------+<=
BR>|&nbsp;</SPAN><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: #3333cc; FONT-FAMILY: 'Courier =
New'">Peter=20
    Hesse</SPAN><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
    style=3D"COLOR: blue"><A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A>=
</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
    style=3D"COLOR: gray">|<BR>|&nbsp;</SPAN><SPAN style=3D"COLOR: =
#3333cc">Phone:=20
    703-378-5808 x105</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
    style=3D"COLOR: #3333cc">Gemini Security Solutions,=20
    Inc.&nbsp;&nbsp;</SPAN><SPAN=20
    style=3D"COLOR: =
gray">|<BR>|&nbsp;</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
    style=3D"COLOR: #3333cc">Visit our InfoSecurity blog: <A=20
    =
href=3D"http://www.securitymusings.com/">securitymusings.com</A></SPAN>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
    style=3D"COLOR: =
gray">|<BR>+-------------------------------------------------------------=
---+<BR></SPAN><SPAN=20
    style=3D"COLOR: teal">"The generation of random numbers is too =
important to be=20
    left<BR>&nbsp;to chance." --Robert R. Coveyou</SPAN></SPAN><SPAN=20
    style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <DIV>
    <DIV=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
    <P class=3DMsoNormal><B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20
    [email-masked] [mailto:[email-masked]] =
<B>On=20
    Behalf Of </B>Hallam-Baker, Phillip<BR><B>Sent:</B> Tuesday, =
February 13,=20
    2007 6:53 PM<BR><B>To:</B> Sharon Boeyen; Stefan Santesson; Russ=20
    Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Certificates=20
    in CRLs<o:p></o:p></SPAN></P></DIV></DIV>
    <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">I=20
    think that Sharon's proposal might have been a good idea in 1995 =
before the=20
    world got wedged on CRLs as the revocation mechanism. We can define =
a=20
    package but its too late to get it embedded in the rest of the =
application=20
    infrastructure.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DSV>&nbsp;<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Given=20
    where we are Stefan's proposal is the best one. It is compatible =
with the=20
    existing infrastructure and solves a real issue. </SPAN><SPAN=20
    lang=3DSV><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DSV>&nbsp;<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">It=20
    is an option, clearly there are cases where it would be =
inappropriate but=20
    universal applicability has never been a requirement. Otherwise we =
could=20
    have saved all the time spent on attribute certificates.</SPAN><SPAN =

    lang=3DSV><o:p></o:p></SPAN></P>
    <BLOCKQUOTE=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
      <P class=3DMsoNormal><SPAN lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
      <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter>
      <HR align=3Dcenter width=3D"100%" SIZE=3D2>
      </DIV>
      <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20
      [email-masked] [mailto:[email-masked]] =
<B>On=20
      Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, January 05, =
2007 9:09=20
      AM<BR><B>To:</B> 'Stefan Santesson'; Sharon Boeyen; Russ=20
      Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE:=20
      Certificates in CRLs</SPAN><o:p></o:p></P>
      <DIV>
      <P class=3DMsoNormal><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
      I really don't think you can state where this will or will not be =
used in=20
      the future. Naturally you know where you want to use it, but =
software only=20
      enables a facility and the customer decides when and how to use =
it.=20
      </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Whether=20
      this scheme could possibly be useful in some cases is not my =
point. My=20
      point is that current deployments seem to be working fine without =
it and I=20
      don't want to see those interfered with just because some CA they =
may have=20
      cross certified with decided to put certificates inside their =
CRLS. Back=20
      to Denis' point - there is no need to impose this in the way =
you've=20
      proposed. </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Earlier=20
      I (and others including Dave Kemp) suggested a "package" that =
includes the=20
      CRL, and the certificate in question as an 'extra' that a CA could =
publish=20
      in addition to a regular CRL. That "package could be published in =
a=20
      separate directory attribute and/or an HTTP accessible file. It =
could be=20
      pointed to from within the certificate&nbsp;just as the CRL =
currently is.=20
      That could be done either by extending the CRLDP or adding a=20
      new&nbsp;pointer extension or adding a new method to the AIA =
extension.=20
      That type of approach gives you what you want but does not in any =
way=20
      interfere with clients who do not want and do not need to retrieve =
that=20
      bloated CRL.&nbsp;</SPAN><SPAN =
lang=3DSV><o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Also,=20
      you haven't addressed the question about&nbsp;what happens =
when&nbsp;more=20
      than one certificate is needed. If a CRL includes more than one=20
      certificate&nbsp;(e.g. the CRL issuer did one or more key=20
      rollovers&nbsp;then CRL gets bloated a lot bigger than you=20
      suggested.&nbsp;I don't want to debate how often a key gets rolled =
over=20
      either however I have definitely seen instances in real world =
deployments=20
      where a key has been rolled very often in a very short period of =
time=20
      (regardless of whether the reason for rolling it was a good one or =
not -=20
      it has happened). Also, regardless of the size of the "bloat" I'm =
saying=20
      that in most cases the clients will already have the certificates =
in=20
      question and this bloat will cause them extra processing in =
managing their=20
      certificate caches etc unnecessarily. The client should have a =
choice as=20
      to whether to download the certificate or not.</SPAN><SPAN=20
      lang=3DSV><o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">I=20
      don't understand why you're so opposed to the "package"=20
      solution.&nbsp;</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Cheers,</SPAN><SPAN=20
      lang=3DSV><o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Sharon</SPAN><SPAN=20
      lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
      <DIV>
      <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN lang=3DSV =

      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">-----Original=20
      Message-----<BR><B>From:</B> Stefan Santesson=20
      [mailto:[email-masked]] <BR><B>Sent:</B> Friday, January =
05, 2007=20
      8:01 AM<BR><B>To:</B> Sharon Boeyen; Russ Housley<BR><B>Cc:</B>=20
      [email-masked]<BR><B>Subject:</B> RE: Certificates in=20
      CRLs<o:p></o:p></SPAN></P></DIV>
      <BLOCKQUOTE=20
style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: 0in">
        <P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">We=20
        are only talking about an extra 16K at most. The download time =
is the=20
        absolute most cases is negligible. </SPAN></A><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">For=20
        those cases where this solution makes sense, the network =
bandwidth issue=20
        is not a problem.<o:p></o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">For=20
        the cases where this would be an issue, this solution would not =
be=20
        used.<o:p></o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">On=20
        the contrary, in some networks and scenarios, this will improve=20
        performance. Especially in high latency networks with PKI based=20
        peer-peer authentication where an extra retrieval cost way more=20
        performance than the expanded CRL size.<o:p></o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Also,=20
        many clients are configured to pre-fetch CRL:s before they are =
used,=20
        using idle time on the network at no extra =
cost.<o:p></o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
        <DIV>
        <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
        style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
        Santesson</SPAN></B><SPAN lang=3DEN-GB=20
        style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
        style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
        Program Manager</SPAN><SPAN lang=3DEN-GB=20
        style=3D"COLOR: navy"><o:p></o:p></SPAN></P>
        <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
        style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
        Security, Standards</SPAN></B><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV>
        <P class=3DMsoNormal><SPAN=20
        style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
        <DIV=20
        style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; =
BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium =
none">
        <DIV>
        <DIV=20
        style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; =
BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; =
BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
        <P class=3DMsoNormal><B><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> =
Sharon=20
        Boeyen [mailto:[email-masked]] <BR><B>Sent:</B> den 4 =
januari=20
        2007 17:36<BR><B>To:</B> Stefan Santesson; Russ =
Housley<BR><B>Cc:</B>=20
        [email-masked]<BR><B>Subject:</B> RE: Certificates in=20
        CRLs<o:p></o:p></SPAN></P></DIV></DIV>
        <P class=3DMsoNormal><SPAN =
lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I still think =
wasted bandwidth=20
        is also an issue. Forcing the download of 'fat' CRLs on clients =
when, in=20
        many cases, those clients already have the certificates locally =
that=20
        caused the bloating of the CRL, is an unnecessary =
waste.</SPAN><SPAN=20
        lang=3DSV><o:p></o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">-----Original=20
        Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">From: [email-masked] [<A =

        =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]=20
        On Behalf Of Stefan Santesson</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
        lang=3DSV style=3D"FONT-SIZE: 10pt">Sent: Wednesday, January 03, =
2007 9:58=20
        AM</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">To: Russ Housley</SPAN><SPAN =
lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Cc:=20
        [email-masked]</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">Subject: RE: Certificates in =
CRLs</SPAN><SPAN=20
        lang=3DSV> <o:p></o:p></SPAN></P>
        <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN=20
        lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Russ,</SPAN><SPAN =
lang=3DSV>=20
        <o:p></o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">In theory, the CA =
can put=20
        different pointers to different CRLs in each certificate if some =

        certificates are prime targets for frequent checking. But I =
don't think=20
        that is a common scenario.</SPAN><SPAN =
lang=3DSV><o:p></o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">My point is that in =
order to=20
        allow free selection of CRLs, you would have to add capability =
to the=20
        CDP extension rather than to the CRL. I don't think such effort =
is worth=20
        the trouble.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I'm convinced that =
including=20
        certs in a CRL will only be made in situations where it in the =
sum of=20
        all, helps increase efficiency and where the extra bandwidth =
consumed is=20
        not an issue.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I read the critique =
of this=20
        idea as not really be a bandwidth issue, but that some =
implementers=20
        simply don't want to be faced with the requirement to implement =
this=20
        feature. But I don't see that they have to. A CRL with certs in =
a=20
        non-critical extension should work just as well in current =
clients as=20
        any current CRL without certs. The extension can simply be=20
        ignored.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">This is not a =
necessary=20
        feature, but a practical one offering performance improvements =
in some=20
        environments at no loss of interoperability.</SPAN><SPAN=20
        lang=3DSV><o:p></o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN =
lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Stefan =
Santesson</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">Senior Program=20
        Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">Windows Security, =
Standards</SPAN><SPAN lang=3DSV>=20
        <o:p></o:p></SPAN></P>
        <P class=3DMsoNormal><SPAN =
lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
        <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; -----Original=20
        Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; From: Russ Housley [<A=20
        =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</SP=
AN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; Sent: den=20
        21 december 2006 16:19</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; To: Stefan Santesson</SPAN><SPAN =
lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; Cc:=20
        [email-masked]</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; Subject: RE: Certificates in=20
        CRLs</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
        lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; Stefan:</SPAN><SPAN =
lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; If the CA=20
        chooses to offer both, how can the RP determine which one it=20
        </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; will get?&nbsp; Does the CA post =
them in=20
        different LDAP attributes?</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
        lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; Russ</SPAN><SPAN =
lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; At 08:00=20
        AM 12/21/2006, Stefan Santesson wrote:</SPAN><SPAN lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;As=20
        with anything else, the relying party can get what the CA=20
        offers.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
        lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;I don't think there =
is any=20
        realistic scenario where the CA has a </SPAN><SPAN=20
        lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;reason=20
        to offer CRLs both with and without certificates. To offer =
</SPAN><SPAN=20
        lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;this=20
        capability to RP is however not a matter for this protocol. It=20
        </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt;would be a matter for the CRL =

        referencing model, i.e. CDP and/or </SPAN><SPAN =
lang=3DSV><BR></SPAN><SPAN=20
        lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;directory =
schema.</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
        &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt;I don't think that extra =
complexity=20
        however is very useful.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
        lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;Stefan =
Santesson</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
        &gt;Senior Program Manager</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt;Windows Security, =
Standards</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
        &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
        lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; -----Original =

        Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; From:=20
        [email-masked] [<A=20
        href=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> </SPAN><SPAN=20
        lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
        [email-masked]] On Behalf Of Denis Pinkas</SPAN><SPAN =
lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; Sent:=20
        den 20 december 2006 17:05</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; To: =
[email-masked]</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
        Subject: Re: Certificates in CRLs</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
        lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
        &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; It is=20
        necessary to provide relying parties with the choice to get =
</SPAN><SPAN=20
        lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
        :</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
        &gt;&nbsp;&nbsp; - CRLs "as usual", or</SPAN><SPAN lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
        &gt;&nbsp;&nbsp; - CRLs that carry that new =
extension.</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;=20
        &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; The current proposal =
does not=20
        allow for it.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; Until=20
        the draft is changed, I am against the addition of this =
work</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
        item</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; to the program of the =
PKIX=20
        WG.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;=20
        Denis</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
        &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt;=20
        =
______________________________________________________________________</S=
PAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
        _</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; _______</SPAN><SPAN =
lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
        &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Since last IETF a =
new draft=20
        was posted:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;<A=20
        =
href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-" =

        =
target=3D_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix-=
vccrl-</A></SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
        00.txt</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;=20
        &gt;There is a request to add this draft to the PKIX work and I=20
        would</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; encourage to start the =
discussion=20
        about this decision in this</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
        lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; thread.</SPAN><SPAN =
lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;=20
        &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Stefan =
Santesson</SPAN><SPAN=20
        lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
        &gt;Senior Program Manager</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Windows Security,=20
        Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
        <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
        &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
        style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
        =
<o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV></BLOCKQUOTE>=
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C75086.2D34F34A--

Date: Wed, 14 Feb 2007 16:19:13 -0500
To: Paul Hoffman <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: URN in subjectAltName
Sender: [email-masked]

Ooops: s/server/several/

RFC 3280 says:

    When the subjectAltName extension contains a URI, the name MUST be
    stored in the uniformResourceIdentifier (an IA5String).  The name
    MUST NOT be a relative URL, and it MUST follow the URL syntax and
    encoding rules specified in [RFC 1738].  The name MUST include both a
    scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
    scheme-specific-part MUST include a fully qualified domain name or IP
    address as the host.

    As specified in [RFC 1738], the scheme name is not case-sensitive
    (e.g., "http" is equivalent to "HTTP").  The host part is also not
    case-sensitive, but other components of the scheme-specific-part may
    be case-sensitive.  When comparing URIs, conforming implementations
    MUST compare the scheme and host without regard to case, but assume
    the remainder of the scheme-specific-part is case sensitive.

I think this prohibits the use of a URN like this:

    URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN

Russ

At 03:47 PM 2/14/2007, Paul Hoffman wrote:
>At 1:43 PM -0500 2/14/07, Russ Housley wrote:
>>Milan & Paul:
>>
>>>>As the group does not seem to have a strong opinion of the choices I
>>>>propose to include the following text just after the URI part of the
>>>>section 4.2.1.6  Subject Alternative Name:
>>>>
>>>>"When the subjectAltName extension contains a URN, the name MUST be
>>>>stored in the uniformResourceIdentifier (IA5String).  The name MUST
>>>>follow the URN syntax and encoding rules specified in [RFC 2141]."
>>>>
>>>>         Comments?
>>>
>>>This seems like a good addition, seeing as there were multiple 
>>>choices given on the mailing list, and that means interoperability 
>>>issues. Note that there are two paragraphs to the "URI part"; this 
>>>should be added after the second paragraph, just before "When the 
>>>subjectAltName extension contains a DN...".
>>
>>I thought that sever people expressed concern that implementations 
>>that follow RFC 3280 will only expect a URL, so the URN ought to be 
>>encoded in other name.
>
>I don't know which server people those are, but there is nothing in 
>RFC 3280 or 3280bis that would make me think "this is a URL and not a URI".
>
>>It would be a very simple (one page) specification.
>
>That's true, but there is no reason not to make it part of the only 
>specification that most implementers will read. I still support 
>putting it into 3280bis to encourage interoperability.
>
>--Paul Hoffman, Director
>--VPN Consortium
>

Content-class: urn:content-classes:message
Subject: RE: URN in subjectAltName
Date: Wed, 14 Feb 2007 13:18:20 -0800
From: "Santosh Chokhani" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

David,

I do not know much about URI also, but the following statement bothers
me: 

"Note that 3280bis currently allows for the inclusion of LDAP URIs
without host names in the cRLDistributionPoints, authorityInfoAccess,
and subjectInfoAccess extensions?"

I suspect it will break many applications that invoke the URI to obtain
the certificates and CRLs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Wednesday, February 14, 2007 3:04 PM
To: pkix
Subject: Re: URN in subjectAltName

All,

I don't know very much about URIs, and I don't really have an opinion 
about what the subjectAltName section of 3280bis should say about URIs.

My only concern is to ensure that the document is completed soon and 
that it is correct.

The latest version of idnits pointed out that RFC 1738 has been 
obsoleted, and while 3280bis still points to RFC 1738 as the 
specification for the HTTP URI syntax, I changed the text in the 
subjectAltName section to point to RFC 3986 (Uniform Resource Identifier

(URI): Generic Syntax).  So, the relevant text now reads:

      When the subjectAltName extension contains a URI, the name MUST be
      stored in the uniformResourceIdentifier (an IA5String).  The name
      MUST NOT be a relative URL, and it MUST follow the URL syntax and
      encoding rules specified in [RFC 3986].  The name MUST include
both a
      scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
      scheme-specific-part MUST include a fully qualified domain name or
IP
      address as the host.  Rules for encoding internationalized
resource
      identifiers (IRIs) are specified in section 7.4.

      As specified in [RFC 3986], the scheme name is not case-sensitive
      (e.g., "http" is equivalent to "HTTP").  The host part is also not
      case-sensitive, but other components of the scheme-specific-part
may
      be case-sensitive.  Rules for comparing URIs are specified in
section
      7.4.

While RFC 2141 is not listed as having been updated or obsoleted by any 
other RFCs, section 1.1.3 of RFC 3986 states:

      A URI can be further classified as a locator, a name, or both.
The
      term "Uniform Resource Locator" (URL) refers to the subset of URIs
      that, in addition to identifying a resource, provide a means of
      locating the resource by describing its primary access mechanism
      (e.g., its network "location").  The term "Uniform Resource Name"
      (URN) has been used historically to refer to both URIs under the
      "urn" scheme [RFC2141], which are required to remain globally
unique
      and persistent even when the resource ceases to exist or becomes
      unavailable, and to any other URI with the properties of a name.

      An individual scheme does not have to be classified as being just
one
      of "name" or "locator".  Instances of URIs from any given scheme
may
      have the characteristics of names or locators or both, often
      depending on the persistence and care in the assignment of
      identifiers by the naming authority, rather than on any quality of
      the scheme.  Future specifications and related documentation
should
      use the general term "URI" rather than the more restrictive terms
      "URL" and "URN" [RFC3305].

As I read this, the use of the term "Uniform Resource Name" is not 
limited to URIs that conform to the "urn" scheme in RFC 2141 and it is 
now recommended that specifications not try to distinguish between 
different types of URIs.

As I read the proposal below, it is recommending that 3280bis state that

the uniformResourceIdentifier may be used to contain a name that 
conforms to the "urn" scheme of RFC 2141, but that all other URIs that 
are placed in uniformResourceIdentifier must conform to the rules 
specified in RFC 3280.  Is that correct and is it intentional?  If not, 
and it is agreed that 3280bis should allow for the inclusion in the 
subjectAltName extension of URIs that do not include host names, would 
it better to simply remove the text that specifies this requirement so 
that the text would read:

      When the subjectAltName extension contains a URI, the name MUST be
      stored in the uniformResourceIdentifier (an IA5String).  The name
      MUST follow the URI syntax and encoding rules specified in [RFC
3986].
      The name MUST include both a scheme (e.g., "http" or "ftp") and a
      scheme-specific-part.  Rules for encoding internationalized
resource
      identifiers (IRIs) are specified in section 7.4.

      As specified in [RFC 3986], the scheme name is not case-sensitive
      (e.g., "http" is equivalent to "HTTP").  The host part is also not
      case-sensitive, but other components of the scheme-specific-part
may
      be case-sensitive.  Rules for comparing URIs are specified in
section
      7.4.

Note that 3280bis currently allows for the inclusion of LDAP URIs 
without host names in the cRLDistributionPoints, authorityInfoAccess, 
and subjectInfoAccess extensions?  Although it should also be noted that

3280bis only provides a way for imposing name constraints on URIs that 
include a DNS name.  As I read this, any names that are placed in the 
uniformResourceIdentifier name form that do not contain DNS names are 
unconstrained, regardless of the contents of nameConstraints extensions 
in other certificates in the path, which would seem to argue against 
allowing such names to be placed in the uniformResourceIdentifier name
form.

Dave

Paul Hoffman wrote:
> At 12:02 AM +0100 2/13/07, Milan Sova wrote:
>>     As the group does not seem to have a strong opinion of the
choices I
>> propose to include the following text just after the URI part of the
>> section 4.2.1.6  Subject Alternative Name:
>>
>> "When the subjectAltName extension contains a URN, the name MUST be
>> stored in the uniformResourceIdentifier (IA5String).  The name MUST
>> follow the URN syntax and encoding rules specified in [RFC 2141]."
>>
>>     Comments?
>
> This seems like a good addition, seeing as there were multiple choices

> given on the mailing list, and that means interoperability issues. 
> Note that there are two paragraphs to the "URI part"; this should be 
> added after the second paragraph, just before "When the subjectAltName

> extension contains a DN...".
>
> --Paul Hoffman, Director
> --VPN Consortium

Date: Wed, 14 Feb 2007 12:47:27 -0800
To: Russ Housley <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: URN in subjectAltName
Sender: [email-masked]

At 1:43 PM -0500 2/14/07, Russ Housley wrote:
>Milan & Paul:
>
>>>As the group does not seem to have a strong opinion of the choices I
>>>propose to include the following text just after the URI part of the
>>>section 4.2.1.6  Subject Alternative Name:
>>>
>>>"When the subjectAltName extension contains a URN, the name MUST be
>>>stored in the uniformResourceIdentifier (IA5String).  The name MUST
>>>follow the URN syntax and encoding rules specified in [RFC 2141]."
>>>
>>>         Comments?
>>
>>This seems like a good addition, seeing as there were multiple 
>>choices given on the mailing list, and that means interoperability 
>>issues. Note that there are two paragraphs to the "URI part"; this 
>>should be added after the second paragraph, just before "When the 
>>subjectAltName extension contains a DN...".
>
>I thought that sever people expressed concern that implementations 
>that follow RFC 3280 will only expect a URL, so the URN ought to be 
>encoded in other name.

I don't know which server people those are, but there is nothing in 
RFC 3280 or 3280bis that would make me think "this is a URL and not a 
URI".

>It would be a very simple (one page) specification.

That's true, but there is no reason not to make it part of the only 
specification that most implementers will read. I still support 
putting it into 3280bis to encourage interoperability.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 14 Feb 2007 15:04:03 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: URN in subjectAltName
Sender: [email-masked]

All,

I don't know very much about URIs, and I don't really have an opinion 
about what the subjectAltName section of 3280bis should say about URIs.  
My only concern is to ensure that the document is completed soon and 
that it is correct.

The latest version of idnits pointed out that RFC 1738 has been 
obsoleted, and while 3280bis still points to RFC 1738 as the 
specification for the HTTP URI syntax, I changed the text in the 
subjectAltName section to point to RFC 3986 (Uniform Resource Identifier 
(URI): Generic Syntax).  So, the relevant text now reads:

      When the subjectAltName extension contains a URI, the name MUST be
      stored in the uniformResourceIdentifier (an IA5String).  The name
      MUST NOT be a relative URL, and it MUST follow the URL syntax and
      encoding rules specified in [RFC 3986].  The name MUST include both a
      scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
      scheme-specific-part MUST include a fully qualified domain name or IP
      address as the host.  Rules for encoding internationalized resource
      identifiers (IRIs) are specified in section 7.4.

      As specified in [RFC 3986], the scheme name is not case-sensitive
      (e.g., "http" is equivalent to "HTTP").  The host part is also not
      case-sensitive, but other components of the scheme-specific-part may
      be case-sensitive.  Rules for comparing URIs are specified in section
      7.4.

While RFC 2141 is not listed as having been updated or obsoleted by any 
other RFCs, section 1.1.3 of RFC 3986 states:

      A URI can be further classified as a locator, a name, or both.  The
      term "Uniform Resource Locator" (URL) refers to the subset of URIs
      that, in addition to identifying a resource, provide a means of
      locating the resource by describing its primary access mechanism
      (e.g., its network "location").  The term "Uniform Resource Name"
      (URN) has been used historically to refer to both URIs under the
      "urn" scheme [RFC2141], which are required to remain globally unique
      and persistent even when the resource ceases to exist or becomes
      unavailable, and to any other URI with the properties of a name.

      An individual scheme does not have to be classified as being just one
      of "name" or "locator".  Instances of URIs from any given scheme may
      have the characteristics of names or locators or both, often
      depending on the persistence and care in the assignment of
      identifiers by the naming authority, rather than on any quality of
      the scheme.  Future specifications and related documentation should
      use the general term "URI" rather than the more restrictive terms
      "URL" and "URN" [RFC3305].

As I read this, the use of the term "Uniform Resource Name" is not 
limited to URIs that conform to the "urn" scheme in RFC 2141 and it is 
now recommended that specifications not try to distinguish between 
different types of URIs.

As I read the proposal below, it is recommending that 3280bis state that 
the uniformResourceIdentifier may be used to contain a name that 
conforms to the "urn" scheme of RFC 2141, but that all other URIs that 
are placed in uniformResourceIdentifier must conform to the rules 
specified in RFC 3280.  Is that correct and is it intentional?  If not, 
and it is agreed that 3280bis should allow for the inclusion in the 
subjectAltName extension of URIs that do not include host names, would 
it better to simply remove the text that specifies this requirement so 
that the text would read:

      When the subjectAltName extension contains a URI, the name MUST be
      stored in the uniformResourceIdentifier (an IA5String).  The name
      MUST follow the URI syntax and encoding rules specified in [RFC 3986].
      The name MUST include both a scheme (e.g., "http" or "ftp") and a
      scheme-specific-part.  Rules for encoding internationalized resource
      identifiers (IRIs) are specified in section 7.4.

      As specified in [RFC 3986], the scheme name is not case-sensitive
      (e.g., "http" is equivalent to "HTTP").  The host part is also not
      case-sensitive, but other components of the scheme-specific-part may
      be case-sensitive.  Rules for comparing URIs are specified in section
      7.4.

Note that 3280bis currently allows for the inclusion of LDAP URIs 
without host names in the cRLDistributionPoints, authorityInfoAccess, 
and subjectInfoAccess extensions?  Although it should also be noted that 
3280bis only provides a way for imposing name constraints on URIs that 
include a DNS name.  As I read this, any names that are placed in the 
uniformResourceIdentifier name form that do not contain DNS names are 
unconstrained, regardless of the contents of nameConstraints extensions 
in other certificates in the path, which would seem to argue against 
allowing such names to be placed in the uniformResourceIdentifier name form.

Dave

Paul Hoffman wrote:
> At 12:02 AM +0100 2/13/07, Milan Sova wrote:
>>     As the group does not seem to have a strong opinion of the choices I
>> propose to include the following text just after the URI part of the
>> section 4.2.1.6  Subject Alternative Name:
>>
>> "When the subjectAltName extension contains a URN, the name MUST be
>> stored in the uniformResourceIdentifier (IA5String).  The name MUST
>> follow the URN syntax and encoding rules specified in [RFC 2141]."
>>
>>     Comments?
>
> This seems like a good addition, seeing as there were multiple choices 
> given on the mailing list, and that means interoperability issues. 
> Note that there are two paragraphs to the "URI part"; this should be 
> added after the second paragraph, just before "When the subjectAltName 
> extension contains a DN...".
>
> --Paul Hoffman, Director
> --VPN Consortium

Cc: Russ Housley <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
Subject: LDAP issues in rfc3280bis
Date: Wed, 14 Feb 2007 11:54:48 -0800
To: [email-masked]
Sender: [email-masked]

I have reviewed draft-ietf-pkix-rfc3280bis-07 for LDAP-related issues,
in particular those around the use of the binary encoding option,
and find the following issues, all relatively minor.

In Section 2.1, references to X.500 and RFC 4510 should
be added, respectively for the terms "X.500 Directory" and "LDAP".
The term LDAP should also be spelled out here (first use in body).

In Section 4.2.1.13, in the paragraph starting with "If the
DistributionPointName contains", the sentence starting with
A reference to RFC 4516 should be provided for "LDAP scheme".
Also, in this sentence, the term "distinguishedName" field
appears to refer to the <dn> field of the LDAP URI,
the term "attribute" to a <attrdesc> field, and "host name"
to the <host> field.   For clarity, it might be better to
say:
	When the LDAP URI scheme [RFC4516] is used, the URI
	MUST contain a <dn> field containing the distinguished
	name of the entry holding the CRL, MUST contain an
	<attrdesc> field containing the name of the attribute
	holding the CRL, and SHOULD contain a <host>.  For
	instance, <ldap://ldap.example.com/cn=exmplCA,
	dc=exmaple,dc=com?certificateRevocationList;binary>.

It may be appropriate to add:
	Where the attribute holding the CRL, typically
	certificateRevocationList or authorityRevocationList
	[RFC4523] requires transfer using ;binary, the <attrdesc>
	field MUST include the binary encoding option, ;binary,
	as discussed in RFC 4522 [RFC4522].

And then to clarify the no host field text:
	Omitting the host name (e.g., <ldap:///cn=example% 
20CA,dc=example,dc=com?
    authorityRevocationList;binary>) has the effect of relying on  
whatever
	a priori knowledge the client might have to contact an appropriate
	server.

Note that I have used angle brackets to clearly indicate the start and
end of the URI.  Angle brackets are reserved in the LDAP URI syntax for
this purpose.

I suggest similar changes be made to sections 4.2.2.1 and 5.2
materials discussing use of LDAP URIs.

-- Kurt

Date: Wed, 14 Feb 2007 14:33:37 -0500
To: "Jonghyun Baek" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Questions on the use case of KeyUsage type in  Key Usage extension
Cc: [email-masked]
Sender: [email-masked]

<html>
<body>
Jonghyun Baek:<br><br>
The encipherOnly and decipherOnly were specified to support a form of key
escrow that was developed at Royal Holloway.&nbsp; To the best of my
knowledge, no one is using that key escrow system today.<br><br>
Russ<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=2>Dear PKIX WG,<br>
</font>&nbsp;<br>
<font size=2>The key usage extension(section 4.2.1.3 in RFC3280)&nbsp;
have nine KeyUsage types such as digitalSignature, non repudiation,
keyEncipherment, etc.<br>
I can understood each of the KeyUsage types meaning but i would like to
know a real example or a use case of the encipherOnly type and the
decipherOnly type. i mean which kind of the service or application need
the encipherOnly or decipherOnly type certificate and for what ?<br>
I will be so appriciate if you give me a hand.<br>
</font>&nbsp;<br>
<font size=2>Thanks!<br>
</font>&nbsp;<br>
<font size=2>Jonghyun Baek</font> <br>
&nbsp;<br>
<font size=2>=================================================== <br>
Jonghyun Baek <br>
--------------------------------------------------- <br>
Senior Researcher<br>
Electronic Transaction Security Planning Team<br>
Korea Information Security Agency (KISA) <br>
--------------------------------------------------- <br>
78 Garak-Dong, Songpa-Gu, Seoul, Korea 138-803 <br>
Tel : +82-2-405-5423&nbsp; <br>
Fax : +82-2-405-5219 <br>
Mobile : +82-16-591-3664 <br>
E-mail : <a href="mailto:[email-masked]">[email-masked]</a> <br>
===================================================</font></blockquote>
</body>
</html>

Date: Wed, 14 Feb 2007 13:43:35 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: URN in subjectAltName
Sender: [email-masked]

Milan & Paul:

>>As the group does not seem to have a strong opinion of the choices I
>>propose to include the following text just after the URI part of the
>>section 4.2.1.6  Subject Alternative Name:
>>
>>"When the subjectAltName extension contains a URN, the name MUST be
>>stored in the uniformResourceIdentifier (IA5String).  The name MUST
>>follow the URN syntax and encoding rules specified in [RFC 2141]."
>>
>>         Comments?
>
>This seems like a good addition, seeing as there were multiple 
>choices given on the mailing list, and that means interoperability 
>issues. Note that there are two paragraphs to the "URI part"; this 
>should be added after the second paragraph, just before "When the 
>subjectAltName extension contains a DN...".

I thought that sever people expressed concern that implementations 
that follow RFC 3280 will only expect a URL, so the URN ought to be 
encoded in other name.  It would be a very simple (one page) specification.

Russ

Content-class: urn:content-classes:message
Subject: RE: Certificates in CRLs
Date: Wed, 14 Feb 2007 09:06:25 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

We could load these semantics into the CRL Distribution point but a =
simpler way to support them would be via the existing HTTP content =
negotiation mechanism (ACCEPT header).=20
=20
To do this all we need to do is to define the appropriate descriptions. =
A single distribution point resource identifier then serves for both =
resources.

________________________________

	From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: Wednesday, February 14, 2007 5:57 AM
	To: [email-masked]
	Subject: Re: Certificates in CRLs
=09
=09

	A way forward ?

	=20

	The key issue is not the structure of the "augmented" CRL proposed by =
Stefan,=20
	but the ability to retrieve from a given CA either a CRL (i.e. the =
current=20
	structure of a CRL) or a CRLwithCerts (i.e. the new structure proposed =
by Stefan),=20
	if a CA chooses to issue both.=20

	=20

	We need to focus on the cRLDistributionPoints extension to allow =
retrieving=20
	either a CRL, or a CRLwithCerts, or both.

	=20

	Let us have a look at some sentences extracted from RFC 3280:

	=20

	=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

	=20

	   The cRLDistributionPoints extension is a SEQUENCE of

	   DistributionPoint.  A DistributionPoint consists of three fields,

	   each of which is optional: distributionPoint, reasons, and =
cRLIssuer.

	=20

	(...)

	=20

	   When the HTTP or FTP scheme is specified, the

	   URI MUST point to a single DER encoded CRL as specified in [RFC

	   2585].  HTTP server implementations accessed via the URI SHOULD

	   specify the media type application/pkix-crl in the content-type

	   header field of the response. =20

	=20

	   When the LDAP scheme is specified, the

	   URI MUST specify a distinguishedName and attribute and SHOULD =
specify

	   a host name (e.g., ldap://ldap.example.com/cn=3DexmplCA,

	   dc=3Dexample,dc=3Dcom?certificateRevocationList;binary). =20

	=20

	(...)

	=20

	   The URI MUST include

	   an appropriate attribute description for the attribute that holds =
the

	   DER [X.690] encoded CRL.

	=20

	=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

	=20

	A way forward would be to define appropriate attribute descriptions for =

	the attributes that holds either the encoded CRL or the encoded =
CRLwithCerts.=20
	We could recommend to use currentCRL and currentCRLwithCerts, or =
latestCRL=20
	or latestCRLwithCerts.

	=20

	For HTTTP or FTP a new media type could be defined such as=20
	application/pkix-crlwithcerts to be used in the content-type header =
field=20
	of the response.=20

	=20

	For LDAP, the query should end up, for example, with =
CRLwithcerts;binary/

	=20

	We could also say that if the CA has chosen to issue both types of =
CRLs,=20
	then every distributionPoint holding a CRL (as defined today) should be =
placed=20
	first in the list.

	=20

	Denis
	=20
________________________________

	I'm in agreement that Stefan's proposal is a decent one.  As Phillip =
mentions, it certainly isn't appropriate in every situation, but I can =
see situations in which it might be useful.  One might argue that a CRL =
issuer could issue two CRLs, the most commonly retrieved one without =
this extension, but a separate one issued with it-the latter being made =
to applications responsible for long term archive, historical signature =
validation, or other purposes which might find it useful. =20

	=20

	I don't see any harm in adding this extension as an optional feature =
for PKIs that wish it, since it is truly optional, non-critical, and =
does not affect path processing. =20

	=20

	--Peter

	=20

	+----------------------------------------------------------------+
	| Peter Hesse                     [email-masked]     |
	| Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.  |
	|       Visit our InfoSecurity blog: securitymusings.com =
<http://www.securitymusings.com/>          |
	+----------------------------------------------------------------+
	"The generation of random numbers is too important to be left
	 to chance." --Robert R. Coveyou

	=20

	=20

	From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
	Sent: Tuesday, February 13, 2007 6:53 PM
	To: Sharon Boeyen; Stefan Santesson; Russ Housley
	Cc: [email-masked]
	Subject: RE: Certificates in CRLs

	=20

	I think that Sharon's proposal might have been a good idea in 1995 =
before the world got wedged on CRLs as the revocation mechanism. We can =
define a package but its too late to get it embedded in the rest of the =
application infrastructure.

	=20

	Given where we are Stefan's proposal is the best one. It is compatible =
with the existing infrastructure and solves a real issue.=20

	=20

	It is an option, clearly there are cases where it would be =
inappropriate but universal applicability has never been a requirement. =
Otherwise we could have saved all the time spent on attribute =
certificates.

		=20

________________________________

		From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Sharon Boeyen
		Sent: Friday, January 05, 2007 9:09 AM
		To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley
		Cc: [email-masked]
		Subject: RE: Certificates in CRLs

		Stefan I really don't think you can state where this will or will not =
be used in the future. Naturally you know where you want to use it, but =
software only enables a facility and the customer decides when and how =
to use it.=20

		=20

		Whether this scheme could possibly be useful in some cases is not my =
point. My point is that current deployments seem to be working fine =
without it and I don't want to see those interfered with just because =
some CA they may have cross certified with decided to put certificates =
inside their CRLS. Back to Denis' point - there is no need to impose =
this in the way you've proposed.=20

		=20

		Earlier I (and others including Dave Kemp) suggested a "package" that =
includes the CRL, and the certificate in question as an 'extra' that a =
CA could publish in addition to a regular CRL. That "package could be =
published in a separate directory attribute and/or an HTTP accessible =
file. It could be pointed to from within the certificate just as the CRL =
currently is. That could be done either by extending the CRLDP or adding =
a new pointer extension or adding a new method to the AIA extension. =
That type of approach gives you what you want but does not in any way =
interfere with clients who do not want and do not need to retrieve that =
bloated CRL.=20

		=20

		Also, you haven't addressed the question about what happens when more =
than one certificate is needed. If a CRL includes more than one =
certificate (e.g. the CRL issuer did one or more key rollovers then CRL =
gets bloated a lot bigger than you suggested. I don't want to debate how =
often a key gets rolled over either however I have definitely seen =
instances in real world deployments where a key has been rolled very =
often in a very short period of time (regardless of whether the reason =
for rolling it was a good one or not - it has happened). Also, =
regardless of the size of the "bloat" I'm saying that in most cases the =
clients will already have the certificates in question and this bloat =
will cause them extra processing in managing their certificate caches =
etc unnecessarily. The client should have a choice as to whether to =
download the certificate or not.

		=20

		I don't understand why you're so opposed to the "package" solution.=20

		=20

		Cheers,

		Sharon=20

		-----Original Message-----
		From: Stefan Santesson [mailto:[email-masked]]=20
		Sent: Friday, January 05, 2007 8:01 AM
		To: Sharon Boeyen; Russ Housley
		Cc: [email-masked]
		Subject: RE: Certificates in CRLs

			We are only talking about an extra 16K at most. The download time is =
the absolute most cases is negligible.=20

			For those cases where this solution makes sense, the network =
bandwidth issue is not a problem.

			=20

			For the cases where this would be an issue, this solution would not =
be used.

			=20

			On the contrary, in some networks and scenarios, this will improve =
performance. Especially in high latency networks with PKI based =
peer-peer authentication where an extra retrieval cost way more =
performance than the expanded CRL size.

			=20

			Also, many clients are configured to pre-fetch CRL:s before they are =
used, using idle time on the network at no extra cost.

			=20

			=20

			Stefan Santesson

			Senior Program Manager

			Windows Security, Standards

			=20

			From: Sharon Boeyen [mailto:[email-masked]]=20
			Sent: den 4 januari 2007 17:36
			To: Stefan Santesson; Russ Housley
			Cc: [email-masked]
			Subject: RE: Certificates in CRLs

			=20

			I still think wasted bandwidth is also an issue. Forcing the download =
of 'fat' CRLs on clients when, in many cases, those clients already have =
the certificates locally that caused the bloating of the CRL, is an =
unnecessary waste.

			-----Original Message-----=20
			From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Stefan Santesson=20
			Sent: Wednesday, January 03, 2007 9:58 AM=20
			To: Russ Housley=20
			Cc: [email-masked]=20
			Subject: RE: Certificates in CRLs=20

			=20

			Russ,=20

			In theory, the CA can put different pointers to different CRLs in =
each certificate if some certificates are prime targets for frequent =
checking. But I don't think that is a common scenario.

			My point is that in order to allow free selection of CRLs, you would =
have to add capability to the CDP extension rather than to the CRL. I =
don't think such effort is worth the trouble.

			I'm convinced that including certs in a CRL will only be made in =
situations where it in the sum of all, helps increase efficiency and =
where the extra bandwidth consumed is not an issue.

			I read the critique of this idea as not really be a bandwidth issue, =
but that some implementers simply don't want to be faced with the =
requirement to implement this feature. But I don't see that they have =
to. A CRL with certs in a non-critical extension should work just as =
well in current clients as any current CRL without certs. The extension =
can simply be ignored.

			This is not a necessary feature, but a practical one offering =
performance improvements in some environments at no loss of =
interoperability.

			=20

			Stefan Santesson=20
			Senior Program Manager=20
			Windows Security, Standards=20

			=20

			> -----Original Message-----=20
			> From: Russ Housley [mailto:[email-masked]]=20
			> Sent: den 21 december 2006 16:19=20
			> To: Stefan Santesson=20
			> Cc: [email-masked]=20
			> Subject: RE: Certificates in CRLs=20
			>=20
			> Stefan:=20
			>=20
			> If the CA chooses to offer both, how can the RP determine which one =
it=20
			> will get?  Does the CA post them in different LDAP attributes?=20
			>=20
			> Russ=20
			>=20
			> At 08:00 AM 12/21/2006, Stefan Santesson wrote:=20
			>=20
			> >As with anything else, the relying party can get what the CA =
offers.=20
			> >=20
			> >I don't think there is any realistic scenario where the CA has a=20
			> >reason to offer CRLs both with and without certificates. To offer=20
			> >this capability to RP is however not a matter for this protocol. =
It=20
			> >would be a matter for the CRL referencing model, i.e. CDP and/or=20
			> >directory schema.=20
			> >=20
			> >I don't think that extra complexity however is very useful.=20
			> >=20
			> >Stefan Santesson=20
			> >Senior Program Manager=20
			> >Windows Security, Standards=20
			> >=20
			> >=20
			> > > -----Original Message-----=20
			> > > From: [email-masked] [mailto:owner-ietf-=20
			> > > [email-masked]] On Behalf Of Denis Pinkas=20
			> > > Sent: den 20 december 2006 17:05=20
			> > > To: [email-masked]=20
			> > > Subject: Re: Certificates in CRLs=20
			> > >=20
			> > >=20
			> > >=20
			> > > It is necessary to provide relying parties with the choice to =
get=20
			> > > :=20
			> > >=20
			> > >   - CRLs "as usual", or=20
			> > >   - CRLs that carry that new extension.=20
			> > >=20
			> > > The current proposal does not allow for it.=20
			> > >=20
			> > > Until the draft is changed, I am against the addition of this =
work=20
			> item=20
			> > > to the program of the PKIX WG.=20
			> > >=20
			> > > Denis=20
			> > >=20
			> > >=20
			> =
______________________________________________________________________=20
			> _=20
			> > > _______=20
			> > >=20
			> > > >Since last IETF a new draft was posted:=20
			> > > =
>http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-=20
			> 00.txt=20
			> > > >=20
			> > > >There is a request to add this draft to the PKIX work and I =
would=20
			> > > encourage to start the discussion about this decision in this=20
			> thread.=20
			> > > >=20
			> > > >Stefan Santesson=20
			> > > >Senior Program Manager=20
			> > > >Windows Security, Standards=20
			> > >=20
			> > >=20
			> > >=20

________________________________

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D963390417-14022007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We could load these semantics into the CRL =
Distribution=20
point but a simpler way to support them would be via the existing HTTP =
content=20
negotiation mechanism (ACCEPT header). </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D963390417-14022007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D963390417-14022007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>To do this all we need to do is to define the =
appropriate=20
descriptions. A single distribution point resource identifier then =
serves for=20
both resources.</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, February 14, 2007 5:57 =
AM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: Certificates in=20
  CRLs<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New">A way=20
  forward&nbsp;?<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New">The key=20
  issue is not the structure of the =93augmented=94 CRL proposed by =
Stefan, <BR>but=20
  the ability to retrieve from a given CA either a CRL (i.e. the current =

  <BR>structure of a CRL) or a CRLwithCerts (i.e. the new structure =
proposed by=20
  Stefan), <BR>if a CA&nbsp;chooses&nbsp;to issue both.=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New">We need=20
  to focus on the cRLDistributionPoints extension to allow retrieving =
<BR>either=20
  a CRL, or a CRLwithCerts, or both.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New">Let us=20
  have a look at some sentences extracted from RFC=20
  3280:<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New" =
size=3D2>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20
  face=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText=20
  style=3D"MARGIN: 0cm 0cm 0pt">&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The =
cRLDistributionPoints=20
  extension is a SEQUENCE of<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;</SPAN><SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>DistributionPoint.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>A=20
  DistributionPoint consists of three=20
fields,<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>each of which is =
optional:=20
  distributionPoint, reasons, and =
cRLIssuer.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20
  face=3D"Courier New">(=85)<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>When the HTTP or FTP =
scheme is=20
  specified, the<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>URI MUST point to a =
single DER=20
  encoded CRL as specified in [RFC<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2585].<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>HTTP server implementations =
accessed=20
  via the URI SHOULD<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>specify the media type =

  application/pkix-crl in the =
content-type<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>header field of the=20
  response.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>When the LDAP scheme =
is=20
  specified, the<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>URI MUST specify a=20
  distinguishedName and attribute and SHOULD=20
  specify<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a host name (e.g.,=20
  =
ldap://ldap.example.com/cn=3DexmplCA,<o:p></o:p></FONT></FONT></SPAN></P>=

  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
  </SPAN>dc=3Dexample,dc=3Dcom?certificateRevocationList;binary).<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20
  face=3D"Courier New">(=85)<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The URI MUST=20
  include<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>an appropriate =
attribute=20
  description for the attribute that holds=20
  the<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New"><SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>DER [X.690] encoded=20
  CRL.</FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20
  face=3D"Courier New"></FONT></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT=20
  face=3D"Courier =
New">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New">A way=20
  forward would be to define appropriate attribute descriptions for =
<BR>the=20
  attributes that holds either the encoded CRL or the encoded =
CRLwithCerts.=20
  <BR>We could recommend to use currentCRL and currentCRLwithCerts, or =
latestCRL=20
  <BR>or latestCRLwithCerts.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New">For=20
  HTTTP or FTP a new media type could be defined such as=20
  <BR>application/pkix-crlwithcerts to be used in the content-type =
header field=20
  <BR>of the response. <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New">For=20
  LDAP, the query should end up, for example, with=20
  CRLwithcerts;binary/<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D2><FONT =
face=3D"Courier New">We=20
  could also say that if the CA has chosen to issue both types of CRLs, =
<BR>then=20
  every distributionPoint holding a CRL (as defined today) should be =
placed=20
  <BR>first in the list.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoPlainText style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT></o:p></SPAN></P></DIV>
  <DIV>Denis</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>
  <HR>
  </DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">I=92m=20
  in agreement that Stefan=92s proposal is a decent one.&nbsp; As =
Phillip=20
  mentions, it certainly isn=92t appropriate in every situation, but I =
can see=20
  situations in which it might be useful.&nbsp; One might argue that a =
CRL=20
  issuer could issue two CRLs, the most commonly retrieved one without =
this=20
  extension, but a separate one issued with it=97the latter being made =
to=20
  applications responsible for long term archive, historical signature=20
  validation, or other purposes which might find it useful.&nbsp;=20
  <o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">I=20
  don=92t see any harm in adding this extension as an optional feature =
for PKIs=20
  that wish it, since it is truly optional, non-critical, and does not =
affect=20
  path processing. &nbsp;<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">--Peter<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Courier =
New'">+----------------------------------------------------------------+<=
BR>|&nbsp;</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: #3333cc; FONT-FAMILY: 'Courier =
New'">Peter=20
  Hesse</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: blue"><A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>=
</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: gray">|<BR>|&nbsp;</SPAN><SPAN style=3D"COLOR: =
#3333cc">Phone:=20
  703-378-5808 x105</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: #3333cc">Gemini Security Solutions, =
Inc.&nbsp;&nbsp;</SPAN><SPAN=20
  style=3D"COLOR: =
gray">|<BR>|&nbsp;</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: #3333cc">Visit our InfoSecurity blog: <A=20
  =
href=3D"http://www.securitymusings.com/">securitymusings.com</A></SPAN>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: =
gray">|<BR>+-------------------------------------------------------------=
---+<BR></SPAN><SPAN=20
  style=3D"COLOR: teal">"The generation of random numbers is too =
important to be=20
  left<BR>&nbsp;to chance." --Robert R. Coveyou</SPAN></SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Hallam-Baker, Phillip<BR><B>Sent:</B> Tuesday, February =
13, 2007=20
  6:53 PM<BR><B>To:</B> Sharon Boeyen; Stefan Santesson; Russ=20
  Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Certificates in=20
  CRLs<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><SPAN lang=3DSV=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">I=20
  think that Sharon's proposal might have been a good idea in 1995 =
before the=20
  world got wedged on CRLs as the revocation mechanism. We can define a =
package=20
  but its too late to get it embedded in the rest of the application=20
  infrastructure.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DSV>&nbsp;<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DSV=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Given=20
  where we are Stefan's proposal is the best one. It is compatible with =
the=20
  existing infrastructure and solves a real issue. </SPAN><SPAN=20
  lang=3DSV><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DSV>&nbsp;<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DSV=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">It is=20
  an option, clearly there are cases where it would be inappropriate but =

  universal applicability has never been a requirement. Otherwise we =
could have=20
  saved all the time spent on attribute certificates.</SPAN><SPAN=20
  lang=3DSV><o:p></o:p></SPAN></P>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
    <P class=3DMsoNormal><SPAN lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter>
    <HR align=3Dcenter width=3D"100%" SIZE=3D2>
    </DIV>
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20
    [email-masked] [mailto:[email-masked]] =
<B>On=20
    Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, January 05, 2007 =
9:09=20
    AM<BR><B>To:</B> 'Stefan Santesson'; Sharon Boeyen; Russ=20
    Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Certificates=20
    in CRLs</SPAN><o:p></o:p></P>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
    I really don't think you can state where this will or will not be =
used in=20
    the future. Naturally you know where you want to use it, but =
software only=20
    enables a facility and the customer decides when and how to use it.=20
    </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Whether=20
    this scheme could possibly be useful in some cases is not my point. =
My point=20
    is that current deployments seem to be working fine without it and I =
don't=20
    want to see those interfered with just because some CA they may have =
cross=20
    certified with decided to put certificates inside their CRLS. Back =
to Denis'=20
    point - there is no need to impose this in the way you've proposed.=20
    </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Earlier=20
    I (and others including Dave Kemp) suggested a "package" that =
includes the=20
    CRL, and the certificate in question as an 'extra' that a CA could =
publish=20
    in addition to a regular CRL. That "package could be published in a =
separate=20
    directory attribute and/or an HTTP accessible file. It could be =
pointed to=20
    from within the certificate&nbsp;just as the CRL currently is. That =
could be=20
    done either by extending the CRLDP or adding a new&nbsp;pointer =
extension or=20
    adding a new method to the AIA extension. That type of approach =
gives you=20
    what you want but does not in any way interfere with clients who do =
not want=20
    and do not need to retrieve that bloated CRL.&nbsp;</SPAN><SPAN=20
    lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Also,=20
    you haven't addressed the question about&nbsp;what happens =
when&nbsp;more=20
    than one certificate is needed. If a CRL includes more than one=20
    certificate&nbsp;(e.g. the CRL issuer did one or more key=20
    rollovers&nbsp;then CRL gets bloated a lot bigger than you =
suggested.&nbsp;I=20
    don't want to debate how often a key gets rolled over either however =
I have=20
    definitely seen instances in real world deployments where a key has =
been=20
    rolled very often in a very short period of time (regardless of =
whether the=20
    reason for rolling it was a good one or not - it has happened). =
Also,=20
    regardless of the size of the "bloat" I'm saying that in most cases =
the=20
    clients will already have the certificates in question and this =
bloat will=20
    cause them extra processing in managing their certificate caches etc =

    unnecessarily. The client should have a choice as to whether to =
download the=20
    certificate or not.</SPAN><SPAN =
lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">I=20
    don't understand why you're so opposed to the "package"=20
    solution.&nbsp;</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Cheers,</SPAN><SPAN=20
    lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Sharon</SPAN><SPAN=20
    lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">-----Original=20
    Message-----<BR><B>From:</B> Stefan Santesson =
[mailto:[email-masked]]=20
    <BR><B>Sent:</B> Friday, January 05, 2007 8:01 AM<BR><B>To:</B> =
Sharon=20
    Boeyen; Russ Housley<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B> RE:=20
    Certificates in CRLs<o:p></o:p></SPAN></P></DIV>
    <BLOCKQUOTE=20
      style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><P=20
      class=3DMsoNormal><A name=3D_MailEndCompose><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">We=20
      are only talking about an extra 16K at most. The download time is =
the=20
      absolute most cases is negligible. </SPAN></A><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">For=20
      those cases where this solution makes sense, the network bandwidth =
issue=20
      is not a problem.<o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">For=20
      the cases where this would be an issue, this solution would not be =

      used.<o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">On=20
      the contrary, in some networks and scenarios, this will improve=20
      performance. Especially in high latency networks with PKI based =
peer-peer=20
      authentication where an extra retrieval cost way more performance =
than the=20
      expanded CRL size.<o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Also,=20
      many clients are configured to pre-fetch CRL:s before they are =
used, using=20
      idle time on the network at no extra cost.<o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <DIV>
      <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
      Santesson</SPAN></B><SPAN lang=3DEN-GB=20
      style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
      Program Manager</SPAN><SPAN lang=3DEN-GB=20
      style=3D"COLOR: navy"><o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
      Security, Standards</SPAN></B><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <DIV=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; =
BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium =
none">
      <DIV>
      <DIV=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; =
BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; =
BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
      <P class=3DMsoNormal><B><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> =
Sharon Boeyen=20
      [mailto:[email-masked]] <BR><B>Sent:</B> den 4 januari =
2007=20
      17:36<BR><B>To:</B> Stefan Santesson; Russ Housley<BR><B>Cc:</B>=20
      [email-masked]<BR><B>Subject:</B> RE: Certificates in=20
      CRLs<o:p></o:p></SPAN></P></DIV></DIV>
      <P class=3DMsoNormal><SPAN lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I still think wasted =
bandwidth is=20
      also an issue. Forcing the download of 'fat' CRLs on clients when, =
in many=20
      cases, those clients already have the certificates locally that =
caused the=20
      bloating of the CRL, is an unnecessary waste.</SPAN><SPAN=20
      lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">-----Original=20
      Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">From: [email-masked] [<A=20
      =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]=20
      On Behalf Of Stefan Santesson</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">Sent: Wednesday, January 03, =
2007 9:58=20
      AM</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">To: Russ Housley</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Cc:=20
      [email-masked]</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">Subject: RE: Certificates in =
CRLs</SPAN><SPAN=20
      lang=3DSV> <o:p></o:p></SPAN></P>
      <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN=20
      lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Russ,</SPAN><SPAN =
lang=3DSV>=20
      <o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">In theory, the CA can =
put=20
      different pointers to different CRLs in each certificate if some=20
      certificates are prime targets for frequent checking. But I don't =
think=20
      that is a common scenario.</SPAN><SPAN =
lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">My point is that in =
order to=20
      allow free selection of CRLs, you would have to add capability to =
the CDP=20
      extension rather than to the CRL. I don't think such effort is =
worth the=20
      trouble.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I'm convinced that =
including=20
      certs in a CRL will only be made in situations where it in the sum =
of all,=20
      helps increase efficiency and where the extra bandwidth consumed =
is not an=20
      issue.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I read the critique =
of this idea=20
      as not really be a bandwidth issue, but that some implementers =
simply=20
      don't want to be faced with the requirement to implement this =
feature. But=20
      I don't see that they have to. A CRL with certs in a non-critical=20
      extension should work just as well in current clients as any =
current CRL=20
      without certs. The extension can simply be ignored.</SPAN><SPAN=20
      lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">This is not a =
necessary feature,=20
      but a practical one offering performance improvements in some =
environments=20
      at no loss of interoperability.</SPAN><SPAN =
lang=3DSV><o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Stefan =
Santesson</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">Senior Program=20
      Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">Windows Security, Standards</SPAN><SPAN =
lang=3DSV>=20
      <o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; -----Original=20
      Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; From: Russ Housley [<A=20
      =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</SP=
AN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; Sent: den=20
      21 december 2006 16:19</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; To: Stefan Santesson</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; Cc:=20
      [email-masked]</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; Subject: RE: Certificates in =
CRLs</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      Stefan:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; If the CA chooses to offer both, =
how can the=20
      RP determine which one it </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; will get?&nbsp; Does the CA post =
them in=20
      different LDAP attributes?</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; Russ</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; At 08:00 AM 12/21/2006, =
Stefan=20
      Santesson wrote:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV =

      style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;As with anything else, the =
relying party=20
      can get what the CA offers.</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;I don't think there =
is any=20
      realistic scenario where the CA has a </SPAN><SPAN=20
      lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;reason=20
      to offer CRLs both with and without certificates. To offer =
</SPAN><SPAN=20
      lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;this=20
      capability to RP is however not a matter for this protocol. It=20
      </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV =
style=3D"FONT-SIZE: 10pt">&gt;=20
      &gt;would be a matter for the CRL referencing model, i.e. CDP =
and/or=20
      </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV =
style=3D"FONT-SIZE: 10pt">&gt;=20
      &gt;directory schema.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;I don't think that =
extra=20
      complexity however is very useful.</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; =
&gt;Stefan=20
      Santesson</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;Senior Program =
Manager</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;Windows=20
      Security, Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;=20
      -----Original Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; From: =
[email-masked]=20
      [<A href=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> =
</SPAN><SPAN=20
      lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
      [email-masked]] On Behalf Of Denis Pinkas</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; Sent: den=20
      20 december 2006 17:05</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; To: =
[email-masked]</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
      Subject: Re: Certificates in CRLs</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; It is=20
      necessary to provide relying parties with the choice to get =
</SPAN><SPAN=20
      lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
      :</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;&nbsp;&nbsp; - CRLs "as usual", or</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;&nbsp;&nbsp; - CRLs that carry that new extension.</SPAN><SPAN =

      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; The current proposal does =
not allow=20
      for it.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; Until the=20
      draft is changed, I am against the addition of this =
work</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      item</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; to the program of the =
PKIX=20
      WG.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;=20
      Denis</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt;=20
      =
______________________________________________________________________</S=
PAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      _</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; _______</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Since last IETF a new =
draft was=20
      posted:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;<A=20
      =
href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-" =

      =
target=3D_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix-=
vccrl-</A></SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      00.txt</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; &gt;There=20
      is a request to add this draft to the PKIX work and I =
would</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
      encourage to start the discussion about this decision in =
this</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      thread.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; &gt;Stefan=20
      Santesson</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Senior Program=20
      Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Windows Security,=20
      Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV>
  <HR>
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C7505A.A565DAF4--

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: Peter Hesse <[email-masked]>, "'Hallam-Baker, Phillip'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Certificates in CRLs
Date: Wed, 14 Feb 2007 10:03:17 -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_01C75049.4035ADB8
Content-Type: text/plain

I likewise agree with Peter, Phillip and Stefan.  The CRL bloat is not
large, and for those of us with large CRLs to begin with (can debate
separately why that circumstance exists...), the bloat is negligible.  Since
this is entirely optional; and since the owner of a CA therefore has full
discretion to include or not include the certs (and can do as Peter
described and published two virtually contemporaneous CRLs, one with and one
without, if needed to avoid breaking apps), it seems to me that this
approach can be used in a fashion which does not break anything, and it can
provide real value for archival purposes.

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 Peter Hesse
Sent: Wednesday, February 14, 2007 12:05 AM
To: 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan Santesson'; 'Russ
Housley'
Cc: [email-masked]
Subject: RE: Certificates in CRLs

I'm in agreement that Stefan's proposal is a decent one.  As Phillip
mentions, it certainly isn't appropriate in every situation, but I can see
situations in which it might be useful.  One might argue that a CRL issuer
could issue two CRLs, the most commonly retrieved one without this
extension, but a separate one issued with it-the latter being made to
applications responsible for long term archive, historical signature
validation, or other purposes which might find it useful.  

I don't see any harm in adding this extension as an optional feature for
PKIs that wish it, since it is truly optional, non-critical, and does not
affect path processing.  

--Peter

+----------------------------------------------------------------+
| Peter Hesse                      [email-masked]
<mailto:[email-masked]>      |
| Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.  |
|       Visit our InfoSecurity blog: securitymusings.com
<http://www.securitymusings.com/>          |
+----------------------------------------------------------------+
"The generation of random numbers is too important to be left
 to chance." --Robert R. Coveyou

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, February 13, 2007 6:53 PM
To: Sharon Boeyen; Stefan Santesson; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

I think that Sharon's proposal might have been a good idea in 1995 before
the world got wedged on CRLs as the revocation mechanism. We can define a
package but its too late to get it embedded in the rest of the application
infrastructure.

Given where we are Stefan's proposal is the best one. It is compatible with
the existing infrastructure and solves a real issue. 

It is an option, clearly there are cases where it would be inappropriate but
universal applicability has never been a requirement. Otherwise we could
have saved all the time spent on attribute certificates.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sharon Boeyen
Sent: Friday, January 05, 2007 9:09 AM
To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

Stefan I really don't think you can state where this will or will not be
used in the future. Naturally you know where you want to use it, but
software only enables a facility and the customer decides when and how to
use it. 

Whether this scheme could possibly be useful in some cases is not my point.
My point is that current deployments seem to be working fine without it and
I don't want to see those interfered with just because some CA they may have
cross certified with decided to put certificates inside their CRLS. Back to
Denis' point - there is no need to impose this in the way you've proposed. 

Earlier I (and others including Dave Kemp) suggested a "package" that
includes the CRL, and the certificate in question as an 'extra' that a CA
could publish in addition to a regular CRL. That "package could be published
in a separate directory attribute and/or an HTTP accessible file. It could
be pointed to from within the certificate just as the CRL currently is. That
could be done either by extending the CRLDP or adding a new pointer
extension or adding a new method to the AIA extension. That type of approach
gives you what you want but does not in any way interfere with clients who
do not want and do not need to retrieve that bloated CRL. 

Also, you haven't addressed the question about what happens when more than
one certificate is needed. If a CRL includes more than one certificate (e.g.
the CRL issuer did one or more key rollovers then CRL gets bloated a lot
bigger than you suggested. I don't want to debate how often a key gets
rolled over either however I have definitely seen instances in real world
deployments where a key has been rolled very often in a very short period of
time (regardless of whether the reason for rolling it was a good one or not
- it has happened). Also, regardless of the size of the "bloat" I'm saying
that in most cases the clients will already have the certificates in
question and this bloat will cause them extra processing in managing their
certificate caches etc unnecessarily. The client should have a choice as to
whether to download the certificate or not.

I don't understand why you're so opposed to the "package" solution. 

Cheers,

Sharon 

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 8:01 AM
To: Sharon Boeyen; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

BM__MailEndComposeWe are only talking about an extra 16K at most. The
download time is the absolute most cases is negligible. 

For those cases where this solution makes sense, the network bandwidth issue
is not a problem.

For the cases where this would be an issue, this solution would not be used.

On the contrary, in some networks and scenarios, this will improve
performance. Especially in high latency networks with PKI based peer-peer
authentication where an extra retrieval cost way more performance than the
expanded CRL size.

Also, many clients are configured to pre-fetch CRL:s before they are used,
using idle time on the network at no extra cost.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: Sharon Boeyen [mailto:[email-masked]] 
Sent: den 4 januari 2007 17:36
To: Stefan Santesson; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

I still think wasted bandwidth is also an issue. Forcing the download of
'fat' CRLs on clients when, in many cases, those clients already have the
certificates locally that caused the bloating of the CRL, is an unnecessary
waste.

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Stefan Santesson 
Sent: Wednesday, January 03, 2007 9:58 AM 
To: Russ Housley 
Cc: [email-masked] 
Subject: RE: Certificates in CRLs 

Russ, 

In theory, the CA can put different pointers to different CRLs in each
certificate if some certificates are prime targets for frequent checking.
But I don't think that is a common scenario.

My point is that in order to allow free selection of CRLs, you would have to
add capability to the CDP extension rather than to the CRL. I don't think
such effort is worth the trouble.

I'm convinced that including certs in a CRL will only be made in situations
where it in the sum of all, helps increase efficiency and where the extra
bandwidth consumed is not an issue.

I read the critique of this idea as not really be a bandwidth issue, but
that some implementers simply don't want to be faced with the requirement to
implement this feature. But I don't see that they have to. A CRL with certs
in a non-critical extension should work just as well in current clients as
any current CRL without certs. The extension can simply be ignored.

This is not a necessary feature, but a practical one offering performance
improvements in some environments at no loss of interoperability.

Stefan Santesson 
Senior Program Manager 
Windows Security, Standards 

> -----Original Message----- 
> From: Russ Housley [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: den 21 december 2006 16:19 
> To: Stefan Santesson 
> Cc: [email-masked] 
> Subject: RE: Certificates in CRLs 
> 
> Stefan: 
> 
> If the CA chooses to offer both, how can the RP determine which one it 
> will get?  Does the CA post them in different LDAP attributes? 
> 
> Russ 
> 
> At 08:00 AM 12/21/2006, Stefan Santesson wrote: 
> 
> >As with anything else, the relying party can get what the CA offers. 
> > 
> >I don't think there is any realistic scenario where the CA has a 
> >reason to offer CRLs both with and without certificates. To offer 
> >this capability to RP is however not a matter for this protocol. It 
> >would be a matter for the CRL referencing model, i.e. CDP and/or 
> >directory schema. 
> > 
> >I don't think that extra complexity however is very useful. 
> > 
> >Stefan Santesson 
> >Senior Program Manager 
> >Windows Security, Standards 
> > 
> > 
> > > -----Original Message----- 
> > > From: [email-masked] [ mailto:owner-ietf-
<mailto:owner-ietf->  
> > > [email-masked]] On Behalf Of Denis Pinkas 
> > > Sent: den 20 december 2006 17:05 
> > > To: [email-masked] 
> > > Subject: Re: Certificates in CRLs 
> > > 
> > > 
> > > 
> > > It is necessary to provide relying parties with the choice to get 
> > > : 
> > > 
> > >   - CRLs "as usual", or 
> > >   - CRLs that carry that new extension. 
> > > 
> > > The current proposal does not allow for it. 
> > > 
> > > Until the draft is changed, I am against the addition of this work 
> item 
> > > to the program of the PKIX WG. 
> > > 
> > > Denis 
> > > 
> > > 
> ______________________________________________________________________ 
> _ 
> > > _______ 
> > > 
> > > >Since last IETF a new draft was posted: 
> > > > http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-
<http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl->  
> 00.txt 
> > > > 
> > > >There is a request to add this draft to the PKIX work and I would 
> > > encourage to start the discussion about this decision in this 
> thread. 
> > > > 
> > > >Stefan Santesson 
> > > >Senior Program Manager 
> > > >Windows Security, Standards 
> > > 
> > > 
> > > 

------_=_NextPart_001_01C75049.4035ADB8
Content-Type: text/html
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" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D =

"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1587" 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-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal
}
SPAN.EmailStyle19 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D790115814-14022007><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
likewise agree with Peter, Phillip and Stefan.&nbsp; The CRL bloat is =
not large,=20
and for those of us with large CRLs to begin with (can debate =
separately why=20
that circumstance exists...), the bloat is negligible.&nbsp; Since this =
is=20
entirely optional; and since the owner of a CA therefore has full =
discretion to=20
include or not include the certs (and can do as Peter described and =
published=20
two virtually contemporaneous CRLs, one with and one without, if needed =
to avoid=20
breaking apps), it seems to me that this approach can be used in a =
fashion which=20
does not break anything, and it can provide real value for archival=20
purposes.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV><BR>
<P><B><FONT face=3DArial size=3D2>Richard A. Guida</FONT></B> =
<BR><B><FONT=20
face=3DArial size=3D2>Director, Information Security</FONT></B> </P>
<P><B><I><FONT face=3D"Times New Roman" color=3D#ff0000 =
size=3D5>Johnson &amp;=20
Johnson</FONT></I></B><I></I> <BR><FONT face=3DArial size=3D2>Room =
GS8217</FONT>=20
<BR><FONT face=3DArial size=3D2>410 George Street</FONT> <BR><FONT =
face=3DArial=20
size=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT =
face=3DArial=20
size=3D2>Phone:&nbsp; 732 524 3785</FONT> </P>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>Peter=20
  Hesse<BR><B>Sent:</B> Wednesday, February 14, 2007 12:05 =
AM<BR><B>To:</B>=20
  'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan Santesson'; 'Russ=20
  Housley'<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Certificates=20
  in CRLs<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">I&#8217;m=20
  in agreement that Stefan&#8217;s proposal is a decent one.&nbsp; As =
Phillip=20
  mentions, it certainly isn&#8217;t appropriate in every situation, =
but I can see=20
  situations in which it might be useful.&nbsp; One might argue that a =
CRL=20
  issuer could issue two CRLs, the most commonly retrieved one without =
this=20
  extension, but a separate one issued with it&#8212;the latter being =
made to=20
  applications responsible for long term archive, historical signature=20
  validation, or other purposes which might find it useful.&nbsp;=20
  <o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">I=20
  don&#8217;t see any harm in adding this extension as an optional =
feature for PKIs=20
  that wish it, since it is truly optional, non-critical, and does not =
affect=20
  path processing. &nbsp;<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">--Peter<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Courier =
New'">+----------------------------------------------------------------+=
<BR>|&nbsp;</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: #3333cc; FONT-FAMILY: 'Courier =
New'">Peter=20
  Hesse</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: blue"><A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A=
></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: gray">|<BR>|&nbsp;</SPAN><SPAN style=3D"COLOR: =
#3333cc">Phone:=20
  703-378-5808 x105</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: #3333cc">Gemini Security Solutions, =
Inc.&nbsp;&nbsp;</SPAN><SPAN=20
  style=3D"COLOR: =
gray">|<BR>|&nbsp;</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: #3333cc">Visit our InfoSecurity blog: <A=20
  =
href=3D"http://www.securitymusings.com/">securitymusings.com</A></SPAN>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
  style=3D"COLOR: =
gray">|<BR>+------------------------------------------------------------=
----+<BR></SPAN><SPAN=20
  style=3D"COLOR: teal">"The generation of random numbers is too =
important to be=20
  left<BR>&nbsp;to chance." --Robert R. Coveyou</SPAN></SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Hallam-Baker, Phillip<BR><B>Sent:</B> Tuesday, February =
13, 2007=20
  6:53 PM<BR><B>To:</B> Sharon Boeyen; Stefan Santesson; Russ=20
  Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Certificates in=20
  CRLs<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><SPAN lang=3DSV=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">I=20
  think that Sharon's proposal might have been a good idea in 1995 =
before the=20
  world got wedged on CRLs as the revocation mechanism. We can define a =
package=20
  but its too late to get it embedded in the rest of the application=20
  infrastructure.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DSV>&nbsp;<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DSV=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Given=20
  where we are Stefan's proposal is the best one. It is compatible with =
the=20
  existing infrastructure and solves a real issue. </SPAN><SPAN=20
  lang=3DSV><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DSV>&nbsp;<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DSV=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">It is=20
  an option, clearly there are cases where it would be inappropriate =
but=20
  universal applicability has never been a requirement. Otherwise we =
could have=20
  saved all the time spent on attribute certificates.</SPAN><SPAN=20
  lang=3DSV><o:p></o:p></SPAN></P>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in =
5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; =
BORDER-BOTTOM: medium none">
    <P class=3DMsoNormal><SPAN lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter>
    <HR align=3Dcenter width=3D"100%" SIZE=3D2>
    </DIV>
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20
    [email-masked] [mailto:[email-masked]] =
<B>On=20
    Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, January 05, =
2007 9:09=20
    AM<BR><B>To:</B> 'Stefan Santesson'; Sharon Boeyen; Russ=20
    Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Certificates=20
    in CRLs</SPAN><o:p></o:p></P>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
    I really don't think you can state where this will or will not be =
used in=20
    the future. Naturally you know where you want to use it, but =
software only=20
    enables a facility and the customer decides when and how to use it. =

    </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Whether=20
    this scheme could possibly be useful in some cases is not my point. =
My point=20
    is that current deployments seem to be working fine without it and =
I don't=20
    want to see those interfered with just because some CA they may =
have cross=20
    certified with decided to put certificates inside their CRLS. Back =
to Denis'=20
    point - there is no need to impose this in the way you've proposed. =

    </SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Earlier=20
    I (and others including Dave Kemp) suggested a "package" that =
includes the=20
    CRL, and the certificate in question as an 'extra' that a CA could =
publish=20
    in addition to a regular CRL. That "package could be published in a =
separate=20
    directory attribute and/or an HTTP accessible file. It could be =
pointed to=20
    from within the certificate&nbsp;just as the CRL currently is. That =
could be=20
    done either by extending the CRLDP or adding a new&nbsp;pointer =
extension or=20
    adding a new method to the AIA extension. That type of approach =
gives you=20
    what you want but does not in any way interfere with clients who do =
not want=20
    and do not need to retrieve that bloated CRL.&nbsp;</SPAN><SPAN=20
    lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Also,=20
    you haven't addressed the question about&nbsp;what happens =
when&nbsp;more=20
    than one certificate is needed. If a CRL includes more than one=20
    certificate&nbsp;(e.g. the CRL issuer did one or more key=20
    rollovers&nbsp;then CRL gets bloated a lot bigger than you =
suggested.&nbsp;I=20
    don't want to debate how often a key gets rolled over either =
however I have=20
    definitely seen instances in real world deployments where a key has =
been=20
    rolled very often in a very short period of time (regardless of =
whether the=20
    reason for rolling it was a good one or not - it has happened). =
Also,=20
    regardless of the size of the "bloat" I'm saying that in most cases =
the=20
    clients will already have the certificates in question and this =
bloat will=20
    cause them extra processing in managing their certificate caches =
etc=20
    unnecessarily. The client should have a choice as to whether to =
download the=20
    certificate or not.</SPAN><SPAN =
lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">I=20
    don't understand why you're so opposed to the "package"=20
    solution.&nbsp;</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN =
lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">Cheers,</SPAN><SPAN=20
    lang=3DSV><o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-se=
rif'">Sharon</SPAN><SPAN=20
    lang=3DSV>&nbsp;<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN lang=3DSV=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">-----Original=20
    Message-----<BR><B>From:</B> Stefan Santesson =
[mailto:[email-masked]]=20
    <BR><B>Sent:</B> Friday, January 05, 2007 8:01 AM<BR><B>To:</B> =
Sharon=20
    Boeyen; Russ Housley<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B> RE:=20
    Certificates in CRLs<o:p></o:p></SPAN></P></DIV>
    <BLOCKQUOTE=20
      style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><P=20
      class=3DMsoNormal><A name=3D_MailEndCompose><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">We=20
      are only talking about an extra 16K at most. The download time is =
the=20
      absolute most cases is negligible. </SPAN></A><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">For=20
      those cases where this solution makes sense, the network =
bandwidth issue=20
      is not a problem.<o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">For=20
      the cases where this would be an issue, this solution would not =
be=20
      used.<o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">On=20
      the contrary, in some networks and scenarios, this will improve=20
      performance. Especially in high latency networks with PKI based =
peer-peer=20
      authentication where an extra retrieval cost way more performance =
than the=20
      expanded CRL size.<o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Also,=20
      many clients are configured to pre-fetch CRL:s before they are =
used, using=20
      idle time on the network at no extra cost.<o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <DIV>
      <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
      Santesson</SPAN></B><SPAN lang=3DEN-GB=20
      style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
      Program Manager</SPAN><SPAN lang=3DEN-GB=20
      style=3D"COLOR: navy"><o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
      Security, Standards</SPAN></B><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
      <DIV=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; =
BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium =
none">
      <DIV>
      <DIV=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; =
BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; =
BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium =
none">
      <P class=3DMsoNormal><B><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> =
Sharon Boeyen=20
      [mailto:[email-masked]] <BR><B>Sent:</B> den 4 januari =
2007=20
      17:36<BR><B>To:</B> Stefan Santesson; Russ Housley<BR><B>Cc:</B>=20
      [email-masked]<BR><B>Subject:</B> RE: Certificates in=20
      CRLs<o:p></o:p></SPAN></P></DIV></DIV>
      <P class=3DMsoNormal><SPAN lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I still think wasted =
bandwidth is=20
      also an issue. Forcing the download of 'fat' CRLs on clients =
when, in many=20
      cases, those clients already have the certificates locally that =
caused the=20
      bloating of the CRL, is an unnecessary waste.</SPAN><SPAN=20
      lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">-----Original=20
      Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">From: [email-masked] [<A=20
      =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]=20
      On Behalf Of Stefan Santesson</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">Sent: Wednesday, January 03, =
2007 9:58=20
      AM</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">To: Russ Housley</SPAN><SPAN lang=3DSV> =

      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Cc:=20
      [email-masked]</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">Subject: RE: Certificates in =
CRLs</SPAN><SPAN=20
      lang=3DSV> <o:p></o:p></SPAN></P>
      <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN=20
      lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Russ,</SPAN><SPAN =
lang=3DSV>=20
      <o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">In theory, the CA =
can put=20
      different pointers to different CRLs in each certificate if some=20
      certificates are prime targets for frequent checking. But I don't =
think=20
      that is a common scenario.</SPAN><SPAN =
lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">My point is that in =
order to=20
      allow free selection of CRLs, you would have to add capability to =
the CDP=20
      extension rather than to the CRL. I don't think such effort is =
worth the=20
      trouble.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I'm convinced that =
including=20
      certs in a CRL will only be made in situations where it in the =
sum of all,=20
      helps increase efficiency and where the extra bandwidth consumed =
is not an=20
      issue.</SPAN><SPAN lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">I read the critique =
of this idea=20
      as not really be a bandwidth issue, but that some implementers =
simply=20
      don't want to be faced with the requirement to implement this =
feature. But=20
      I don't see that they have to. A CRL with certs in a non-critical =

      extension should work just as well in current clients as any =
current CRL=20
      without certs. The extension can simply be ignored.</SPAN><SPAN=20
      lang=3DSV><o:p></o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">This is not a =
necessary feature,=20
      but a practical one offering performance improvements in some =
environments=20
      at no loss of interoperability.</SPAN><SPAN =
lang=3DSV><o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">Stefan =
Santesson</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">Senior Program=20
      Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">Windows Security, Standards</SPAN><SPAN =
lang=3DSV>=20
      <o:p></o:p></SPAN></P>
      <P class=3DMsoNormal><SPAN lang=3DSV><o:p>&nbsp;</o:p></SPAN></P>
      <P><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; -----Original=20
      Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; From: Russ Housley [<A=20
      =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</S=
PAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; Sent: den=20
      21 december 2006 16:19</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; To: Stefan Santesson</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; Cc:=20
      [email-masked]</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; Subject: RE: Certificates in =
CRLs</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      Stefan:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; If the CA chooses to offer both, =
how can the=20
      RP determine which one it </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; will get?&nbsp; Does the CA post =
them in=20
      different LDAP attributes?</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; Russ</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; At 08:00 AM 12/21/2006, =
Stefan=20
      Santesson wrote:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;As with anything else, the =
relying party=20
      can get what the CA offers.</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;I don't think there =
is any=20
      realistic scenario where the CA has a </SPAN><SPAN=20
      lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;reason=20
      to offer CRLs both with and without certificates. To offer =
</SPAN><SPAN=20
      lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;this=20
      capability to RP is however not a matter for this protocol. It=20
      </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV =
style=3D"FONT-SIZE: 10pt">&gt;=20
      &gt;would be a matter for the CRL referencing model, i.e. CDP =
and/or=20
      </SPAN><SPAN lang=3DSV><BR></SPAN><SPAN lang=3DSV =
style=3D"FONT-SIZE: 10pt">&gt;=20
      &gt;directory schema.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;I don't think that =
extra=20
      complexity however is very useful.</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; =
&gt;Stefan=20
      Santesson</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;Senior Program =
Manager</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;Windows=20
      Security, Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;=20
      -----Original Message-----</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN=
 lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; From: =
[email-masked]=20
      [<A href=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> =
</SPAN><SPAN=20
      lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
      [email-masked]] On Behalf Of Denis Pinkas</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; Sent: den=20
      20 december 2006 17:05</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN =
lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; To: =
[email-masked]</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
      Subject: Re: Certificates in CRLs</SPAN><SPAN lang=3DSV> =
<BR></SPAN><SPAN=20
      lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; It is=20
      necessary to provide relying parties with the choice to get =
</SPAN><SPAN=20
      lang=3DSV><BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
      :</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;&nbsp;&nbsp; - CRLs "as usual", or</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;&nbsp;&nbsp; - CRLs that carry that new =
extension.</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; The current proposal =
does not allow=20
      for it.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; Until the=20
      draft is changed, I am against the addition of this =
work</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      item</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; to the program of the =
PKIX=20
      WG.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;=20
      Denis</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt;=20
      =
______________________________________________________________________</=
SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      _</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; _______</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Since last IETF a =
new draft was=20
      posted:</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;<A=20
      =
href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-"=
=20
      =
target=3D_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix=
-vccrl-</A></SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      00.txt</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; &gt;There=20
      is a request to add this draft to the PKIX work and I =
would</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt; &gt; &gt;=20
      encourage to start the discussion about this decision in =
this</SPAN><SPAN=20
      lang=3DSV> <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: =
10pt">&gt;=20
      thread.</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;</SPAN><SPAN =
lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt; &gt;Stefan=20
      Santesson</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Senior Program=20
      Manager</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Windows Security,=20
      Standards</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      <BR></SPAN><SPAN lang=3DSV style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
      &gt;</SPAN><SPAN lang=3DSV> <BR></SPAN><SPAN lang=3DSV=20
      style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=3DSV>=20
      =
<o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV></BLOCKQUOTE=
></BODY></HTML>

------_=_NextPart_001_01C75049.4035ADB8--

Date: Wed, 14 Feb 2007 07:11:13 -0500
To: "Jonghyun Baek" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Questions on the use case of KeyUsage type in  Key Usage extension
Cc: <[email-masked]>
Sender: [email-masked]

--============_-1040667416==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:47 PM +0900 2/14/07, Jonghyun Baek wrote:
>Dear PKIX WG,
>
>The key usage extension(section 4.2.1.3 in RFC3280)  have nine 
>KeyUsage types such as digitalSignature, non repudiation, 
>keyEncipherment, etc.
>I can understood each of the KeyUsage types meaning but i would like 
>to know a real example or a use case of the encipherOnly type and 
>the decipherOnly type. i mean which kind of the service or 
>application need the encipherOnly or decipherOnly type certificate 
>and for what ?
>I will be so appriciate if you give me a hand.
>
>Thanks!
>
>Jonghyun Baek 

The typical example that has been provided (by others) is a multicast 
application where one wants to enforce encrypt/decrypt only key use 
for subscribers, e.g., most subscribers are authorized to listen 
(decrypt) and only one or a few are authorized to send (encrypt).

Steve
--============_-1040667416==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Questions on the use case of KeyUsage type in 
Key Usa</title></head><body>
<div>At 2:47 PM +0900 2/14/07, Jonghyun Baek wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1">Dear PKIX
WG,</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">The key
usage extension(section&nbsp;4.2.1.3 in&nbsp;RFC3280)&nbsp;&nbsp;have
nine KeyUsage types such as digitalSignature, non repudiation,
keyEncipherment, etc.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I can
understood each of&nbsp;the KeyUsage&nbsp;types meaning but i would
like to know a&nbsp;real example or a&nbsp;use case of the
encipherOnly&nbsp;type and the decipherOnly type. i mean which kind of
the service or application need the encipherOnly or
decipherOnly&nbsp;type certificate and for what ?</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I will be so
appriciate if you give me a hand.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">Thanks!</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Jonghyun
Baek</font><font face="Arial">&nbsp;</font></blockquote>
<div><br></div>
<div>The typical example that has been provided (by others) is a
multicast application where one wants to enforce encrypt/decrypt only
key use for subscribers, e.g., most subscribers are authorized to
listen (decrypt) and only one or a few are authorized to send
(encrypt).</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1040667416==_ma============--

Date: Wed, 14 Feb 2007 11:57:20 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Certificates in CRLs
Sender: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon615448871137_=====
Content-Transfer-Encoding: base64
Content-Type: text/plain;
	charset="iso-8859-1"

--=====003_Dragon615448871137_=====
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1586" name=GENERATOR></HEAD>
<BODY>
<DIV>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">A way 
forward&nbsp;?<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">The key 
issue is not the structure of the “augmented” CRL proposed by Stefan, <BR>but 
the ability to retrieve from a given CA either a CRL (i.e. the current 
<BR>structure of a CRL) or a CRLwithCerts (i.e. the new structure proposed by 
Stefan), <BR>if a CA&nbsp;chooses&nbsp;to issue both. 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">We need 
to focus on the cRLDistributionPoints extension to allow retrieving <BR>either a 
CRL, or a CRLwithCerts, or both.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">Let us 
have a look at some sentences extracted from RFC 
3280:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" size=2>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT 
face="Courier New">==========================================================================<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The cRLDistributionPoints 
extension is a SEQUENCE of<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;</SPAN><SPAN style="mso-spacerun: yes">&nbsp; 
</SPAN>DistributionPoint.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>A 
DistributionPoint consists of three fields,<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>each of which is optional: 
distributionPoint, reasons, and cRLIssuer.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT 
face="Courier New">(…)<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>When the HTTP or FTP scheme is 
specified, the<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>URI MUST point to a single DER 
encoded CRL as specified in [RFC<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>2585].<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>HTTP server implementations accessed via 
the URI SHOULD<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>specify the media type 
application/pkix-crl in the content-type<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>header field of the response.<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>When the LDAP scheme is specified, 
the<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>URI MUST specify a 
distinguishedName and attribute and SHOULD 
specify<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a host name (e.g., 
ldap://ldap.example.com/cn=exmplCA,<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; 
</SPAN>dc=example,dc=com?certificateRevocationList;binary).<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT 
face="Courier New">(…)<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The URI MUST 
include<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>an appropriate attribute 
description for the attribute that holds the<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>DER [X.690] encoded 
CRL.</FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT 
face="Courier New">&nbsp;</FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT 
face="Courier New">==========================================================================<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">A way 
forward would be to define appropriate attribute descriptions for <BR>the 
attributes that holds either the encoded CRL or the encoded CRLwithCerts. <BR>We 
could recommend to use currentCRL and currentCRLwithCerts, or latestCRL <BR>or 
latestCRLwithCerts.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">For HTTTP 
or FTP a new media type could be defined such as 
<BR>application/pkix-crlwithcerts to be used in the content-type header field 
<BR>of the response. <o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">For LDAP, 
the query should end up, for example, with 
CRLwithcerts;binary/<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><FONT size=2><FONT face="Courier New">We could 
also say that if the CA has chosen to issue both types of CRLs, <BR>then every 
distributionPoint holding a CRL (as defined today) should be placed <BR>first in 
the list.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US 
style="mso-ansi-language: EN-US"><o:p><FONT face="Courier New" 
size=2>&nbsp;</FONT></o:p></SPAN></P></DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV class=Section1>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I’m 
in agreement that Stefan’s proposal is a decent one.&nbsp; As Phillip mentions, 
it certainly isn’t appropriate in every situation, but I can see situations in 
which it might be useful.&nbsp; One might argue that a CRL issuer could issue 
two CRLs, the most commonly retrieved one without this extension, but a separate 
one issued with it—the latter being made to applications responsible for long 
term archive, historical signature validation, or other purposes which might 
find it useful.&nbsp; <o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I 
don’t see any harm in adding this extension as an optional feature for PKIs that 
wish it, since it is truly optional, non-critical, and does not affect path 
processing. &nbsp;<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">--Peter<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: 'Courier New'">+----------------------------------------------------------------+<BR>|&nbsp;</SPAN><SPAN 
style="FONT-SIZE: 10pt; COLOR: #3333cc; FONT-FAMILY: 'Courier New'">Peter 
Hesse</SPAN><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN 
style="COLOR: blue"><A 
href="mailto:[email-masked]">[email-masked]</A></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN 
style="COLOR: gray">|<BR>|&nbsp;</SPAN><SPAN style="COLOR: #3333cc">Phone: 
703-378-5808 x105</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN 
style="COLOR: #3333cc">Gemini Security Solutions, Inc.&nbsp;&nbsp;</SPAN><SPAN 
style="COLOR: gray">|<BR>|&nbsp;</SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN 
style="COLOR: #3333cc">Visit our InfoSecurity blog: <A 
href="http://www.securitymusings.com/">securitymusings.com</A></SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN 
style="COLOR: gray">|<BR>+----------------------------------------------------------------+<BR></SPAN><SPAN 
style="COLOR: teal">"The generation of random numbers is too important to be 
left<BR>&nbsp;to chance." --Robert R. Coveyou</SPAN></SPAN><SPAN 
style="FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<DIV>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=MsoNormal><B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> 
[email-masked] [mailto:[email-masked]] <B>On Behalf 
Of </B>Hallam-Baker, Phillip<BR><B>Sent:</B> Tuesday, February 13, 2007 6:53 
PM<BR><B>To:</B> Sharon Boeyen; Stefan Santesson; Russ Housley<BR><B>Cc:</B> 
[email-masked]<BR><B>Subject:</B> RE: Certificates in 
CRLs<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<P class=MsoNormal><SPAN lang=SV 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">I think 
that Sharon's proposal might have been a good idea in 1995 before the world got 
wedged on CRLs as the revocation mechanism. We can define a package but its too 
late to get it embedded in the rest of the application 
infrastructure.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=SV>&nbsp;<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=SV 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Given 
where we are Stefan's proposal is the best one. It is compatible with the 
existing infrastructure and solves a real issue. </SPAN><SPAN 
lang=SV><o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=SV>&nbsp;<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN lang=SV 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">It is an 
option, clearly there are cases where it would be inappropriate but universal 
applicability has never been a requirement. Otherwise we could have saved all 
the time spent on attribute certificates.</SPAN><SPAN 
lang=SV><o:p></o:p></SPAN></P>
<BLOCKQUOTE 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
  <P class=MsoNormal><SPAN lang=SV><o:p>&nbsp;</o:p></SPAN></P>
  <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center>
  <HR align=center width="100%" SIZE=2>
  </DIV>
  <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><B><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> 
  [email-masked] [mailto:[email-masked]] <B>On 
  Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, January 05, 2007 9:09 
  AM<BR><B>To:</B> 'Stefan Santesson'; Sharon Boeyen; Russ Housley<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> RE: Certificates in 
  CRLs</SPAN><o:p></o:p></P>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Stefan 
  I really don't think you can state where this will or will not be used in the 
  future. Naturally you know where you want to use it, but software only enables 
  a facility and the customer decides when and how to use it. </SPAN><SPAN 
  lang=SV><o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV>&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Whether 
  this scheme could possibly be useful in some cases is not my point. My point 
  is that current deployments seem to be working fine without it and I don't 
  want to see those interfered with just because some CA they may have cross 
  certified with decided to put certificates inside their CRLS. Back to Denis' 
  point - there is no need to impose this in the way you've proposed. 
  </SPAN><SPAN lang=SV><o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV>&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Earlier 
  I (and others including Dave Kemp) suggested a "package" that includes the 
  CRL, and the certificate in question as an 'extra' that a CA could publish in 
  addition to a regular CRL. That "package could be published in a separate 
  directory attribute and/or an HTTP accessible file. It could be pointed to 
  from within the certificate&nbsp;just as the CRL currently is. That could be 
  done either by extending the CRLDP or adding a new&nbsp;pointer extension or 
  adding a new method to the AIA extension. That type of approach gives you what 
  you want but does not in any way interfere with clients who do not want and do 
  not need to retrieve that bloated CRL.&nbsp;</SPAN><SPAN 
  lang=SV><o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV>&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Also, 
  you haven't addressed the question about&nbsp;what happens when&nbsp;more than 
  one certificate is needed. If a CRL includes more than one 
  certificate&nbsp;(e.g. the CRL issuer did one or more key rollovers&nbsp;then 
  CRL gets bloated a lot bigger than you suggested.&nbsp;I don't want to debate 
  how often a key gets rolled over either however I have definitely seen 
  instances in real world deployments where a key has been rolled very often in 
  a very short period of time (regardless of whether the reason for rolling it 
  was a good one or not - it has happened). Also, regardless of the size of the 
  "bloat" I'm saying that in most cases the clients will already have the 
  certificates in question and this bloat will cause them extra processing in 
  managing their certificate caches etc unnecessarily. The client should have a 
  choice as to whether to download the certificate or not.</SPAN><SPAN 
  lang=SV><o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV>&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">I 
  don't understand why you're so opposed to the "package" 
  solution.&nbsp;</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV>&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Cheers,</SPAN><SPAN 
  lang=SV><o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN lang=SV 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Arial','sans-serif'">Sharon</SPAN><SPAN 
  lang=SV>&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><SPAN lang=SV 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">-----Original 
  Message-----<BR><B>From:</B> Stefan Santesson [mailto:[email-masked]] 
  <BR><B>Sent:</B> Friday, January 05, 2007 8:01 AM<BR><B>To:</B> Sharon Boeyen; 
  Russ Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: 
  Certificates in CRLs<o:p></o:p></SPAN></P></DIV>
  <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: 0in">
    <P class=MsoNormal><A name=_MailEndCompose><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">We 
    are only talking about an extra 16K at most. The download time is the 
    absolute most cases is negligible. </SPAN></A><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">For 
    those cases where this solution makes sense, the network bandwidth issue is 
    not a problem.<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">For 
    the cases where this would be an issue, this solution would not be 
    used.<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">On 
    the contrary, in some networks and scenarios, this will improve performance. 
    Especially in high latency networks with PKI based peer-peer authentication 
    where an extra retrieval cost way more performance than the expanded CRL 
    size.<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Also, 
    many clients are configured to pre-fetch CRL:s before they are used, using 
    idle time on the network at no extra cost.<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <DIV>
    <P class=MsoNormal><B><SPAN lang=EN-GB 
    style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan 
    Santesson</SPAN></B><SPAN lang=EN-GB 
    style="COLOR: #1f497d"><o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-GB 
    style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Senior 
    Program Manager</SPAN><SPAN lang=EN-GB 
    style="COLOR: navy"><o:p></o:p></SPAN></P>
    <P class=MsoNormal><B><SPAN lang=EN-GB 
    style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows 
    Security, Standards</SPAN></B><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <DIV 
    style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
    <DIV>
    <DIV 
    style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
    <P class=MsoNormal><B><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Sharon Boeyen 
    [mailto:[email-masked]] <BR><B>Sent:</B> den 4 januari 2007 
    17:36<BR><B>To:</B> Stefan Santesson; Russ Housley<BR><B>Cc:</B> 
    [email-masked]<BR><B>Subject:</B> RE: Certificates in 
    CRLs<o:p></o:p></SPAN></P></DIV></DIV>
    <P class=MsoNormal><SPAN lang=SV><o:p>&nbsp;</o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">I still think wasted bandwidth is 
    also an issue. Forcing the download of 'fat' CRLs on clients when, in many 
    cases, those clients already have the certificates locally that caused the 
    bloating of the CRL, is an unnecessary waste.</SPAN><SPAN 
    lang=SV><o:p></o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">-----Original 
    Message-----</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">From: [email-masked] [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>] 
    On Behalf Of Stefan Santesson</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">Sent: Wednesday, January 03, 2007 9:58 
    AM</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">To: 
    Russ Housley</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">Cc: [email-masked]</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">Subject: RE: Certificates 
    in CRLs</SPAN><SPAN lang=SV> <o:p></o:p></SPAN></P>
    <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><SPAN 
    lang=SV><o:p>&nbsp;</o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">Russ,</SPAN><SPAN lang=SV> 
    <o:p></o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">In theory, the CA can put different 
    pointers to different CRLs in each certificate if some certificates are 
    prime targets for frequent checking. But I don't think that is a common 
    scenario.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">My point is that in order to allow 
    free selection of CRLs, you would have to add capability to the CDP 
    extension rather than to the CRL. I don't think such effort is worth the 
    trouble.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">I'm convinced that including certs 
    in a CRL will only be made in situations where it in the sum of all, helps 
    increase efficiency and where the extra bandwidth consumed is not an 
    issue.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">I read the critique of this idea as 
    not really be a bandwidth issue, but that some implementers simply don't 
    want to be faced with the requirement to implement this feature. But I don't 
    see that they have to. A CRL with certs in a non-critical extension should 
    work just as well in current clients as any current CRL without certs. The 
    extension can simply be ignored.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">This is not a necessary feature, 
    but a practical one offering performance improvements in some environments 
    at no loss of interoperability.</SPAN><SPAN lang=SV><o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=SV><o:p>&nbsp;</o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">Stefan Santesson</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">Senior Program 
    Manager</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">Windows Security, Standards</SPAN><SPAN lang=SV> 
    <o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=SV><o:p>&nbsp;</o:p></SPAN></P>
    <P><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; -----Original 
    Message-----</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; From: Russ Housley [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>]</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; Sent: den 21 
    december 2006 16:19</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; To: Stefan Santesson</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; Cc: 
    [email-masked]</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; Subject: RE: Certificates in CRLs</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt;</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; 
    Stefan:</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; If the CA chooses to offer both, how can the RP 
    determine which one it </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; will get?&nbsp; Does the CA post them in 
    different LDAP attributes?</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; Russ</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; At 08:00 AM 12/21/2006, Stefan 
    Santesson wrote:</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt;As with anything else, the relying party 
    can get what the CA offers.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt;I don't think there is any 
    realistic scenario where the CA has a </SPAN><SPAN lang=SV><BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt;reason to offer CRLs both with and 
    without certificates. To offer </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt;this capability to RP is however not a 
    matter for this protocol. It </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt;would be a matter for the CRL referencing 
    model, i.e. CDP and/or </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt;directory schema.</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt;I don't 
    think that extra complexity however is very useful.</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt;Stefan 
    Santesson</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt;Senior Program Manager</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt;Windows Security, 
    Standards</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt;</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; 
    -----Original Message-----</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt; From: [email-masked] 
    [<A href="mailto:owner-ietf-">mailto:owner-ietf-</A> </SPAN><SPAN 
    lang=SV><BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; 
    [email-masked]] On Behalf Of Denis Pinkas</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; Sent: den 20 
    december 2006 17:05</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt; To: [email-masked]</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; 
    Subject: Re: Certificates in CRLs</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; 
    &gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt; It is necessary to provide relying 
    parties with the choice to get </SPAN><SPAN lang=SV><BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt; :</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; 
    &gt;&nbsp;&nbsp; - CRLs "as usual", or</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt;&nbsp;&nbsp; - CRLs that carry 
    that new extension.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; The current proposal does not 
    allow for it.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; Until the draft is changed, I 
    am against the addition of this work</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; item</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; to the 
    program of the PKIX WG.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; Denis</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; 
    &gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; 
    ______________________________________________________________________</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; _</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; 
    _______</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Since last IETF a new 
    draft was posted:</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;<A 
    href="http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-" 
    target=_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-</A></SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; 
    00.txt</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;There is 
    a request to add this draft to the PKIX work and I would</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; 
    encourage to start the discussion about this decision in this</SPAN><SPAN 
    lang=SV> <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; 
    thread.</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Stefan 
    Santesson</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Senior Program 
    Manager</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Windows Security, 
    Standards</SPAN><SPAN lang=SV> <BR></SPAN><SPAN lang=SV 
    style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=SV> <BR></SPAN><SPAN 
    lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN lang=SV> 
    <BR></SPAN><SPAN lang=SV style="FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN><SPAN 
    lang=SV> <o:p></o:p></SPAN></P></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV>
<HR>
</BODY></HTML>

--=====003_Dragon615448871137_=====--

From: "Jonghyun Baek" <[email-masked]>
To: <[email-masked]>
Subject: Questions on the use case of KeyUsage type in  Key Usage extension
Date: Wed, 14 Feb 2007 14:47:24 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01C75047.0A519F90
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_0022_01C75047.0A519F90
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_0022_01C75047.0A519F90--

From: "Peter Hesse" <[email-masked]>
To: "'Hallam-Baker, Phillip'" <[email-masked]>, "'Sharon Boeyen'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Certificates in CRLs
Date: Wed, 14 Feb 2007 00:04:50 -0500
Sender: [email-masked]

This is a multipart message in MIME format.

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

I'm in agreement that Stefan's proposal is a decent one.  As Phillip
mentions, it certainly isn't appropriate in every situation, but I can see
situations in which it might be useful.  One might argue that a CRL issuer
could issue two CRLs, the most commonly retrieved one without this
extension, but a separate one issued with it-the latter being made to
applications responsible for long term archive, historical signature
validation, or other purposes which might find it useful.  

I don't see any harm in adding this extension as an optional feature for
PKIs that wish it, since it is truly optional, non-critical, and does not
affect path processing.  

--Peter

+----------------------------------------------------------------+
| Peter Hesse                     [email-masked]     |
| Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.  |
|       Visit our InfoSecurity blog: securitymusings.com
<http://www.securitymusings.com/>          |
+----------------------------------------------------------------+
"The generation of random numbers is too important to be left
 to chance." --Robert R. Coveyou

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, February 13, 2007 6:53 PM
To: Sharon Boeyen; Stefan Santesson; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

I think that Sharon's proposal might have been a good idea in 1995 before
the world got wedged on CRLs as the revocation mechanism. We can define a
package but its too late to get it embedded in the rest of the application
infrastructure.

Given where we are Stefan's proposal is the best one. It is compatible with
the existing infrastructure and solves a real issue. 

It is an option, clearly there are cases where it would be inappropriate but
universal applicability has never been a requirement. Otherwise we could
have saved all the time spent on attribute certificates.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sharon Boeyen
Sent: Friday, January 05, 2007 9:09 AM
To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

Stefan I really don't think you can state where this will or will not be
used in the future. Naturally you know where you want to use it, but
software only enables a facility and the customer decides when and how to
use it. 

Whether this scheme could possibly be useful in some cases is not my point.
My point is that current deployments seem to be working fine without it and
I don't want to see those interfered with just because some CA they may have
cross certified with decided to put certificates inside their CRLS. Back to
Denis' point - there is no need to impose this in the way you've proposed. 

Earlier I (and others including Dave Kemp) suggested a "package" that
includes the CRL, and the certificate in question as an 'extra' that a CA
could publish in addition to a regular CRL. That "package could be published
in a separate directory attribute and/or an HTTP accessible file. It could
be pointed to from within the certificate just as the CRL currently is. That
could be done either by extending the CRLDP or adding a new pointer
extension or adding a new method to the AIA extension. That type of approach
gives you what you want but does not in any way interfere with clients who
do not want and do not need to retrieve that bloated CRL. 

Also, you haven't addressed the question about what happens when more than
one certificate is needed. If a CRL includes more than one certificate (e.g.
the CRL issuer did one or more key rollovers then CRL gets bloated a lot
bigger than you suggested. I don't want to debate how often a key gets
rolled over either however I have definitely seen instances in real world
deployments where a key has been rolled very often in a very short period of
time (regardless of whether the reason for rolling it was a good one or not
- it has happened). Also, regardless of the size of the "bloat" I'm saying
that in most cases the clients will already have the certificates in
question and this bloat will cause them extra processing in managing their
certificate caches etc unnecessarily. The client should have a choice as to
whether to download the certificate or not.

I don't understand why you're so opposed to the "package" solution. 

Cheers,

Sharon 

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 8:01 AM
To: Sharon Boeyen; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

We are only talking about an extra 16K at most. The download time is the
absolute most cases is negligible. 

For those cases where this solution makes sense, the network bandwidth issue
is not a problem.

For the cases where this would be an issue, this solution would not be used.

On the contrary, in some networks and scenarios, this will improve
performance. Especially in high latency networks with PKI based peer-peer
authentication where an extra retrieval cost way more performance than the
expanded CRL size.

Also, many clients are configured to pre-fetch CRL:s before they are used,
using idle time on the network at no extra cost.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: Sharon Boeyen [mailto:[email-masked]] 
Sent: den 4 januari 2007 17:36
To: Stefan Santesson; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

I still think wasted bandwidth is also an issue. Forcing the download of
'fat' CRLs on clients when, in many cases, those clients already have the
certificates locally that caused the bloating of the CRL, is an unnecessary
waste.

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson 
Sent: Wednesday, January 03, 2007 9:58 AM 
To: Russ Housley 
Cc: [email-masked] 
Subject: RE: Certificates in CRLs 

Russ, 

In theory, the CA can put different pointers to different CRLs in each
certificate if some certificates are prime targets for frequent checking.
But I don't think that is a common scenario.

My point is that in order to allow free selection of CRLs, you would have to
add capability to the CDP extension rather than to the CRL. I don't think
such effort is worth the trouble.

I'm convinced that including certs in a CRL will only be made in situations
where it in the sum of all, helps increase efficiency and where the extra
bandwidth consumed is not an issue.

I read the critique of this idea as not really be a bandwidth issue, but
that some implementers simply don't want to be faced with the requirement to
implement this feature. But I don't see that they have to. A CRL with certs
in a non-critical extension should work just as well in current clients as
any current CRL without certs. The extension can simply be ignored.

This is not a necessary feature, but a practical one offering performance
improvements in some environments at no loss of interoperability.

Stefan Santesson 
Senior Program Manager 
Windows Security, Standards 

> -----Original Message----- 
> From: Russ Housley [mailto:[email-masked]] 
> Sent: den 21 december 2006 16:19 
> To: Stefan Santesson 
> Cc: [email-masked] 
> Subject: RE: Certificates in CRLs 
> 
> Stefan: 
> 
> If the CA chooses to offer both, how can the RP determine which one it 
> will get?  Does the CA post them in different LDAP attributes? 
> 
> Russ 
> 
> At 08:00 AM 12/21/2006, Stefan Santesson wrote: 
> 
> >As with anything else, the relying party can get what the CA offers. 
> > 
> >I don't think there is any realistic scenario where the CA has a 
> >reason to offer CRLs both with and without certificates. To offer 
> >this capability to RP is however not a matter for this protocol. It 
> >would be a matter for the CRL referencing model, i.e. CDP and/or 
> >directory schema. 
> > 
> >I don't think that extra complexity however is very useful. 
> > 
> >Stefan Santesson 
> >Senior Program Manager 
> >Windows Security, Standards 
> > 
> > 
> > > -----Original Message----- 
> > > From: [email-masked] [mailto:owner-ietf- 
> > > [email-masked]] On Behalf Of Denis Pinkas 
> > > Sent: den 20 december 2006 17:05 
> > > To: [email-masked] 
> > > Subject: Re: Certificates in CRLs 
> > > 
> > > 
> > > 
> > > It is necessary to provide relying parties with the choice to get 
> > > : 
> > > 
> > >   - CRLs "as usual", or 
> > >   - CRLs that carry that new extension. 
> > > 
> > > The current proposal does not allow for it. 
> > > 
> > > Until the draft is changed, I am against the addition of this work 
> item 
> > > to the program of the PKIX WG. 
> > > 
> > > Denis 
> > > 
> > > 
> ______________________________________________________________________ 
> _ 
> > > _______ 
> > > 
> > > >Since last IETF a new draft was posted: 
> > > >http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl- 
> 00.txt 
> > > > 
> > > >There is a request to add this draft to the PKIX work and I would 
> > > encourage to start the discussion about this decision in this 
> thread. 
> > > > 
> > > >Stefan Santesson 
> > > >Senior Program Manager 
> > > >Windows Security, Standards 
> > > 
> > > 
> > > 

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-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-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.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/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.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/XMLSchema-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.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	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=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I&#8217;m in agreement that Stefan&#8217;s proposal is a =
decent
one.&nbsp; As Phillip mentions, it certainly isn&#8217;t appropriate in =
every
situation, but I can see situations in which it might be useful.&nbsp; =
One might
argue that a CRL issuer could issue two CRLs, the most commonly =
retrieved one
without this extension, but a separate one issued with it&#8212;the =
latter being
made to applications responsible for long term archive, historical =
signature
validation, or other purposes which might find it useful.&nbsp; =
<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I don&#8217;t see any harm in adding this extension as an
optional feature for PKIs that wish it, since it is truly optional, =
non-critical,
and does not affect path processing. &nbsp;<o:p></o:p></span></p>

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

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

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

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:gray'>+------------------------------------------------------------=
----+<br>
|&nbsp;</span><span style=3D'font-size:10.0pt;font-family:"Courier New";
color:#3333CC'>Peter Hesse</span><span =
style=3D'font-size:10.0pt;font-family:
"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
style=3D'color:blue'><a =
href=3D"mailto:[email-masked]">[email-masked]</a>=
</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
style=3D'color:gray'>|<br>
|&nbsp;</span><span style=3D'color:#3333CC'>Phone: 703-378-5808 =
x105</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
style=3D'color:#3333CC'>Gemini Security Solutions, =
Inc.&nbsp;&nbsp;</span><span
style=3D'color:gray'>|<br>
|&nbsp;</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
style=3D'color:#3333CC'>Visit
our InfoSecurity blog: <a =
href=3D"http://www.securitymusings.com/">securitymusings.com</a></span>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
style=3D'color:gray'>|<br>
+----------------------------------------------------------------+<br>
</span><span style=3D'color:teal'>&quot;The generation of random numbers =
is too
important to be left<br>
&nbsp;to chance.&quot; --Robert R. Coveyou</span></span><span =
style=3D'font-size:
10.0pt'><o:p></o:p></span></p>

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

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

<div>

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

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On =
Behalf
Of </b>Hallam-Baker, Phillip<br>
<b>Sent:</b> Tuesday, February 13, 2007 6:53 PM<br>
<b>To:</b> Sharon Boeyen; Stefan Santesson; Russ Housley<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> RE: Certificates in CRLs<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>I think that Sharon's proposal might have been a good idea =
in 1995
before the world got wedged on CRLs as the revocation mechanism. We can =
define
a package but its too late to get it embedded in the rest of the =
application
infrastructure.</span><span lang=3DSV><o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Given where we are Stefan's proposal is the best one. It is
compatible with the existing infrastructure and solves a real issue. =
</span><span
lang=3DSV><o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>It is an option, clearly there are cases where it would be
inappropriate but universal applicability has never been a requirement.
Otherwise we could have saved all the time spent on attribute =
certificates.</span><span
lang=3DSV><o:p></o:p></span></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Sharon =
Boeyen<br>
<b>Sent:</b> Friday, January 05, 2007 9:09 AM<br>
<b>To:</b> 'Stefan Santesson'; Sharon Boeyen; Russ Housley<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> RE: Certificates in CRLs</span><o:p></o:p></p>

<div>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Stefan I really don't think you can state where this will or =
will
not be used in the future. Naturally you know where you want to use it, =
but
software only enables a facility and the customer decides when and how =
to use
it. </span><span lang=3DSV><o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Whether this scheme could possibly be useful in some cases =
is not
my point. My point is that current deployments seem to be working fine =
without
it and I don't want to see those interfered with just because some CA =
they may
have cross certified with decided to put certificates inside their CRLS. =
Back
to Denis' point - there is no need to impose this in the way you've =
proposed. </span><span
lang=3DSV><o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Earlier I (and others including Dave Kemp) suggested a
&quot;package&quot; that includes the CRL, and the certificate in =
question as
an 'extra' that a CA could publish in addition to a regular CRL. That
&quot;package could be published in a separate directory attribute =
and/or an
HTTP accessible file. It could be pointed to from within the
certificate&nbsp;just as the CRL currently is. That could be done either =
by
extending the CRLDP or adding a new&nbsp;pointer extension or adding a =
new
method to the AIA extension. That type of approach gives you what you =
want but
does not in any way interfere with clients who do not want and do not =
need to
retrieve that bloated CRL.&nbsp;</span><span =
lang=3DSV><o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Also, you haven't addressed the question about&nbsp;what =
happens
when&nbsp;more than one certificate is needed. If a CRL includes more =
than one
certificate&nbsp;(e.g. the CRL issuer did one or more key =
rollovers&nbsp;then
CRL gets bloated a lot bigger than you suggested.&nbsp;I don't want to =
debate
how often a key gets rolled over either however I have definitely seen
instances in real world deployments where a key has been rolled very =
often in a
very short period of time (regardless of whether the reason for rolling =
it was
a good one or not - it has happened). Also, regardless of the size of =
the
&quot;bloat&quot; I'm saying that in most cases the clients will already =
have
the certificates in question and this bloat will cause them extra =
processing in
managing their certificate caches etc unnecessarily. The client should =
have a
choice as to whether to download the certificate or not.</span><span =
lang=3DSV><o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>I don't understand why you're so opposed to the =
&quot;package&quot;
solution.&nbsp;</span><span lang=3DSV><o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Cheers,</span><span lang=3DSV><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Sharon</span><span lang=3DSV>&nbsp;<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span lang=3DSV =
style=3D'font-size:
10.0pt;font-family:"Tahoma","sans-serif"'>-----Original Message-----<br>
<b>From:</b> Stefan Santesson [mailto:[email-masked]] <br>
<b>Sent:</b> Friday, January 05, 2007 8:01 AM<br>
<b>To:</b> Sharon Boeyen; Russ Housley<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> RE: Certificates in CRLs<o:p></o:p></span></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>We are only talking =
about an
extra 16K at most. The download time is the absolute most cases is =
negligible. </span></a><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>For those cases where this solution makes sense, the =
network
bandwidth issue is not a problem.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>For the cases where this would be an issue, this solution =
would
not be used.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>On the contrary, in some networks and scenarios, this =
will
improve performance. Especially in high latency networks with PKI based
peer-peer authentication where an extra retrieval cost way more =
performance
than the expanded CRL size.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Also, many clients are configured to pre-fetch CRL:s =
before they
are used, using idle time on the network at no extra =
cost.<o:p></o:p></span></p>

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

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

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span =
lang=3DEN-GB
style=3D'color:#1F497D'><o:p></o:p></span></p>

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

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

</div>

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

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

<div>

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

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Sharon =
Boeyen
[mailto:[email-masked]] <br>
<b>Sent:</b> den 4 januari 2007 17:36<br>
<b>To:</b> Stefan Santesson; Russ Housley<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> RE: Certificates in CRLs<o:p></o:p></span></p>

</div>

</div>

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

<p><span lang=3DSV style=3D'font-size:10.0pt'>I still think wasted =
bandwidth is
also an issue. Forcing the download of 'fat' CRLs on clients when, in =
many
cases, those clients already have the certificates locally that caused =
the
bloating of the CRL, is an unnecessary waste.</span><span =
lang=3DSV><o:p></o:p></span></p>

<p><span lang=3DSV style=3D'font-size:10.0pt'>-----Original =
Message-----</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>From:
[email-masked] [<a =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
On Behalf Of Stefan Santesson</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>Sent: Wednesday, =
January 03, 2007
9:58 AM</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>To: Russ =
Housley</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>Cc: =
[email-masked]</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>Subject: RE: =
Certificates in CRLs</span><span
lang=3DSV> <o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
lang=3DSV><o:p>&nbsp;</o:p></span></p>

<p><span lang=3DSV style=3D'font-size:10.0pt'>Russ,</span><span =
lang=3DSV> <o:p></o:p></span></p>

<p><span lang=3DSV style=3D'font-size:10.0pt'>In theory, the CA can put =
different
pointers to different CRLs in each certificate if some certificates are =
prime
targets for frequent checking. But I don't think that is a common =
scenario.</span><span
lang=3DSV><o:p></o:p></span></p>

<p><span lang=3DSV style=3D'font-size:10.0pt'>My point is that in order =
to allow
free selection of CRLs, you would have to add capability to the CDP =
extension
rather than to the CRL. I don't think such effort is worth the =
trouble.</span><span
lang=3DSV><o:p></o:p></span></p>

<p><span lang=3DSV style=3D'font-size:10.0pt'>I'm convinced that =
including certs in
a CRL will only be made in situations where it in the sum of all, helps
increase efficiency and where the extra bandwidth consumed is not an =
issue.</span><span
lang=3DSV><o:p></o:p></span></p>

<p><span lang=3DSV style=3D'font-size:10.0pt'>I read the critique of =
this idea as
not really be a bandwidth issue, but that some implementers simply don't =
want
to be faced with the requirement to implement this feature. But I don't =
see
that they have to. A CRL with certs in a non-critical extension should =
work
just as well in current clients as any current CRL without certs. The =
extension
can simply be ignored.</span><span lang=3DSV><o:p></o:p></span></p>

<p><span lang=3DSV style=3D'font-size:10.0pt'>This is not a necessary =
feature, but
a practical one offering performance improvements in some environments =
at no
loss of interoperability.</span><span lang=3DSV><o:p></o:p></span></p>

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

<p><span lang=3DSV style=3D'font-size:10.0pt'>Stefan =
Santesson</span><span lang=3DSV>
<br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>Senior Program =
Manager</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>Windows Security, =
Standards</span><span
lang=3DSV> <o:p></o:p></span></p>

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

<p><span lang=3DSV style=3D'font-size:10.0pt'>&gt; -----Original =
Message-----</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; From: Russ =
Housley [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]</sp=
an><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; Sent: den 21 =
december 2006
16:19</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; To: Stefan =
Santesson</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; Cc: =
[email-masked]</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; Subject: RE: =
Certificates in
CRLs</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; =
Stefan:</span><span lang=3DSV>
<br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; If the CA chooses =
to offer
both, how can the RP determine which one it </span><span lang=3DSV><br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; will get?&nbsp; =
Does the CA
post them in different LDAP attributes?</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; Russ</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; At 08:00 AM =
12/21/2006,
Stefan Santesson wrote:</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;As with =
anything else,
the relying party can get what the CA offers.</span><span lang=3DSV> =
<br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;I don't think =
there is
any realistic scenario where the CA has a </span><span lang=3DSV><br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;reason to =
offer CRLs
both with and without certificates. To offer </span><span lang=3DSV><br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;this =
capability to RP is
however not a matter for this protocol. It </span><span lang=3DSV><br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;would be a =
matter for
the CRL referencing model, i.e. CDP and/or </span><span lang=3DSV><br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;directory =
schema.</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;I don't think =
that extra
complexity however is very useful.</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;Stefan =
Santesson</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;Senior =
Program Manager</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;Windows =
Security,
Standards</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt;</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
-----Original
Message-----</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; From: =
[email-masked]
[<a href=3D"mailto:owner-ietf-">mailto:owner-ietf-</a> </span><span =
lang=3DSV><br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
[email-masked]]
On Behalf Of Denis Pinkas</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; Sent: =
den 20
december 2006 17:05</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; To:
[email-masked]</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
Subject: Re:
Certificates in CRLs</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; It is =
necessary to
provide relying parties with the choice to get </span><span =
lang=3DSV><br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
:</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;&nbsp;&nbsp; - CRLs
&quot;as usual&quot;, or</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;&nbsp;&nbsp; - CRLs
that carry that new extension.</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; The =
current
proposal does not allow for it.</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; Until =
the draft is
changed, I am against the addition of this work</span><span lang=3DSV> =
<br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; item</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; to the =
program of
the PKIX WG.</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
Denis</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt;
______________________________________________________________________</s=
pan><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; _</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
_______</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
&gt;Since last
IETF a new draft was posted:</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; &gt;<a
href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-"
target=3D"_blank">http://www.ietf.org/internet-drafts/draft-santesson-pki=
x-vccrl-</a></span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; =
00.txt</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
&gt;There is a
request to add this draft to the PKIX work and I would</span><span =
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
encourage to start
the discussion about this decision in this</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; =
thread.</span><span lang=3DSV>
<br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
&gt;Stefan
Santesson</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
&gt;Senior Program
Manager</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; &gt; =
&gt;Windows
Security, Standards</span><span lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <br>
</span><span lang=3DSV style=3D'font-size:10.0pt'>&gt; &gt; =
&gt;</span><span
lang=3DSV> <o:p></o:p></span></p>

</div>

</blockquote>

</blockquote>

</div>

</body>

</html>

------=_NextPart_000_001C_01C74FCB.C0BDAD40--

Date: Tue, 13 Feb 2007 17:35:55 -0800
To: Milan Sova <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: URN in subjectAltName
Sender: [email-masked]

At 12:02 AM +0100 2/13/07, Milan Sova wrote:
>	As the group does not seem to have a strong opinion of the choices I
>propose to include the following text just after the URI part of the
>section 4.2.1.6  Subject Alternative Name:
>
>"When the subjectAltName extension contains a URN, the name MUST be
>stored in the uniformResourceIdentifier (IA5String).  The name MUST
>follow the URN syntax and encoding rules specified in [RFC 2141]."
>
>	Comments?

This seems like a good addition, seeing as there were multiple 
choices given on the mailing list, and that means interoperability 
issues. Note that there are two paragraphs to the "URI part"; this 
should be added after the second paragraph, just before "When the 
subjectAltName extension contains a DN...".

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Certificates in CRLs
Date: Tue, 13 Feb 2007 15:52:36 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

I think that Sharon's proposal might have been a good idea in 1995 =
before the world got wedged on CRLs as the revocation mechanism. We can =
define a package but its too late to get it embedded in the rest of the =
application infrastructure.
=20
Given where we are Stefan's proposal is the best one. It is compatible =
with the existing infrastructure and solves a real issue.=20
=20
It is an option, clearly there are cases where it would be inappropriate =
but universal applicability has never been a requirement. Otherwise we =
could have saved all the time spent on attribute certificates.

________________________________

	From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Sharon Boeyen
	Sent: Friday, January 05, 2007 9:09 AM
	To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley
	Cc: [email-masked]
	Subject: RE: Certificates in CRLs
=09
=09
	Stefan I really don't think you can state where this will or will not =
be used in the future. Naturally you know where you want to use it, but =
software only enables a facility and the customer decides when and how =
to use it.=20
	=20
	Whether this scheme could possibly be useful in some cases is not my =
point. My point is that current deployments seem to be working fine =
without it and I don't want to see those interfered with just because =
some CA they may have cross certified with decided to put certificates =
inside their CRLS. Back to Denis' point - there is no need to impose =
this in the way you've proposed.=20
	=20
	Earlier I (and others including Dave Kemp) suggested a "package" that =
includes the CRL, and the certificate in question as an 'extra' that a =
CA could publish in addition to a regular CRL. That "package could be =
published in a separate directory attribute and/or an HTTP accessible =
file. It could be pointed to from within the certificate just as the CRL =
currently is. That could be done either by extending the CRLDP or adding =
a new pointer extension or adding a new method to the AIA extension. =
That type of approach gives you what you want but does not in any way =
interfere with clients who do not want and do not need to retrieve that =
bloated CRL.=20
	=20
	Also, you haven't addressed the question about what happens when more =
than one certificate is needed. If a CRL includes more than one =
certificate (e.g. the CRL issuer did one or more key rollovers then CRL =
gets bloated a lot bigger than you suggested. I don't want to debate how =
often a key gets rolled over either however I have definitely seen =
instances in real world deployments where a key has been rolled very =
often in a very short period of time (regardless of whether the reason =
for rolling it was a good one or not - it has happened). Also, =
regardless of the size of the "bloat" I'm saying that in most cases the =
clients will already have the certificates in question and this bloat =
will cause them extra processing in managing their certificate caches =
etc unnecessarily. The client should have a choice as to whether to =
download the certificate or not.
	=20
	I don't understand why you're so opposed to the "package" solution.=20
	=20
	Cheers,
	Sharon=20
	-----Original Message-----
	From: Stefan Santesson [mailto:[email-masked]]=20
	Sent: Friday, January 05, 2007 8:01 AM
	To: Sharon Boeyen; Russ Housley
	Cc: [email-masked]
	Subject: RE: Certificates in CRLs
=09
=09

		We are only talking about an extra 16K at most. The download time is =
the absolute most cases is negligible.=20

		For those cases where this solution makes sense, the network bandwidth =
issue is not a problem.

		=20

		For the cases where this would be an issue, this solution would not be =
used.

		=20

		On the contrary, in some networks and scenarios, this will improve =
performance. Especially in high latency networks with PKI based =
peer-peer authentication where an extra retrieval cost way more =
performance than the expanded CRL size.

		=20

		Also, many clients are configured to pre-fetch CRL:s before they are =
used, using idle time on the network at no extra cost.

		=20

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

		=20

		From: Sharon Boeyen [mailto:[email-masked]]=20
		Sent: den 4 januari 2007 17:36
		To: Stefan Santesson; Russ Housley
		Cc: [email-masked]
		Subject: RE: Certificates in CRLs

		=20

		I still think wasted bandwidth is also an issue. Forcing the download =
of 'fat' CRLs on clients when, in many cases, those clients already have =
the certificates locally that caused the bloating of the CRL, is an =
unnecessary waste.

		-----Original Message-----=20
		From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Stefan Santesson=20
		Sent: Wednesday, January 03, 2007 9:58 AM=20
		To: Russ Housley=20
		Cc: [email-masked]=20
		Subject: RE: Certificates in CRLs=20

		=20

		Russ,=20

		In theory, the CA can put different pointers to different CRLs in each =
certificate if some certificates are prime targets for frequent =
checking. But I don't think that is a common scenario.

		My point is that in order to allow free selection of CRLs, you would =
have to add capability to the CDP extension rather than to the CRL. I =
don't think such effort is worth the trouble.

		I'm convinced that including certs in a CRL will only be made in =
situations where it in the sum of all, helps increase efficiency and =
where the extra bandwidth consumed is not an issue.

		I read the critique of this idea as not really be a bandwidth issue, =
but that some implementers simply don't want to be faced with the =
requirement to implement this feature. But I don't see that they have =
to. A CRL with certs in a non-critical extension should work just as =
well in current clients as any current CRL without certs. The extension =
can simply be ignored.

		This is not a necessary feature, but a practical one offering =
performance improvements in some environments at no loss of =
interoperability.

		=20

		Stefan Santesson=20
		Senior Program Manager=20
		Windows Security, Standards=20

		=20

		> -----Original Message-----=20
		> From: Russ Housley [mailto:[email-masked]]=20
		> Sent: den 21 december 2006 16:19=20
		> To: Stefan Santesson=20
		> Cc: [email-masked]=20
		> Subject: RE: Certificates in CRLs=20
		>=20
		> Stefan:=20
		>=20
		> If the CA chooses to offer both, how can the RP determine which one =
it=20
		> will get?  Does the CA post them in different LDAP attributes?=20
		>=20
		> Russ=20
		>=20
		> At 08:00 AM 12/21/2006, Stefan Santesson wrote:=20
		>=20
		> >As with anything else, the relying party can get what the CA =
offers.=20
		> >=20
		> >I don't think there is any realistic scenario where the CA has a=20
		> >reason to offer CRLs both with and without certificates. To offer=20
		> >this capability to RP is however not a matter for this protocol. It =

		> >would be a matter for the CRL referencing model, i.e. CDP and/or=20
		> >directory schema.=20
		> >=20
		> >I don't think that extra complexity however is very useful.=20
		> >=20
		> >Stefan Santesson=20
		> >Senior Program Manager=20
		> >Windows Security, Standards=20
		> >=20
		> >=20
		> > > -----Original Message-----=20
		> > > From: [email-masked] [mailto:owner-ietf-=20
		> > > [email-masked]] On Behalf Of Denis Pinkas=20
		> > > Sent: den 20 december 2006 17:05=20
		> > > To: [email-masked]=20
		> > > Subject: Re: Certificates in CRLs=20
		> > >=20
		> > >=20
		> > >=20
		> > > It is necessary to provide relying parties with the choice to =
get=20
		> > > :=20
		> > >=20
		> > >   - CRLs "as usual", or=20
		> > >   - CRLs that carry that new extension.=20
		> > >=20
		> > > The current proposal does not allow for it.=20
		> > >=20
		> > > Until the draft is changed, I am against the addition of this =
work=20
		> item=20
		> > > to the program of the PKIX WG.=20
		> > >=20
		> > > Denis=20
		> > >=20
		> > >=20
		> =
______________________________________________________________________=20
		> _=20
		> > > _______=20
		> > >=20
		> > > >Since last IETF a new draft was posted:=20
		> > > >http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl- =

		> 00.txt=20
		> > > >=20
		> > > >There is a request to add this draft to the PKIX work and I =
would=20
		> > > encourage to start the discussion about this decision in this=20
		> thread.=20
		> > > >=20
		> > > >Stefan Santesson=20
		> > > >Senior Program Manager=20
		> > > >Windows Security, Standards=20
		> > >=20
		> > >=20
		> > >=20

------_=_NextPart_001_01C74FCA.09741062
Content-Type: text/html;
	charset="iso-8859-1"
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" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types"><HEAD><TITLE>=
Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: =
"Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
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 vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I think that Sharon's proposal might have been =
a good idea=20
in 1995 before the world got wedged on CRLs as the revocation mechanism. =
We can=20
define a package but its too late to get it embedded in the rest of the=20
application infrastructure.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Given where we are Stefan's proposal is the =
best one. It is=20
compatible with the existing infrastructure and solves a real issue.=20
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D105122723-13022007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>It is an option, clearly there are cases where =
it would be=20
inappropriate but universal applicability has never been a requirement.=20
Otherwise we could have saved all the time spent on attribute=20
certificates.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=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>Sharon=20
  Boeyen<BR><B>Sent:</B> Friday, January 05, 2007 9:09 AM<BR><B>To:</B> =
'Stefan=20
  Santesson'; Sharon Boeyen; Russ Housley<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> RE: Certificates in=20
  CRLs<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Stefan I really don't think you can state where this will or =
will not=20
  be used in the future. Naturally you know where you want to use it, =
but=20
  software only enables a facility and the customer decides when and how =
to use=20
  it. </FONT></SPAN></DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Whether this scheme could possibly be useful in some cases is =
not my=20
  point. My point is that current deployments seem to be working fine =
without it=20
  and I don't want to see those interfered with just because some CA =
they may=20
  have cross certified with decided to put certificates inside their =
CRLS. Back=20
  to Denis' point - there is no need to impose this in the way you've =
proposed.=20
  </FONT></SPAN></DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Earlier I (and others including Dave Kemp) suggested a =
"package" that=20
  includes the CRL, and the certificate in question as an 'extra' that a =
CA=20
  could publish in addition to a regular CRL. That "package could be =
published=20
  in a separate directory attribute and/or an HTTP accessible file. It =
could be=20
  pointed to from within the certificate&nbsp;just as the CRL currently =
is. That=20
  could be done either by extending the CRLDP or adding a =
new&nbsp;pointer=20
  extension or adding a new method to the AIA extension. That type of =
approach=20
  gives you what you want but does not in any way interfere with clients =
who do=20
  not want and do not need to retrieve that bloated=20
  CRL.&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Also, you haven't addressed the question about&nbsp;what =
happens=20
  when&nbsp;more than one certificate is needed. If a CRL includes more =
than one=20
  certificate&nbsp;(e.g. the CRL issuer did one or more key =
rollovers&nbsp;then=20
  CRL gets bloated a lot bigger than you suggested.&nbsp;I don't want to =
debate=20
  how often a key gets rolled over either however I have definitely seen =

  instances in real world deployments where a key has been rolled very =
often in=20
  a very short period of time (regardless of whether the reason for =
rolling it=20
  was a good one or not - it has happened). Also, regardless of the size =
of the=20
  "bloat" I'm saying that in most cases the clients will already have =
the=20
  certificates in question and this bloat will cause them extra =
processing in=20
  managing their certificate caches etc unnecessarily. The client should =
have a=20
  choice as to whether to download the certificate or =
not.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  don't understand why you're so opposed to the "package"=20
  solution.&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Cheers,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D427185713-05012007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Sharon</FONT>&nbsp;</SPAN></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
  Stefan Santesson [mailto:[email-masked]] <BR><B>Sent:</B> =
Friday,=20
  January 05, 2007 8:01 AM<BR><B>To:</B> Sharon Boeyen; Russ=20
  Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Certificates in=20
  CRLs<BR><BR></DIV></FONT>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DSection1>
    <P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">We=20
    are only talking about an extra 16K at most. The download time is =
the=20
    absolute most cases is negligible. <o:p></o:p></SPAN></A></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">For=20
    those cases where this solution makes sense, the network bandwidth =
issue is=20
    not a problem.<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">For=20
    the cases where this would be an issue, this solution would not be=20
    used.<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">On=20
    the contrary, in some networks and scenarios, this will improve =
performance.=20
    Especially in high latency networks with PKI based peer-peer =
authentication=20
    where an extra retrieval cost way more performance than the expanded =
CRL=20
    size.<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Also,=20
    many clients are configured to pre-fetch CRL:s before they are used, =
using=20
    idle time on the network at no extra cost.<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <DIV>
    <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
    Santesson</SPAN></B><SPAN lang=3DEN-GB=20
    style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
    Program Manager</SPAN><SPAN lang=3DEN-GB=20
    style=3D"COLOR: navy"><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
    Security, Standards</SPAN></B><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV>
    <P class=3DMsoNormal><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <DIV=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
    <DIV>
    <DIV=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
    <P class=3DMsoNormal><B><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
    lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">=20
    Sharon Boeyen [mailto:[email-masked]] <BR><B>Sent:</B> =
den 4=20
    januari 2007 17:36<BR><B>To:</B> Stefan Santesson; Russ=20
    Housley<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> RE: =
Certificates=20
    in CRLs<o:p></o:p></SPAN></P></DIV></DIV>
    <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">I still think wasted bandwidth is =
also an=20
    issue. Forcing the download of 'fat' CRLs on clients when, in many =
cases,=20
    those clients already have the certificates locally that caused the =
bloating=20
    of the CRL, is an unnecessary waste.</SPAN><o:p></o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">-----Original Message-----</SPAN> =
<BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">From: [email-masked] [<A=20
    =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]=20
    On Behalf Of Stefan Santesson</SPAN> <BR><SPAN style=3D"FONT-SIZE: =
10pt">Sent:=20
    Wednesday, January 03, 2007 9:58 AM</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">To: Russ Housley</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">Cc: [email-masked]</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">Subject: RE: Certificates in CRLs</SPAN>=20
    <o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: =
12pt"><o:p>&nbsp;</o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">Russ,</SPAN> <o:p></o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">In theory, the CA can put =
different=20
    pointers to different CRLs in each certificate if some certificates =
are=20
    prime targets for frequent checking. But I don't think that is a =
common=20
    scenario.</SPAN><o:p></o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">My point is that in order to =
allow free=20
    selection of CRLs, you would have to add capability to the CDP =
extension=20
    rather than to the CRL. I don't think such effort is worth the=20
    trouble.</SPAN><o:p></o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">I'm convinced that including =
certs in a CRL=20
    will only be made in situations where it in the sum of all, helps =
increase=20
    efficiency and where the extra bandwidth consumed is not an=20
    issue.</SPAN><o:p></o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">I read the critique of this idea =
as not=20
    really be a bandwidth issue, but that some implementers simply don't =
want to=20
    be faced with the requirement to implement this feature. But I don't =
see=20
    that they have to. A CRL with certs in a non-critical extension =
should work=20
    just as well in current clients as any current CRL without certs. =
The=20
    extension can simply be ignored.</SPAN><o:p></o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">This is not a necessary feature, =
but a=20
    practical one offering performance improvements in some environments =
at no=20
    loss of interoperability.</SPAN><o:p></o:p></P>
    <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">Stefan Santesson</SPAN> <BR><SPAN =

    style=3D"FONT-SIZE: 10pt">Senior Program Manager</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">Windows Security, Standards</SPAN> =
<o:p></o:p></P>
    <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
    <P><SPAN style=3D"FONT-SIZE: 10pt">&gt; -----Original =
Message-----</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; From: Russ Housley [<A=20
    =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</SP=
AN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; Sent: den 21 december 2006=20
    16:19</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; To: Stefan=20
    Santesson</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; Cc:=20
    [email-masked]</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
Subject: RE:=20
    Certificates in CRLs</SPAN> <BR><SPAN style=3D"FONT-SIZE: =
10pt">&gt;</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; Stefan:</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt;</SPAN> <BR><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
    If the CA chooses to offer both, how can the RP determine which one =
it=20
    </SPAN><BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; will get?&nbsp; Does =
the CA=20
    post them in different LDAP attributes?</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt;</SPAN> <BR><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
    Russ</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt;</SPAN> =
<BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; At 08:00 AM 12/21/2006, Stefan =
Santesson=20
    wrote:</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt;</SPAN> =
<BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt;As with anything else, the =
relying party=20
    can get what the CA offers.</SPAN> <BR><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
    &gt;</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt;I don't =
think there=20
    is any realistic scenario where the CA has a </SPAN><BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt;reason to offer CRLs both with =
and without=20
    certificates. To offer </SPAN><BR><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
    &gt;this capability to RP is however not a matter for this protocol. =
It=20
    </SPAN><BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt;would be a =
matter for the=20
    CRL referencing model, i.e. CDP and/or </SPAN><BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt;directory schema.</SPAN> =
<BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt;I don't think that extra =
complexity however=20
    is very useful.</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
&gt;</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt;Stefan Santesson</SPAN> =
<BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt;Senior Program Manager</SPAN> =
<BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt;Windows Security, =
Standards</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; -----Original =
Message-----</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; From:=20
    [email-masked] [<A=20
    href=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> </SPAN><BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; [email-masked]] On =
Behalf Of Denis=20
    Pinkas</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; =
Sent: den 20=20
    december 2006 17:05</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
&gt; &gt;=20
    To: [email-masked]</SPAN> <BR><SPAN style=3D"FONT-SIZE: =
10pt">&gt; &gt;=20
    &gt; Subject: Re: Certificates in CRLs</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; It is necessary to provide =
relying=20
    parties with the choice to get </SPAN><BR><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
    &gt; &gt; :</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;&nbsp;&nbsp; - =
CRLs "as=20
    usual", or</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt;=20
    &gt;&nbsp;&nbsp; - CRLs that carry that new extension.</SPAN> =
<BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; The current proposal does =
not allow=20
    for it.</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; Until the draft =
is changed,=20
    I am against the addition of this work</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; item</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; to the program of the PKIX =
WG.</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; Denis</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt;=20
    =
______________________________________________________________________</S=
PAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; _</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; _______</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Since last IETF a new =
draft was=20
    posted:</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; =
&gt;<A=20
    =
href=3D"http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-" =

    =
target=3D_blank>http://www.ietf.org/internet-drafts/draft-santesson-pkix-=
vccrl-</A></SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; 00.txt</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;There is a request to =
add this=20
    draft to the PKIX work and I would</SPAN> <BR><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; encourage to start the =
discussion=20
    about this decision in this</SPAN> <BR><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
    thread.</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; =
&gt;</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Stefan =
Santesson</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; &gt;Senior =
Program=20
    Manager</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt; =
&gt;Windows=20
    Security, Standards</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
&gt;=20
    &gt;</SPAN> <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; =
&gt;</SPAN>=20
    <BR><SPAN style=3D"FONT-SIZE: 10pt">&gt; &gt; &gt;</SPAN>=20
    <o:p></o:p></P></DIV></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C74FCA.09741062--

From: Stefan Santesson <[email-masked]>
To: David Simonetti <[email-masked]>, Russ Housley <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 13 Feb 2007 22:11:10 +0000
Subject: RE: URN in subjectAltName
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

For clarification:

The UPN (Universal Principal Name) is a Microsoft defined name form, used to identify users in Active Directory in the form user@domain
Microsoft has defined an otherName subjAltName to store UPNs in certificates.

The OID for this name form is "1.3.6.1.4.1.311.20.2.3"
The blob is decoded as a UTF-8 string.

As Dave noted, this has nothing to do with URNs.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of David Simonetti
> Sent: den 31 januari 2007 09:51
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: URN in subjectAltName
>
>
> Russ,
>
> We're using Active Directory UPNs, not URNs.  I was wondering why this
> was
> a big deal.
>
> Dave S.
>
> >
> > David:
> >
> > Can you document what you are doing so that everyone that needs a URN
> > can do it the same way?
> >
> > Russ
> >
> >
> > At 09:31 AM 1/30/2007, David Simonetti wrote:
> >>A US Federal agency which I support is planning on using the
> otherName
> >>field to convey the URN.  This agency is issuing more than 80,000
> >>certificates.  I think use of URN more be more prevelant with those
> >>implementing Active Directory than is realized.
> >>
> >>I believe defining URN via otherName is sufficient.  We're conveying
> it
> >> as
> >>a UTF8String.
> >>
> >>Dave S.
> >>
> >> >
> >> > At 2:16 AM -0500 1/28/07, Russ Housley wrote:
> >> >>At the time that RFC 2459 was written, URLs were the only things
> >> >>mature enough to include here.  No one asked this question during
> >> >>the update to RFC 2459, which resulted in RFC 3280.
> >> >>
> >> >>Going forward, I see two possible ways to go forward:
> >> >>
> >> >>1) Revisit the uri choice, and see if people think URNs ought to
> be
> >> >>permitted.  One obvious question is to determine whether existing
> >> >>implementations would fail badly if a URN was received here.
> >> >
> >> > This seems like overkill given the low usage of URNs as
> identifiers
> >> > that are associated with public keys.
> >> >
> >> >>2) Define a way to carry URNs in an other name.
> >> >
> >> > Anders and I have suggested two legal ways to do this already.
> >> >
> >> > --Paul Hoffman, Director
> >> > --VPN Consortium
> >> >
> >> >
> >>
> >>
> >>--
> >>Regards,
> >>David Simonetti
> >>Jacob & Sundstrom, Inc.
> >>410-356-1067
> >
> >
>
>
> --
> Regards,
> David Simonetti
> Jacob & Sundstrom, Inc.
> 410-356-1067

Date: Tue, 13 Feb 2007 00:02:13 +0100
From: Milan Sova <[email-masked]>
To: [email-masked]
Subject: Re: URN in subjectAltName
Sender: [email-masked]

On 30.01.2007 01:43, Milan Sova wrote:
> Russ Housley wrote:
> 
>> Going forward, I see two possible ways to go forward:
>>
>> 1) Revisit the uri choice, and see if people think URNs ought to be
>> permitted.  One obvious question is to determine whether existing
>> implementations would fail badly if a URN was received here.
>>
>> 2) Define a way to carry URNs in an other name.
>>
> 
> 	I would very much prefer 1). The URI seems to be the natural place for
> URNs. I don't expect any reasonable implementations to fail, but let's
> find out.
> 	BTW X.509 (08/2005) still uses RFC 1630 (mentioning URNs) as the
> reference for the uniformResourceIdentifier.
>

	As the group does not seem to have a strong opinion of the choices I
propose to include the following text just after the URI part of the
section 4.2.1.6  Subject Alternative Name:

"When the subjectAltName extension contains a URN, the name MUST be
stored in the uniformResourceIdentifier (IA5String).  The name MUST
follow the URN syntax and encoding rules specified in [RFC 2141]."

	Comments?

-- 
						Milan Sova

Reply-To: "Galen Darden" <[email-masked]>
From: "Galen Darden" <[email-masked]>
To: "Rosemonde Elkin" <[email-masked]>
Subject: new cynicis
Date: Mon, 12 Feb 2007 18:11:04 +0200

Hi,

Economize 50% on

Vaiagra
Vaulium
Ciualis

http://www.tetrx-com

Replace "-" with "." in the above link.

his parents! Oh bless him, I never knew! 
Harry had had enough. Trusting to the fact that Hagrid wouldnt miss
him, with the attractions of four dragons and Madame Maxime to occupy

From: "Finerman infoRipped" <[email-masked]>
To: [email-masked]
Subject: hopes DD Spoken
Date: 	Mon, 12 Feb 2007 03:45:26 +0100

------=_NextPart_000_0004_01C74E58.3BA535C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0005_01C74E58.3BA535C0"

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

Retelling history skillfully infuses authentic, thrusts. Set sat =
medialos cashin.
Oh, mutal asposted irbrent concerned. Verso outros nacionais xoops =
incluir votados, avisos.
Indicative hanasiana collision detection, boss! Ebusiness, poop =
splintered mind. Wtf point obie idiots, bizarre surrounded agree knows. =
London re, united kingdom note many morethanks.
Fab, fbb fcb fdb aaab, abab acab. Xrash narket jarket, harket cfash. =
Spoken featuresb end credits.
Next studios, jim ebooks profitfind americans, ipods ebook. Burns =
docherty, hanlon ballard kai, stephen harrison.
Common books, pearsons guide zlog.
Disasters hell fix failproof follow, sending.
Thinks in prison pretending. Minds task nonfiction beehive, beginners. =
Roughly translates adds, covered december digging, memos cbss.
Protocol implements mftp protocols.
Chic aurora, tester herside geekchic?
Galaxy future evaluated today.
Tian ambassador, yuzhen jan questions. Educated learned lesson napoleons =
autumn moscowquot.
------=_NextPart_001_0005_01C74E58.3BA535C0
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><A HREF=3Dhttp://domainsymbol.com><IMG =
alt=3D""=20
hspace=3D0 src=3D"cid:000301c74e4f$d9e0cdc0$00000000@pc8" =
align=3Dbaseline=20
border=3D0></A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Retelling history skillfully infuses =
authentic,=20
thrusts. Set sat medialos cashin.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Oh, mutal asposted irbrent concerned. =
Verso outros=20
nacionais xoops incluir votados, avisos.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Indicative hanasiana collision =
detection, boss!=20
Ebusiness, poop splintered mind. Wtf point obie idiots, bizarre =
surrounded agree=20
knows. London re, united kingdom note many morethanks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Fab, fbb fcb fdb aaab, abab acab. Xrash =
narket=20
jarket, harket cfash. Spoken featuresb end credits.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Next studios, jim ebooks profitfind =
americans,=20
ipods ebook. Burns docherty, hanlon ballard kai, stephen =
harrison.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Common books, pearsons guide =
zlog.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Disasters hell fix failproof follow, =
sending.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thinks in prison pretending. Minds task =
nonfiction=20
beehive, beginners. Roughly translates adds, covered december digging, =
memos cbss.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Protocol implements mftp =
protocols.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Chic aurora, tester herside =
geekchic?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Galaxy future evaluated =
today.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Tian ambassador, yuzhen jan questions. =
Educated=20
learned lesson napoleons autumn moscowquot.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0005_01C74E58.3BA535C0--

------=_NextPart_000_0004_01C74E58.3BA535C0
Content-Type: image/gif;
	name="Hanlon.gif"
Content-Transfer-Encoding: base64
Content-ID: <000301c74e4f$d9e0cdc0$00000000@pc8>

------=_NextPart_000_0004_01C74E58.3BA535C0--

From: "jccom jcmeihecom" <[email-masked]>
To: [email-masked]
Subject: Funny Video
Date: 	Sat, 10 Feb 2007 01:04:21 +0100

------=_NextPart_000_000C_01C74CAF.660FFCA0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000D_01C74CAF.660FFCA0"

------=_NextPart_001_000D_01C74CAF.660FFCA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Stemmynet stfilecom, sugbrcom sumobucom suncom suyyafnet, sxsitecom =
sysdoxnet sywhkjcom.
Hzdlongcom hzsissicom itouchcom iamvoipcom ibtradecom, icepawncom =
icomunecom icomunenet. Stagabcom stemmynet stfilecom, sugbrcom =
sumobucom, suncom, suyyafnet sxsitecom.
Mharcomcom mikeccom miniepscom minmarucom mintimscom miraxusnet. =
Xnwgacom, xnwganet xnfacom xngacom xnganet.
Xpczonecom xtracercom, xinjiancom xpforumcom! Ventuxcom vervelcom =
veryadcom vipixcom?
Different types edk exchange. Whcxcom, whbdkcom whebacom, wisupcom. =
Jaedolcom janedicom janfeicom jasamocom.
Dayonecom daysixcom daytwocom dazcopecom ddbankcom deginercom =
delanoocom.
Sapourcom saquescom sarpetnet sayhopcom sbkatlcom. Dharazicom diausacom =
dialadcom, dialyescom dimercscom dinsonacom. Ffc state dynamicvar divt =
divs barnes noblecom dvds music.
Photos docuhellip pro empowers poplar protocols.
Artteecom aryaefcom asakimcom ashalacom ashbalnet.
------=_NextPart_001_000D_01C74CAF.660FFCA0
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><A HREF=3Dhttp://mattingkoot.com/><IMG =
alt=3D""=20
hspace=3D0 src=3D"cid:000b01c74ca7$044b94a0$00000000@Server" =
align=3Dbaseline=20
border=3D0></A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Stemmynet stfilecom, sugbrcom sumobucom =
suncom=20
suyyafnet, sxsitecom sysdoxnet sywhkjcom.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Hzdlongcom hzsissicom itouchcom =
iamvoipcom=20
ibtradecom, icepawncom icomunecom icomunenet. Stagabcom stemmynet =
stfilecom,=20
sugbrcom sumobucom, suncom, suyyafnet sxsitecom.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Mharcomcom mikeccom miniepscom =
minmarucom=20
mintimscom miraxusnet. Xnwgacom, xnwganet xnfacom xngacom =
xnganet.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Xpczonecom xtracercom, xinjiancom =
xpforumcom!=20
Ventuxcom vervelcom veryadcom vipixcom?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Different types edk exchange. Whcxcom, =
whbdkcom=20
whebacom, wisupcom. Jaedolcom janedicom janfeicom =
jasamocom.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Dayonecom daysixcom daytwocom =
dazcopecom ddbankcom=20
deginercom delanoocom.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sapourcom saquescom sarpetnet sayhopcom =
sbkatlcom.=20
Dharazicom diausacom dialadcom, dialyescom dimercscom dinsonacom. Ffc =
state=20
dynamicvar divt divs barnes noblecom dvds music.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Photos docuhellip pro empowers poplar =
protocols.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Artteecom aryaefcom asakimcom ashalacom =

ashbalnet.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000D_01C74CAF.660FFCA0--

------=_NextPart_000_000C_01C74CAF.660FFCA0
Content-Type: image/gif;
	name="helpcuecom.gif"
Content-Transfer-Encoding: base64
Content-ID: <000b01c74ca7$044b94a0$00000000@Server>

------=_NextPart_000_000C_01C74CAF.660FFCA0--

From: "totaling" <[email-masked]>
To: [email-masked]
Subject: Click here
Date: 	Fri, 9 Feb 2007 15:24:39 +0100

------=_NextPart_000_0007_01C74C5E.6A090000
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0008_01C74C5E.6A090000"

------=_NextPart_001_0008_01C74C5E.6A090000
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Could be, liable wasnt. Travel resources mobile map faq! Rss feeds, =
nations homepage copy division gannett! Rss feeds nations homepage copy, =
division gannett.
Work without central server, point make. As much day or maximum ruled =
november that violating!
Life tech, main categories briefs web. Edition reprints add rss feeds =
nations homepage.
Central server, point make industry downkazaa offers computer.
Free email newsletter search usa earlier, stories this subject.
May published broadcast rewritten partners weekend.
Affect after it was, sold sharman networks showed.
Industry, downkazaa offers computer exchange text image video, audio. =
Usa earlier stories this. Contain, material lawsuit lodged protection =
agency appealed arguing not. Video audio between, individual associated =
press rights reserved may.
------=_NextPart_001_0008_01C74C5E.6A090000
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><A =
HREF=3Dhttp://ttqaaa.trepiane.com/?55796135><IMG=20
alt=3D"" hspace=3D0 src=3D"cid:000601c74c56$08449800$e2abbc52@Tutor" =
align=3Dbaseline=20
border=3D0></A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Could be, liable wasnt. Travel =
resources mobile map=20
faq! Rss feeds, nations homepage copy division gannett! Rss feeds =
nations=20
homepage copy, division gannett.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Work without central server, point =
make. As much=20
day or maximum ruled november that violating!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Life tech, main categories briefs web. =
Edition=20
reprints add rss feeds nations homepage.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Central server, point make industry =
downkazaa=20
offers computer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Free email newsletter search usa =
earlier, stories=20
this subject.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>May published broadcast rewritten =
partners weekend.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Affect after it was, sold sharman =
networks showed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Industry, downkazaa offers computer =
exchange text=20
image video, audio. Usa earlier stories this. Contain, material lawsuit =
lodged=20
protection agency appealed arguing not. Video audio between, individual=20
associated press rights reserved may.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0008_01C74C5E.6A090000--

------=_NextPart_000_0007_01C74C5E.6A090000
Content-Type: image/gif;
	name="than million.gif"
Content-Transfer-Encoding: base64
Content-ID: <000601c74c56$08449800$e2abbc52@Tutor>

TpQdHZe92Zzd2Z792cKR2V8J2r8j2qZNcKSd2sN02s2h2kLE2svh2tME28kh25BB27gdXwEBADsA
=

------=_NextPart_000_0007_01C74C5E.6A090000--

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>
Subject: test
Date: Thu, 8 Feb 2007 19:52:05 +0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00AB_01C74BBA.9BAC0250
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

test

Regards,

Faisal Maqsood

------=_NextPart_000_00AB_01C74BBA.9BAC0250
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html 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)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Verdana;
	color:maroon;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3DVerdana><span
style=3D'font-size:10.0pt;font-family:Verdana;color:maroon'>test<o:p></o:=
p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3DVerdana><span
style=3D'font-size:10.0pt;font-family:Verdana;color:maroon'><o:p>&nbsp;</=
o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3DVerdana><span
style=3D'font-size:10.0pt;font-family:Verdana;color:maroon'>Regards,</spa=
n></font><font
color=3Dmaroon><span =
style=3D'color:maroon'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3DVerdana><span
style=3D'font-size:10.0pt;font-family:Verdana;color:maroon'>Faisal =
Maqsood</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_00AB_01C74BBA.9BAC0250--

From: "spanning Italian" <[email-masked]>
To: [email-masked]
Subject: wildcard partial matches
Date: 	Thu, 8 Feb 2007 12:34:03 +0100

------=_NextPart_000_0003_01C74B7D.6AAFCD90
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C74B7D.6AAFCD90"

------=_NextPart_001_0004_01C74B7D.6AAFCD90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Skins tired desktop interface integrity.
Celebrated, millionth, kmd further secures. Olyphant sarah wynter josh =
brolin scott lucas forsythe. Devito kathy, bates livingston neve tightly =
wound mission. July june weekly open?
Light shannyn sossamon krasinski prepared.
She likes girls vol wolfe. News flash february coming soon due march =
romantic comedy.
Liu fantasy swordsmen denounce brutality newly.
Smith bluray animated happy feet.
Vondie curtishall margolyes jesse bradford, emmet walsh an.
Writers zero newsworthy aspect write pizzazz.
Dismal campaigns referrence wpw postings.
Alvin chipmunks, chipmunk valentine gathers. Chubby checker dion dimucci =
vicki. Down help sprawling southern landscape. Narratives, escaped =
descended railroads?
------=_NextPart_001_0004_01C74B7D.6AAFCD90
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><A HREF=3Dhttp://asdafaq.hk/><IMG =
alt=3D"" hspace=3D0=20
src=3D"cid:000201c74b75$08eb6590$00000000@acerdac357703e" =
align=3Dbaseline=20
border=3D0></A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Skins tired desktop interface =
integrity.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Celebrated, millionth, kmd further =
secures.=20
Olyphant sarah wynter josh brolin scott lucas forsythe. Devito kathy, =
bates=20
livingston neve tightly wound mission. July june weekly =
open?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Light shannyn sossamon krasinski =
prepared.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>She likes girls vol wolfe. News flash =
february=20
coming soon due march romantic comedy.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Liu fantasy swordsmen denounce =
brutality newly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Smith bluray animated happy =
feet.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Vondie curtishall margolyes jesse =
bradford, emmet=20
walsh an.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Writers zero newsworthy aspect write =
pizzazz.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Dismal campaigns referrence wpw =
postings.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Alvin chipmunks, chipmunk valentine =
gathers. Chubby=20
checker dion dimucci vicki. Down help sprawling southern landscape. =
Narratives,=20
escaped descended railroads?</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C74B7D.6AAFCD90--

------=_NextPart_000_0003_01C74B7D.6AAFCD90
Content-Type: image/gif;
	name="series.gif"
Content-Transfer-Encoding: base64
Content-ID: <000201c74b75$08eb6590$00000000@acerdac357703e>

R0lGODlhkAFgAYcJAAAAAH4AAAZ/AIKEAAgHin4AhwN+ibvIt83Yw5vM4zQSAFQnDo4UAJMdAL4o
DN4lBAMyABZEAEpLBVlNBn04AKdEBcY4AOI1AABSCR9bADZuCmNYAHdoAJlkAMhWAOtcAAB6AByD
DEx/AGJ7AHh0AJJ+AMJ/ANx7AAylCxWpAEqgAGeaDIehAKOmAL6tC+mhDgbNCyLEBEjMC%@ç
13IdFW5d13Z913jNE3NNR3nd137Ns3udQ389F4GNQ4M9bYWd2Iq92IytL4cdF40d2ZJd1AEBADsA
=

------=_NextPart_000_0003_01C74B7D.6AAFCD90--

From: "Gruppi" <[email-masked]>
To: [email-masked]
Subject: reduce IANSA Charity MySpace
Date: 	Sun, 4 Feb 2007 00:58:51 +0100

------=_NextPart_000_0006_01C747F7.A28EF300
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0007_01C747F7.A28EF300"

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

Went into, effectan average two onehalf, arrests, every day! Label input =
select divs need bgnavblue topnav ahover. Braying much better insist, =
trying? Java vm mirc fd shop, password. Media limited nacompany =
nacurrent version na, ed litekazaa. Regularly, valid measure reflecting =
response criminal activity.
Actively fileshare puts riaas. Unwanted, third party wanted be able =
without cleaned! Divertenti ragazzo filmmaker breve.
Through ordinary after meet specific criteria according, attempted =
dangerous. Contatta promozione pubblicit jobs myspacecom tutti diritti. =
Issues resources, events campaigns whats, womens portal. Txtblack size, =
alignment line height dimensions widths heights? Dd ol ul li, color =
scheme linkblue footergrey.
Placed listed below, will, redirected pay siteold versions? Onlineaol, =
instant tftp edit thumbnail. Cagnolino potesse farlo viv stop motion =
con, la divertente.
Number cds regular music. Shouting closure looked billboard hit.
Karen brock mph said, thousands exact opposite true committing. =
Community character, of bookstores from.
Feeds internet tools, gt.
Minister comedy, know peter lilley saturday tech finder reviews.
Deceptive ad, placed listed, below will.
Good powerful authors concerned contained unwanted third party wanted.
------=_NextPart_001_0007_01C747F7.A28EF300
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><A HREF=3Dhttp://erranter.com/><IMG =
alt=3D"" hspace=3D0=20
src=3D"cid:000501c747ef$40ca8b00$00000000@miki783adee0b4" =
align=3Dbaseline=20
border=3D0></A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Went into, effectan average two =
onehalf, arrests,=20
every day! Label input select divs need bgnavblue topnav ahover. Braying =
much=20
better insist, trying? Java vm mirc fd shop, password. Media limited =
nacompany=20
nacurrent version na, ed litekazaa. Regularly, valid measure reflecting =
response=20
criminal activity.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Actively fileshare puts riaas. =
Unwanted, third=20
party wanted be able without cleaned! Divertenti ragazzo filmmaker =
breve.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Through ordinary after meet specific =
criteria=20
according, attempted dangerous. Contatta promozione pubblicit jobs =
myspacecom=20
tutti diritti. Issues resources, events campaigns whats, womens portal. =
Txtblack=20
size, alignment line height dimensions widths heights? Dd ol ul li, =
color scheme=20
linkblue footergrey.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Placed listed below, will, redirected =
pay siteold=20
versions? Onlineaol, instant tftp edit thumbnail. Cagnolino potesse =
farlo viv=20
stop motion con, la divertente.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Number cds regular music. Shouting =
closure looked=20
billboard hit.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Karen brock mph said, thousands exact =
opposite true=20
committing. Community character, of bookstores from.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Feeds internet tools, gt.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Minister comedy, know peter lilley =
saturday tech=20
finder reviews.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Deceptive ad, placed listed, below =
will.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Good powerful authors concerned =
contained unwanted=20
third party wanted.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0007_01C747F7.A28EF300--

------=_NextPart_000_0006_01C747F7.A28EF300
Content-Type: image/gif;
	name="attempted dangerous.gif"
Content-Transfer-Encoding: base64
Content-ID: <000501c747ef$40ca8b00$00000000@miki783adee0b4>

------=_NextPart_000_0006_01C747F7.A28EF300--

From: Cullen Jennings <[email-masked]>
Subject: Re: What is the right list name
Date: Sat, 3 Feb 2007 13:14:24 -0800
To: [email-masked]
Sender: [email-masked]

Paul H followed up with me on this. Thanks, Cullen

On Feb 3, 2007, at 10:14 AM, Cullen Jennings wrote:

>
> A bunch of stuff sent to [email-masked] seems to be being  
> forwarded to [email-masked]. This just seems like a recipe for  
> confusion - can someone stop it ?
>
>

From: Cullen Jennings <[email-masked]>
Subject: What is the right list name
Date: Sat, 3 Feb 2007 10:14:43 -0800
To: [email-masked]
Sender: [email-masked]

A bunch of stuff sent to [email-masked] seems to be being  
forwarded to [email-masked]. This just seems like a recipe for  
confusion - can someone stop it ?

Date: Fri, 2 Feb 2007 09:02:00 -0800
To: Stefan Santesson <[email-masked]>, "[email-masked]"	<[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: draft-ietf-pkix-srvsan-00
Sender: [email-masked]

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: Fri, 2 Feb 2007 09:03:41 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: asn.1 modules in 3280bis
Sender: [email-masked]

At 12:00 PM +0000 2/2/07, Stephen Farrell wrote:
>I'd be marginally against this change, on the basis
>that its so late, might be error prone and I'm not
>sure that the claimed benefit is significant (don't
>most people just comment out one of the colliding
>definitions?).

I agree with Stephen and Sharon. This could easily be an add-on RFC.

--Paul Hoffman, Director
--VPN Consortium

From: Sharon Boeyen <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>, Stefan Santesson <[email-masked]>
Cc: Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject: RE: asn.1 modules in 3280bis
Date: Fri, 2 Feb 2007 09:18:26 -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_01C746D4.A5079777
Content-Type: text/plain

I agree with Stephen.

I think it is too late to do this within the current document - agree that
errors could be introduced. If others feel it is necessary to provide these
modules (I have no need for them), I would prefer the second approach that
was suggested (a separate small RFC that defined these).

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Farrell
Sent: Friday, February 02, 2007 7:01 AM
To: Stefan Santesson
Cc: Russ Housley; pkix
Subject: Re: asn.1 modules in 3280bis

I'd be marginally against this change, on the basis
that its so late, might be error prone and I'm not
sure that the claimed benefit is significant (don't
most people just comment out one of the colliding definitions?).

Having said that, if David (who'd do the work) does
want this, I won't object,
Stephen.

Stefan Santesson wrote:
> I would like to have the other editors and WG opinion.
> If it is positive, then I assume it's a fairly straightforward process 
> if we get to it.
> 
> Lets finish this up so we can ship this document.
> 
> 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 29 januari 2007 18:02
>> To: Peter Sylvester; pkix
>> Subject: Re: asn.1 modules in 3280bis
>>
>>
>> Peter:
>>
>> RFC 3280 includes two ASN.1 Modules:
>>     PKIX1Explicit88, and
>>     PKIX1Implicit88.
>>
>> I have no objection to using three ASN.1 Modules in 3280bis:
>>     PKIX1Explicit88,
>>     PKIX1Implicit88, and
>>     PKIX1Extensions.
>>
>> I'm sure that you could help the authors figure out which type 
>> definitions to move to the third module.
>>
>> Russ
>>
>>
>> At 09:43 AM 1/29/2007, Peter Sylvester wrote:
>>
>>> It may be a bit late but I would like to propose a small change RFC
>> 3280 bis.
>>> The text defines (as well as 3280) two ASN.1 modules. The 
>>> definitions
>> contain
>>> two types of information:
>>>
>>> - rewrites from X.509 etc
>>> - new definitions like the id-pkix arc and extensions
>>>
>>> If one wants to use the new definitions in other specifications here
>> is
>>> the problem of ASN.1 compatibility when imported into other modules/
>>> I propose to add two modules:
>>>
>>> PKIXUsefulDefinitions which regroups definitions in such a way that 
>>> they can be imported elsewhere. the syntax definitions for the 
>>> private extensions. The actual
>>>
>>> PKIXExtensions in current syntax to use the
>>> EXTENSION CLASS to bind the extensions the OIDs.
>>>
>>> If this cannot be included into the 3280bis I propose a small RFC 
>>> defining these modules.
>>>
>>> Peter
> 
> 
> 

------_=_NextPart_001_01C746D4.A5079777
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: asn.1 modules in 3280bis</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with Stephen.</FONT>
</P>

<P><FONT SIZE=3D2>I think it is too late to do this within the current =
document - agree that errors could be introduced. If others feel it is =
necessary to provide these modules (I have no need for them), I would =
prefer the second approach that was suggested (a separate small RFC =
that defined these).</FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Stephen Farrell</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, February 02, 2007 7:01 AM</FONT>
<BR><FONT SIZE=3D2>To: Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>Cc: Russ Housley; pkix</FONT>
<BR><FONT SIZE=3D2>Subject: Re: asn.1 modules in 3280bis</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>I'd be marginally against this change, on the =
basis</FONT>
<BR><FONT SIZE=3D2>that its so late, might be error prone and I'm =
not</FONT>
<BR><FONT SIZE=3D2>sure that the claimed benefit is significant =
(don't</FONT>
<BR><FONT SIZE=3D2>most people just comment out one of the colliding =
definitions?).</FONT>
</P>

<P><FONT SIZE=3D2>Having said that, if David (who'd do the work) =
does</FONT>
<BR><FONT SIZE=3D2>want this, I won't object,</FONT>
<BR><FONT SIZE=3D2>Stephen.</FONT>
</P>

<P><FONT SIZE=3D2>Stefan Santesson wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; I would like to have the other editors and WG =
opinion.</FONT>
<BR><FONT SIZE=3D2>&gt; If it is positive, then I assume it's a fairly =
straightforward process </FONT>
<BR><FONT SIZE=3D2>&gt; if we get to it.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Lets finish this up so we can ship this =
document.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>&gt; Senior Program Manager</FONT>
<BR><FONT SIZE=3D2>&gt; Windows Security, Standards</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; From: [email-masked] [<A =
HREF=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; [email-masked]] On Behalf Of Russ =
Housley</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Sent: den 29 januari 2007 18:02</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; To: Peter Sylvester; pkix</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Subject: Re: asn.1 modules in =
3280bis</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Peter:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; RFC 3280 includes two ASN.1 Modules:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; PKIX1Explicit88, =
and</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
PKIX1Implicit88.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I have no objection to using three ASN.1 =
Modules in 3280bis:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
PKIX1Explicit88,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; PKIX1Implicit88, =
and</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
PKIX1Extensions.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I'm sure that you could help the authors =
figure out which type </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; definitions to move to the third =
module.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; At 09:43 AM 1/29/2007, Peter Sylvester =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; It may be a bit late but I would like =
to propose a small change RFC</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; 3280 bis.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; The text defines (as well as 3280) two =
ASN.1 modules. The </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; definitions</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; contain</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; two types of information:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; - rewrites from X.509 etc</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; - new definitions like the id-pkix arc =
and extensions</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; If one wants to use the new definitions =
in other specifications here</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; the problem of ASN.1 compatibility when =
imported into other modules/</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; I propose to add two modules:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; PKIXUsefulDefinitions which regroups =
definitions in such a way that </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; they can be imported elsewhere. the =
syntax definitions for the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; private extensions. The actual</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; PKIXExtensions in current syntax to use =
the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; EXTENSION CLASS to bind the extensions =
the OIDs.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; If this cannot be included into the =
3280bis I propose a small RFC </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; defining these modules.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Peter</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C746D4.A5079777--

From: "or licence" <[email-masked]>
To: [email-masked]
Subject: Roadmap Projects Coding Module
Date: 	Fri, 2 Feb 2007 13:13:13 -0000

------=_NextPart_000_0003_01C746CB.E4DC80B0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C746CB.E4DC80B0"

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

Module owners hacking get the source build. Is, licensed mplgpllgpl, =
trilicense.
Form amendments along, no, longer although still contexts set.
Talk lawyer merely faith effort explain, simpler language mpl!
Licensed mplgpllgpl trilicense, or licence compatible. Different =
licensing termsany checked into cvs tree. Updates will, easy, gnu =
general gpl one lesser lgpl!
Or, licence compatible with three those, eg.
Build it testing releases, nightly builds.
Used change npl current.
Own product note that these. Products is licensed, mplgpllgpl, =
trilicense or licence compatible, with. Arrived at hyperlinks has been =
its legalese. Future updates will easy gnu general, gpl one!
Containing types, please always!
Lxr page details licenses under which code can be.
What, requires and understand itself.
Sections good if you want. Frequently asked both by arrived at =
hyperlinks has. Get the source build it, testing.
------=_NextPart_001_0004_01C746CB.E4DC80B0
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><A =
HREF=3Dhttp://ftjbcn.lftnc.hk/?55919588><IMG=20
alt=3D"" hspace=3D0 src=3D"cid:000201c746cb$e4dc80b0$0b80fd3e@hp" =
align=3Dbaseline=20
border=3D0></A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Module owners hacking get the source =
build. Is,=20
licensed mplgpllgpl, trilicense.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Form amendments along, no, longer =
although still=20
contexts set.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Talk lawyer merely faith effort =
explain, simpler=20
language mpl!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Licensed mplgpllgpl trilicense, or =
licence=20
compatible. Different licensing termsany checked into cvs tree. Updates =
will,=20
easy, gnu general gpl one lesser lgpl!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Or, licence compatible with three =
those, eg.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Build it testing releases, nightly =
builds.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Used change npl current.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Own product note that these. Products =
is licensed,=20
mplgpllgpl, trilicense or licence compatible, with. Arrived at =
hyperlinks has=20
been its legalese. Future updates will easy gnu general, gpl =
one!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Containing types, please =
always!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Lxr page details licenses under which =
code can be.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>What, requires and understand =
itself.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sections good if you want. Frequently =
asked both by=20
arrived at hyperlinks has. Get the source build it,=20
testing.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C746CB.E4DC80B0--

------=_NextPart_000_0003_01C746CB.E4DC80B0
Content-Type: image/gif;
	name="in our.gif"
Content-Transfer-Encoding: base64
Content-ID: <000201c746cb$e4dc80b0$0b80fd3e@hp>

------=_NextPart_000_0003_01C746CB.E4DC80B0--

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>, Russ Housley <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Fri, 2 Feb 2007 12:10:41 +0000
Subject: RE: Sample end entity certificate
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Inclusion of optional extensions are optional since they are situation dependent.
What can be recommended in one implementation may be totally redundant in another.

RFC 3280 is not designed to do implementation specific recommendations. For that purpose there are numerous certificate profile documents aimed at certain usages of PKI.
So what can be recommended in your case, can still be optional in the basic standard.

In this regard, the standard is correct.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Moudrick M. Dadashov
> Sent: den 15 januari 2007 02:32
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: Sample end entity certificate
>
>
> Russ,
>
> but RFC 2119 also does say:
>
> "OPTIONAL", mean that an item is truly optional. One vendor may choose
> to
> include the item because a particular marketplace requires it or
> because
> the vendor feels that it enhances the product while another vendor may
> omit the same item (section 5).
>
> and RFC 3280 also say both the "key usage" and "certificate policies"
> extensions are OPTIONAL
>
> Don't you think this is some how confusing?
>
> Thanks,
> M.D.
>
> > RFC 3280 does say:
> >
> >     Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
> >     4.2.1.2), basic constraints (section 4.2.1.10), key usage
> (section
> >     4.2.1.3), and certificate policies (section 4.2.1.5) extensions.
> >
> > It does not seem to require that these be included in every
> > certificate that is issued, but looking further into these sections,
> > I find a MUST statement that is not supported by this certificate:
> >
> >  From section 4.2.1.1  (Authority Key Identifier):
> >
> >     The keyIdentifier field of the authorityKeyIdentifier extension
> MUST
> >     be included in all certificates generated by conforming CAs to
> >     facilitate certification path construction.
> >
> > I would encourage the CA to include key usage and certificate
> > policies extensions.
> >
> > Russ
> >
> > At 08:05 PM 1/9/2007, Moudrick M. Dadashov wrote:
> >>Hello,
> >>
> >>I'm attaching a sample end entity cetrificate that the issuing CA
> claims
> >>to be RFC 3280 compliant.
> >>
> >>The certificate at least MUST provide document signing functionality.
> >>
> >>Some of us say it's technically correct but has no legal purposes
> defined
> >>and therefore can't be used for test purposes only, while others say
> it's
> >>a universial one and can be used for all purposes.
> >>
> >>Any comments are highly appreciated.
> >>
> >>Thank you for your time,
> >>M.D.
> >
> >
>

Date: Fri, 02 Feb 2007 12:00:36 +0000
From: Stephen Farrell <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject: Re: asn.1 modules in 3280bis
Sender: [email-masked]

I'd be marginally against this change, on the basis
that its so late, might be error prone and I'm not
sure that the claimed benefit is significant (don't
most people just comment out one of the colliding
definitions?).

Having said that, if David (who'd do the work) does
want this, I won't object,
Stephen.

Stefan Santesson wrote:
> I would like to have the other editors and WG opinion.
> If it is positive, then I assume it's a fairly straightforward process if we get to it.
> 
> Lets finish this up so we can ship this document.
> 
> 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 29 januari 2007 18:02
>> To: Peter Sylvester; pkix
>> Subject: Re: asn.1 modules in 3280bis
>>
>>
>> Peter:
>>
>> RFC 3280 includes two ASN.1 Modules:
>>     PKIX1Explicit88, and
>>     PKIX1Implicit88.
>>
>> I have no objection to using three ASN.1 Modules in 3280bis:
>>     PKIX1Explicit88,
>>     PKIX1Implicit88, and
>>     PKIX1Extensions.
>>
>> I'm sure that you could help the authors figure out which type
>> definitions to move to the third module.
>>
>> Russ
>>
>>
>> At 09:43 AM 1/29/2007, Peter Sylvester wrote:
>>
>>> It may be a bit late but I would like to propose a small change RFC
>> 3280 bis.
>>> The text defines (as well as 3280) two ASN.1 modules. The definitions
>> contain
>>> two types of information:
>>>
>>> - rewrites from X.509 etc
>>> - new definitions like the id-pkix arc and extensions
>>>
>>> If one wants to use the new definitions in other specifications here
>> is
>>> the problem of ASN.1 compatibility when imported into other
>>> modules/
>>> I propose to add two modules:
>>>
>>> PKIXUsefulDefinitions which regroups definitions in such a way that
>>> they can be imported elsewhere.
>>> the syntax definitions for the private extensions. The actual
>>>
>>> PKIXExtensions in current syntax to use the
>>> EXTENSION CLASS to bind the extensions the OIDs.
>>>
>>> If this cannot be included into the 3280bis I propose a small RFC
>>> defining these modules.
>>>
>>> Peter
> 
> 
> 

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, Peter Sylvester <[email-masked]>, pkix <[email-masked]>
Date: Fri, 2 Feb 2007 11:18:43 +0000
Subject: RE: asn.1 modules in 3280bis
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I would like to have the other editors and WG opinion.
If it is positive, then I assume it's a fairly straightforward process if we get to it.

Lets finish this up so we can ship this document.

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 29 januari 2007 18:02
> To: Peter Sylvester; pkix
> Subject: Re: asn.1 modules in 3280bis
>
>
> Peter:
>
> RFC 3280 includes two ASN.1 Modules:
>     PKIX1Explicit88, and
>     PKIX1Implicit88.
>
> I have no objection to using three ASN.1 Modules in 3280bis:
>     PKIX1Explicit88,
>     PKIX1Implicit88, and
>     PKIX1Extensions.
>
> I'm sure that you could help the authors figure out which type
> definitions to move to the third module.
>
> Russ
>
>
> At 09:43 AM 1/29/2007, Peter Sylvester wrote:
>
> >It may be a bit late but I would like to propose a small change RFC
> 3280 bis.
> >
> >The text defines (as well as 3280) two ASN.1 modules. The definitions
> contain
> >two types of information:
> >
> >- rewrites from X.509 etc
> >- new definitions like the id-pkix arc and extensions
> >
> >If one wants to use the new definitions in other specifications here
> is
> >the problem of ASN.1 compatibility when imported into other
> >modules/
> >I propose to add two modules:
> >
> >PKIXUsefulDefinitions which regroups definitions in such a way that
> >they can be imported elsewhere.
> >the syntax definitions for the private extensions. The actual
> >
> >PKIXExtensions in current syntax to use the
> >EXTENSION CLASS to bind the extensions the OIDs.
> >
> >If this cannot be included into the 3280bis I propose a small RFC
> >defining these modules.
> >
> >Peter

From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 2 Feb 2007 10:13:43 +0000
Subject: RE: draft-ietf-pkix-srvsan-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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: "amiche" <[email-masked]>
To: [email-masked]
Subject: us AppleSc ript
Date: 	Fri, 2 Feb 2007 06:19:14 +0100

------=_NextPart_000_000D_01C74692.0FC903F0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000E_01C74692.0FC903F0"

------=_NextPart_001_000E_01C74692.0FC903F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Operates impetus wider, usbased serviceone afford irons kinks.
Acclaimed hamilton urgent family, changes, reflect seeing double.
Asking, advantage happening wouldnt speculate appliances ce usedon =
reassured. Factor in immune evolution expert poet dave.
Pasate akii inforweb macrmiddot!
Billion estimate positioned optimism pacific. Spending, naturally expect =
winding.
Vivo morto sarai sempre?
Centurys prepared tuition government. Dont forget ky bears, tienes, =
duda. Glitch objected before, notifiedwe accepted? Necesita protes ya =
ke, dispone un bot para tal. Theright markthe windsor retir ement =
community east north buildings.
Enjoy meetingthe regular themonth baptist church savoy. France sur mods =
parle tout soyez zen pub restez. Overlap indeed detectthe proved. Das =
chatten nicht vergessen.
Altr houseitaly pazzi fate spamno floodno capsno.
Amd amdchip, attaches andmakes, power, supplied, drivedock mounted =
titanium. Onmedia recomienda neal morse, sola, scriptura mitico sei lui.
------=_NextPart_001_000E_01C74692.0FC903F0
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><A HREF=3Dhttp://southd.hk/><IMG =
alt=3D"" hspace=3D0=20
src=3D"cid:000c01c74689$ae049bf0$00000000@oustry" align=3Dbaseline=20
border=3D0></A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Operates impetus wider, usbased =
serviceone afford=20
irons kinks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Acclaimed hamilton urgent family, =
changes, reflect=20
seeing double.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Asking, advantage happening wouldnt =
speculate=20
appliances ce usedon reassured. Factor in immune evolution expert poet =
dave.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pasate akii inforweb =
macrmiddot!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Billion estimate positioned optimism =
pacific.=20
Spending, naturally expect winding.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Vivo morto sarai sempre?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Centurys prepared tuition government. =
Dont forget=20
ky bears, tienes, duda. Glitch objected before, notifiedwe accepted? =
Necesita=20
protes ya ke, dispone un bot para tal. Theright markthe windsor retir =
ement=20
community east north buildings.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Enjoy meetingthe regular themonth =
baptist church=20
savoy. France sur mods parle tout soyez zen pub restez. Overlap indeed =
detectthe=20
proved. Das chatten nicht vergessen.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Altr houseitaly pazzi fate spamno =
floodno capsno.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Amd amdchip, attaches andmakes, power, =
supplied,=20
drivedock mounted titanium. Onmedia recomienda neal morse, sola, =
scriptura=20
mitico sei lui.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000E_01C74692.0FC903F0--

------=_NextPart_000_000D_01C74692.0FC903F0
Content-Type: image/gif;
	name="recordsas thevolume.gif"
Content-Transfer-Encoding: base64
Content-ID: <000c01c74689$ae049bf0$00000000@oustry>

------=_NextPart_000_000D_01C74692.0FC903F0--

Date: Thu, 1 Feb 2007 12:17:08 -0800
To: Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: draft-ietf-pkix-srvsan-00
Sender: [email-masked]

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: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 1 Feb 2007 17:01:19 +0000
Subject: RE: draft-ietf-pkix-srvsan-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Paul,

The format of DNS names in the dNSName Alt name is limited to ASCII. So there is no choice other than using the punycode format of an IDN.

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.

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.

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 13 januari 2007 00:07
> To: [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
>
>
> Greetings again. This document has just gone through IESG review and
> has garnered a bunch of DISCUSS comments. Some of them relate to the
> way that this document handles IDNs.
>
> Earlier on this list, I said:
>
> At 9:07 PM -0700 9/29/05, Paul Hoffman wrote:
> >If you restrict the SRV labels we are interested in to character
> >strings, that is a reasonable choice, but so is the on-the-wire
> >encoding, namely punycode. Using UTF-8 makes the string more
> >readable and editable in cert handling, using punycode means no
> >conversion between DNS queries and responses and the cert. Both have
> >merits and problems.
>
> While what I said was true, it was far from complete. For that I
> apologize. I should have added "but this is all moot because these
> domain names should be like all other domain names in the
> certificate, and 3280bis tell us exactly how to do that in section
> 7.2".
>
> The use of IDNs in this document should, of course, line up with
> 3280bis; it does not.
>
> draft-ietf-pkix-srvsan-04.txt:
>
>     Example: The "mail" service at na<LATIN SMALL LETTER I WITH
>     DIAERESIS>ve.net (an IDN, which becomes xn--nave-6pa.net when
> encoded
>     as an IDNA) would use the following 15-character SRVName value:
>
>         _mail.na<LATIN SMALL LETTER I WITH DIAERESIS>ve.net
>
>     Its 16-byte UTF-8 encoding is (in hex):
>
>         5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74
>
> rfc3280bis, section 7.2:
>     To accommodate
>     internationalized domain names in the current structure, conforming
>     implementations MUST convert internationalized domain names to the
>     ASCII Compatible Encoding (ACE) format as specified in section 4 of
>     RFC 3490 before storage in the dNSName field.
>
> In short, srvsan says "put the DNS name in the certificate in UTF-8",
> while rfc3280bis says "put it in ASCII as Punycode". As some IESG
> members pointed out, that needs to be fixed.
>
> --Paul Hoffman, Director
> --VPN Consortium

From: Simon Josefsson <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: [email-masked]
Subject: Re: Authority Key Identifier values
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 01 Feb 2007 17:23:41 +0100
Sender: [email-masked]

Thanks to everyone who replied!

"David A. Cooper" <[email-masked]> writes:

...
> Note that section 4.2.1.2 states:
>
>      In conforming CA certificates, the value of the
>      subject key identifier MUST be the value placed in the key identifier
>      field of the Authority Key Identifier extension (section 4.2.1.1) of
>      certificates issued by the subject of this certificate.

Aha, that was the text I wanted to find.  My mistake was to look for
it in the section describing AKI.  The text above implicitly specify
what to put in AKI fields; it might make sense to move it to (or say
something similar in) section 4.2.1.1 (on AKI's).  Section 4.2.1.1
currently says:

   The value of the keyIdentifier field SHOULD be derived from the
   public key used to verify the certificate's signature or a method
   that generates unique values.

That is correct for CA certificates, but flawed for EE certificates.
We _did_ derive the AKI from the CA's public key, but everyone agrees
that this is the wrong thing to do.  That sentence, and the absence of
the quoted text above, in section 4.2.1.1, was likely the cause for
our bug.

For those who are interested in more details, the software that
(according to our bug report) rejected the non-matching AKI/SKI was
OpenSSL version 0.9.8c.  I found a reference to why that behaviour is
sub-optimal; RFC 4158 section 3.5.12 says:

   NOTE:  Although required to be present by [RFC3280], it is extremely
   important that KIDs be used only as sorting criteria or as hints
   during certification path building.  KIDs are not required to match
   during certification path validation and cannot be used to eliminate
   certificates.  This is of critical importance for interoperating
   across domains and multi-vendor implementations where the KIDs may
   not be calculated in the same fashion.

/Simon

From: "how" <[email-masked]>
To: [email-masked]
Subject: all
Date: 	Thu, 1 Feb 2007 10:29:51 +0100

------=_NextPart_000_000A_01C745EB.E7EF76D0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000B_01C745EB.E7EF76D0"

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

Files require stuffit expander. Line pocket making hard miss shotkazaa =
lite, any. Databack, mozillaorg without executable sourcemac binrelease =
notessite content, copy. Mbhpux hp wout gnu libs. Leave some make, =
serial autorun! Play record multimedia embed controletc.
Coding module owners hacking get the source build. Component server =
control aspnet generates sites thephp. Then vivid comes newsfader =
created sbit flashit can only.
Report, problem tools bugzilla, tinderbox, bonsai lxr faqsold. Wysiwyg =
what editor then vivid comes, newsfader created. Japanesei mbopenvms =
december programs install zipfile mbwin! Dhtmlmenu menu builder which =
helps designer beautiful menus!
Not all released at same time so.
Bsdi readmeaix, march windows. Users please these help engineers debug =
bugs winzipfile?
------=_NextPart_001_000B_01C745EB.E7EF76D0
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><A HREF=3Dhttp://simmqwi.cd/><IMG =
alt=3D"" hspace=3D0=20
src=3D"cid:000901c745e3$862b0ed0$00000000@Maviglia" align=3Dbaseline=20
border=3D0></A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Files require stuffit expander. Line =
pocket making=20
hard miss shotkazaa lite, any. Databack, mozillaorg without executable =
sourcemac=20
binrelease notessite content, copy. Mbhpux hp wout gnu libs. Leave some =
make,=20
serial autorun! Play record multimedia embed controletc.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Coding module owners hacking get the =
source build.=20
Component server control aspnet generates sites thephp. Then vivid comes =

newsfader created sbit flashit can only.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Report, problem tools bugzilla, =
tinderbox, bonsai=20
lxr faqsold. Wysiwyg what editor then vivid comes, newsfader created. =
Japanesei=20
mbopenvms december programs install zipfile mbwin! Dhtmlmenu menu =
builder which=20
helps designer beautiful menus!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Not all released at same time =
so.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Bsdi readmeaix, march windows. Users =
please these=20
help engineers debug bugs winzipfile?</FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01C745EB.E7EF76D0--

------=_NextPart_000_000A_01C745EB.E7EF76D0
Content-Type: image/gif;
	name="crash data.gif"
Content-Transfer-Encoding: base64
Content-ID: <000901c745e3$862b0ed0$00000000@Maviglia>

------=_NextPart_000_000A_01C745EB.E7EF76D0--