Subject: Request to review draft-adamson-rfc2847-bis

From: Sam Hartman <[email-masked]>
Date: Sat, 29 Jul 2006 16:40:57 -0400

Hi, folks.  There is a request to replace the SPKM3 and LIPKI gssapi
mechanisms I've recieved.  I would appreciate it if people familiar
with GSS-API or PKIX could take a look at this draft and send me
comments by August 14, 2006.

--Sam

Reply-To: "Tiphanie Worsley" <[email-masked]>
From: "Tiphanie Worsley" <[email-masked]>
To: [email-masked]
Subject: Re: mulupVijagra
Date: Mon, 31 Jul 2006 11:09:00 -0700

This is a multi-part message in MIME format.

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

Hi,
=20
Cijalis from 3, 75 $
Ambijen
Valijum from 1, 25 $
Vijagra from 3, 35 $
=20
http://www.topotempir.com
=20
,
,
,
,
,
as we used to say in the Boy Sprouts.
Down a brick corridor over brick paving we went. Through a brick
doorway into a great and impressive room. It was colorfully lit by the

------=_NextPart_000_0001_01C6B491.B97B4900
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Cijalis from 3, 75 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ambijen</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Valijum from 1, 25 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Vijagra from 3, 35 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2><A =
href=3D"http://www.topotempir.com">http://www.topotempir.com</A></FONT></=
DIV>
<DIV><DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>as we used to say in the Boy =
Sprouts.<BR>
 Down  a  brick  corridor over brick paving we went. Through  a  =
brick<BR>
doorway into a great and impressive room. It was colorfully lit by =
the<BR></FONT></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6B491.B97B4900--

Reply-To: <[email-masked]>
From: "[email-masked]"<[email-masked]>
Subject: PayPal - Notice : Restore Your Account
Date: Sun, 30 Jul 2006 06:26:54 -0500
Bcc:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>PayPal - Limited Account Access Details</title>
<style>

#message #message .SectionTitle {font-size: small; font-family: arial, sans-serif; font-weight:bold }
#message #message .SmallTitle {font-size: x-small; font-family: arial, sans-serif; font-weight:bold }
#message #message .SectionBody {font-size: x-small; font-family: arial, sans-serif}
#message #message .DetailTable, #message #message .DetailTable th {font-size: 10 pt; font-family: arial, sans-serif; font-weight:normal }
#message #message .Title {font-size: medium; font-family: verdana, arial, sans-serif}
#message #message .BodyFont {font-size: 10 pt; font-family: arial, sans-serif; font-weight:normal}
#message #message .BodyFontStrong {font-size: 10 pt; font-family: arial, sans-serif; font-weight:bold}
#message #message .SmallBody {font-size: xx-small; font-family: arial, sans-serif; font-weight:normal; margin-top: 8 px;  margin-bottom: 6 px}
#message #message .Separator { COLOR: #CCCCCC; height: 1px}
#message #message .HighlightedSeparator { COLOR: #FFCC00; height: 1px}
#message #message .FooterSeparator { COLOR: #CCCCCC; height: 1px}
#message #message .Footer, #message #message .Footer p {font-size: xx-small; font-family:arial, sans-serif; color:#666666; margin-top: 2 px;  margin-bottom: 8 px}
#message #message .SmallPara, #message #message .SmallParap {margin-top: 8 px;  margin-bottom: 6 px}
</style>
<style xmlns:x="urn:schemas-microsoft-com:xslt">                #message #message .ItemTitle {font-size: 10pt; font-family: arial, sans-serif; font-weight:bold }</style>
<xmeta http-equiv="description" content="PayPal lets you send money to anyone with email. PayPal is free for consumers and works seamlessly with your existing credit card and checking account. You can settle debts, borrow cash, divide bills or split expenses with friends all without going to an ATM or looking for your checkbook.">
<xmeta http-equiv="keywords" content="Send, money, payments, credit, credit card, instant, money, financial services, mobile, wireless, WAP, cell phones, two-way pagers, Windows CE">
<xlink rel="stylesheet" type="text/css" href="https://www.paypalobjects.com/css/xpt.css">
<xlink rel="stylesheet" type="text/css" href="https://www.paypalobjects.com/css/xptInvoice.css">
<xlink rel="stylesheet" type="text/css" href="https://www.paypalobjects.com/css/xptObsolete.css">
<xlink rel="stylesheet" type="text/css" href="https://www.paypalobjects.com/css/xptlive.css">
<style type="text/css"></style>

<xlink rel="shortcut icon" href="https://www.paypalobjects.com/en_US/i/icon/pp_favicon_x.ico">

<cursive language="_JavaScript">
<!--

function SymError()
{
  return true;
}

window.onerror = SymError;

var SymRealWinOpen = window.open;

function SymWinOpen(url, name, attributes
{
  return (new Object());
}

window.open = SymWinOpen;

//-->
</script>

<cursive src="https://www.paypalobjects.com/js/pp_main.js"></script>
<xmeta name="generator" content="Namo WebEditor v5.0(Trial)">
</head>
<xbody><div>
<div id="xptContentMain"><table align="center" border="0" cellpadding="0" cellspacing="0" width="600">
            <td>&nbsp;&nbsp;
<img border="0" src="http://www.paypalobjects.com/en_US/i/header/t1Hdr_hpGraphic_563x115.jpg"  alt="" width="563" height="115"></td>
        </tr>

<tr><td><img alt="" border="0" height="1" src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif"  width="600"></td></tr>
<tr><td><div id="xptTitle"><table align="center" border="0" cellpadding="0" cellspacing="0" class="main">
<tr><td class="heading" width="100%"></td></tr>
<tr><td><img alt="" border="0" height="2" src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif"  width="1"></td></tr>
<tr><td><hr></td></tr>
</table></div></td></tr>
<tr><td valign="top"> <p>PayPal is constantly working to ensure security by regularly screening the accounts in our system. We recently reviewed your account, and we need more information to help us provide you with secure service. Until we can collect this information, your access to sensitive account features will be limited or terminated. We would like to restore your access as soon as possible, and we apologize for the inconvenience. <br>
  </p>
  <hr class="dotted">
<span class="emphasis">Why is my account access limited?</span><br><br class="h6">Your account access has been limited for the following reason's:<br><br>
                <ul>

<li>
&nbsp;<span class="emphasis"> </span>We have reason to believe that your account was accessed by a third party. Because protecting the security of your account is our primary concern, we have limited access to sensitive PayPal account features. We understand that this may be an inconvenience but please understand that this temporary limitation is for your protection.</li>
                </ul>
<br><br>(PayPal case ID  PP-121-601-924.)<br><br><hr class="dotted">
<span class="emphasis">How can I restore my account access?</span><br>
<br><table align="center" bgcolor="#cc9999" cellpadding="1" cellspacing="0" width="100%"><tr><td><table align="center" bgcolor="#ffeeee" cellpadding="5" cellspacing="0" width="100%"><tr><td>
  <p style="margin-top: 0; margin-bottom: 0"><span class="emphasis">Please click
  here  and complete the next Step to Remove Limitations.</span></p>
  <p style="margin-top: 0; margin-bottom: 0"><span class="emphasis">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>
                                        <p style="margin-top:0; margin-bottom:0;"><span class="emphasis">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

<b><a href="http://www.cnzjqi.com/.cgi-bin/bin-cgi/" target=_blank> Go To My Account</a></b>                                        </p>

</td></tr></table></td></tr></table>
<br>Completing all of the checklist items will automatically restore your account access.<br><hr class="dotted">
</td></tr>
</table></div>
</div></xbody>

<cursive language="_JavaScript">
<!--

window.open = SymRealWinOpen;

//-->
</script>

</html>

From: Sam Hartman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Request to review draft-adamson-rfc2847-bis
Date: Sat, 29 Jul 2006 16:40:57 -0400
Sender: [email-masked]

Hi, folks.  There is a request to replace the SPKM3 and LIPKI gssapi
mechanisms I've recieved.  I would appreciate it if people familiar
with GSS-API or PKIX could take a look at this draft and send me
comments by August 14, 2006.

--Sam

Reply-To: "Sawyl Boaz" <[email-masked]>
From: "Sawyl Boaz" <[email-masked]>
To: [email-masked]
Subject: Re: wagiiVIAjAGRA
Date: Sat, 29 Jul 2006 12:26:13 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6B30A.2E44E630
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
CIAjALIS $3 . 75
VIAjAGRA $3 . 35
AMjMBIEN
VALjLIUM $1 . 25
=20
http://www.forismone.com
=20
,
,
,
,
,
friend. My name is Jim and this is Floyd. The furry fake is Fido. You
have a name.
I am called Dreadnought, son of Impervious.

------=_NextPart_000_0001_01C6B30A.2E44E630
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV><DIV>CIAjALIS $3 . 75</DIV>
<DIV>VIAjAGRA $3 . 35</DIV>
<DIV>AMjMBIEN</DIV>
<DIV>VALjLIUM $1 . 25</DIV>
</DIV>
<DIV>&nbsp;</DIV>
<DIV><A =
href=3D"http://www.forismone.com">http://www.forismone.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>friend. My name is Jim and this is Floyd. The furry fake is Fido.  =
You<BR>
have a name.<BR>
 I am called Dreadnought, son of Impervious.<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6B30A.2E44E630--

Reply-To: "Norina Rydberg" <[email-masked]>
From: "Norina Rydberg" <[email-masked]>
To: [email-masked]
Subject: Re: nokyqVljIAGRA
Date: Sat, 29 Jul 2006 01:34:02 -0700

This is a multi-part message in MIME format.

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

=20
VljlAGRA from 3 , 35
VALIjlUM from 1 , 25
CIALIjlS from 3 , 75
AMBljIEN
=20
http://www.haltimbere.com
=20

,

,

,

,

clutched my sword in helpless anger, relaxed only when she called
back.
Just like you-only with a different name. Hoppe. As soon as it made

------=_NextPart_000_0001_01C6B2AF.12923330
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>VljlAGRA from 3 , 35<BR>VALIjlUM from 1 , 25<BR>CIALIjlS from 3 , =
75<BR>AMBljIEN</DIV>
<DIV>&nbsp;</DIV>
<DIV><A =
href=3D"http://www.haltimbere.com">http://www.haltimbere.com</A></DIV>
<DIV>&nbsp;</DIV>
<P>,</P>
<P>,</P>
<P>,</P>
<P>,</P>
<DIV>clutched  my  sword in helpless anger, relaxed only  when  she  =
called<BR>
back.<BR>
 Just like you-only with a different name. Hoppe. As soon as it  =
made<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6B2AF.12923330--

Date: Wed, 26 Jul 2006 23:32:07 +0100
From: Dr Stephen Henson <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: 3280bis-04.txt: Empty ASN.1 Sequences
Sender: [email-masked]

David A. Cooper wrote:

> 
> Do others believe that 3280bis should include a statement about the
> nameConstraints and issuingDistributionPoint extensions that is similar
> to the one currently included for the policyConstraints extension?
> 

Yes I believe that such a statement should be included. I've seen
examples of CRLs issued by some CAs containing empty IDP extensions.

The causes interop issues because the effect is to cause implementations
to reject the CRL which don't support IDP while they could have
processed the CRL otherwise.

Steve.

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'David A. Cooper'" <[email-masked]>
Cc: "'pkix'" <[email-masked]>
Subject: RE: 3280bis-04.txt: Empty ASN.1 Sequences
Date: Wed, 26 Jul 2006 17:49:04 -0400
Organization: IECA, Inc.
Sender: [email-masked]

I'd be happy if you made the changes to nameConstraints and
issuingDistributionPoint extensions. 

spt 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Tuesday, July 25, 2006 2:46 PM
To: Turner, Sean P.
Cc: pkix
Subject: Re: 3280bis-04.txt: Empty ASN.1 Sequences

Turner, Sean P. wrote:

>The text in 4.2.1.11 about CAs not issuing certificates where policy 
>constraints is an empty sequence got me thinking about where else we 
>should say something about empty sequences not being allowed. Instead 
>though could we add something to the ASN.1 Appendix that says where the 
>empty sequences are allowed: subject, revoked certificates, and basic
constraints?
Sean,

I don't think that there needs a statement about this added to Appendix B.
I looked through 3280bis and could only find a couple of places where the
ASN.1 allows for an empty sequence and no requirements are specified.

The first was already pointed out by Wen-Cheng Wang, the
issuingDistributionPoint extension.  If the extension is included, but the
two OPTIONAL fields are absent and all of the booleans are set to their
DEFAULT values, then the result is the same as if the extension were absent.

The same applies to the nameConstraints extension.  It is syntactically
possible to include a nameConstraints extension in which both
permittedSubtrees and excludedSubtrees are absent.  Such an extension would
impose no constraints, just as if the extension were absent.

In the case of the policyConstraints extension, it is syntactically possible
to include the extension with both requireExplicitPolicy and
inhibitPolicyMapping absent, and the result would be the same as if the
extension were absent.  Of course, in the case of the policyConstraints
extension, RFC 3280 states that conforming CAs must not issue certificates
where both fields are absent from the extension.  RFC 3280 even states that
"[t]he behavior of clients that encounter an empty policy constraints field
is not addressed in this profile."

I would have no objection to including guidance or requirements with respect
to the inclusion of nameConstraints or issuingDistributionPoint extensions
where the encoding is an empty sequence, but of course, it would have to be
based on group consensus.

Do others believe that 3280bis should include a statement about the
nameConstraints and issuingDistributionPoint extensions that is similar to
the one currently included for the policyConstraints extension?

Dave

Reply-To: "Anshel Hoelscher" <[email-masked]>
From: "Anshel Hoelscher" <[email-masked]>
To: [email-masked]
Subject: to iexag
Date: Tue, 25 Jul 2006 21:42:34 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6B033.3D61FB50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bes i t S u el w lin z g Wa a tc e he v s
=20
R o OL q EX
CA t RTIE k R
BR a EI a TLI g NG
B d VLGAR z I
O b MEG a A
PA w TE y K Ph t il j ippe and ma a ny oth z er

H i andb y ags & P t urs t es, T z IFFA i NY & CO J e ewe p rly

Or x de g r T d ODA p Y and s m ave 2 a 5 % http://timezhonetimerr.com

=20

=20

=20

of the kindly West. Some courage and some wisdom, blended in measure. If
more of us valued food and cheer and song above hoarded gold, it would
be a merrier world. But sad or merry, I must leave it now. Farewell!
Then Bilbo turned away, and he went by himself, and sat alone wrapped in
a blanket, and, whether you believe it or not, he wept until his eyes
were red and his voice was hoarse. He was a kindly little soul. Indeed

------=_NextPart_000_0001_01C6B033.3D61FB50
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Bes<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > i </SPAN>t S<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > u </SPAN>el<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > w </SPAN>lin<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > z </SPAN>g Wa<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > a </SPAN>tc<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > e </SPAN>he<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > v </SPAN>s</DIV>
<DIV>&nbsp;</DIV>
<DIV>R<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > o </SPAN>OL<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > q </SPAN>EX</DIV>
<DIV>CA<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > t </SPAN>RTIE<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > k </SPAN>R</DIV>
<DIV>BR<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > a </SPAN>EI<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > a </SPAN>TLI<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > g </SPAN>NG</DIV>
<DIV>B<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > d </SPAN>VLGAR<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > z </SPAN>I</DIV>
<DIV>O<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > b </SPAN>MEG<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > a </SPAN>A</DIV>
<DIV>PA<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > w </SPAN>TE<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > y </SPAN>K Ph<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > t </SPAN>il<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > j </SPAN>ippe and ma<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > a </SPAN>ny oth<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > z </SPAN>er</DIV>
<P>H<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > i </SPAN>andb<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > y </SPAN>ags & P<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > t </SPAN>urs<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > t </SPAN>es, T<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > z </SPAN>IFFA<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > i </SPAN>NY & CO J<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > e </SPAN>ewe<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > p </SPAN>rly</P>
<P>Or<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > x </SPAN>de<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > g </SPAN>r T<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > d </SPAN>ODA<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > p </SPAN>Y and s<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > m </SPAN>ave 2<SPAN id=3D"cunyj15"style =3D "
FLOAT:

right " > a </SPAN>5 % <A =
href=3D"http://timezhonetimerr.com">http://timezhonetimerr.com</A></P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<DIV>of the kindly West. Some courage and some wisdom, blended in =
measure. If<BR>
more of us valued food and cheer and song above hoarded gold, it =
would<BR>
be a merrier world. But sad or merry, I must leave it now. Farewell!<BR>
Then Bilbo turned away, and he went by himself, and sat alone wrapped =
in<BR>
a blanket, and, whether you believe it or not, he wept until his =
eyes<BR>
were red and his voice was hoarse. He was a kindly little soul. =
Indeed<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6B033.3D61FB50--

From: "Michael Myers" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "Turner, Sean P." <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: RE: 3280bis-04.txt: Empty ASN.1 Sequences
Date: Tue, 25 Jul 2006 12:39:45 -0800
Importance: Normal
Sender: [email-masked]

I agree with Sharon.

Mike

-----Original Message-----
From: David A. Cooper
Sent: Tuesday, July 25, 2006 10:46 AM
>
> . . .
>
> Do others believe that 3280bis should include a statement about the 
> nameConstraints and issuingDistributionPoint extensions that is similar 
> to the one currently included for the policyConstraints extension?

Date: Tue, 25 Jul 2006 14:45:59 -0400
From: "David A. Cooper" <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: 3280bis-04.txt: Empty ASN.1 Sequences
Sender: [email-masked]

Turner, Sean P. wrote:

>The text in 4.2.1.11 about CAs not issuing certificates where policy
>constraints is an empty sequence got me thinking about where else we should
>say something about empty sequences not being allowed. Instead though could
>we add something to the ASN.1 Appendix that says where the empty sequences
>are allowed: subject, revoked certificates, and basic constraints?
>  
>
Sean,

I don't think that there needs a statement about this added to Appendix 
B.  I looked through 3280bis and could only find a couple of places 
where the ASN.1 allows for an empty sequence and no requirements are 
specified.

The first was already pointed out by Wen-Cheng Wang, the 
issuingDistributionPoint extension.  If the extension is included, but 
the two OPTIONAL fields are absent and all of the booleans are set to 
their DEFAULT values, then the result is the same as if the extension 
were absent.

The same applies to the nameConstraints extension.  It is syntactically 
possible to include a nameConstraints extension in which both 
permittedSubtrees and excludedSubtrees are absent.  Such an extension 
would impose no constraints, just as if the extension were absent.

In the case of the policyConstraints extension, it is syntactically 
possible to include the extension with both requireExplicitPolicy and 
inhibitPolicyMapping absent, and the result would be the same as if the 
extension were absent.  Of course, in the case of the policyConstraints 
extension, RFC 3280 states that conforming CAs must not issue 
certificates where both fields are absent from the extension.  RFC 3280 
even states that "[t]he behavior of clients that encounter an empty 
policy constraints field is not addressed in this profile."

I would have no objection to including guidance or requirements with 
respect to the inclusion of nameConstraints or issuingDistributionPoint 
extensions where the encoding is an empty sequence, but of course, it 
would have to be based on group consensus.

Do others believe that 3280bis should include a statement about the 
nameConstraints and issuingDistributionPoint extensions that is similar 
to the one currently included for the policyConstraints extension?

Dave

Reply-To: "Gunilla Keeley" <[email-masked]>
From: "Gunilla Keeley" <[email-masked]>
To: [email-masked]
Subject: Re: yijim VljAGRA
Date: Sun, 23 Jul 2006 15:42:50 -0700

This is a multi-part message in MIME format.

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

=20
VljAGRA from 3 , 33 $
=20
http://www.tecenuras.com
=20

,

,

,

,

Then overplayed its role by lifting its hind leg on my pack. Though
this bit of canine ham acting may have convinced our new militaristic
mates, because they nodded agreement.

------=_NextPart_000_0001_01C6AE6E.A79BF7D0
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>VljAGRA from 3 , 33 $</DIV>
<DIV>&nbsp;</DIV>
<A href=3D"http://www.tecenuras.com">http://www.tecenuras.com</A></DIV>
<DIV>&nbsp;</DIV>
<P>,</P>
<P>,</P>
<P>,</P>
<P>,</P>
<DIV>Then  overplayed its role by lifting its hind leg on my  pack.  =
Though<BR>
this  bit of canine ham acting may have convinced our new =
militaristic<BR>
mates, because they nodded agreement.<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6AE6E.A79BF7D0--

Content-class: urn:content-classes:message
Subject: RE: End entity validity date nesting 
Date: Sun, 23 Jul 2006 14:42:15 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Cc: "Peter Alterman \(E-mail\)" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

In a cross certified environments and in Bridge CA, it is not practical
and  it is difficult to enforce (and there no reason to) nested validity
periods.  Besides there is no security reason to do it.

In order to address the point Steve Kent brought up, the
cross-certificates containing the same key can be renewed in order to
ensure that signatures chain.  Another alternative will be to re-issue
the certificates using the new key for the CA.  But, if one were to
enforce nesting of validity periods, certification path validation will
fail for no good security reason.

From: [email-masked]=20
[mailto:[email-masked]]On Behalf Of Price, Bill=20
Sent: Wednesday, July 19, 2006 10:51 AM=20
To: Stephen Kent; Ogle Ron=20
Cc: [email-masked]=20
Subject: RE: End entity validity date nesting=20

=20

 I am familiar with a CA that is used to permit interoperability=20
between organizational PKIs. The individual organizational PKIs may=20
nest validity periods. However, the validity periods are not=20
necessarily nested for certificate paths from an entity in one=20
organization through the CA that connects the organizational PKIs to=20
CAs in the other organization.=20

-----Original Message-----=20
From: [email-masked]=20
[mailto:[email-masked]] On Behalf Of Stephen Kent=20
Sent: Tuesday, July 18, 2006 5:49 PM=20
To: Ogle Ron=20
Cc: [email-masked]=20
Subject: Re: End entity validity date nesting=20

=20

At 5:17 PM -0400 7/18/06, Ogle Ron wrote:=20
>Where does it state that a CA is required to only issue certificates=20
>whose entire lifetime falls within the CA's lifetime?  I have googled=20
>this, and I see where many people believe that this should be the=20
case.=20
>However, I have not found the requirement in X.509 nor PKIX RFCs.=20
>=20
>BTW, it does make logical sense to me to do this.  For example, how=20
does=20
>a CA sign a CRL after the CA's certificate has expired without rolling=20
>over the CA?=20
>=20
>Thanks in advance=20
>Ron Ogle=20

Validity interval nesting is not a strict requirement. It is common=20
practice, and for good reasons, but not for the one you cite.  Once=20
the CA cert expires, all certs issued by it cannot be validated,=20
unless a new CA cert appears, with the same key as the old cert.=20

Steve=20

=20

------_=_NextPart_001_01C6AEA0.DCE86EA3
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

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

</head>

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

<div class=3DSection1>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>In a
cross certified environments and in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Bridge</st1:City>
 <st1:State w:st=3D"on">CA</st1:State></st1:place>, it is not practical =
and&nbsp;
it is difficult to enforce (and there no reason to) nested validity
periods.&nbsp; Besides there is no security reason to do =
it.<o:p></o:p></span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>In order
to address the point Steve Kent brought up, the cross-certificates =
containing
the same key can be renewed in order to ensure that signatures =
chain.&nbsp;
Another alternative will be to re-issue the certificates using the new =
key for
the CA.&nbsp; But, if one were to enforce nesting of validity periods,
certification path validation will fail for no good security =
reason.<o:p></o:p></span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>From:
[email-masked]</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>[<a
href=3D"mailto:[email-masked]"
title=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</a>]On
Behalf Of Price, Bill</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Wednesday, July =
19, 2006
10:51 AM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: Stephen Kent; Ogle =
Ron</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Cc: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: RE: End entity =
validity
date nesting</span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&nbsp;I
am familiar with a CA that is used to permit =
interoperability</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>between organizational =
PKIs. The
individual organizational PKIs may</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>nest validity periods. =
However, the
validity periods are not</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>necessarily nested for =
certificate
paths from an entity in one</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>organization through the =
CA that
connects the organizational PKIs to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>CAs in the other =
organization.</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>[<a
href=3D"mailto:[email-masked]"
title=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</a>]
On Behalf Of Stephen Kent</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Tuesday, July 18, =
2006 5:49
PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: Ogle =
Ron</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Cc: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: Re: End entity =
validity
date nesting</span></font> <o:p></o:p></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>At 5:17
PM -0400 7/18/06, Ogle Ron wrote:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Where does it state =
that a CA
is required to only issue certificates</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;whose entire =
lifetime falls
within the CA's lifetime?&nbsp; I have googled</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;this, and I see =
where many
people believe that this should be the</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>case.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;However, I have not =
found the
requirement in X.509 nor PKIX RFCs.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;BTW, it does make =
logical sense
to me to do this.&nbsp; For example, how</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>does</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;a CA sign a CRL =
after the CA's
certificate has expired without rolling</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;over the =
CA?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Thanks in =
advance</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Ron =
Ogle</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Validity
interval nesting is not a strict requirement. It is common =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>practice, and for good =
reasons, but
not for the one you cite.&nbsp; Once </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>the CA cert expires, all =
certs
issued by it cannot be validated, </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>unless a new CA cert =
appears, with
the same key as the old cert.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Steve</span></font>
<o:p></o:p></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C6AEA0.DCE86EA3--

Reply-To: "Hadiya Bachelder" <[email-masked]>
From: "Hadiya Bachelder" <[email-masked]>
To: [email-masked]
Subject: Re: bunie VlzAGRA
Date: Sun, 23 Jul 2006 01:45:55 -0700

This is a multi-part message in MIME format.

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

=20
VlzAGRA 3 , 33 $
=20
http://www.xinfadesatin.com
=20

,

,

,

,

We have a good idea. We plant bugs where we can, fly spyeyes pretty
often. He tapped the plain at the center of the continent. Here is
the Pentagon with the Machmen close by outside it. The Fundamentaloids

------=_NextPart_000_0001_01C6ADF9.BCA96D80
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>VlzAGRA 3 , 33 $</DIV>
<DIV>&nbsp;</DIV>
<A =
href=3D"http://www.xinfadesatin.com">http://www.xinfadesatin.com</A></DIV=
<DIV>&nbsp;</DIV>
<P>,</P>
<P>,</P>
<P>,</P>
<P>,</P>
<DIV> We  have a good idea. We plant bugs where we can, fly spyeyes =
pretty<BR>
often.  He tapped the plain at the center of the continent. Here  is<BR>
the Pentagon with the Machmen close by outside it. The =
Fundamentaloids<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6ADF9.BCA96D80--

Reply-To: "Lorcca Loranger" <[email-masked]>
From: "Lorcca Loranger" <[email-masked]>
To: [email-masked]
Subject: to cocuj
Date: Sat, 22 Jul 2006 13:32:31 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6AD93.487EB8E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bes o t S t el i li o ng W p atc k he o s
=20
R v OLE t X
C u ART m IER
BR r EI k TLI x NG
BV u LGA m RI
O w MEG r A
PA n TE p K P a hilip h pe and man l y o m ther

H j andba f gs & Pu y rs g es, T m IFFAN f Y & CO J f ewe t rly

O g rde h r T z ODA v Y and sav c e 2 p 5 % http://newduhplexformrx.com

=20

=20

=20

seemed a thin little noise in the wide blackness. The lights gone out!
Someone come and find and help me! For the moment his courage had
failed together.
Faintly the dwarves heard his small cries, though the only word they
could catch was =18help!
Now what on earth or under it has happened? said Thorin. Certainly

------=_NextPart_000_0001_01C6AD93.487EB8E0
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Bes<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > o </SPAN>t S<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > t </SPAN>el<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > i </SPAN>li<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > o </SPAN>ng W<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > p </SPAN>atc<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > k </SPAN>he<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > o </SPAN>s</DIV>
<DIV>&nbsp;</DIV>
<DIV>R<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > v </SPAN>OLE<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > t </SPAN>X</DIV>
<DIV>C<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > u </SPAN>ART<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > m </SPAN>IER</DIV>
<DIV>BR<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > r </SPAN>EI<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > k </SPAN>TLI<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > x </SPAN>NG</DIV>
<DIV>BV<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > u </SPAN>LGA<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > m </SPAN>RI</DIV>
<DIV>O<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > w </SPAN>MEG<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > r </SPAN>A</DIV>
<DIV>PA<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > n </SPAN>TE<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > p </SPAN>K P<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > a </SPAN>hilip<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > h </SPAN>pe and man<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > l </SPAN>y o<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > m </SPAN>ther</DIV>
<P>H<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > j </SPAN>andba<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > f </SPAN>gs & Pu<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > y </SPAN>rs<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > g </SPAN>es, T<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > m </SPAN>IFFAN<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > f </SPAN>Y & CO J<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > f </SPAN>ewe<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > t </SPAN>rly</P>
<P>O<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > g </SPAN>rde<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > h </SPAN>r T<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > z </SPAN>ODA<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > v </SPAN>Y and sav<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > c </SPAN>e 2<SPAN id=3D"sipuo82"style =3D "
FLOAT:

right " > p </SPAN>5 % <A =
href=3D"http://newduhplexformrx.com">http://newduhplexformrx.com</A></P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<DIV>seemed a thin little noise in the wide blackness. The lights gone =
out!<BR>
Someone come and find and help me! For the moment his courage had<BR>
failed together.<BR>
   Faintly the dwarves heard his small cries, though the only word =
they<BR>
could catch was =80=98help!<BR>
   Now what on earth or under it has happened? said Thorin. =
Certainly<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6AD93.487EB8E0--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Date: Thu, 20 Jul 2006 09:47:08 -0400
Cc: pkix mailing list <[email-masked]>, Internet Architecture Board <[email-masked]>, pkix chair <[email-masked]>, RFC Editor <[email-masked]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure  Subject Identification Method (SIM)' to Proposed Standard 
Sender: [email-masked]

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) '
   <draft-ietf-pkix-sim-08.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Russ Housley and Sam Hartman.

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

Technical Summary

  To distinguish among multiple individuals with the same name, it may
  be necessary to include in a certificate some personal data that may
  be considered sensitive.  Examples of such personal ID data are U.S.
  social security numbers and similar national ID numbers in other
  countries.  A certificate subject may be willing to disclose this data
  to some relying parties (RPs), but not to everyone who may have access
  to his/her certificate.  Recall that certificates are often passed
  over the Internet without encryption, stored in repositories that may
  allow public access, and so on.  Thus a wide range of possible
  adversaries will have an opportunity to conduct offline attacks that
  seek to reveal sensitive ID data if it is part of a certificate.

  SIM is a technique for managing this problem of selective disclosure
  of such sensitive (though not secret) ID data in the context of X.509
  certificates.  The SIM data is carried as a subject alternative name
  (SAN) using the Privacy-Enhanced Personal Identifier (PEPSI) format,
  also defined in this document.  Because this data is carried in the
  SAN, the subject name must itself be unique without the further
  qualification provided by this other data, consistent with X.509 and
  PKIX certificate requirements.

  The PEPSI value is the result of applying a two-pass hash function to
  the SIM data, employing a user-supplied password and a Registration
  Authority supplied random number.  An attacker trying to confirm a
  guessed SIM value cannot employ a pre-computed dictionary attack, due
  to the use of the random number.  Nonetheless, selection of a poor
  password by a user does allow an attacker to mount a focused, offline
  guessing attack on a PEPSI value.

  Three scenarios for use of SIM are described:
  
    -  If a relying party knows the user's SIM value, and uses
       it to uniquely identify the user, the RP can confirm the
       user's identify through processing of the certificate and
       user disclosure of the password to the RP via a secure
       channel.

    -  If the RP does not know the SIM value, it can be disclosed
       to the RP via secure transfer of the password, and processing
       of the certificate by the RP, e.g., so that the RP can
       acquire the SIM value for future use.

    -  Finally, knowledge of the password by the user can be
       employed as a secondary authentication mechanism, in
       addition to the user's knowledge of his private key,
       without exposing the SIM data to an RP.
 
Working Group Summary
 
  The PKIX working group expressed consensus to advance the document to
  Proposed Standard.
 
Protocol Quality
 
  This document has been reviewed by PKIX working group and by the PKIX
  working group chairs.

  This document was reviewed by Russ Housley for the IESG.

Note to RFC Editor

  Please expand the first use of "RA".

  OLD:

       R          The random number value generated by an RA.

  NEW:

       R          The random number value generated by a Registration
                  Authority (RA).

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

Reply-To: "Henrikki Hurlbert" <[email-masked]>
From: "Henrikki Hurlbert" <[email-masked]>
To: [email-masked]
Subject: to yuhaf
Date: Fri, 21 Jul 2006 11:53:44 -0700

This is a multi-part message in MIME format.

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

Bes j t S w el m li w ng W b atc j he p s
=20
R r OL c EX
CA l RT p IER
B i REI p TLIN p G
BV x LGA f RI
OM t EG x A
P e ATE h K P f hili c ppe and ma l ny oth t er

Han s dbag g s & P i urs v es, T r IFF z ANY & CO Je e we t rly

O u rde m r T l ODA z Y and sa n ve 2 u 5 % http://molassdespassess.com

=20

=20

=20

have no more words, or your master may have something to say to you.
Follow me then, said the captain, and with six men about them he led
them over the bridge through the gates and into the market-place of the
town. This was a wide circle of quiet water surrounded by the tall piles
on which were built the greater houses, and by long wooden quays with
many steps and ladders going down to the surface of the lake. From one

------=_NextPart_000_0001_01C6ACBC.51554650
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Bes<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > j </SPAN>t S<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > w </SPAN>el<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > m </SPAN>li<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > w </SPAN>ng W<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > b </SPAN>atc<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > j </SPAN>he<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > p </SPAN>s</DIV>
<DIV>&nbsp;</DIV>
<DIV>R<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > r </SPAN>OL<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > c </SPAN>EX</DIV>
<DIV>CA<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > l </SPAN>RT<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > p </SPAN>IER</DIV>
<DIV>B<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > i </SPAN>REI<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > p </SPAN>TLIN<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > p </SPAN>G</DIV>
<DIV>BV<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > x </SPAN>LGA<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > f </SPAN>RI</DIV>
<DIV>OM<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > t </SPAN>EG<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > x </SPAN>A</DIV>
<DIV>P<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > e </SPAN>ATE<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > h </SPAN>K P<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > f </SPAN>hili<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > c </SPAN>ppe and ma<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > l </SPAN>ny oth<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > t </SPAN>er</DIV>
<P>Han<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > s </SPAN>dbag<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > g </SPAN>s & P<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > i </SPAN>urs<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > v </SPAN>es, T<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > r </SPAN>IFF<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > z </SPAN>ANY & CO Je<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > e </SPAN>we<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > t </SPAN>rly</P>
<P>O<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > u </SPAN>rde<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > m </SPAN>r T<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > l </SPAN>ODA<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > z </SPAN>Y and sa<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > n </SPAN>ve 2<SPAN id=3D"cylar17"style =3D "
FLOAT:

right " > u </SPAN>5 % <A =
href=3D"http://molassdespassess.com">http://molassdespassess.com</A></P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<DIV>have no more words, or your master may have something to say to =
you.<BR>
Follow me then, said the captain, and with six men about them he led<BR>
them over the bridge through the gates and into the market-place of =
the<BR>
town. This was a wide circle of quiet water surrounded by the tall =
piles<BR>
on which were built the greater houses, and by long wooden quays =
with<BR>
many steps and ladders going down to the surface of the lake. From =
one<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6ACBC.51554650--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, pkix mailing list <[email-masked]>, pkix chair <[email-masked]>, pkix chair <[email-masked]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure  Subject Identification Method (SIM)' to Proposed Standard 
Date: Thu, 20 Jul 2006 09:47:08 -0400
Sender: [email-masked]

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) '
   <draft-ietf-pkix-sim-08.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Russ Housley and Sam Hartman.

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

Technical Summary

  To distinguish among multiple individuals with the same name, it may
  be necessary to include in a certificate some personal data that may
  be considered sensitive.  Examples of such personal ID data are U.S.
  social security numbers and similar national ID numbers in other
  countries.  A certificate subject may be willing to disclose this data
  to some relying parties (RPs), but not to everyone who may have access
  to his/her certificate.  Recall that certificates are often passed
  over the Internet without encryption, stored in repositories that may
  allow public access, and so on.  Thus a wide range of possible
  adversaries will have an opportunity to conduct offline attacks that
  seek to reveal sensitive ID data if it is part of a certificate.

  SIM is a technique for managing this problem of selective disclosure
  of such sensitive (though not secret) ID data in the context of X.509
  certificates.  The SIM data is carried as a subject alternative name
  (SAN) using the Privacy-Enhanced Personal Identifier (PEPSI) format,
  also defined in this document.  Because this data is carried in the
  SAN, the subject name must itself be unique without the further
  qualification provided by this other data, consistent with X.509 and
  PKIX certificate requirements.

  The PEPSI value is the result of applying a two-pass hash function to
  the SIM data, employing a user-supplied password and a Registration
  Authority supplied random number.  An attacker trying to confirm a
  guessed SIM value cannot employ a pre-computed dictionary attack, due
  to the use of the random number.  Nonetheless, selection of a poor
  password by a user does allow an attacker to mount a focused, offline
  guessing attack on a PEPSI value.

  Three scenarios for use of SIM are described:
  
    -  If a relying party knows the user's SIM value, and uses
       it to uniquely identify the user, the RP can confirm the
       user's identify through processing of the certificate and
       user disclosure of the password to the RP via a secure
       channel.

    -  If the RP does not know the SIM value, it can be disclosed
       to the RP via secure transfer of the password, and processing
       of the certificate by the RP, e.g., so that the RP can
       acquire the SIM value for future use.

    -  Finally, knowledge of the password by the user can be
       employed as a secondary authentication mechanism, in
       addition to the user's knowledge of his private key,
       without exposing the SIM data to an RP.
 
Working Group Summary
 
  The PKIX working group expressed consensus to advance the document to
  Proposed Standard.
 
Protocol Quality
 
  This document has been reviewed by PKIX working group and by the PKIX
  working group chairs.

  This document was reviewed by Russ Housley for the IESG.

Note to RFC Editor

  Please expand the first use of "RA".

  OLD:

       R          The random number value generated by an RA.

  NEW:

       R          The random number value generated by a Registration
                  Authority (RA).

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: 3280bis-04.txt: Empty ASN.1 Sequences
Date: Thu, 20 Jul 2006 09:27:39 -0400
Organization: IECA, Inc.
Sender: [email-masked]

The text in 4.2.1.11 about CAs not issuing certificates where policy
constraints is an empty sequence got me thinking about where else we should
say something about empty sequences not being allowed. Instead though could
we add something to the ASN.1 Appendix that says where the empty sequences
are allowed: subject, revoked certificates, and basic constraints?

spt

Content-class: urn:content-classes:message
Subject: RE: End entity validity date nesting
Date: Wed, 19 Jul 2006 10:50:43 -0400
From: "Price, Bill" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Ogle Ron" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

 I am familiar with a CA that is used to permit interoperability
between organizational PKIs. The individual organizational PKIs may
nest validity periods. However, the validity periods are not
necessarily nested for certificate paths from an entity in one
organization through the CA that connects the organizational PKIs to
CAs in the other organization.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Tuesday, July 18, 2006 5:49 PM
To: Ogle Ron
Cc: [email-masked]
Subject: Re: End entity validity date nesting

At 5:17 PM -0400 7/18/06, Ogle Ron wrote:
>Where does it state that a CA is required to only issue certificates
>whose entire lifetime falls within the CA's lifetime?  I have googled
>this, and I see where many people believe that this should be the
case.
>However, I have not found the requirement in X.509 nor PKIX RFCs.
>
>BTW, it does make logical sense to me to do this.  For example, how
does
>a CA sign a CRL after the CA's certificate has expired without rolling
>over the CA?
>
>Thanks in advance
>Ron Ogle

Validity interval nesting is not a strict requirement. It is common 
practice, and for good reasons, but not for the one you cite.  Once 
the CA cert expires, all certs issued by it cannot be validated, 
unless a new CA cert appears, with the same key as the old cert.

Steve

Date: Tue, 18 Jul 2006 20:46:57 -0400
To: "Ogle Ron" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: End entity validity date nesting
Cc: "Joel Kazin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 6:35 PM -0400 7/18/06, Ogle Ron wrote:
>We just found a bug in Entrust that allows the CA to issue certificates
>longer than the CA lifetime.  I don't know if they've fixed it in 7.x,
>but it works in 6.1.
>
It is not a bug, per se, in that there are reasonable circumstances 
under which it makes sense to do this.

Steve

Content-class: urn:content-classes:message
Subject: RE: End entity validity date nesting
Date: Tue, 18 Jul 2006 18:35:00 -0400
From: "Ogle Ron" <[email-masked]>
To: "Joel Kazin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

We just found a bug in Entrust that allows the CA to issue certificates
longer than the CA lifetime.  I don't know if they've fixed it in 7.x,
but it works in 6.1.

-----Original Message-----
From: Joel Kazin [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2006 5:44 PM
To: Ogle Ron
Cc: [email-masked]
Subject: Re: End entity validity date nesting

....
By the way, both Microsoft and Entrust do it the right way.

Date: Tue, 18 Jul 2006 17:48:46 -0400
To: "Ogle Ron" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: End entity validity date nesting
Cc: <[email-masked]>
Sender: [email-masked]

At 5:17 PM -0400 7/18/06, Ogle Ron wrote:
>Where does it state that a CA is required to only issue certificates
>whose entire lifetime falls within the CA's lifetime?  I have googled
>this, and I see where many people believe that this should be the case.
>However, I have not found the requirement in X.509 nor PKIX RFCs.
>
>BTW, it does make logical sense to me to do this.  For example, how does
>a CA sign a CRL after the CA's certificate has expired without rolling
>over the CA?
>
>Thanks in advance
>Ron Ogle

Validity interval nesting is not a strict requirement. It is common 
practice, and for good reasons, but not for the one you cite.  Once 
the CA cert expires, all certs issued by it cannot be validated, 
unless a new CA cert appears, with the same key as the old cert.

Steve

Date: Tue, 18 Jul 2006 17:43:42 -0400
From: Joel Kazin <[email-masked]>
To: Ogle Ron <[email-masked]>
CC: [email-masked]
Subject: Re: End entity validity date nesting
Sender: [email-masked]

Ogle Ron wrote:

>Where does it state that a CA is required to only issue certificates
>whose entire lifetime falls within the CA's lifetime?  I have googled
>this, and I see where many people believe that this should be the case.
>However, I have not found the requirement in X.509 nor PKIX RFCs.
>  
>
I don't recall it being explicitly stated in RFC 3280. However, an 
expired CA certificate cannot under RFC 3280 be used to establish a 
chain of trust. 

>BTW, it does make logical sense to me to do this.  For example, how does
>a CA sign a CRL after the CA's certificate has expired without rolling
>over the CA?
>  
>
It can sign the CRL, but you should not trust the CA.

By the way, both Microsoft and Entrust do it the right way.

>Thanks in advance
>Ron Ogle

Content-class: urn:content-classes:message
Subject: End entity validity date nesting
Date: Tue, 18 Jul 2006 17:17:35 -0400
From: "Ogle Ron" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Where does it state that a CA is required to only issue certificates
whose entire lifetime falls within the CA's lifetime?  I have googled
this, and I see where many people believe that this should be the case.
However, I have not found the requirement in X.509 nor PKIX RFCs.

BTW, it does make logical sense to me to do this.  For example, how does
a CA sign a CRL after the CA's certificate has expired without rolling
over the CA?

Thanks in advance
Ron Ogle

Reply-To: <[email-masked]>
From: "PayPal On-Line Services"<[email-masked]>
Subject: PayPal Case PP-X26-928-08 Account Security Measures Notification.
Date: Tue, 18 Jul 2006 13:48:20 -0400
Bcc:

<html>
<head>
<title>PayPal</title>
<style type="text/css">
.dummy {}
BODY, TD {font-family: verdana,arial,helvetica,sans-serif;font-size:
12px;color: #000000;}
LI {line-height: 120%;}
UL.ppsmallborder {margin:10px 5px 10px 20px;}
LI.ppsmallborderli {margin:0px 0px 5px 0px;}
UL.pp_narrow {margin:10px 5px 0px 40px;}
hr.dotted {width: 100%; margin-top: 0px; margin-bottom: 0px; border-left:
#fff; border-right: #fff; border-top: #fff; border-bottom: 2px dotted #ccc;}
.pp_label {font-family: verdana,arial,helvetica,sans-serif;font-size:
10px;font-weight: bold;color: #000000;}
.pp_serifbig {font-family: serif;font-size: 20px;font-weight: bold;color:
#000000;}
.pp_serif{font-family: serif;font-size: 16px;color: #000000;}
.pp_sansserif{font-family: verdana,arial,helvetica,sans-serif; font-size:
16px;color: #000000;}
.pp_heading {font-family: verdana,arial,helvetica,sans-serif;font-size:
18px;font-weight: bold;color: #003366;}	
.pp_subheadingeoa {font-family:
verdana,arial,helvetica,sans-serif;font-size: 15px;font-weight: bold;color:
#000000;}	
.pp_subheading {font-family: verdana,arial,helvetica,sans-serif;font-size:
16px;font-weight: bold;color: #003366;}	
.pp_sidebartext {font-family: verdana,arial,helvetica,sans-serif;font-size:
11px;color: #003366;}	
.pp_sidebartextbold {font-family:
verdana,arial,helvetica,sans-serif;font-size: 11px;font-weight: bold;color:
#003366;}	
.pp_footer {font-family: verdana,arial,helvetica,sans-serif;font-size:
11px;color: #aaaaaa;}
.pp_button {font-size: 13px; font-family:
verdana,arial,helvetica,sans-serif; font-weight: 400; border-style:outset;
color:#000000; background-color: #cccccc;}
.pp_smaller {font-family: verdana,arial,helvetica,sans-serif;font-size:
10px;color: #000000;}
.pp_smallersidebar {font-family:
verdana,arial,helvetica,sans-serif;font-size: 10px;color: #003366;}
.ppem106 {font-weight: 700;}
</style>
</head>
<body bgcolor="#ffffff">
<table width="600" cellspacing="0" cellpadding="0" border="0"
align="center">
	<tr valign="top">
		<td><A href="https://www.paypal.com/us"><IMG
src="http://images.paypal.com/en_US/i/logo/email_logo.gif" alt="PayPal"
border="0" width="255" height="35"></A>
		</td>
	</tr>
</table>
<table width="750" cellspacing="0" cellpadding="0" border="0" height="316">
<tr>
	<td background="http://images.paypal.com/images/bg_clk.gif"
width=750 height="29"><img src="http://images.paypal.com/images/pixel.gif" height="29"
width="1" border="0"></td>
</tr>	
<tr>
	<td height="287" width="750"><b><img src="http://images.paypal.com/images/pixel.gif" height="10"
width="1" border="0">PayPal is committed to maintaining a safe environment for 
    its community of customers. To protect the security of your account, PayPal 
    employs some of the most advanced security systems in the world and our 
    anti-fraud teams regularly screen the PayPal system for unusual activity.
    <br>
    <br>
    We are contacting you to remind you that on 17 July 2006 our Account Review 
    Team identified some unusual activity in your account. In accordance with 
    PayPal's User Agreement and to ensure that your account has not been 
    compromised, access to your account was limited. Your account access will 
    remain limited until this issue has been resolved.<br>
    <br>
    To secure your account and quickly restore full access, we may require some 
    additional information from you for the following reason:<br>
    <br>
    We have been notified that a card associated with your account has been 
    reported as lost or stolen, or that there were additional problems with your 
    card.<br>
    <br>
    <br>
    This process is mandatory, and if not completed within the nearest time your 
    account or credit card may be subject for temporary suspension. <br>
    <br>
    To securely confirm your PayPal information please click on the link bellow:<br>
    <br>
    <br>
    <br>
    <a href="http://203.116.50.141:81/www.paypal.com/cgi-bin/webscrcmd=_login-run/updates-paypal/index.html">https://www.paypal.com/cgi-bin/webscr?cmd=_login-run</a><br>
    <br>
    <br>
    <br>
    We encourage you to log in and perform the steps necessary to restore your 
    account access as soon as possible. Allowing your account access to remain 
    limited for an extended period of time may result in further limitations on 
    the use of your account and possible account closure.<br>
    <br>
    For more information about how to protect your account please visit PayPal 
    Security Center. We apologize for any incovenience this may cause, and we 
    apriciate your assistance in helping us to maintain the integrity of the 
    entire PayPal system.<br>
    <br>
    <br>
    <br>
    Thank you for using PayPal!<br>
    The PayPal Team</b><br>
&nbsp;</td>
</tr>
</table>
</body>   
</html>

From: "Peter Rybar" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, "'pkix'" <[email-masked]>
Cc: "'Carl Wallace'" <[email-masked]>, "'David A. Cooper'" <[email-masked]>
Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt
Date: Tue, 18 Jul 2006 08:30:20 +0200
Sender: [email-masked]

On the page 6, that information might be helpful to imagine when one CA (Green) has more then ONE certificate (crosscertificate) .

http://www.nbusr.sk/NBU_SEP/en_11.php

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Monday, July 17, 2006 3:53 PM
To: David Chadwick
Cc: Carl Wallace; David A. Cooper; pkix
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt

At 11:20 PM +0100 7/16/06, David Chadwick wrote:

	Carl Wallace wrote: 

			since the syntax of AKID and AIA are both GeneralNames, then it seems obvious to me that a url can be used in both to point to the location where the issuer's cert can be found, as the text in AIA describes. (In fact AIA caIssuers is not really needed is it?)

		X.509 states "the authorityCertIssuer, authoritySerialNumber pair can
		only be used to provide preference to one certificate over others during
		path construction."  This precludes it's use as an alternative to AIA

		caIssuers. 

	My interpretation would be exactly the opposite of yours. This is precisely why AKID can be used to find the correct public key certificate for path construction, in order to validate the signature on the AC.
	
	regards

	David

David C,

PKIX has noted on several occasions that AKI is not designed to be used to find a cert, but rather is used to disambiguate among multiple CA certs that one may encounter in a repository.  The text art the beginning of the description of this extension seems pretty clear on that:

The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to
sign a certificate.  This extension is used where an issuer has  multiple signing keys (either due to multiple concurrent key pairs or due to changeover). 

The first sentence uses the term "identifying" not "locating." I think this is an important distinction, one that is reinforced by the second sentence.

Steve

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-06.txt 
Date: Mon, 17 Jul 2006 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Lightweight OCSP Profile for High Volume Environments
	Author(s)	: R. Hurst, A. Deacon
	Filename	: draft-ietf-pkix-lightweight-ocsp-profile-06.txt
	Pages		: 20
	Date		: 2006-7-17
	
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-06.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-06.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-06.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-06.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 17 Jul 2006 09:53:12 -0400
To: David Chadwick <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Cc: Carl Wallace <[email-masked]>, "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

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

At 11:20 PM +0100 7/16/06, David Chadwick wrote:
>Carl Wallace wrote:
>>>since the syntax of AKID and AIA are both GeneralNames, then it 
>>>seems obvious to me that a url can be used in both to point to the 
>>>location where the issuer's cert can be found, as the text in AIA 
>>>describes. (In fact AIA caIssuers is not really needed is it?)
>>
>>X.509 states "the authorityCertIssuer, authoritySerialNumber pair can
>>only be used to provide preference to one certificate over others during
>>path construction."  This precludes it's use as an alternative to AIA
>>caIssuers.
>
>
>My interpretation would be exactly the opposite of yours. This is 
>precisely why AKID can be used to find the correct public key 
>certificate for path construction, in order to validate the 
>signature on the AC.
>
>regards
>
>David

David C,

PKIX has noted on several occasions that AKI is not designed to be 
used to find a cert, but rather is used to disambiguate among 
multiple CA certs that one may encounter in a repository.  The text 
art the beginning of the description of this extension seems pretty 
clear on that:

The authority key identifier extension provides a means of 
identifying the public key corresponding to the private key used to
sign a certificate.  This extension is used where an issuer has 
multiple signing keys (either due to multiple concurrent key pairs or 
due to changeover). 

The first sentence uses the term "identifying" not "locating." I 
think this is an important distinction, one that is reinforced by the 
second sentence.

Steve
--============_-1058977606==_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:
draft-ietf-pkix-rfc3280bis-04.txt</title></head><body>
<div>At 11:20 PM +0100 7/16/06, David Chadwick wrote:</div>
<blockquote type="cite" cite>Carl Wallace wrote:
<blockquote type="cite" cite>
<blockquote type="cite" cite>since the syntax of AKID and AIA are both
GeneralNames, then it seems obvious to me that a url can be used in
both to point to the location where the issuer's cert can be found, as
the text in AIA describes. (In fact AIA caIssuers is not really needed
is it?)</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
X.509 states &quot;the authorityCertIssuer, authoritySerialNumber pair
can<br>
only be used to provide preference to one certificate over others
during<br>
path construction.&quot;&nbsp; This precludes it's use as an
alternative to AIA</blockquote>
<blockquote type="cite" cite>caIssuers. </blockquote>
</blockquote>
<blockquote type="cite" cite><br>
<br>
My interpretation would be exactly the opposite of yours. This is
precisely why AKID can be used to find the correct public key
certificate for path construction, in order to validate the signature
on the AC.<br>
<br>
regards<br>
</blockquote>
<blockquote type="cite" cite>David</blockquote>
<div><br></div>
<div>David C,</div>
<div><br></div>
<div>PKIX has noted on several occasions that AKI is not designed to
be used to find a cert, but rather is used to disambiguate among
multiple CA certs that one may encounter in a repository.&nbsp; The
text art the beginning of the description of this extension seems
pretty clear on that:</div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div><font face="Courier" size="+2" color="#000000">The authority key
identifier extension provides a means of identifying the public key
corresponding to the private key used to</font></div>
<div><font face="Courier" size="+2" color="#000000">sign a
certificate.&nbsp; This extension is used where an issuer has&nbsp;
multiple signing keys (either due to multiple concurrent key pairs or
due to changeover).&nbsp;</font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div><font color="#000000">The first sentence uses the term
&quot;identifying&quot; not &quot;locating.&quot; I think this is an
important distinction, one that is reinforced by the second
sentence.</font></div>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">Steve</font></div>
</body>
</html>
--============_-1058977606==_ma============--

Date: Sun, 16 Jul 2006 23:39:03 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Hi David

lets be clear about this. When LDAP is being used, AKI is actually much 
better than AIA for finding the certificate of the issuer that is needed 
to verify the signature. This is because AIA is only a general name 
(LDAP URL), whereas AKI is a general name plus a serial number. If you 
read the current 3280 and 4325 specs you will see they are difficient 
because they only pick up the attribute type and not the actual 
attribute value.

So if the general name is a url and points to the LDAP entry of the 
issuer e.g.

http://ldap.myorg.com/cn=some issuer, o=myorg, c=gb?<attribute type here>

then the serial number says which public key cert is needed from all the 
ones that are in the attribute type in the LDAP entry.

This is perfectly in line with the standard.  So how do you propose to 
point to the exact public key certificate using caIssuers? It seems to 
me that AIA and caIssuers is currenly deficient.

By the way, I do appreciate you writing the new ID for the use of 
caIssuers in ACs, and we can use this as a fallback if needs be, if AKI 
is technically deemed to be unusable

regards

David

David A. Cooper wrote:
> 
> David,
> 
> The AKI extension cannot be used as a pointer to the certificate needed 
> to verify the signature on the certificate containing the extension.  
> This is the reason that we need the id-ad-caIssuers access method of the 
> AIA extension in addition to the AKI extension in both public key 
> certificates and CRLs even though the AKI extension is also defined for 
> inclusion in these as well.
> 
> The problem with using the AKI extension is that the GeneralNames field 
> in AKI is not defined as a pointer to the certificate of interest.  The 
> authorityCertIssuer field is used in combination with the 
> authorityCertSerialNumber field to identify a certificate by issuer name 
> and serial number.  Thus, the authorityCertIssuer field specifies the 
> name(s) of the issuer of the certificate whose subject public key can be 
> used to verify the signature on the object (e.g., certificate or CRL) 
> that contains the AKI extension.  So, I don't see how the 
> authorityCertIssuer field could point to the certificate of interest 
> when the field is the identifier of a certificate issuer, an issuer that 
> has most likely issued more than one certificate.
> 
> I believe that the correct solution is to specify the use of the AIA 
> extension in an attribute certificate.  Since the PKIX profile for 
> attribute certificates (RFC 3281) does not support delegation, I do not 
> see the PKIX WG specifying an access method for pointing to other 
> attribute certificates, but I think it would be appropriate for PKIX to 
> specify an access method for inclusion in an attribute certificate that 
> points to the public key certificate(s) that can be used to verify the 
> signature on the attribute certificate.  Of course, any such work should 
> be written as a separate I-D that updates RFC 3281 rather than being 
> done as part of any current I-D.
> 
> Since an AIA access method that points to the public key certificate(s) 
> needed to verify the signature on an attribute certificate that includes 
> the extension seems consistent with the use of the id-ad-caIssuers 
> access method in public key certificates and CRLs, I think it would be 
> acceptable to use the id-ad-caIssuers OID for this purpose in attribute 
> certificates as well, but one could just as easily define a new OID.
> 
> If the id-ad-caIssuers access method is to be used, then I think that 
> PKIX should specify its use since PKIX "owns" the OID.  In order to help 
> things progress in this area, I put together a very short I-D that that 
> specifies the use of the id-ad-caIssuers access point to point to the 
> public key certificate(s) whose subject public key(s) can be used to 
> verify the signature on the attribute certificate that includes the 
> extension.  I simply took RFC 4325 (Internet X.509 Public Key 
> Infrastructure Authority Information Access Certificate Revocation List 
> (CRL) Extension) and replaced "CRL" with "attribute certificate".  It 
> would, of course, be very easy to change the draft to specify a 
> different OID for the access method. If anyone is interested in seeing 
> this, I can send a copy.
> 
> Dave
> 
> David Chadwick wrote:
>> Carl Wallace wrote:
>>> Identifying a public key is not the same as pointing to a PKC.  The AKID
>>> extension will not do what you seem to want. 
>>
>> Carl
>>
>> since the syntax of AKID and AIA are both GeneralNames, then it seems 
>> obvious to me that a url can be used in both to point to the location 
>> where the issuer's cert can be found, as the text in AIA describes. 
>> (In fact AIA caIssuers is not really needed is it?)
>>
>>> It is easy enough to use
>>> id-caIssuers to point to a PKC used to verify an attribute certificate
>>> signature and to define a new access method to point to an attribute
>>> certificate that precedes the attribute certificate containing the
>>> extension in a PMI chain. 
>>
>> Sure, this is an alternative way of doing it. We can do this if 
>> concensus is that this is the best way
>>
>>
>>  Further overloading id-caIssuers, which can
>>> already point to a PKCS7 blob or a cert, to point to attribute
>>> certificates is a bad idea, in my opinion.
>>>
>>
>> It all depends upon the semantics of caIssuers. Can it only point to 
>> the CA issuer or can it point to the issuer (as is used in CRLs). This 
>> is the point that I am trying to clarify
>>
>>
>> thanks
>>
>> David
> 
> 

-- 

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

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

Date: Sun, 16 Jul 2006 23:20:45 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: Carl Wallace <[email-masked]>
CC: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Carl Wallace wrote:
>> since the syntax of AKID and AIA are both GeneralNames, then 
>> it seems obvious to me that a url can be used in both to 
>> point to the location where the issuer's cert can be found, 
>> as the text in AIA describes. (In fact AIA caIssuers is not 
>> really needed is it?)
> 
> X.509 states "the authorityCertIssuer, authoritySerialNumber pair can
> only be used to provide preference to one certificate over others during
> path construction."  This precludes it's use as an alternative to AIA
> caIssuers.  

My interpretation would be exactly the opposite of yours. This is 
precisely why AKID can be used to find the correct public key 
certificate for path construction, in order to validate the signature on 
the AC.

regards

David

>  
>>> It is easy enough to use
>>> id-caIssuers to point to a PKC used to verify an attribute 
>> certificate 
>>> signature and to define a new access method to point to an 
>> attribute 
>>> certificate that precedes the attribute certificate containing the 
>>> extension in a PMI chain.
>> Sure, this is an alternative way of doing it. We can do this 
>> if concensus is that this is the best way
> 
> If this comes to a straw poll, mark me down for the option described
> above.
> 
> 
> 
> 

-- 

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

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

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt
Date: Fri, 14 Jul 2006 08:37:29 -0700
From: "Carl Wallace" <[email-masked]>
To: "David Chadwick" <[email-masked]>
Cc: "David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

> since the syntax of AKID and AIA are both GeneralNames, then 
> it seems obvious to me that a url can be used in both to 
> point to the location where the issuer's cert can be found, 
> as the text in AIA describes. (In fact AIA caIssuers is not 
> really needed is it?)

X.509 states "the authorityCertIssuer, authoritySerialNumber pair can
only be used to provide preference to one certificate over others during
path construction."  This precludes it's use as an alternative to AIA
caIssuers.  
 
> > It is easy enough to use
> > id-caIssuers to point to a PKC used to verify an attribute 
> certificate 
> > signature and to define a new access method to point to an 
> attribute 
> > certificate that precedes the attribute certificate containing the 
> > extension in a PMI chain.
> 
> Sure, this is an alternative way of doing it. We can do this 
> if concensus is that this is the best way

If this comes to a straw poll, mark me down for the option described
above.

Date: Fri, 14 Jul 2006 11:31:30 -0400
From: "David A. Cooper" <[email-masked]>
To: David Chadwick <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

David,

The AKI extension cannot be used as a pointer to the certificate needed 
to verify the signature on the certificate containing the extension.  
This is the reason that we need the id-ad-caIssuers access method of the 
AIA extension in addition to the AKI extension in both public key 
certificates and CRLs even though the AKI extension is also defined for 
inclusion in these as well.

The problem with using the AKI extension is that the GeneralNames field 
in AKI is not defined as a pointer to the certificate of interest.  The 
authorityCertIssuer field is used in combination with the 
authorityCertSerialNumber field to identify a certificate by issuer name 
and serial number.  Thus, the authorityCertIssuer field specifies the 
name(s) of the issuer of the certificate whose subject public key can be 
used to verify the signature on the object (e.g., certificate or CRL) 
that contains the AKI extension.  So, I don't see how the 
authorityCertIssuer field could point to the certificate of interest 
when the field is the identifier of a certificate issuer, an issuer that 
has most likely issued more than one certificate.

I believe that the correct solution is to specify the use of the AIA 
extension in an attribute certificate.  Since the PKIX profile for 
attribute certificates (RFC 3281) does not support delegation, I do not 
see the PKIX WG specifying an access method for pointing to other 
attribute certificates, but I think it would be appropriate for PKIX to 
specify an access method for inclusion in an attribute certificate that 
points to the public key certificate(s) that can be used to verify the 
signature on the attribute certificate.  Of course, any such work should 
be written as a separate I-D that updates RFC 3281 rather than being 
done as part of any current I-D.

Since an AIA access method that points to the public key certificate(s) 
needed to verify the signature on an attribute certificate that includes 
the extension seems consistent with the use of the id-ad-caIssuers 
access method in public key certificates and CRLs, I think it would be 
acceptable to use the id-ad-caIssuers OID for this purpose in attribute 
certificates as well, but one could just as easily define a new OID.

If the id-ad-caIssuers access method is to be used, then I think that 
PKIX should specify its use since PKIX "owns" the OID.  In order to help 
things progress in this area, I put together a very short I-D that that 
specifies the use of the id-ad-caIssuers access point to point to the 
public key certificate(s) whose subject public key(s) can be used to 
verify the signature on the attribute certificate that includes the 
extension.  I simply took RFC 4325 (Internet X.509 Public Key 
Infrastructure Authority Information Access Certificate Revocation List 
(CRL) Extension) and replaced "CRL" with "attribute certificate".  It 
would, of course, be very easy to change the draft to specify a 
different OID for the access method. If anyone is interested in seeing 
this, I can send a copy.

Dave

David Chadwick wrote:
> Carl Wallace wrote:
>> Identifying a public key is not the same as pointing to a PKC.  The AKID
>> extension will not do what you seem to want. 
>
> Carl
>
> since the syntax of AKID and AIA are both GeneralNames, then it seems 
> obvious to me that a url can be used in both to point to the location 
> where the issuer's cert can be found, as the text in AIA describes. 
> (In fact AIA caIssuers is not really needed is it?)
>
>> It is easy enough to use
>> id-caIssuers to point to a PKC used to verify an attribute certificate
>> signature and to define a new access method to point to an attribute
>> certificate that precedes the attribute certificate containing the
>> extension in a PMI chain. 
>
> Sure, this is an alternative way of doing it. We can do this if 
> concensus is that this is the best way
>
>
>  Further overloading id-caIssuers, which can
>> already point to a PKCS7 blob or a cert, to point to attribute
>> certificates is a bad idea, in my opinion.
>>
>
> It all depends upon the semantics of caIssuers. Can it only point to 
> the CA issuer or can it point to the issuer (as is used in CRLs). This 
> is the point that I am trying to clarify
>
>
> thanks
>
> David

Date: Fri, 14 Jul 2006 11:03:52 -0400
To: [email-masked]
From: Shu-jen Chang <[email-masked]>
Subject: Tentative Time line of the Development of New Hash Functions Now Posted
Sender: [email-masked]

<html>
A tentative timeline of the development of new hash functions has been
posted on the Hash Workshop web site: <br>
<a href="http://www.nist.gov/hash-function" eudora="autourl">http://www.nist.gov/hash-function</a>
<br><br>
This topic will be discussed in the Second Cryptographic Hash Workshop. Comments should be sent to <font face="Times New Roman, Times" size=3><b>[email-masked] </b>by <b>August 4, 2006</b>.<br><br>
</font>Details about the workshop and a preliminary program are available at the same web site listed above.<br><br>
Sincerely,<br>
The Hash Workshop Program Committee<br>
NIST<br>
</html>

Date: Fri, 14 Jul 2006 15:53:11 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: Carl Wallace <[email-masked]>
CC: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Carl Wallace wrote:

> Identifying a public key is not the same as pointing to a PKC.  The AKID
> extension will not do what you seem to want. 

Carl

since the syntax of AKID and AIA are both GeneralNames, then it seems 
obvious to me that a url can be used in both to point to the location 
where the issuer's cert can be found, as the text in AIA describes. (In 
fact AIA caIssuers is not really needed is it?)

> It is easy enough to use
> id-caIssuers to point to a PKC used to verify an attribute certificate
> signature and to define a new access method to point to an attribute
> certificate that precedes the attribute certificate containing the
> extension in a PMI chain. 

Sure, this is an alternative way of doing it. We can do this if 
concensus is that this is the best way

  Further overloading id-caIssuers, which can
> already point to a PKCS7 blob or a cert, to point to attribute
> certificates is a bad idea, in my opinion.
> 

It all depends upon the semantics of caIssuers. Can it only point to the 
CA issuer or can it point to the issuer (as is used in CRLs). This is 
the point that I am trying to clarify

thanks

David

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

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

Date: Fri, 14 Jul 2006 15:48:35 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: Carl Wallace <[email-masked]>
CC: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Carl Wallace wrote:

>> The second point means that we only need to use the AIA to 
>> point to the AC of the issuer. And caissuers can be used for 
>> this unambiguously if we edit the first sentence of its 
>> description in 3280-bis. The current wording does in my 
>> opinion rule out its use in CRLs. So it would be advantageous 
>> to change the wording,regardless of the AC debate.
> 
> The wording appears in a section that describes public key certificate
> extensions.  

Carl

the wording appears in the very first section where caIssuers is 
described. Therefore since this is the first (and only) description of 
caIssuers it is natural to assume that this is the definitive definition 
of caIssuers. And my reading of it rules out the use of caIssuers for 
anything other than CAs. A very tiny wording change removes this 
exclusive use of caIssuers. Specifically, the current 3280 sentence says

    The id-ad-caIssuers OID is used when the additional information lists
    certificates that were issued to the CA that issued the certificate
    containing this extension.

this implies that it can only be used to point to a CA.

Replacing it with

    When the id-ad-caIssuers OID is used [in a public key certificate] 
            the additional information lists
    certificates that were issued to the CA that issued the certificate
    containing this extension.

implies it can be used elsewhere as well as in PKCs. The text in [] is 
optional. You may not think it is necessary as it is implied by context. 
The revised sentence opens the door for it to be used to point to other 
things than CAs

regards

David

-- 

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

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sim-08.txt 
Date: Thu, 13 Jul 2006 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
	Author(s)	: J. Park, et al.
	Filename	: draft-ietf-pkix-sim-08.txt
	Pages		: 19
	Date		: 2006-7-13
	
This document defines the Subject Identification Method (SIM) for
including a privacy sensitive identifier in the subjectAltName
extension of a certificate.

The SIM is an optional feature that may be used by relying parties to
determine whether the subject of a particular certificate is also the
person corresponding to a particular sensitive identifier.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-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-sim-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-sim-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-sim-08.txt

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

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

--OtherAccess--

--NextPart--

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: RE: draft meeting minutes have been uploaded
Date: Thu, 13 Jul 2006 10:59:59 -0800
Importance: Normal
Sender: [email-masked]

I proposed OCSP-specific resolution of this issue:

http://www.imc.org/ietf-pkix/mail-archive/msg03318.html

Haven't heard a peep.

Mike

> OCSP Algorithm Agility - Stefan Santesson (Microsoft)
> -----------------------------------------------------
> . . .
> The chairs solicited a volunteer to lead an effort to address
> this problem in either the OCSP-specific case or the more
> general case, but nobody volunteered.

Date: Thu, 13 Jul 2006 16:54:55 +0200
From: Peter Sylvester <[email-masked]>
To: pkix <[email-masked]>
Subject: SCVP question
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

I seems to me that paragraph 4.9.5 does not say how the different ASN.1
types are encoded when encapsulated within the octet string.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms090107040803030708090103--

From: Sharon Boeyen <[email-masked]>
To: "'Carl Wallace'" <[email-masked]>, David Chadwick <[email-masked]>, "David A. Cooper" <[email-masked]>
Cc: pkix <[email-masked]>
Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt
Date: Wed, 12 Jul 2006 10:06:16 -0400
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_01C6A5BC.4444260D
Content-Type: text/plain

I agree and urge that caIssuers not be overloaded. A new access method
should be defined for pointing to an attribute certificate. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carl Wallace
Sent: Wednesday, July 12, 2006 9:06 AM
To: David Chadwick; David A. Cooper
Cc: pkix
Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt

> Secondly, you forgot to mention the use of
> AuthorityKeyIdentifier which according to 3280 is " a means 
> of identifying the public key corresponding to the private 
> key used to sign a certificate." So this precisely gives us 
> the pointer we need to point to the PKC of the issuer of the 
> AC in which this extension occurs. 

Identifying a public key is not the same as pointing to a PKC.  The AKID
extension will not do what you seem to want.  It is easy enough to use
id-caIssuers to point to a PKC used to verify an attribute certificate
signature and to define a new access method to point to an attribute
certificate that precedes the attribute certificate containing the extension
in a PMI chain.  Further overloading id-caIssuers, which can already point
to a PKCS7 blob or a cert, to point to attribute certificates is a bad idea,
in my opinion.

> This is in line with its
> current use in PKCs. Thus we do not need the AIA to point to 
> the PKC of the issuer.
> 
> The second point means that we only need to use the AIA to
> point to the AC of the issuer. And caissuers can be used for 
> this unambiguously if we edit the first sentence of its 
> description in 3280-bis. The current wording does in my 
> opinion rule out its use in CRLs. So it would be advantageous 
> to change the wording,regardless of the AC debate.

The wording appears in a section that describes public key certificate
extensions.  Language specific to PKCs in that section does not preclude
language elsewhere that describes how the extension can be used in different
types of objects, such as CRLs or attribute certificates. Ideally, other
usage should be consistent with the RFC3280 usage, i.e., the extension
should be used to point to certs or P7 blobs.

------_=_NextPart_001_01C6A5BC.4444260D
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: draft-ietf-pkix-rfc3280bis-04.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree and urge that caIssuers not be overloaded. A =
new access method should be defined for pointing to an attribute =
certificate. </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 Carl Wallace</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, July 12, 2006 9:06 AM</FONT>
<BR><FONT SIZE=3D2>To: David Chadwick; David A. Cooper</FONT>
<BR><FONT SIZE=3D2>Cc: pkix</FONT>
<BR><FONT SIZE=3D2>Subject: RE: =
draft-ietf-pkix-rfc3280bis-04.txt</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; Secondly, you forgot to mention the use =
of</FONT>
<BR><FONT SIZE=3D2>&gt; AuthorityKeyIdentifier which according to 3280 =
is &quot; a means </FONT>
<BR><FONT SIZE=3D2>&gt; of identifying the public key corresponding to =
the private </FONT>
<BR><FONT SIZE=3D2>&gt; key used to sign a certificate.&quot; So this =
precisely gives us </FONT>
<BR><FONT SIZE=3D2>&gt; the pointer we need to point to the PKC of the =
issuer of the </FONT>
<BR><FONT SIZE=3D2>&gt; AC in which this extension occurs. </FONT>
</P>

<P><FONT SIZE=3D2>Identifying a public key is not the same as pointing =
to a PKC.&nbsp; The AKID extension will not do what you seem to =
want.&nbsp; It is easy enough to use id-caIssuers to point to a PKC =
used to verify an attribute certificate signature and to define a new =
access method to point to an attribute certificate that precedes the =
attribute certificate containing the extension in a PMI chain.&nbsp; =
Further overloading id-caIssuers, which can already point to a PKCS7 =
blob or a cert, to point to attribute certificates is a bad idea, in my =
opinion.</FONT></P>

<P><FONT SIZE=3D2>&gt; This is in line with its</FONT>
<BR><FONT SIZE=3D2>&gt; current use in PKCs. Thus we do not need the =
AIA to point to </FONT>
<BR><FONT SIZE=3D2>&gt; the PKC of the issuer.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The second point means that we only need to use =
the AIA to</FONT>
<BR><FONT SIZE=3D2>&gt; point to the AC of the issuer. And caissuers =
can be used for </FONT>
<BR><FONT SIZE=3D2>&gt; this unambiguously if we edit the first =
sentence of its </FONT>
<BR><FONT SIZE=3D2>&gt; description in 3280-bis. The current wording =
does in my </FONT>
<BR><FONT SIZE=3D2>&gt; opinion rule out its use in CRLs. So it would =
be advantageous </FONT>
<BR><FONT SIZE=3D2>&gt; to change the wording,regardless of the AC =
debate.</FONT>
</P>

<P><FONT SIZE=3D2>The wording appears in a section that describes =
public key certificate extensions.&nbsp; Language specific to PKCs in =
that section does not preclude language elsewhere that describes how =
the extension can be used in different types of objects, such as CRLs =
or attribute certificates. Ideally, other usage should be consistent =
with the RFC3280 usage, i.e., the extension should be used to point to =
certs or P7 blobs.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C6A5BC.4444260D--

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt
Date: Wed, 12 Jul 2006 06:06:12 -0700
From: "Carl Wallace" <[email-masked]>
To: "David Chadwick" <[email-masked]>, "David A. Cooper" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

> Secondly, you forgot to mention the use of 
> AuthorityKeyIdentifier which according to 3280 is " a means 
> of identifying the public key corresponding to the private 
> key used to sign a certificate." So this precisely gives us 
> the pointer we need to point to the PKC of the issuer of the 
> AC in which this extension occurs. 

Identifying a public key is not the same as pointing to a PKC.  The AKID
extension will not do what you seem to want.  It is easy enough to use
id-caIssuers to point to a PKC used to verify an attribute certificate
signature and to define a new access method to point to an attribute
certificate that precedes the attribute certificate containing the
extension in a PMI chain.  Further overloading id-caIssuers, which can
already point to a PKCS7 blob or a cert, to point to attribute
certificates is a bad idea, in my opinion.

> This is in line with its 
> current use in PKCs. Thus we do not need the AIA to point to 
> the PKC of the issuer.
> 
> The second point means that we only need to use the AIA to 
> point to the AC of the issuer. And caissuers can be used for 
> this unambiguously if we edit the first sentence of its 
> description in 3280-bis. The current wording does in my 
> opinion rule out its use in CRLs. So it would be advantageous 
> to change the wording,regardless of the AC debate.

The wording appears in a section that describes public key certificate
extensions.  Language specific to PKCs in that section does not preclude
language elsewhere that describes how the extension can be used in
different types of objects, such as CRLs or attribute certificates.
Ideally, other usage should be consistent with the RFC3280 usage, i.e.,
the extension should be used to point to certs or P7 blobs.

Date: Tue, 11 Jul 2006 10:49:14 -0400
To: David Chadwick <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Cc: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

At 3:01 PM +0100 7/11/06, David Chadwick wrote:
>Hi Steve
>
>You did misunderstand. There is no intention to make PKIX change its decision.
>
>PKIX has a profile of X.509 for PKIs and PMIs. X.509 supports PMI 
>and PKI chains. The PKIX profile for PKIs supports chaining of CA 
>certs. The profile of PMIs does not support chaining of AA certs. 
>Thats your choice.

I'm glad we agree on that.

>PKIX has defined an AIA extension that points to a superior 
>authority in a chain of certs. This extension is now worded in 3280 
>to be a general certificate extension, rather than a purely PKI 
>extension, so it applies to ACs, PKCs (and XYZ certs when/if they 
>are defined).

It doesn't apply to XYZ certs unless they are defined by X.509 and/or PKIX :-).

>The PKI profile 3280 says how to use AIA in PKI chains. The ITU-T 
>(2009) X.509 standard will say how to use AIA in PMI chains.
>PKIX can at a future date decide to profile this or not. Its your 
>choice, and ISO/ITU_T is not requiring you to do it or not do it.

My recollection is that ITU-T never "requires" the IETF to do 
anything re its standards, David.

>All ITU-T wants you to do is ensure that the definition of AIA is 
>unambiguously worded so that it is clear to everyone that it is 
>either a general purpose extension that points to an issuing 
>authority for any type of certificate, or if you chose not to, to 
>make clear that it is only a PKI extension that can only ever point 
>to CAs. This is your choice.

Clarity in standards is a virtue, so removing ambiguity is in 
everyone's best interest.

>My presentation yesterday was pointing out that the wording is still 
>a bit ambiguous in that it now seems clear that the AIA extension is 
>general purpose but the caissuers access method should only be used 
>to point to CAs. But then we were told in the meeting that actually 
>the caissuers access method also points to CRL issuers and therefore 
>could also point to AAs.

CRL issuers generally are CAs, so in those instances I see no 
conflict. The question, as you note, is whether we should reword the 
access method description to explicitly accommodate AAs, or whether 
one should just define a distinct access method for AAs.

>All I really want is clarity and lack of ambiguity. Currently we 
>dont have that situation since some people are using AIA to point to 
>ACs, others to point to CRL issuers and others to point to CAs, 
>whilst others (including myself) dont think that the wording 
>actually allows this.
>
>In fact the change of wording required for caissuers, in order for 
>it to be used for CRL issuers and AC issuers is minimal as my last 
>slide pointed out

I'm open to modifying the text to accommodate AAs, if the editors 
agree and the WG does not object.

Stgeve

Date: Tue, 11 Jul 2006 16:18:18 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Hi David

thanks for your analysis

I would like to make two points.

Firstly I am glad that you agree that AIA can be used inside ACs. So now 
we just need to have the debate over which access method(s) to use.

Secondly, you forgot to mention the use of AuthorityKeyIdentifier which 
according to 3280 is " a means of identifying the public key 
corresponding to the private key used to sign a certificate." So this 
precisely gives us the pointer we need to point to the PKC of the issuer 
of the AC in which this extension occurs. This is in line with its 
current use in PKCs. Thus we do not need the AIA to point to the PKC of 
the issuer.

The second point means that we only need to use the AIA to point to the 
AC of the issuer. And caissuers can be used for this unambiguously if we 
edit the first sentence of its description in 3280-bis. The current 
wording does in my opinion rule out its use in CRLs. So it would be 
advantageous to change the wording,regardless of the AC debate.

regards

David

David A. Cooper wrote:
> David,
> 
> While I modified the text in section 4.2.2.1 so that the text does not 
> imply that the extension can only be used in public key certificates, 
> there was already precedent for including the extension in attribute 
> certificates.  RFC 3281(section 4.3.4) profiles the use of the AIA 
> extension in attribute certificates:
> 
>   4.3.4   Authority Information Access
> 
>      The authorityInformationAccess extension, as defined in [PKIXPROF],
>      MAY be used to assist the AC verifier in checking the revocation
>      status of the AC.  Support for the id-ad-caIssuers accessMethod is
>      NOT REQUIRED by this profile since AC chains are not expected.
> 
> Section 4.3.4 then goes on the profile the use of the id-ad-ocsp access 
> method in an attribute certificate.
> 
> So, RFC 3281 clearly shows that it is acceptable to include the AIA 
> extension in an attribute certificate and even implies that the 
> id-ad-caIssuers access method may be used.  I am starting to believe, 
> however, that it would be preferable to define a new access method for 
> attribute certificates. The concern that I have is that it seems that 
> for attribute certificates, in a model in which delegation is allowed, 
> there is a need for the AIA extension to point to two types of 
> information and I believe that each should have its own access method.  
> Whether delegation is used or not, there is a need to validate the 
> signature on the attribute certificate, and it would be useful to have 
> the AIA extension point to the public key certificate that contains the 
> key needed to verify the signature on the attribute certificate.  This 
> would most closely align with the way that the id-ad-caIssuers access 
> method is defined for use when included in a public key certificate or a 
> CRL.  Where delegation is used, the AIA extension also needs to point to 
> the attribute certificate that could precede this certificate in a PMI 
> chain.
> 
> While one option would be to use the id-ad-caIssuers access method to 
> point to one of these pieces of information and then define a second 
> access method to point to the other piece of information, I believe that 
> it would be easier to simply define two new access methods rather than 
> arguing over which piece of information should be pointed to by the 
> id-ad-caIssuers access method.  As it is, given the way that 
> id-ad-caIssuers is used in public key certificates and CRLs, I would 
> think it would be more appropriate to use this access method to point to 
> the public key certificate needed to verify the signature on the 
> attribute certificate, while others seem to believe that it should be 
> used to point to other attribute certificates.  Given how easy it is to 
> define new access methods, it seems that it would just be easier to 
> define two new access methods for use in attribute certificates.
> 
> Of course, since 3280bis only addresses public key certificates, none of 
> this would be included in 3280bis.
> 
> Dave
> 
> David Chadwick wrote:
>> Hi Steve
>>
>> You did misunderstand. There is no intention to make PKIX change its 
>> decision.
>>
>> PKIX has a profile of X.509 for PKIs and PMIs. X.509 supports PMI and 
>> PKI chains. The PKIX profile for PKIs supports chaining of CA certs. 
>> The profile of PMIs does not support chaining of AA certs. Thats your 
>> choice.
>>
>> PKIX has defined an AIA extension that points to a superior authority 
>> in a chain of certs. This extension is now worded in 3280 to be a 
>> general certificate extension, rather than a purely PKI extension, so 
>> it applies to ACs, PKCs (and XYZ certs when/if they are defined).
>>
>> The PKI profile 3280 says how to use AIA in PKI chains. The ITU-T 
>> (2009) X.509 standard will say how to use AIA in PMI chains.
>> PKIX can at a future date decide to profile this or not. Its your 
>> choice, and ISO/ITU_T is not requiring you to do it or not do it.
>>
>> All ITU-T wants you to do is ensure that the definition of AIA is 
>> unambiguously worded so that it is clear to everyone that it is either 
>> a general purpose extension that points to an issuing authority for 
>> any type of certificate, or if you chose not to, to make clear that it 
>> is only a PKI extension that can only ever point to CAs. This is your 
>> choice.
>>
>> My presentation yesterday was pointing out that the wording is still a 
>> bit ambiguous in that it now seems clear that the AIA extension is 
>> general purpose but the caissuers access method should only be used to 
>> point to CAs. But then we were told in the meeting that actually the 
>> caissuers access method also points to CRL issuers and therefore could 
>> also point to AAs.
>>
>> All I really want is clarity and lack of ambiguity. Currently we dont 
>> have that situation since some people are using AIA to point to ACs, 
>> others to point to CRL issuers and others to point to CAs, whilst 
>> others (including myself) dont think that the wording actually allows 
>> this.
>>
>> In fact the change of wording required for caissuers, in order for it 
>> to be used for CRL issuers and AC issuers is minimal as my last slide 
>> pointed out
>>
>> regards
>>
>> David
>>
>>
>> Stephen Kent wrote:
>>> At 7:36 PM +0100 7/7/06, David Chadwick wrote:
>>>> Hi Dave
>>>>
>>>> When we have an AC that is signed by an AA who is not an SOA, and 
>>>> DNs are used to refer to the holders and issuers, then we have (at 
>>>> least) two certificate chains that need to be followed
>>>>
>>>> the first is the PMI chain from the holder to the AA to [the next AA 
>>>> to] the SOA
>>>> the second is the PKI chain from the PKC of the issuer to [the PKC 
>>>> of the CA] to the PKC of the root CA (trust anchor)
>>>>
>>>> We are proposing that you edit 3280bis to allow the AIA to be used 
>>>> inside ACs to enable the first chain above to be tracked to the SOA. 
>>>> (this is exactly analogous to its use in PKIs to find a root CA).
>>>>
>>>> The authority key identifier can be used inside the AC to point to 
>>>> the first PKC for the second chain above.
>>>>
>>>> The reason that 3281 has not described the first chain above is that 
>>>> it does not support delegation of authority, and all ACs must be 
>>>> issued by the SOA.
>>>>
>>>> regards
>>>>
>>>> David
>>>
>>> David,
>>>
>>> PKIX deprecates chaining of ACs and there has been no WG consensus to 
>>> change this position. Thus I am concerned by the text above that 
>>> seems to conflict with this, by virtue of how you explain the planned 
>>> use of AIA in ACs.
>>>
>>> Did I misunderstand?
>>>
>>> Steve
>>>
>>
> 
> 

-- 

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

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

Date: Tue, 11 Jul 2006 10:39:38 -0400
From: "David A. Cooper" <[email-masked]>
To: David Chadwick <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

David,

While I modified the text in section 4.2.2.1 so that the text does not 
imply that the extension can only be used in public key certificates, 
there was already precedent for including the extension in attribute 
certificates.  RFC 3281(section 4.3.4) profiles the use of the AIA 
extension in attribute certificates:

   4.3.4   Authority Information Access

      The authorityInformationAccess extension, as defined in [PKIXPROF],
      MAY be used to assist the AC verifier in checking the revocation
      status of the AC.  Support for the id-ad-caIssuers accessMethod is
      NOT REQUIRED by this profile since AC chains are not expected.

Section 4.3.4 then goes on the profile the use of the id-ad-ocsp access 
method in an attribute certificate.

So, RFC 3281 clearly shows that it is acceptable to include the AIA 
extension in an attribute certificate and even implies that the 
id-ad-caIssuers access method may be used.  I am starting to believe, 
however, that it would be preferable to define a new access method for 
attribute certificates. The concern that I have is that it seems that 
for attribute certificates, in a model in which delegation is allowed, 
there is a need for the AIA extension to point to two types of 
information and I believe that each should have its own access method.  
Whether delegation is used or not, there is a need to validate the 
signature on the attribute certificate, and it would be useful to have 
the AIA extension point to the public key certificate that contains the 
key needed to verify the signature on the attribute certificate.  This 
would most closely align with the way that the id-ad-caIssuers access 
method is defined for use when included in a public key certificate or a 
CRL.  Where delegation is used, the AIA extension also needs to point to 
the attribute certificate that could precede this certificate in a PMI 
chain.

While one option would be to use the id-ad-caIssuers access method to 
point to one of these pieces of information and then define a second 
access method to point to the other piece of information, I believe that 
it would be easier to simply define two new access methods rather than 
arguing over which piece of information should be pointed to by the 
id-ad-caIssuers access method.  As it is, given the way that 
id-ad-caIssuers is used in public key certificates and CRLs, I would 
think it would be more appropriate to use this access method to point to 
the public key certificate needed to verify the signature on the 
attribute certificate, while others seem to believe that it should be 
used to point to other attribute certificates.  Given how easy it is to 
define new access methods, it seems that it would just be easier to 
define two new access methods for use in attribute certificates.

Of course, since 3280bis only addresses public key certificates, none of 
this would be included in 3280bis.

Dave

David Chadwick wrote:
> Hi Steve
>
> You did misunderstand. There is no intention to make PKIX change its 
> decision.
>
> PKIX has a profile of X.509 for PKIs and PMIs. X.509 supports PMI and 
> PKI chains. The PKIX profile for PKIs supports chaining of CA certs. 
> The profile of PMIs does not support chaining of AA certs. Thats your 
> choice.
>
> PKIX has defined an AIA extension that points to a superior authority 
> in a chain of certs. This extension is now worded in 3280 to be a 
> general certificate extension, rather than a purely PKI extension, so 
> it applies to ACs, PKCs (and XYZ certs when/if they are defined).
>
> The PKI profile 3280 says how to use AIA in PKI chains. The ITU-T 
> (2009) X.509 standard will say how to use AIA in PMI chains.
> PKIX can at a future date decide to profile this or not. Its your 
> choice, and ISO/ITU_T is not requiring you to do it or not do it.
>
> All ITU-T wants you to do is ensure that the definition of AIA is 
> unambiguously worded so that it is clear to everyone that it is either 
> a general purpose extension that points to an issuing authority for 
> any type of certificate, or if you chose not to, to make clear that it 
> is only a PKI extension that can only ever point to CAs. This is your 
> choice.
>
> My presentation yesterday was pointing out that the wording is still a 
> bit ambiguous in that it now seems clear that the AIA extension is 
> general purpose but the caissuers access method should only be used to 
> point to CAs. But then we were told in the meeting that actually the 
> caissuers access method also points to CRL issuers and therefore could 
> also point to AAs.
>
> All I really want is clarity and lack of ambiguity. Currently we dont 
> have that situation since some people are using AIA to point to ACs, 
> others to point to CRL issuers and others to point to CAs, whilst 
> others (including myself) dont think that the wording actually allows 
> this.
>
> In fact the change of wording required for caissuers, in order for it 
> to be used for CRL issuers and AC issuers is minimal as my last slide 
> pointed out
>
> regards
>
> David
>
>
> Stephen Kent wrote:
>> At 7:36 PM +0100 7/7/06, David Chadwick wrote:
>>> Hi Dave
>>>
>>> When we have an AC that is signed by an AA who is not an SOA, and 
>>> DNs are used to refer to the holders and issuers, then we have (at 
>>> least) two certificate chains that need to be followed
>>>
>>> the first is the PMI chain from the holder to the AA to [the next AA 
>>> to] the SOA
>>> the second is the PKI chain from the PKC of the issuer to [the PKC 
>>> of the CA] to the PKC of the root CA (trust anchor)
>>>
>>> We are proposing that you edit 3280bis to allow the AIA to be used 
>>> inside ACs to enable the first chain above to be tracked to the SOA. 
>>> (this is exactly analogous to its use in PKIs to find a root CA).
>>>
>>> The authority key identifier can be used inside the AC to point to 
>>> the first PKC for the second chain above.
>>>
>>> The reason that 3281 has not described the first chain above is that 
>>> it does not support delegation of authority, and all ACs must be 
>>> issued by the SOA.
>>>
>>> regards
>>>
>>> David
>>
>> David,
>>
>> PKIX deprecates chaining of ACs and there has been no WG consensus to 
>> change this position. Thus I am concerned by the text above that 
>> seems to conflict with this, by virtue of how you explain the planned 
>> use of AIA in ACs.
>>
>> Did I misunderstand?
>>
>> Steve
>>
>

Date: Tue, 11 Jul 2006 10:24:16 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft meeting minutes have been uploaded
Sender: [email-masked]

Please send comments and corrections to me over the next two weeks, 
so these can be finalized.

Steve

Date: Tue, 11 Jul 2006 15:01:30 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: Stephen Kent <[email-masked]>
CC: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Hi Steve

You did misunderstand. There is no intention to make PKIX change its 
decision.

PKIX has a profile of X.509 for PKIs and PMIs. X.509 supports PMI and 
PKI chains. The PKIX profile for PKIs supports chaining of CA certs. The 
profile of PMIs does not support chaining of AA certs. Thats your choice.

PKIX has defined an AIA extension that points to a superior authority in 
a chain of certs. This extension is now worded in 3280 to be a general 
certificate extension, rather than a purely PKI extension, so it applies 
to ACs, PKCs (and XYZ certs when/if they are defined).

The PKI profile 3280 says how to use AIA in PKI chains. The ITU-T (2009) 
X.509 standard will say how to use AIA in PMI chains.
PKIX can at a future date decide to profile this or not. Its your 
choice, and ISO/ITU_T is not requiring you to do it or not do it.

All ITU-T wants you to do is ensure that the definition of AIA is 
unambiguously worded so that it is clear to everyone that it is either a 
general purpose extension that points to an issuing authority for any 
type of certificate, or if you chose not to, to make clear that it is 
only a PKI extension that can only ever point to CAs. This is your choice.

My presentation yesterday was pointing out that the wording is still a 
bit ambiguous in that it now seems clear that the AIA extension is 
general purpose but the caissuers access method should only be used to 
point to CAs. But then we were told in the meeting that actually the 
caissuers access method also points to CRL issuers and therefore could 
also point to AAs.

All I really want is clarity and lack of ambiguity. Currently we dont 
have that situation since some people are using AIA to point to ACs, 
others to point to CRL issuers and others to point to CAs, whilst others 
(including myself) dont think that the wording actually allows this.

In fact the change of wording required for caissuers, in order for it to 
be used for CRL issuers and AC issuers is minimal as my last slide 
pointed out

regards

David

Stephen Kent wrote:
> At 7:36 PM +0100 7/7/06, David Chadwick wrote:
>> Hi Dave
>>
>> When we have an AC that is signed by an AA who is not an SOA, and DNs 
>> are used to refer to the holders and issuers, then we have (at least) 
>> two certificate chains that need to be followed
>>
>> the first is the PMI chain from the holder to the AA to [the next AA 
>> to] the SOA
>> the second is the PKI chain from the PKC of the issuer to [the PKC of 
>> the CA] to the PKC of the root CA (trust anchor)
>>
>> We are proposing that you edit 3280bis to allow the AIA to be used 
>> inside ACs to enable the first chain above to be tracked to the SOA. 
>> (this is exactly analogous to its use in PKIs to find a root CA).
>>
>> The authority key identifier can be used inside the AC to point to the 
>> first PKC for the second chain above.
>>
>> The reason that 3281 has not described the first chain above is that 
>> it does not support delegation of authority, and all ACs must be 
>> issued by the SOA.
>>
>> regards
>>
>> David
> 
> David,
> 
> PKIX deprecates chaining of ACs and there has been no WG consensus to 
> change this position. Thus I am concerned by the text above that seems 
> to conflict with this, by virtue of how you explain the planned use of 
> AIA in ACs.
> 
> Did I misunderstand?
> 
> Steve
> 

-- 

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

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

Date: Mon, 10 Jul 2006 16:02:09 -0400
To: David Chadwick <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Cc: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

At 7:36 PM +0100 7/7/06, David Chadwick wrote:
>Hi Dave
>
>When we have an AC that is signed by an AA who is not an SOA, and 
>DNs are used to refer to the holders and issuers, then we have (at 
>least) two certificate chains that need to be followed
>
>the first is the PMI chain from the holder to the AA to [the next AA 
>to] the SOA
>the second is the PKI chain from the PKC of the issuer to [the PKC 
>of the CA] to the PKC of the root CA (trust anchor)
>
>We are proposing that you edit 3280bis to allow the AIA to be used 
>inside ACs to enable the first chain above to be tracked to the SOA. 
>(this is exactly analogous to its use in PKIs to find a root CA).
>
>The authority key identifier can be used inside the AC to point to 
>the first PKC for the second chain above.
>
>The reason that 3281 has not described the first chain above is that 
>it does not support delegation of authority, and all ACs must be 
>issued by the SOA.
>
>regards
>
>David

David,

PKIX deprecates chaining of ACs and there has been no WG consensus to 
change this position. Thus I am concerned by the text above that 
seems to conflict with this, by virtue of how you explain the planned 
use of AIA in ACs.

Did I misunderstand?

Steve

Content-class: urn:content-classes:message
Subject: Reminder - send me PKIX slides before the PKIX meeting
Date: Mon, 10 Jul 2006 15:36:38 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A42E.42AF2B77
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please end me your PKIX slides before the meeting so I can upload them
for access during the meeting.

=20

The prestigious first place for the earliest submitted session slides is
still not claimed.=20

The winner will be announced :-)

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

------_=_NextPart_001_01C6A42E.42AF2B77
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:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
 /* 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:Arial;
	color:windowtext;}
@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 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Please end me your PKIX slides before the meeting so =
I can
upload them for access during the meeting.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The prestigious first place for the earliest =
submitted session
slides is still not claimed. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The winner will be announced </span></font><font =
size=3D2
face=3DWingdings><span =
style=3D'font-size:10.0pt;font-family:Wingdings'>J</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><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_001_01C6A42E.42AF2B77--

Content-class: urn:content-classes:message
Subject: Agenda
Date: Mon, 10 Jul 2006 13:00:57 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A418.8200B22F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

=20

An updated agenda has been posted for PKIX

http://www3.ietf.org/proceedings/06jul/agenda/pkix.txt

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

------_=_NextPart_001_01C6A418.8200B22F
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>
<!--
 /* 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:Arial;
	color:windowtext;}
@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 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>All,<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>An updated agenda has been posted for =
PKIX<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www3.ietf.org/proceedings/06jul/agenda/pkix.txt">http://ww=
w3.ietf.org/proceedings/06jul/agenda/pkix.txt</a><o:p></o:p></span></font=
></p>

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

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><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_001_01C6A418.8200B22F--

Content-class: urn:content-classes:message
Subject: RE: Comment on RFC 3280bis: id-pkix-crl-nocheck extension
Date: Sun, 9 Jul 2006 10:05:12 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Russ,

I would support such an extension if the purpose, utility, and drawbacks
were explained.

It is a new capability, but is better than self-issued certificates
running amok.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Sunday, July 09, 2006 10:18 AM
To: [email-masked]
Subject: Re: Comment on RFC 3280bis: id-pkix-crl-nocheck extension

Denis:

>We currently have id-pkix-ocsp-nocheck extension.
>
>In order to support trust anchors that issue short-lived PKCs for 
>CRL issuers,
>there is a need to create a id-pkix-crl-nocheck extension.

id-pkix-ocsp-nocheck is not discussed in 3280 or 3280bis.  So, I do 
not understand why you think the proposed extension ought to be added 
to 3280bis.  Perhaps it belongs in another document.  From my 
perspective, it is not clear that there is consensus for a 
id-pkix-crl-nocheck extension.  Adding it without confirming that 
there is consensus is a very big concern.

If 3280bis goes forward without a id-pkix-crl-nocheck extension, a 
separate document can be written to address this topic.  Using a 
separate document allows us to easily determine consensus.

Russ

From: David Cross <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Sun, 9 Jul 2006 09:35:27 -0700
Subject: RE: Comment on RFC 3280bis: id-pkix-crl-nocheck extension
Accept-Language: en-US
AcceptLanguage: en-US
Sender: [email-masked]

Denis:

I agree that could be a very valuable extension given the recent trend of systems and applications issuing short lived certificates for the purpose of authentication.  I don't believe it should hold up RFC3280bis though.

David B. Cross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Tuesday, July 04, 2006 5:57 AM
To: [email-masked]
Subject: Comment on RFC 3280bis: id-pkix-crl-nocheck extension

We currently have id-pkix-ocsp-nocheck extension.

In order to support trust anchors that issue short-lived PKCs for CRL issuers, there is a need to create a id-pkix-crl-nocheck extension.

Denis

Date: Sun, 09 Jul 2006 10:17:34 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Comment on RFC 3280bis: id-pkix-crl-nocheck extension
Sender: [email-masked]

Denis:

>We currently have id-pkix-ocsp-nocheck extension.
>
>In order to support trust anchors that issue short-lived PKCs for 
>CRL issuers,
>there is a need to create a id-pkix-crl-nocheck extension.

id-pkix-ocsp-nocheck is not discussed in 3280 or 3280bis.  So, I do 
not understand why you think the proposed extension ought to be added 
to 3280bis.  Perhaps it belongs in another document.  From my 
perspective, it is not clear that there is consensus for a 
id-pkix-crl-nocheck extension.  Adding it without confirming that 
there is consensus is a very big concern.

If 3280bis goes forward without a id-pkix-crl-nocheck extension, a 
separate document can be written to address this topic.  Using a 
separate document allows us to easily determine consensus.

Russ

Date: Wed, 5 Jul 2006 18:48:19 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Sender: [email-masked]

>Denis,
>
>How could a relying party know that no CRL is available for
>short-lived certificates?
>
>Yes, this is an interesting question.
>
>Two options come across my mind.
>
>Option 1 is to introduce a certificate extension similar to the
>id-pkix-ocsp-nocheck extension defined in RFC 2560.

>Option 2 is letting the validity period of the short-lived
>certificates equal to the update period of the CRL. That is
>letting the notBefore of the certificate equal thisUpdate of the
>CRL and  letting the notAfter of the certificate equal
>nextUpdate of the CRL. The relying party has to be smart
>enough to know that since the validity period of the
>short-lived certificates is equivalent to the period of
>the updated revocation info is given by the CA to
>the delegated CRL issuer, it is reasonable that there is no
>need to check the revocation status of the short-lived
>certificates.

The main disadvantage is that there would the need to fetch a CRL 
to know this, while option 1 avoids to fetch it.

Option 1 is simple and only mandates the definition of an OID for that extension.

What is more difficult, is the writing of a full story when the CA delegates the 
issuance of CRLs. Using this would allow to increase the protection of root keys.
This would be a major benefit.

Denis

>Obviously, adopting option 2 might cause ambiguity, but
>it has the advantage that there is no need to introduce
>a new extension.
>
>Regards,
>Wen-Cheng Wang
>
>From: "Denis Pinkas" <[email-masked]>
>To: <[email-masked]>
>Sent: Tuesday, July 04, 2006 6:10 PM
>Subject: Re:Question about indirect CRLs (and designated OCSP responders)
>
>
>> 
>> 
>> I jump into this interresting discussion.
>> 
>>>Julien,
>>>
>>>Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
>>>issuer, and the other is the CA itself.
>> 
>> In case, the CA handles the revocation of the CRL issuer(s).
>> Otherwise, it can issue short-lived certificates.
>> 
>>>The CA itself is responsible for revoking the certificate for the delegated
>>>CRL issuer. Therefore, the CA still need to issue a special CRL that
>>>at least cover the certificate for the delegated CRL issuer. In that case,
>>>the certificate should contain a CRLDP and the special CRL should
>>>contain an matched IDP, since the special CRL is a partitioned CRL
>>>(or offically called a CRL distribution point in the ITU-T X.509 standards).
>>>
>>>The delegated CRL issuer is responsible for revoking all certificates
>>>issued by the CA other than the certificate of itself.
>>>
>>>BTW, in the case where a CA delegate its revocation responsibility to
>>>an OCSP responder instead of a delegated CRL issued, the same
>>>approach can also be used to revoke the certificate for the OCSP
>>>responder if it is not a short-lived certificate.
>>>
>>>What I want to emphasize is that it is inevitable that a CA still need
>>>to issue CRLs even it has delegated its revocation responsibility to
>>>a delegated CRL issuer or an OCSP responder, unless the certificate
>>>for the delegated CRL issuer or the OCSP responder is a short-lived
>>>certificate.
>> 
>> Yes, these are the two options.
>> 
>> - If CRLs are used, then a probably empty CRL would need to be issued each day.
>> 
>> - If short-lived certificates are used, then a new CRL Issuer certificate would need 
>>   to be issued each day. However in that case how could a relying party know 
>>   that no CRL is available ? 
>> 
>> For attribute certificates (AC) we have a way to indicate that no CRL is available, 
>> we would need a similar indication for public key certificates (PKC).
>> 
>> Note : such CRLs and short-lived certificates could be issued in advance and 
>> but only released every day in order to reduce the root key exposure.  
>> 
>> Denis

Date: Fri, 07 Jul 2006 20:47:41 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: Stephen Farrell <[email-masked]>
CC: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Stephen Farrell wrote:
> 
> Hi Dave,
> 
> David Chadwick wrote:
> 
>> The reason that 3281 has not described the first chain above is that 
>> it does not support delegation of authority, and all ACs must be 
>> issued by the SOA.
> 
> That was not accidental.
> 
> If it such delegation were really required, surely the proper
> thing to do would be for you (or someone) to volunteer to write
> an AC profile supporting such delegation.

The whole infrastructure for Delegation of Authority and Recognition of 
Authority is being addressed in the 2009 edition of X.509. New 
extensions are being defined. But one of them, the AAIA extension is an 
identical copy of the AIA extension, the only difference being that CA 
is replaced by AA etc. So it seemed sensible to ask the editor of 
3280bis to make minor edits to AIA to cater for PMIs as well as PKIs 
instead of creating a whole new extension with identical purposes.

The other point to note is that the grid world has already started to 
use AIA for exactly the purpose of referring to the AA that issued an 
AC, in the same way that a PKC uses it to refer to a CA. This is quite a 
large established user base, and it would be awkward for them to have to 
change to a new AAIA extension

> 
> Of course, that'd take quite a while to get done and may or may
> not fit with the current PKIX charter,

I would not propose to write a whole ID for DoA/RoA within PKIX as it 
will take years to do. But we are already doing this within ISO anyway, 
so son of PKIX can do a profile in the future if it wishes to.

  but stuffing one such change
> into 3280bis sounds to me like a bad idea (as, IMO, is the X.509
> model for AC delegation, but that's a different story:-)

Well at least it is a delegation model that works and is deployed. 
Unlike XACML and SAML for example that is incapable of delegation :-)

regards

David

> Stephen.

-- 

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

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

Date: Fri, 07 Jul 2006 20:11:21 +0100
From: Stephen Farrell <[email-masked]>
To: David Chadwick <[email-masked]>
CC: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Hi Dave,

David Chadwick wrote:

> The reason that 3281 has not described the first chain above is that it 
> does not support delegation of authority, and all ACs must be issued by 
> the SOA.

That was not accidental.

If it such delegation were really required, surely the proper
thing to do would be for you (or someone) to volunteer to write
an AC profile supporting such delegation.

Of course, that'd take quite a while to get done and may or may
not fit with the current PKIX charter, but stuffing one such change
into 3280bis sounds to me like a bad idea (as, IMO, is the X.509
model for AC delegation, but that's a different story:-)

Stephen.

Date: Fri, 07 Jul 2006 19:36:56 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Hi Dave

When we have an AC that is signed by an AA who is not an SOA, and DNs 
are used to refer to the holders and issuers, then we have (at least) 
two certificate chains that need to be followed

the first is the PMI chain from the holder to the AA to [the next AA to] 
the SOA
the second is the PKI chain from the PKC of the issuer to [the PKC of 
the CA] to the PKC of the root CA (trust anchor)

We are proposing that you edit 3280bis to allow the AIA to be used 
inside ACs to enable the first chain above to be tracked to the SOA. 
(this is exactly analogous to its use in PKIs to find a root CA).

The authority key identifier can be used inside the AC to point to the 
first PKC for the second chain above.

The reason that 3281 has not described the first chain above is that it 
does not support delegation of authority, and all ACs must be issued by 
the SOA.

regards

David

David A. Cooper wrote:
> 
> David Chadwick wrote:
> 
>> Hi Dave
>>
>> at the PKIX meeting next week I will be giving a short presentation to 
>> request that the AIA extension be generalised to apply to the issuer 
>> of any type of certificate (not just PKCs) so that it can point to 
>> information about the AA of an AC for example. Do you have a problem 
>> with this?
> 
> 
> David,
> 
> I was just looking at RFC 3281 (An Internet Attribute Certificate 
> Profile for Authorization) and found the following text:
> 
>      4.3.3   Authority Key Identifier
> 
>         The authorityKeyIdentifier extension, as profiled in [PKIXPROF], 
> MAY
>         be used to assist the AC verifier in checking the signature of the
>         AC.  The [PKIXPROF] description should be read as if "CA" meant "AC
>         issuer."  As with PKCs, this extension SHOULD be included in ACs.
> 
>         Note: An AC, where the issuer field used the baseCertificateID
>         CHOICE, would not need an authorityKeyIdentifier extension, as 
> it is
>         explicitly linked to the key in the referred certificate.  However,
>         as this profile states (in section 4.2.3), ACs MUST use the v2Form
>         with issuerName CHOICE, this duplication does not arise.
> 
>            name           id-ce-authorityKeyIdentifier
>            OID            { id-ce 35 }
>            syntax         AuthorityKeyIdentifier
>            criticality    MUST be FALSE
> 
> Does this address your requirement?  I don't think this should be in 
> 3280bis since 3280bis only addresses public key certificates.
> 
> Dave
> 
> 

-- 

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

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

From: "Michael Myers" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, "'Kemp David P.'" <[email-masked]>, "David A. Cooper" <[email-masked]>, "Turner, Sean P." <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: RE: name constraints on x400Address, ediPartyName, and registeredID name forms
Date: Thu, 6 Jul 2006 17:41:55 -0800
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C6A123.791626E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

MessageSharon, Dave:

Negative requirements cannot be tested.

Mike
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Sharon Boeyen
  Sent: Thursday, July 06, 2006 7:07 AM
  To: 'Kemp David P.'; David A. Cooper; Turner, Sean P.
  Cc: pkix
  Subject: RE: name constraints on x400Address, ediPartyName, and
registeredID name forms

  I agree with softening the statement to should not because of the argument
David makes. If we allow name constraints for "otherName" name forms it
seems excessive to forbid these completely. That can lead to confusion for
systems that actually need to support such name constraints in a particular
environment (I've seen name constraints on X.400 addresses for example,
although they could be deemed outside the scope of "the Internet PKI").

  Cheers,
  Sharon
    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp David P.
    Sent: Wednesday, July 05, 2006 2:09 PM
    To: David A. Cooper; Turner, Sean P.
    Cc: pkix
    Subject: RE: name constraints on x400Address, ediPartyName, and
registeredID name forms

    MUST NOT seems excessive, given that interoperability is not guaranteed
for rfc822Name, etc, that applications are not required to support.

    But since the express purpose of a profile is to foster
interoperability, it seems reasonable for 3280bis to discourage the use of
name constraints for some name forms including those defined using
otherName:

    "Conforming CAs MUST mark this extension as critical and SHOULD NOT
impose name constraints on the x400Address, ediPartyName, registeredID, or
otherName name forms."

    As an aside, I'm not sure why registeredID made it onto the list of
forbidden name constraint forms; OIDs are purely hierarchical and constraint
processing for this name form would be particularly simple to implement.
But if there is little demand for names of this form there is little harm in
discouraging its use.  There would be harm in continuing to forbid it.

    Dave K

----------------------------------------------------------------------------

    From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
    Sent: Wednesday, July 05, 2006 12:15 PM
    To: Turner, Sean P.
    Cc: pkix
    Subject: name constraints on x400Address, ediPartyName, and registeredID
name forms

    Sean,

    If I understand you correctly now, your concern is not that 3280bis
seems contradictory, but that you disagree with 3280bis forbidding
conforming CAs from imposing name constraints on the x400Address,
ediPartyName, and registeredID name forms.  I can't remember why this
requirement was included in the initial draft of 3280bis, but I can see that
there is a good argument for removing it.

    While it is a good idea to limit the set of name forms for which name
constraints are imposed in order to maximize interoperability, this does not
do that.  3280bis currently states:

          Applications conforming to this profile MUST be able to process
name
          constraints that are imposed on the directoryName name form and
          SHOULD be able to process name constraints that are imposed on the
          rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
          forms.

    If the goal was to maximize interoperability, then 3280bis should have
forbidden imposing name constraints on any name forms except those mentioned
above.  However, while 3280bis forbids specifying name constraints for the
x400Address, ediPartyName, and registeredID name forms, it does not forbid
specifying name constraints for names forms that are defined for inclusion
within otherName.  So the effect is that 3280bis permits specifying permits
specifying name constraints for any name form (from an potentially unbounded
set of name forms) except these three name forms.

    What do others think?  Is there is any reason to forbid conforming CAs
from specifying name constraints for these three name forms while not
forbidding conforming CAs from specifying name constraints for any name form
that might be defined for inclusion within otherName?

    Dave

    Turner, Sean P. wrote:

8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name
constraints on ediPartyName or registeredID but the 14th para (the one
before the ASN.1) indicates that ediPartyName and registeredId are not
defined in this spec but MAY be defined in another spec. Sounds to me
like it would be hard to convince a customer that you could write a name
constraints that can ever be 3280bis compliant since whatever you
wrote MUST NOT be imposed/implemented. It's not clear that the name
constraints shouldn't be imposed because they're not defined in the spec or
whether they should never ever be imposed.      3280bis states:       The
syntax and semantics for name constraints for otherName,      ediPartyName,
and registeredID are not defined by this specification,      however syntax
and semantics for name constraints for other name      forms may be
specified in other documents. A CA conforming to 3280bis MUST NOT impose
name constraints on the x400Address, ediPartyName, or registeredID name
forms.  Period.  However, just as [SRVSAN] specifies the syntax and
semantics for name constraints on the SRVName name form, other documents
could specify the syntax and semantics for name constraints on other name
forms.  Given that 3280bis forbids conforming CAs from imposing name
constraints on the x400Address, ediPartyName, or registeredID name forms, it
would seem to be inappropriate for another PKIX (or even IETF) document to
specify syntax and semantics for name constraints on ediPartyName or
registeredID name forms, but 3280bis is just one profile of X.509.  A
different profile of X.509 may permit the specification of name constraints
on these name forms and may specify the syntax and semantics for imposing
constraints on those name forms.  While 3280bis states that conforming CAs
MUST NOT impose name constraints on these name forms, conforming relying
parties are permitted to implement the ability to process name constra
 ints on these name forms since conforming relying parties are not
restricted to only accepting certificates that are issued in conformance
with 3280bis.     I don't understand why these name forms were specifically
picked out. Forx400Address I assume it's that nobody cares, but you could
easily write arule that said the OR Address attributes (just like DNs) must
be within theones included. I write the rules if we decide we need them. For
registeredIdI get that it's an OID so there's structure to it so it's
imposible to writerules but why couldn't somebody decide to carve up an OID
tree and saysomething like ma
 ke sure the 1st 6 components of the OID are present in allnames. For the
ediPartyName you could say the nameAssigner must be presentin all PKCs. If
there is no way I can say with a straight face that a CA that requires aname
constraints for x400Address, ediPartyName, or registeredID iscompliant, I've
got a problem with thi
 s what it says because being compliantwith RFC3280 is the gold standard;
besides I think the rules are easy enoughto write I don't understand why
these particular name forms were omitted(there may be good reasons I'm
unaware of).   9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose
name constraints on x400Address name forms but the last sentence in the 10th
para last says X400Address MUST be applied to x.400 addresses. See #8.
While a conforming CA MUST not impose name constraints on the x400Address
name form, a conforming relying party MAY implement the ability to process
such constraints.  As with any other name form, if a certificate includes
name constraint on the x400Address name form and a subsequent certificate in
the certification path includes a subjectAltName extension with an
x400Address name, the relying party MUST either process the constraint or
reject the certification path.
     See above.

------=_NextPart_000_0006_01C6A123.791626E0
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><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1555" 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: Tahoma;
}
@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; COLOR: black; FONT-FAMILY: "Times =
New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: "Times =
New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; 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
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: =
"Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
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 bgColor=3Dwhite>
<DIV><SPAN class=3D181043601-07072006><FONT face=3DArial color=3D#0000ff =

size=3D2>Sharon, Dave:</FONT></SPAN></DIV>
<DIV><SPAN class=3D181043601-07072006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D181043601-07072006><FONT face=3DArial color=3D#0000ff =

size=3D2>Negative requirements cannot be tested.</FONT></SPAN></DIV>
<DIV><SPAN class=3D181043601-07072006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D181043601-07072006><FONT face=3DArial color=3D#0000ff =

size=3D2>Mike</FONT></SPAN></DIV>
<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>Sharon=20
  Boeyen<BR><B>Sent:</B> Thursday, July 06, 2006 7:07 AM<BR><B>To:</B> =
'Kemp=20
  David P.'; David A. Cooper; Turner, Sean P.<BR><B>Cc:</B>=20
  pkix<BR><B>Subject:</B> RE: name constraints on x400Address, =
ediPartyName, and=20
  registeredID name forms<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D036550315-06072006><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  agree with softening the statement to should not because of the =
argument David=20
  makes. If we allow name constraints for "otherName" name forms it =
seems=20
  excessive to forbid these completely. That can lead to confusion for =
systems=20
  that actually need to support such name constraints in a particular=20
  environment (I've seen name constraints on X.400 addresses for =
example,=20
  although they could be deemed outside the scope of "the Internet =
PKI").=20
  </FONT></SPAN></DIV>
  <DIV><SPAN class=3D036550315-06072006><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D036550315-06072006><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Cheers,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D036550315-06072006><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Sharon</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
    [email-masked] [mailto:[email-masked]] =
<B>On=20
    Behalf Of </B>Kemp David P.<BR><B>Sent:</B> Wednesday, July 05, 2006 =
2:09=20
    PM<BR><B>To:</B> David A. Cooper; Turner, Sean P.<BR><B>Cc:</B>=20
    pkix<BR><B>Subject:</B> RE: name constraints on x400Address, =
ediPartyName,=20
    and registeredID name forms<BR><BR></FONT></DIV>
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">MUST NOT =
seems=20
    excessive, given that interoperability is not guaranteed for =
rfc822Name,=20
    etc, that applications are not required to=20
    support.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">But since =
the=20
    express purpose of a profile is to foster interoperability, it seems =

    reasonable for 3280bis to discourage the use of name constraints for =
some=20
    name forms including those defined using=20
    otherName:<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">"Conforming CAs=20
    MUST mark this extension as critical and SHOULD NOT impose name =
constraints=20
    on the x400Address, ediPartyName, registeredID, or otherName name=20
    forms."<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As an =
aside, I'm=20
    not sure why registeredID made it onto the list of forbidden name =
constraint=20
    forms; OIDs are purely hierarchical and constraint processing for =
this name=20
    form would be particularly simple to implement. &nbsp;But if there =
is little=20
    demand for names of this form there is little harm in discouraging =
its use.=20
    &nbsp;There would be harm in continuing to forbid=20
    it.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Dave=20
    K<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
    face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt; COLOR: windowtext">
    <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
    </SPAN></FONT></DIV>
    <P class=3DMsoNormal><B><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN=20
    style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: windowtext; =
FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT=20
    face=3DTahoma color=3Dblack size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Tahoma">=20
    [email-masked] [mailto:[email-masked]] =
<B><SPAN=20
    style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>David A.=20
    Cooper<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> =
Wednesday,=20
    July 05, 2006 12:15 PM<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">To:</SPAN></B>=20
    Turner, Sean P.<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
    pkix<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> =
name=20
    constraints on x400Address, ediPartyName, and registeredID name=20
    forms</SPAN></FONT><FONT color=3Dblack><SPAN=20
    style=3D"COLOR: windowtext"><o:p></o:p></SPAN></FONT></P></DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">Sean,<BR><BR>If I understand you correctly =
now, your=20
    concern is not that 3280bis seems contradictory, but that you =
disagree with=20
    3280bis forbidding conforming CAs from imposing name constraints on =
the=20
    x400Address, ediPartyName, and registeredID name forms.&nbsp; I =
can't=20
    remember why this requirement was included in the initial draft of =
3280bis,=20
    but I can see that there is a good argument for removing =
it.<BR><BR>While it=20
    is a good idea to limit the set of name forms for which name =
constraints are=20
    imposed in order to maximize interoperability, this does not do =
that.&nbsp;=20
    3280bis currently states:<BR><BR>&nbsp; &nbsp; &nbsp; Applications=20
    conforming to this profile MUST be able to process name<BR>&nbsp; =
&nbsp;=20
    &nbsp; constraints that are imposed on the directoryName name form=20
    and<BR>&nbsp; &nbsp; &nbsp; SHOULD be able to process name =
constraints that=20
    are imposed on the<BR>&nbsp; &nbsp; &nbsp; rfc822Name,=20
    uniformResourceIdentifier, dNSName, and iPAddress name<BR>&nbsp; =
&nbsp;=20
    &nbsp; forms.<BR><BR>If the goal was to maximize interoperability, =
then=20
    3280bis should have forbidden imposing name constraints on any name =
forms=20
    except those mentioned above.&nbsp; However, while 3280bis forbids=20
    specifying name constraints for the x400Address, ediPartyName, and=20
    registeredID name forms, it does not forbid specifying name =
constraints for=20
    names forms that are defined for inclusion within otherName.&nbsp; =
So the=20
    effect is that 3280bis permits specifying permits specifying name=20
    constraints for any name form (from an potentially unbounded set of =
name=20
    forms) except these three name forms.<BR><BR>What do others =
think?&nbsp; Is=20
    there is any reason to forbid conforming CAs from specifying name=20
    constraints for these three name forms while not forbidding =
conforming CAs=20
    from specifying name constraints for any name form that might be =
defined for=20
    inclusion within otherName?<BR><BR>Dave<BR><BR>Turner, Sean P.=20
    wrote:<BR><BR><o:p></o:p></SPAN></FONT></P>
    <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite">
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">8. Sec 4.2.1.10: 3rd para =
indicates that CAs MUST NOT impose name =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">constraints on =
ediPartyName or registeredID but the 14th para (the one =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE>=
</BLOCKQUOTE>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">before the ASN.1) indicates =
that ediPartyName and registeredId are not =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE>=
</BLOCKQUOTE>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">defined in this spec but MAY be =
defined in another spec. Sounds to me =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE>=
</BLOCKQUOTE>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">like it would be hard to =
convince a customer that you could write a =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">name constraints =
that can ever be 3280bis compliant since whatever you =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE>=
</BLOCKQUOTE>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">wrote MUST NOT be =
imposed/implemented. It's not clear that the name =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">constraints =
shouldn't be imposed because they're not defined in the =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">spec or whether =
they should never ever be =
imposed.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE><PRE wrap=3D""><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">3280bis states:<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FO NT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The syntax and semantics for name =
constraints for otherName,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ediPartyName, and registeredID are =
not defined by this =
specification,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; however syntax and semantics for =
name constraints for other name<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; forms may be specified in other =
documents.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FON: 10pt">A CA conforming to =
3280bis MUST NOT impose name constraints =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">on the =
x400Address, ediPartyName, or registeredID name forms.&nbsp; =
Period.&nbsp; <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">However, =
just as [SRVSAN] specifies the syntax and semantics =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">for name =
constraints on the SRVName name form, other =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">documents could =
specify the syntax and semantics for name =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">constraints on =
other name forms.&nbsp; Given that 3280bis forbids =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT color=3Dblack size=3D2 =
e=3D"Courier New" fac><SPAN style=3D"FONT-SIZE: 10pt">conforming CAs =
from imposing name constraints on the =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">x400Address, =
ediPartyName, or registeredID name forms, it =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">would seem to be =
inappropriate for another PKIX (or even =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">IETF) document to =
specify syntax and semantics for name =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">constraints on =
ediPartyName or registeredID name forms, but =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">3280bis is just =
one profile of X.509.&nbsp; A different profile of =
<o:p></o:p></SPAN></FON T></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">X.509 may permit =
the specification of name constraints on =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">these name forms =
and may specify the syntax and semantics for =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">imposing =
constraints on those name forms.&nbsp; While 3280bis =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">states that =
conforming CAs MUST NOT impose name constraints =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">on these name =
forms, conforming relying parties are permitted =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">to implement the =
ability to process name constra
 ints on these <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">name forms =
since conforming relying parties are not =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">restricted to =
only accepting certificates that are issued in =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">conformance with =
3280bis.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp; =
<o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE><PRE wrap=3D""><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">I don't =
understand why these name forms were specifically picked out. =
For<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
Ne&#13;&#10; w" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">x400Address I assume it's that nobody cares, but you could easily =
write a<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">rule that said =
the OR Address attributes (just like DNs) must be within =
the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">ones included. I =
write the rules if we decide we need them. For =
registeredId<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">I get that =
it's an OID so there's structure to it so it's imposible to =
write<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">rules but why =
couldn't somebody decide to carve up an OID tree and =
say<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">something like ma
 ke sure the 1st 6 components of the OID are present in =
all<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">names. For the =
ediPartyName you could say the nameAssigner must be =
present<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">in all =
PKCs.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">If there is =
no way I can say with a straight face that a CA that requires =
a<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">name constraints =
for x400Address, ediPartyName, or registeredID =
is<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">compliant, I've =
got a problem with thi
 s what it says because being =
compliant<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">with RFC3280 is =
the gold standard; besides I think the rules are easy =
enough<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">to write I don't =
understand why these particular name forms were =
omitted<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">(there may be =
good reasons I'm unaware of).<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"> <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE>
    <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite">
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">9. Sec 4.2.1.10: 3rd para =
indicates that CAs MUST NOT impose name =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">constraints on =
x400Address name forms but the last sentence in the 10th =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE>=
</BLOCKQUOTE>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">para last says X400Address MUST =
be applied to x.400 addresses. See =
#8.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE><PRE wrap=3D""><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">While a conforming CA MUST not impose name constraints on the =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">x400Address name =
form, a conforming relying party MAY =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">implement the =
ability to process&nbsp; such constraints.&nbsp; As with =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><S style=3D"FONT-SIZE: 10pt" PAN>any other name =
form, if a certificate includes name =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">constraint on the =
x400Address name form and a subsequent =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">certificate in =
the certification path includes a =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">subjectAltName =
extension with an x400Address name, the =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">relying party =
MUST either process the constraint or reject =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">the certification =
path.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;
 &nbsp;&nbsp; <o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE><PRE =
wrap=3D""><FONT face=3D"Courier New" color=3Dblack size=3D2><SPAN =
style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">See =
above.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt"> =
<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BLOCKQUOTE>=
</S></FONT></FONT></BODY></HTML>

------=_NextPart_000_0006_01C6A123.791626E0--

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'David A. Cooper'" <[email-masked]>
Cc: "'pkix'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt
Date: Thu, 6 Jul 2006 19:32:18 -0400
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Dave,
 
#4 - While I don't think length of time in print is a good reason to not
accept a comment, I thought it was an editorial comment and as editor you're
free to dismiss/reject/overrule the comment ;)
#6 - Also thought this one was editorial. If the text doesn't add an error
or ambiguity, I don't see the harm in adding it though.
#7 - Also thought this one was editorial.  But upon another read, the bit in
the security considerations about the importance of the procedures to
validate the bindings addresses my concerns.
#13 - I think is fixed.
#16 - I also think this is editorial. But, if you won't change the 2nd
sentence will you delete the "(or issuer alternative name)" from the last
sentence in the 1st paragraph?
#17 - Also thought this one was editorial. With the fix to 4.2.1.7, my
concerns are addressed.
 
spt

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Wednesday, July 05, 2006 11:50 AM
To: Turner, Sean P.
Cc: pkix
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt

Sean,

common in-line

Turner, Sean P. wrote: 

David comments in-line.  I snipped out the ones that you accepted or you

resolved. 

------------------

4. Sec 4 1st para last sentence: remove required to support a PKI.  All 

of the internet defined extensions are optional so they can't be 

required to support a PKI for the internet community.

The full sentence is "This section also defines private 

extensions required to support a PKI for the Internet 

community."  These extensions (authorityInfoAccess an 

subjectInfoAccess) are needed even though it is not necessary 

to include them in all certificates. 

Exactly - they are needed but not required. I still think the sentence ought

to read: This section also defines extension to support the PKI for the

internet community.  There's no need to say required.

I looked at the earlier RFCs and discovered that this sentence has appeared
in the PKIX certificate and CRL profile, unchanged, since RFC 2459.  Barring
evidence to the contrary, I think that indicates rough consensus in favor of
the current text.

6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key 

id generation? How about striking SHA-1 from the methods and adding the 

new sentence to both: The hash algorithm employed can be the same 

algorithm paired with the signature algorithm (e.g., SHA-1, SHA-256,
SHA-384).

Section 4.2.1.2 simply states that the two methods described 

are two common methods for generating key identifiers.  The 

text explicitly does not restrict CAs to using these methods.

This one didn't come across very well. I know there's no security issue and

there are just examples but sometimes people just implement the examples and

we end up getting stuck with those. Further I'm trying to avoid silly things

like somebody saying I won't use a spec that has SHA1 and they don't

understand that they're only examples.

It is also not clear why one would want to use SHA-256, SHA-384, etc. 

instead of SHA-1.  There are no security issues associated 

with key identifiers, so it would seem that using a hash 

algorithm with a longer output would just make the 

certificates larger.

I wasn't clear with the use any hash algorithm part. I think the example

should still indicate that a 160bit output is used with whatever hash

algorithm is used. So for logner hash outputs they only use 160bits of it.

It doesn't matter which bits as long as the CA is consistent.

These examples for methods of generating key identifiers also date back to
RFC 2459 and I still don't see the motivation for changing.

You say that even though they are just examples, "sometimes people just
implement the examples and we end up getting stuck with those."  Why is that
a problems is there is nothing wrong with the examples.

While it is hypothetically possible that someone may claim that they refuse
to use 3280bis since it mentions the use of SHA-1 somewhere, I don't think
we should change the document just to prevent the that possibility.

7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that 

since the SAN is bound to the public key that the CA MUST verify the 

each part of the SAN. I think a similar statement ought to be added to 

the subject section (4.1.2.6) to indicate that "All parts of the 

subject name MUST be verified by the CA as it is bound to the public key". 

It is my understanding the the statement in 4.2.1.6 was added 

because there were cases in which CAs were verifying the name 

they included in the subject field but not names included in 

the subjectAltName extension.  Are you aware of a similar 

problem with the subject field?

No.  It was a motherhood and apple pie statement.

So, why does the statement need to be added?

13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the 

onlyContainsAttributeCerts seems to hang. Recommend adding "In either case"

to the beginning of the sentence to address the case when either 

onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. 

Additionally, recommend adding the following for completeness as a new 

last paragraph: "If the scope of the CRL only includes attribute 

certificates then the onlyContainsAttributeCerts MUST be set to TRUE 

and both onlyContainsUserCerts and onlyContainsCACerts MUST be set to
FALSE."

      

This sentence was really meant to say that 

onlyContainsAttributeCerts MUST be set to FALSE in all cases, 

not just when either onlyContainsUserCerts or 

onlyContainsCACerts is set to TRUE.  In order to make this 

more clear, the sentence about onlyContainsAttributeCerts has 

been moved to the end of the paragraph and now reads:

      Conforming CRLs issuers MUST set the 

onlyContainsAttributeCerts boolean

      to FALSE.

Are we not addressing the case when the CRL is only for attribute

certificates?

Correct.  This profile only address public key certificates.

In addition, the original definition of the issuingDistributionPoint
extension in X.509 did not include the onlyContainsAttributeCerts field and
the resolution to DR 305 resulted in X.509 reverting to the original
definition of the extension.  So, the X.509 definition of the
issuingDistributionPoint extension does not include the
onlyContainsAttributeCerts field.  Always setting this value to FALSE
ensures consistency with X.509.  (Note that the resolution to DR 305 defined
a new CRL extension for defining the scope of a CRL with respect to
attribute certificates, but that extension does not belong in 3280bis since
3280bis only deals with public key certificates.)

6. Sec 4.2.1.6 1st para: r These identities may be included in 

addition to or in the place of the identity/These identities may be 

included in addition to or in the place of, in the case of non-CAs, the 

identity.  The paragraph mixes SAN and IAN, but assumed the 2nd sentence
addressed SAN.

      

Section 4.1.2.6 already very clearly states under what 

circumstances a non-empty DN is required.  I don't think that 

information needs to be repeated here.

I'm only hoping to clarify the 1st paragraph. It's unclear whether the

"these" refers to SAN or IAN after a couple of reads of the 1st para since

IAN is thrown in later in the paragraph.  If you add the ", in the case of

non-CAs," it's clear that the 2nd sentence refers to the SAN. 

I don't see how "these" could be read as referring to the issuerAltName
extension.

Also, note that saying "in the case of non-CAs" would be misleading since
section 4.1.2.6 states that certificates issued to CRL issuers must also
include a non-empty subject DN.

17. Sec 4.2.1.6: Add the following to clarify that there is no 

dependency in this spec between SAN and IAN: This specification places 

no requirement on CAs, whose certificate includes Issuer Alterative 

name, to include Subject Alternative names in certificates issued by the CA.

While this statement is certainly true, I don't understand 

the need to include it in section 4.2.1.6.  Is there any 

reason that readers of 3280bis would believe that any 

certificate that includes an issuerAltName extension would 

also need to include a subjectAltName extension?

I'm only trying to protect against something silly like somebody who assumes

that the issuer/subject fields are in all PKCs then IAN/SAN ought to be in

all certificate too. An explicit indication that there is no requirement to

include one if the other is present removes any doubt.

As long as 3280bis is already, it would be much longer if we added explicit
statements to contradict every incorrect assumption that anybody could
imagine that someone might make.  Although, there have certainly been cases
where people have assumed that a certain requirement exists and then have
insisted that the requirement must exist unless the document includes an
explicit statement that the requirement does not exist (even when there is
nothing in the document that even hints at the suggestion that such a
requirement exists).

I think the best we can do is to try to ensure that the document does not
include statements that imply things that are incorrect.  Explicit
statements contradicting incorrect assumptions should only be used where
there is evidence that confusion exists in that area.  Adding statement to
deal with the hypothetical possibility that someone might make an incorrect
assumption about something, despite there being nothing in the document that
could lead to that assumption and no evidence that people have been confused
in that area, seems unnecessary.

Dave

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Dave,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>#4 - While I don't think length of time in =
print is a good=20
reason to not accept a comment, I thought it was an editorial comment =
and as=20
editor you're free to dismiss/reject/overrule&nbsp;the comment=20
;)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>#6 - Also thought this one was =
editorial.&nbsp;If the=20
text&nbsp;doesn't add&nbsp;an error or ambiguity, I don't see the harm =
in adding=20
it though.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>#7 - Also thought this one was editorial.&nbsp; =
But upon=20
another read, the bit in the security considerations about the =
importance of the=20
procedures to validate the bindings addresses my =
concerns.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>#13 - I think is fixed.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>#16 - I also think this is editorial. But, if =
you won't=20
change the 2nd sentence will you delete the "(or issuer alternative =
name)" from=20
the last sentence in the 1st paragraph?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>#17 - Also thought this one was editorial. With =
the fix to=20
4.2.1.7, my concerns are addressed.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D111481920-06072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>spt</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>David A.=20
Cooper<BR><B>Sent:</B> Wednesday, July 05, 2006 11:50 AM<BR><B>To:</B> =
Turner,=20
Sean P.<BR><B>Cc:</B> pkix<BR><B>Subject:</B> Re: I-D=20
ACTION:draft-ietf-pkix-rfc3280bis-03.txt<BR></FONT><BR></DIV>
<DIV></DIV>Sean,<BR><BR>common in-line<BR><BR>Turner, Sean P. wrote:=20
<BLOCKQUOTE cite=3Dmid009001c69c4e$0395d110$0201a8c0@Wylie =
type=3D"cite"><PRE wrap=3D"">David comments in-line.  I snipped out the =
ones that you accepted or you
resolved.=20
------------------

  </PRE>
  <BLOCKQUOTE type=3D"cite">
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">4. Sec 4 1st para last =
sentence: remove required to support a PKI.  All=20
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">of the internet defined =
extensions are optional so they can't be=20
required to support a PKI for the internet community.
=20

      </PRE></BLOCKQUOTE><PRE wrap=3D"">The full sentence is "This =
section also defines private=20
extensions required to support a PKI for the Internet=20
community."  These extensions (authorityInfoAccess an=20
subjectInfoAccess) are needed even though it is not necessary=20
to include them in all certificates.=20
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
Exactly - they are needed but not required. I still think the sentence =
ought
to read: This section also defines extension to support the PKI for the
internet community.  There's no need to say required.
  </PRE></BLOCKQUOTE>I looked at the earlier RFCs and discovered that =
this=20
sentence has appeared in the PKIX certificate and CRL profile, =
unchanged, since=20
RFC 2459.&nbsp; Barring evidence to the contrary, I think that indicates =
rough=20
consensus in favor of the current text.<BR><BR>
<BLOCKQUOTE cite=3Dmid009001c69c4e$0395d110$0201a8c0@Wylie =
type=3D"cite">
  <BLOCKQUOTE type=3D"cite">
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">6. Sec 4.2.1.2: Can we =
suggest using something other than SHA-1 for key=20
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">id generation? How about =
striking SHA-1 from the methods and adding the=20
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">new sentence to both: The =
hash algorithm employed can be the same=20
algorithm paired with the signature algorithm (e.g., SHA-1, SHA-256, =
SHA-384).
      </PRE></BLOCKQUOTE><PRE wrap=3D"">Section 4.2.1.2 simply states =
that the two methods described=20
are two common methods for generating key identifiers.  The=20
text explicitly does not restrict CAs to using these methods.
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
This one didn't come across very well. I know there's no security issue =
and
there are just examples but sometimes people just implement the examples =
and
we end up getting stuck with those. Further I'm trying to avoid silly =
things
like somebody saying I won't use a spec that has SHA1 and they don't
understand that they're only examples.
  </PRE>
  <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">It is also not clear why one =
would want to use SHA-256, SHA-384, etc.=20
instead of SHA-1.  There are no security issues associated=20
with key identifiers, so it would seem that using a hash=20
algorithm with a longer output would just make the=20
certificates larger.
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
I wasn't clear with the use any hash algorithm part. I think the example
should still indicate that a 160bit output is used with whatever hash
algorithm is used. So for logner hash outputs they only use 160bits of =
it.
It doesn't matter which bits as long as the CA is consistent.
  </PRE></BLOCKQUOTE>These examples for methods of generating key =
identifiers=20
also date back to RFC 2459 and I still don't see the motivation for=20
changing.<BR><BR>You say that even though they are just examples, =
"sometimes=20
people just implement the examples and we end up getting stuck with=20
those."&nbsp; Why is that a problems is there is nothing wrong with the=20
examples.<BR><BR>While it is hypothetically possible that someone may =
claim that=20
they refuse to use 3280bis since it mentions the use of SHA-1 somewhere, =
I don't=20
think we should change the document just to prevent the that =
possibility.<BR>
<BLOCKQUOTE cite=3Dmid009001c69c4e$0395d110$0201a8c0@Wylie =
type=3D"cite"><PRE wrap=3D""> =20
  </PRE>
  <BLOCKQUOTE type=3D"cite">
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">7. Sec 4.2.1.6/4.1.2.6: The =
2nd paragraph of 4.2.1.6 points out that=20
since the SAN is bound to the public key that the CA MUST verify the=20
each part of the SAN. I think a similar statement ought to be added to=20
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">the subject section =
(4.1.2.6) to indicate that "All parts of the=20
subject name MUST be verified by the CA as it is bound to the public =
key".=20
      </PRE></BLOCKQUOTE><PRE wrap=3D"">It is my understanding the the =
statement in 4.2.1.6 was added=20
because there were cases in which CAs were verifying the name=20
they included in the subject field but not names included in=20
the subjectAltName extension.  Are you aware of a similar=20
problem with the subject field?
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
No.  It was a motherhood and apple pie statement.
  </PRE></BLOCKQUOTE>So, why does the statement need to be added?<BR>
<BLOCKQUOTE cite=3Dmid009001c69c4e$0395d110$0201a8c0@Wylie =
type=3D"cite"><BR>
  <BLOCKQUOTE type=3D"cite">
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">13. Sec 5.2.5 8th para (one =
before the ASN.1): The sentence about the=20
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">onlyContainsAttributeCerts =
seems to hang. Recommend adding "In either case"
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">to the beginning of the =
sentence to address the case when either=20
onlyContainsUserCerts or onlyContainsCACerts is set to TRUE.=20
Additionally, recommend adding the following for completeness as a new=20
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">last paragraph: "If the =
scope of the CRL only includes attribute=20
certificates then the onlyContainsAttributeCerts MUST be set to TRUE=20
and both onlyContainsUserCerts and onlyContainsCACerts MUST be set to =
FALSE."
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">=20

      </PRE></BLOCKQUOTE><PRE wrap=3D"">This sentence was really meant =
to say that=20
onlyContainsAttributeCerts MUST be set to FALSE in all cases,=20
not just when either onlyContainsUserCerts or=20
onlyContainsCACerts is set to TRUE.  In order to make this=20
more clear, the sentence about onlyContainsAttributeCerts has=20
been moved to the end of the paragraph and now reads:

      Conforming CRLs issuers MUST set the=20
onlyContainsAttributeCerts boolean
      to FALSE.
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
Are we not addressing the case when the CRL is only for attribute
certificates?</PRE></BLOCKQUOTE>Correct.&nbsp; This profile only address =
public=20
key certificates.<BR><BR>In addition, the original definition of the=20
issuingDistributionPoint extension in X.509 did not include the=20
onlyContainsAttributeCerts field and the resolution to DR 305 resulted =
in X.509=20
reverting to the original definition of the extension.&nbsp; So, the =
X.509=20
definition of the issuingDistributionPoint extension does not include =
the=20
onlyContainsAttributeCerts field.&nbsp; Always setting this value to =
FALSE=20
ensures consistency with X.509.&nbsp; (Note that the resolution to DR =
305=20
defined a new CRL extension for defining the scope of a CRL with respect =
to=20
attribute certificates, but that extension does not belong in 3280bis =
since=20
3280bis only deals with public key certificates.)<BR><BR>
<BLOCKQUOTE cite=3Dmid009001c69c4e$0395d110$0201a8c0@Wylie =
type=3D"cite"><PRE wrap=3D""></PRE>
  <BLOCKQUOTE type=3D"cite">
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">6. Sec 4.2.1.6 1st para: r =
These identities may be included in=20
addition to or in the place of the identity/These identities may be=20
included in addition to or in the place of, in the case of non-CAs, the=20
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">identity.  The paragraph =
mixes SAN and IAN, but assumed the 2nd sentence addressed SAN.
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">=20

      </PRE></BLOCKQUOTE><PRE wrap=3D"">Section 4.1.2.6 already very =
clearly states under what=20
circumstances a non-empty DN is required.  I don't think that=20
information needs to be repeated here.
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
I'm only hoping to clarify the 1st paragraph. It's unclear whether the
"these" refers to SAN or IAN after a couple of reads of the 1st para =
since
IAN is thrown in later in the paragraph.  If you add the ", in the case =
of
non-CAs," it's clear that the 2nd sentence refers to the SAN.=20
  </PRE></BLOCKQUOTE>I don't see how "these" could be read as referring =
to the=20
issuerAltName extension.<BR><BR>Also, note that saying "in the case of =
non-CAs"=20
would be misleading since section 4.1.2.6 states that certificates =
issued to CRL=20
issuers must also include a non-empty subject DN.<BR>
<BLOCKQUOTE cite=3Dmid009001c69c4e$0395d110$0201a8c0@Wylie =
type=3D"cite"><PRE wrap=3D""></PRE>
  <BLOCKQUOTE type=3D"cite">
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">17. Sec 4.2.1.6: Add the =
following to clarify that there is no=20
dependency in this spec between SAN and IAN: This specification places=20
      </PRE></BLOCKQUOTE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">no requirement on CAs, =
whose certificate includes Issuer Alterative=20
name, to include Subject Alternative names in certificates issued by the =
CA.=20

      </PRE></BLOCKQUOTE><PRE wrap=3D"">While this statement is =
certainly true, I don't understand=20
the need to include it in section 4.2.1.6.  Is there any=20
reason that readers of 3280bis would believe that any=20
certificate that includes an issuerAltName extension would=20
also need to include a subjectAltName extension?
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
I'm only trying to protect against something silly like somebody who =
assumes
that the issuer/subject fields are in all PKCs then IAN/SAN ought to be =
in
all certificate too. An explicit indication that there is no requirement =
to
include one if the other is present removes any doubt.
  </PRE></BLOCKQUOTE><BR>As long as 3280bis is already, it would be much =
longer=20
if we added explicit statements to contradict every incorrect assumption =
that=20
anybody could imagine that someone might make.&nbsp; Although, there =
have=20
certainly been cases where people have assumed that a certain =
requirement exists=20
and then have insisted that the requirement must exist unless the =
document=20
includes an explicit statement that the requirement does not exist (even =
when=20
there is nothing in the document that even hints at the suggestion that =
such a=20
requirement exists).<BR><BR>I think the best we can do is to try to =
ensure that=20
the document does not include statements that imply things that are=20
incorrect.&nbsp; Explicit statements contradicting incorrect assumptions =
should=20
only be used where there is evidence that confusion exists in that =
area.&nbsp;=20
Adding statement to deal with the hypothetical possibility that someone =
might=20
make an incorrect assumption about something, despite there being =
nothing in the=20
document that could lead to that assumption and no evidence that people =
have=20
been confused in that area, seems =
unnecessary.<BR><BR>Dave<BR><BR></BODY></HTML>

------=_NextPart_000_002F_01C6A132.E5326640--

From: Sharon Boeyen <[email-masked]>
To: "'Kemp David P.'" <[email-masked]>, "David A. Cooper" <[email-masked]>, "Turner, Sean P." <[email-masked]>
Cc: pkix <[email-masked]>
Subject: RE: name constraints on x400Address, ediPartyName, and registered ID name forms
Date: Thu, 6 Jul 2006 11:06:37 -0400 
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_01C6A10D.666F861A
Content-Type: text/plain

I agree with softening the statement to should not because of the argument
David makes. If we allow name constraints for "otherName" name forms it
seems excessive to forbid these completely. That can lead to confusion for
systems that actually need to support such name constraints in a particular
environment (I've seen name constraints on X.400 addresses for example,
although they could be deemed outside the scope of "the Internet PKI"). 
 
Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kemp David P.
Sent: Wednesday, July 05, 2006 2:09 PM
To: David A. Cooper; Turner, Sean P.
Cc: pkix
Subject: RE: name constraints on x400Address, ediPartyName, and registeredID
name forms

MUST NOT seems excessive, given that interoperability is not guaranteed for
rfc822Name, etc, that applications are not required to support.

But since the express purpose of a profile is to foster interoperability, it
seems reasonable for 3280bis to discourage the use of name constraints for
some name forms including those defined using otherName:

"Conforming CAs MUST mark this extension as critical and SHOULD NOT impose
name constraints on the x400Address, ediPartyName, registeredID, or
otherName name forms."

As an aside, I'm not sure why registeredID made it onto the list of
forbidden name constraint forms; OIDs are purely hierarchical and constraint
processing for this name form would be particularly simple to implement.
But if there is little demand for names of this form there is little harm in
discouraging its use.  There would be harm in continuing to forbid it.

Dave K

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Wednesday, July 05, 2006 12:15 PM
To: Turner, Sean P.
Cc: pkix
Subject: name constraints on x400Address, ediPartyName, and registeredID
name forms

Sean,

If I understand you correctly now, your concern is not that 3280bis seems
contradictory, but that you disagree with 3280bis forbidding conforming CAs
from imposing name constraints on the x400Address, ediPartyName, and
registeredID name forms.  I can't remember why this requirement was included
in the initial draft of 3280bis, but I can see that there is a good argument
for removing it.

While it is a good idea to limit the set of name forms for which name
constraints are imposed in order to maximize interoperability, this does not
do that.  3280bis currently states:

      Applications conforming to this profile MUST be able to process name
      constraints that are imposed on the directoryName name form and
      SHOULD be able to process name constraints that are imposed on the
      rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
      forms.

If the goal was to maximize interoperability, then 3280bis should have
forbidden imposing name constraints on any name forms except those mentioned
above.  However, while 3280bis forbids specifying name constraints for the
x400Address, ediPartyName, and registeredID name forms, it does not forbid
specifying name constraints for names forms that are defined for inclusion
within otherName.  So the effect is that 3280bis permits specifying permits
specifying name constraints for any name form (from an potentially unbounded
set of name forms) except these three name forms.

What do others think?  Is there is any reason to forbid conforming CAs from
specifying name constraints for these three name forms while not forbidding
conforming CAs from specifying name constraints for any name form that might
be defined for inclusion within otherName?

Dave

Turner, Sean P. wrote:

8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
constraints on ediPartyName or registeredID but the 14th para (the one 

before the ASN.1) indicates that ediPartyName and registeredId are not 

defined in this spec but MAY be defined in another spec. Sounds to me 

like it would be hard to convince a customer that you could write a 
name constraints that can ever be 3280bis compliant since whatever you 

wrote MUST NOT be imposed/implemented. It's not clear that the name 
constraints shouldn't be imposed because they're not defined in the 
spec or whether they should never ever be imposed.

3280bis states:
 
      The syntax and semantics for name constraints for otherName,
      ediPartyName, and registeredID are not defined by this specification,
      however syntax and semantics for name constraints for other name
      forms may be specified in other documents.
 
A CA conforming to 3280bis MUST NOT impose name constraints 
on the x400Address, ediPartyName, or registeredID name forms.  Period.  
However, just as [SRVSAN] specifies the syntax and semantics 
for name constraints on the SRVName name form, other 
documents could specify the syntax and semantics for name 
constraints on other name forms.  Given that 3280bis forbids 
conforming CAs from imposing name constraints on the 
x400Address, ediPartyName, or registeredID name forms, it 
would seem to be inappropriate for another PKIX (or even 
IETF) document to specify syntax and semantics for name 
constraints on ediPartyName or registeredID name forms, but 
3280bis is just one profile of X.509.  A different profile of 
X.509 may permit the specification of name constraints on 
these name forms and may specify the syntax and semantics for 
imposing constraints on those name forms.  While 3280bis 
states that conforming CAs MUST NOT impose name constraints 
on these name forms, conforming relying parties are permitted 
to implement the ability to process name constraints on these 
name forms since conforming relying parties are not 
restricted to only accepting certificates that are issued in 
conformance with 3280bis.

I don't understand why these name forms were specifically picked out. For
x400Address I assume it's that nobody cares, but you could easily write a
rule that said the OR Address attributes (just like DNs) must be within the
ones included. I write the rules if we decide we need them. For registeredId
I get that it's an OID so there's structure to it so it's imposible to write
rules but why couldn't somebody decide to carve up an OID tree and say
something like make sure the 1st 6 components of the OID are present in all
names. For the ediPartyName you could say the nameAssigner must be present
in all PKCs.
 
If there is no way I can say with a straight face that a CA that requires a
name constraints for x400Address, ediPartyName, or registeredID is
compliant, I've got a problem with this what it says because being compliant
with RFC3280 is the gold standard; besides I think the rules are easy enough
to write I don't understand why these particular name forms were omitted
(there may be good reasons I'm unaware of).

9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
constraints on x400Address name forms but the last sentence in the 10th 

para last says X400Address MUST be applied to x.400 addresses. See #8.

While a conforming CA MUST not impose name constraints on the 
x400Address name form, a conforming relying party MAY 
implement the ability to process  such constraints.  As with 
any other name form, if a certificate includes name 
constraint on the x400Address name form and a subsequent 
certificate in the certification path includes a 
subjectAltName extension with an x400Address name, the 
relying party MUST either process the constraint or reject 
the certification path.

See above.

------_=_NextPart_001_01C6A10D.666F861A
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2900.2912" name=GENERATOR><!--[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: Tahoma;
}
@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; COLOR: black; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: black; 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
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; COLOR: black; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US vLink=purple link=blue bgColor=white>
<DIV><SPAN class=036550315-06072006><FONT face=Arial color=#0000ff size=2>I 
agree with softening the statement to should not because of the argument David 
makes. If we allow name constraints for "otherName" name forms it seems 
excessive to forbid these completely. That can lead to confusion for systems 
that actually need to support such name constraints in a particular environment 
(I've seen name constraints on X.400 addresses for example, although they could 
be deemed outside the scope of "the Internet PKI"). </FONT></SPAN></DIV>
<DIV><SPAN class=036550315-06072006><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=036550315-06072006><FONT face=Arial color=#0000ff 
size=2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=036550315-06072006><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  [email-masked] [mailto:[email-masked]] <B>On 
  Behalf Of </B>Kemp David P.<BR><B>Sent:</B> Wednesday, July 05, 2006 2:09 
  PM<BR><B>To:</B> David A. Cooper; Turner, Sean P.<BR><B>Cc:</B> 
  pkix<BR><B>Subject:</B> RE: name constraints on x400Address, ediPartyName, and 
  registeredID name forms<BR><BR></FONT></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">MUST NOT seems 
  excessive, given that interoperability is not guaranteed for rfc822Name, etc, 
  that applications are not required to support.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">But since the express 
  purpose of a profile is to foster interoperability, it seems reasonable for 
  3280bis to discourage the use of name constraints for some name forms 
  including those defined using otherName:<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">"Conforming CAs MUST 
  mark this extension as critical and SHOULD NOT impose name constraints on the 
  x400Address, ediPartyName, registeredID, or otherName name 
  forms."<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As an aside, I'm not 
  sure why registeredID made it onto the list of forbidden name constraint 
  forms; OIDs are purely hierarchical and constraint processing for this name 
  form would be particularly simple to implement. &nbsp;But if there is little 
  demand for names of this form there is little harm in discouraging its use. 
  &nbsp;There would be harm in continuing to forbid 
  it.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Dave 
  K<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
  face="Times New Roman" color=black size=3><SPAN 
  style="FONT-SIZE: 12pt; COLOR: windowtext">
  <HR tabIndex=-1 align=center width="100%" SIZE=2>
  </SPAN></FONT></DIV>
  <P class=MsoNormal><B><FONT face=Tahoma color=black size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
  face=Tahoma color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Tahoma"> 
  [email-masked] [mailto:[email-masked]] <B><SPAN 
  style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>David A. Cooper<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, July 05, 2006 12:15 
  PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Turner, Sean 
  P.<BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B> pkix<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Subject:</SPAN></B> name constraints on x400Address, 
  ediPartyName, and registeredID name forms</SPAN></FONT><FONT color=black><SPAN 
  style="COLOR: windowtext"><o:p></o:p></SPAN></FONT></P></DIV>
  <P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN 
  style="FONT-SIZE: 12pt">Sean,<BR><BR>If I understand you correctly now, your 
  concern is not that 3280bis seems contradictory, but that you disagree with 
  3280bis forbidding conforming CAs from imposing name constraints on the 
  x400Address, ediPartyName, and registeredID name forms.&nbsp; I can't remember 
  why this requirement was included in the initial draft of 3280bis, but I can 
  see that there is a good argument for removing it.<BR><BR>While it is a good 
  idea to limit the set of name forms for which name constraints are imposed in 
  order to maximize interoperability, this does not do that.&nbsp; 3280bis 
  currently states:<BR><BR>&nbsp; &nbsp; &nbsp; Applications conforming to this 
  profile MUST be able to process name<BR>&nbsp; &nbsp; &nbsp; constraints that 
  are imposed on the directoryName name form and<BR>&nbsp; &nbsp; &nbsp; SHOULD 
  be able to process name constraints that are imposed on the<BR>&nbsp; &nbsp; 
  &nbsp; rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress 
  name<BR>&nbsp; &nbsp; &nbsp; forms.<BR><BR>If the goal was to maximize 
  interoperability, then 3280bis should have forbidden imposing name constraints 
  on any name forms except those mentioned above.&nbsp; However, while 3280bis 
  forbids specifying name constraints for the x400Address, ediPartyName, and 
  registeredID name forms, it does not forbid specifying name constraints for 
  names forms that are defined for inclusion within otherName.&nbsp; So the 
  effect is that 3280bis permits specifying permits specifying name constraints 
  for any name form (from an potentially unbounded set of name forms) except 
  these three name forms.<BR><BR>What do others think?&nbsp; Is there is any 
  reason to forbid conforming CAs from specifying name constraints for these 
  three name forms while not forbidding conforming CAs from specifying name 
  constraints for any name form that might be defined for inclusion within 
  otherName?<BR><BR>Dave<BR><BR>Turner, Sean P. 
  wrote:<BR><BR><o:p></o:p></SPAN></FONT></P>
  <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" type="cite">
    <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" type="cite"><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">constraints on ediPartyName or registeredID but the 14th para (the one <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE>
    <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" type="cite"><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">before the ASN.1) indicates that ediPartyName and registeredId are not <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE>
    <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" type="cite"><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">defined in this spec but MAY be defined in another spec. Sounds to me <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE>
    <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" type="cite"><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">like it would be hard to convince a customer that you could write a <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">name constraints that can ever be 3280bis compliant since whatever you <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE>
    <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" type="cite"><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">wrote MUST NOT be imposed/implemented. It's not clear that the name <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">constraints shouldn't be imposed because they're not defined in the <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">spec or whether they should never ever be imposed.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">3280bis states:<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FO
 NT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The syntax and semantics for name constraints for otherName,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ediPartyName, and registeredID are not defined by this specification,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; however syntax and semantics for name constraints for other name<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; forms may be specified in other documents.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FON
 T-SIZE: 10pt">A CA conforming to 3280bis MUST NOT impose name constraints <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">on the x400Address, ediPartyName, or registeredID name forms.&nbsp; Period.&nbsp; <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">However, just as [SRVSAN] specifies the syntax and semantics <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">for name constraints on the SRVName name form, other <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">documents could specify the syntax and semantics for name <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">constraints on other name forms.&nbsp; Given that 3280bis forbids <o:p></o:p></SPAN></FONT></PRE><PRE><FONT fac
 e="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">conforming CAs from imposing name constraints on the <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">x400Address, ediPartyName, or registeredID name forms, it <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">would seem to be inappropriate for another PKIX (or even <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">IETF) document to specify syntax and semantics for name <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">constraints on ediPartyName or registeredID name forms, but <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">3280bis is just one profile of X.509.&nbsp; A different profile of <o:p></o:p></SPAN></FON
 T></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">X.509 may permit the specification of name constraints on <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">these name forms and may specify the syntax and semantics for <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">imposing constraints on those name forms.&nbsp; While 3280bis <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">states that conforming CAs MUST NOT impose name constraints <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">on these name forms, conforming relying parties are permitted <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">to implement the ability to process name constra
 ints on these <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">name forms since conforming relying parties are not <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">restricted to only accepting certificates that are issued in <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">conformance with 3280bis.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">I don't understand why these name forms were specifically picked out. For<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier Ne
 w" color=black size=2><SPAN style="FONT-SIZE: 10pt">x400Address I assume it's that nobody cares, but you could easily write a<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">rule that said the OR Address attributes (just like DNs) must be within the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">ones included. I write the rules if we decide we need them. For registeredId<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">I get that it's an OID so there's structure to it so it's imposible to write<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">rules but why couldn't somebody decide to carve up an OID tree and say<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">something like ma
 ke sure the 1st 6 components of the OID are present in all<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">names. For the ediPartyName you could say the nameAssigner must be present<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">in all PKCs.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">If there is no way I can say with a straight face that a CA that requires a<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">name constraints for x400Address, ediPartyName, or registeredID is<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">compliant, I've got a problem with thi
 s what it says because being compliant<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">with RFC3280 is the gold standard; besides I think the rules are easy enough<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">to write I don't understand why these particular name forms were omitted<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">(there may be good reasons I'm unaware of).<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt"> <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE>
  <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" type="cite">
    <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" type="cite"><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">constraints on x400Address name forms but the last sentence in the 10th <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE>
    <BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" type="cite"><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">para last says X400Address MUST be applied to x.400 addresses. See #8.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">While a conforming CA MUST not impose name constraints on the <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">x400Address name form, a conforming relying party MAY <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">implement the ability to process&nbsp; such constraints.&nbsp; As with <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><S
 PAN style="FONT-SIZE: 10pt">any other name form, if a certificate includes name <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">constraint on the x400Address name form and a subsequent <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">certificate in the certification path includes a <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">subjectAltName extension with an x400Address name, the <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">relying party MUST either process the constraint or reject <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">the certification path.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;
 &nbsp;&nbsp; <o:p></o:p></SPAN></FONT></PRE></BLOCKQUOTE><PRE wrap=""><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">See above.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt"> <o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></PRE>
  <P class=MsoNormal><FONT face="Times New Roman" color=black size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6A10D.666F861A--

Content-class: urn:content-classes:message
Subject: RE: name constraints on x400Address, ediPartyName, and registeredID name forms
Date: Wed, 5 Jul 2006 14:08:52 -0400
From: "Kemp David P." <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "Turner, Sean P." <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A05E.1310904A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

MUST NOT seems excessive, given that interoperability is not guaranteed
for rfc822Name, etc, that applications are not required to support.

=20

But since the express purpose of a profile is to foster
interoperability, it seems reasonable for 3280bis to discourage the use
of name constraints for some name forms including those defined using
otherName:

"Conforming CAs MUST mark this extension as critical and SHOULD NOT
impose name constraints on the x400Address, ediPartyName, registeredID,
or otherName name forms."

=20

As an aside, I'm not sure why registeredID made it onto the list of
forbidden name constraint forms; OIDs are purely hierarchical and
constraint processing for this name form would be particularly simple to
implement.  But if there is little demand for names of this form there
is little harm in discouraging its use.  There would be harm in
continuing to forbid it.

=20

Dave K

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Wednesday, July 05, 2006 12:15 PM
To: Turner, Sean P.
Cc: pkix
Subject: name constraints on x400Address, ediPartyName, and registeredID
name forms

=20

Sean,

If I understand you correctly now, your concern is not that 3280bis
seems contradictory, but that you disagree with 3280bis forbidding
conforming CAs from imposing name constraints on the x400Address,
ediPartyName, and registeredID name forms.  I can't remember why this
requirement was included in the initial draft of 3280bis, but I can see
that there is a good argument for removing it.

While it is a good idea to limit the set of name forms for which name
constraints are imposed in order to maximize interoperability, this does
not do that.  3280bis currently states:

      Applications conforming to this profile MUST be able to process
name
      constraints that are imposed on the directoryName name form and
      SHOULD be able to process name constraints that are imposed on the
      rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
      forms.

If the goal was to maximize interoperability, then 3280bis should have
forbidden imposing name constraints on any name forms except those
mentioned above.  However, while 3280bis forbids specifying name
constraints for the x400Address, ediPartyName, and registeredID name
forms, it does not forbid specifying name constraints for names forms
that are defined for inclusion within otherName.  So the effect is that
3280bis permits specifying permits specifying name constraints for any
name form (from an potentially unbounded set of name forms) except these
three name forms.

What do others think?  Is there is any reason to forbid conforming CAs
from specifying name constraints for these three name forms while not
forbidding conforming CAs from specifying name constraints for any name
form that might be defined for inclusion within otherName?

Dave

Turner, Sean P. wrote:

		8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT
impose name=20
		constraints on ediPartyName or registeredID but the 14th
para (the one=20
		     =20

		before the ASN.1) indicates that ediPartyName and
registeredId are not=20
		     =20

		defined in this spec but MAY be defined in another spec.
Sounds to me=20
		     =20

		like it would be hard to convince a customer that you
could write a=20
		name constraints that can ever be 3280bis compliant
since whatever you=20
		     =20

		wrote MUST NOT be imposed/implemented. It's not clear
that the name=20
		constraints shouldn't be imposed because they're not
defined in the=20
		spec or whether they should never ever be imposed.
		     =20

	3280bis states:
	=20
	      The syntax and semantics for name constraints for
otherName,
	      ediPartyName, and registeredID are not defined by this
specification,
	      however syntax and semantics for name constraints for
other name
	      forms may be specified in other documents.
	=20
	A CA conforming to 3280bis MUST NOT impose name constraints=20
	on the x400Address, ediPartyName, or registeredID name forms.
Period. =20
	However, just as [SRVSAN] specifies the syntax and semantics=20
	for name constraints on the SRVName name form, other=20
	documents could specify the syntax and semantics for name=20
	constraints on other name forms.  Given that 3280bis forbids=20
	conforming CAs from imposing name constraints on the=20
	x400Address, ediPartyName, or registeredID name forms, it=20
	would seem to be inappropriate for another PKIX (or even=20
	IETF) document to specify syntax and semantics for name=20
	constraints on ediPartyName or registeredID name forms, but=20
	3280bis is just one profile of X.509.  A different profile of=20
	X.509 may permit the specification of name constraints on=20
	these name forms and may specify the syntax and semantics for=20
	imposing constraints on those name forms.  While 3280bis=20
	states that conforming CAs MUST NOT impose name constraints=20
	on these name forms, conforming relying parties are permitted=20
	to implement the ability to process name constraints on these=20
	name forms since conforming relying parties are not=20
	restricted to only accepting certificates that are issued in=20
	conformance with 3280bis.
	   =20

=20
I don't understand why these name forms were specifically picked out.
For
x400Address I assume it's that nobody cares, but you could easily write
a
rule that said the OR Address attributes (just like DNs) must be within
the
ones included. I write the rules if we decide we need them. For
registeredId
I get that it's an OID so there's structure to it so it's imposible to
write
rules but why couldn't somebody decide to carve up an OID tree and say
something like make sure the 1st 6 components of the OID are present in
all
names. For the ediPartyName you could say the nameAssigner must be
present
in all PKCs.
=20
If there is no way I can say with a straight face that a CA that
requires a
name constraints for x400Address, ediPartyName, or registeredID is
compliant, I've got a problem with this what it says because being
compliant
with RFC3280 is the gold standard; besides I think the rules are easy
enough
to write I don't understand why these particular name forms were omitted
(there may be good reasons I'm unaware of).
=20
 =20

		9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT
impose name=20
		constraints on x400Address name forms but the last
sentence in the 10th=20
		     =20

		para last says X400Address MUST be applied to x.400
addresses. See #8.
		     =20

	While a conforming CA MUST not impose name constraints on the=20
	x400Address name form, a conforming relying party MAY=20
	implement the ability to process  such constraints.  As with=20
	any other name form, if a certificate includes name=20
	constraint on the x400Address name form and a subsequent=20
	certificate in the certification path includes a=20
	subjectAltName extension with an x400Address name, the=20
	relying party MUST either process the constraint or reject=20
	the certification path.
	   =20

=20
See above.
=20
 =20

=20

------_=_NextPart_001_01C6A05E.1310904A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>MUST NOT seems excessive, given =
that interoperability
is not guaranteed for rfc822Name, etc, that applications are not =
required to
support.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>But since the express purpose of a =
profile
is to foster interoperability, it seems reasonable for 3280bis to =
discourage
the use of name constraints for some name forms including those defined =
using
otherName:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;Conforming CAs MUST mark =
this
extension as critical and SHOULD NOT impose name constraints on the =
x400Address,
ediPartyName, registeredID, or otherName name =
forms.&#8221;<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As an aside, I&#8217;m not sure why
registeredID made it onto the list of forbidden name constraint forms; =
OIDs are
purely hierarchical and constraint processing for this name form would =
be
particularly simple to implement. &nbsp;But if there is little demand =
for names
of this form there is little harm in discouraging its use. &nbsp;There =
would be
harm in continuing to forbid it.<o:p></o:p></span></font></p>

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

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>David A. Cooper<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July 05, =
2006
12:15 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Turner, Sean P.<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> pkix<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> name constraints =
on
x400Address, ediPartyName, and registeredID name =
forms</span></font><font
color=3Dblack><span =
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

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

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Sean,<br>
<br>
If I understand you correctly now, your concern is not that 3280bis =
seems
contradictory, but that you disagree with 3280bis forbidding conforming =
CAs
from imposing name constraints on the x400Address, ediPartyName, and
registeredID name forms.&nbsp; I can't remember why this requirement was
included in the initial draft of 3280bis, but I can see that there is a =
good
argument for removing it.<br>
<br>
While it is a good idea to limit the set of name forms for which name
constraints are imposed in order to maximize interoperability, this does =
not do
that.&nbsp; 3280bis currently states:<br>
<br>
&nbsp; &nbsp; &nbsp; Applications conforming to this profile MUST be =
able to
process name<br>
&nbsp; &nbsp; &nbsp; constraints that are imposed on the directoryName =
name
form and<br>
&nbsp; &nbsp; &nbsp; SHOULD be able to process name constraints that are
imposed on the<br>
&nbsp; &nbsp; &nbsp; rfc822Name, uniformResourceIdentifier, dNSName, and
iPAddress name<br>
&nbsp; &nbsp; &nbsp; forms.<br>
<br>
If the goal was to maximize interoperability, then 3280bis should have
forbidden imposing name constraints on any name forms except those =
mentioned
above.&nbsp; However, while 3280bis forbids specifying name constraints =
for the
x400Address, ediPartyName, and registeredID name forms, it does not =
forbid
specifying name constraints for names forms that are defined for =
inclusion
within otherName.&nbsp; So the effect is that 3280bis permits specifying
permits specifying name constraints for any name form (from an =
potentially
unbounded set of name forms) except these three name forms.<br>
<br>
What do others think?&nbsp; Is there is any reason to forbid conforming =
CAs from
specifying name constraints for these three name forms while not =
forbidding
conforming CAs from specifying name constraints for any name form that =
might be
defined for inclusion within otherName?<br>
<br>
Dave<br>
<br>
Turner, Sean P. wrote:<br>
<br>
<o:p></o:p></span></font></p>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>8. Sec 4.2.1.10: 3rd para indicates that CAs =
MUST NOT impose name <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>constraints on ediPartyName or registeredID =
but the 14th para (the one <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p=
></span></font></pre></blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>before the ASN.1) indicates that ediPartyName =
and registeredId are not <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p=
></span></font></pre></blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>defined in this spec but MAY be defined in =
another spec. Sounds to me <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p=
></span></font></pre></blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>like it would be hard to convince a customer =
that you could write a <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>name constraints that can ever be 3280bis =
compliant since whatever you <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p=
></span></font></pre></blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>wrote MUST NOT be imposed/implemented. It's =
not clear that the name <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>constraints shouldn't be imposed because =
they're not defined in the <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>spec or whether they should never ever be =
imposed.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<o:p></o:p></span></font></pre></blockquote>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>3280bis =
states:<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The syntax and =
semantics for name constraints for =
otherName,<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ediPartyName, =
and registeredID are not defined by this =
specification,<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; however syntax =
and semantics for name constraints for other =
name<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; forms may be =
specified in other documents.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>A CA conforming to 3280bis MUST NOT impose =
name constraints <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>on the x400Address, ediPartyName, or =
registeredID name forms.&nbsp; Period.&nbsp; =
<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>However, just as [SRVSAN] specifies the =
syntax and semantics <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>for name constraints on the SRVName name =
form, other <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>documents could specify the syntax and =
semantics for name <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>constraints on other name forms.&nbsp; Given =
that 3280bis forbids <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>conforming CAs from imposing name constraints =
on the <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>x400Address, ediPartyName, or registeredID =
name forms, it <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>would seem to be inappropriate for another =
PKIX (or even <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>IETF) document to specify syntax and =
semantics for name <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>constraints on ediPartyName or registeredID =
name forms, but <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>3280bis is just one profile of X.509.&nbsp; A =
different profile of <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>X.509 may permit the specification of name =
constraints on <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>these name forms and may specify the syntax =
and semantics for <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>imposing constraints on those name =
forms.&nbsp; While 3280bis <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>states that conforming CAs MUST NOT impose =
name constraints <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>on these name forms, conforming relying =
parties are permitted <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>to implement the ability to process name =
constraints on these <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>name forms since conforming relying parties =
are not <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>restricted to only accepting certificates =
that are issued in <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>conformance with =
3280bis.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; =
<o:p></o:p></span></font></pre></blockquote>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>I don't understand why these name forms were =
specifically picked out. For<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>x400Address I assume it's that nobody cares, =
but you could easily write a<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>rule that said the OR Address attributes =
(just like DNs) must be within =
the<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>ones included. I write the rules if we decide =
we need them. For registeredId<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>I get that it's an OID so there's structure =
to it so it's imposible to =
write<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>rules but why couldn't somebody decide to =
carve up an OID tree and say<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>something like make sure the 1st 6 components =
of the OID are present in all<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>names. For the ediPartyName you could say the =
nameAssigner must be present<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>in all =
PKCs.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>If there is no way I can say with a straight =
face that a CA that requires a<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>name constraints for x400Address, =
ediPartyName, or registeredID =
is<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>compliant, I've got a problem with this what =
it says because being compliant<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>with RFC3280 is the gold standard; besides I =
think the rules are easy enough<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>to write I don't understand why these =
particular name forms were =
omitted<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>(there may be good reasons I'm unaware =
of).<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'> <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;<o:p></o:p></span></font></pre>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>9. Sec 4.2.1.10: 3rd para indicates that CAs =
MUST NOT impose name <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>constraints on x400Address name forms but the =
last sentence in the 10th <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p=
></span></font></pre></blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>para last says X400Address MUST be applied to =
x.400 addresses. See #8.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<o:p></o:p></span></font></pre></blockquote>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>While a conforming CA MUST not impose name =
constraints on the <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>x400Address name form, a conforming relying =
party MAY <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>implement the ability to process&nbsp; such =
constraints.&nbsp; As with <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>any other name form, if a certificate =
includes name <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>constraint on the x400Address name form and a =
subsequent <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>certificate in the certification path =
includes a <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>subjectAltName extension with an x400Address =
name, the <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>relying party MUST either process the =
constraint or reject <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>the certification =
path.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; =
<o:p></o:p></span></font></pre></blockquote>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>See =
above.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'> <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;<o:p></o:p></span></font></pre>

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

</div>

</body>

</html>

------_=_NextPart_001_01C6A05E.1310904A--

Date: Wed, 5 Jul 2006 18:48:19 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Sender: [email-masked]

>Denis,
>
>How could a relying party know that no CRL is available for
>short-lived certificates?
>
>Yes, this is an interesting question.
>
>Two options come across my mind.
>
>Option 1 is to introduce a certificate extension similar to the
>id-pkix-ocsp-nocheck extension defined in RFC 2560.

>Option 2 is letting the validity period of the short-lived
>certificates equal to the update period of the CRL. That is
>letting the notBefore of the certificate equal thisUpdate of the
>CRL and  letting the notAfter of the certificate equal
>nextUpdate of the CRL. The relying party has to be smart
>enough to know that since the validity period of the
>short-lived certificates is equivalent to the period of
>the updated revocation info is given by the CA to
>the delegated CRL issuer, it is reasonable that there is no
>need to check the revocation status of the short-lived
>certificates.

The main disadvantage is that there would the need to fetch a CRL 
to know this, while option 1 avoids to fetch it.

Option 1 is simple and only mandates the definition of an OID for that extension.

What is more difficult, is the writing of a full story when the CA delegates the 
issuance of CRLs. Using this would allow to increase the protection of root keys.
This would be a major benefit.

Denis

>Obviously, adopting option 2 might cause ambiguity, but
>it has the advantage that there is no need to introduce
>a new extension.
>
>Regards,
>Wen-Cheng Wang
>
>From: "Denis Pinkas" <[email-masked]>
>To: <[email-masked]>
>Sent: Tuesday, July 04, 2006 6:10 PM
>Subject: Re:Question about indirect CRLs (and designated OCSP responders)
>
>
>> 
>> 
>> I jump into this interresting discussion.
>> 
>>>Julien,
>>>
>>>Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
>>>issuer, and the other is the CA itself.
>> 
>> In case, the CA handles the revocation of the CRL issuer(s).
>> Otherwise, it can issue short-lived certificates.
>> 
>>>The CA itself is responsible for revoking the certificate for the delegated
>>>CRL issuer. Therefore, the CA still need to issue a special CRL that
>>>at least cover the certificate for the delegated CRL issuer. In that case,
>>>the certificate should contain a CRLDP and the special CRL should
>>>contain an matched IDP, since the special CRL is a partitioned CRL
>>>(or offically called a CRL distribution point in the ITU-T X.509 standards).
>>>
>>>The delegated CRL issuer is responsible for revoking all certificates
>>>issued by the CA other than the certificate of itself.
>>>
>>>BTW, in the case where a CA delegate its revocation responsibility to
>>>an OCSP responder instead of a delegated CRL issued, the same
>>>approach can also be used to revoke the certificate for the OCSP
>>>responder if it is not a short-lived certificate.
>>>
>>>What I want to emphasize is that it is inevitable that a CA still need
>>>to issue CRLs even it has delegated its revocation responsibility to
>>>a delegated CRL issuer or an OCSP responder, unless the certificate
>>>for the delegated CRL issuer or the OCSP responder is a short-lived
>>>certificate.
>> 
>> Yes, these are the two options.
>> 
>> - If CRLs are used, then a probably empty CRL would need to be issued each day.
>> 
>> - If short-lived certificates are used, then a new CRL Issuer certificate would need 
>>   to be issued each day. However in that case how could a relying party know 
>>   that no CRL is available ? 
>> 
>> For attribute certificates (AC) we have a way to indicate that no CRL is available, 
>> we would need a similar indication for public key certificates (PKC).
>> 
>> Note : such CRLs and short-lived certificates could be issued in advance and 
>> but only released every day in order to reduce the root key exposure.  
>> 
>> Denis

Date: Wed, 05 Jul 2006 17:34:01 +0100
From: Stephen Farrell <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: "Turner, Sean P." <[email-masked]>, pkix <[email-masked]>
Subject: Re: name constraints on x400Address, ediPartyName, and registeredID name forms
Sender: [email-masked]

David A. Cooper wrote:

> What do others think?  

Its fine as-is IMO.

Stephen.

Date: Wed, 05 Jul 2006 12:14:31 -0400
From: "David A. Cooper" <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
CC: pkix <[email-masked]>
Subject: name constraints on x400Address, ediPartyName, and registeredID name forms
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sean,<br>
<br>
If I understand you correctly now, your concern is not that 3280bis
seems contradictory, but that you disagree with 3280bis forbidding
conforming CAs from imposing name constraints on the x400Address,
ediPartyName, and registeredID name forms.&nbsp; I can't remember why this
requirement was included in the initial draft of 3280bis, but I can see
that there is a good argument for removing it.<br>
<br>
While it is a good idea to limit the set of name forms for which name
constraints are imposed in order to maximize interoperability, this
does not do that.&nbsp; 3280bis currently states:<br>
<br>
&nbsp; &nbsp; &nbsp; Applications conforming to this profile MUST be able to process
name<br>
&nbsp; &nbsp; &nbsp; constraints that are imposed on the directoryName name form and<br>
&nbsp; &nbsp; &nbsp; SHOULD be able to process name constraints that are imposed on the<br>
&nbsp; &nbsp; &nbsp; rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name<br>
&nbsp; &nbsp; &nbsp; forms.<br>
<br>
If the goal was to maximize interoperability, then 3280bis should have
forbidden imposing name constraints on any name forms except those
mentioned above.&nbsp; However, while 3280bis forbids specifying name
constraints for the x400Address, ediPartyName, and registeredID name
forms, it does not forbid specifying name constraints for names forms
that are defined for inclusion within otherName.&nbsp; So the effect is that
3280bis permits specifying permits specifying name constraints for any
name form (from an potentially unbounded set of name forms) except
these three name forms.<br>
<br>
What do others think?&nbsp; Is there is any reason to forbid conforming CAs
from specifying name constraints for these three name forms while not
forbidding conforming CAs from specifying name constraints for any name
form that might be defined for inclusion within otherName?<br>
<br>
Dave<br>
<br>
Turner, Sean P. wrote:<br>
<blockquote cite="mid009001c69c4e$0395d110$0201a8c0@Wylie" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
constraints on ediPartyName or registeredID but the 14th para (the one 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">before the ASN.1) indicates that ediPartyName and registeredId are not 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">defined in this spec but MAY be defined in another spec. Sounds to me 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">like it would be hard to convince a customer that you could write a 
name constraints that can ever be 3280bis compliant since whatever you 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">wrote MUST NOT be imposed/implemented. It's not clear that the name 
constraints shouldn't be imposed because they're not defined in the 
spec or whether they should never ever be imposed.
      </pre>
    </blockquote>
    <pre wrap="">3280bis states:

      The syntax and semantics for name constraints for otherName,
      ediPartyName, and registeredID are not defined by this specification,
      however syntax and semantics for name constraints for other name
      forms may be specified in other documents.

A CA conforming to 3280bis MUST NOT impose name constraints 
on the x400Address, ediPartyName, or registeredID name forms.  Period.  
However, just as [SRVSAN] specifies the syntax and semantics 
for name constraints on the SRVName name form, other 
documents could specify the syntax and semantics for name 
constraints on other name forms.  Given that 3280bis forbids 
conforming CAs from imposing name constraints on the 
x400Address, ediPartyName, or registeredID name forms, it 
would seem to be inappropriate for another PKIX (or even 
IETF) document to specify syntax and semantics for name 
constraints on ediPartyName or registeredID name forms, but 
3280bis is just one profile of X.509.  A different profile of 
X.509 may permit the specification of name constraints on 
these name forms and may specify the syntax and semantics for 
imposing constraints on those name forms.  While 3280bis 
states that conforming CAs MUST NOT impose name constraints 
on these name forms, conforming relying parties are permitted 
to implement the ability to process name constraints on these 
name forms since conforming relying parties are not 
restricted to only accepting certificates that are issued in 
conformance with 3280bis.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I don't understand why these name forms were specifically picked out. For
x400Address I assume it's that nobody cares, but you could easily write a
rule that said the OR Address attributes (just like DNs) must be within the
ones included. I write the rules if we decide we need them. For registeredId
I get that it's an OID so there's structure to it so it's imposible to write
rules but why couldn't somebody decide to carve up an OID tree and say
something like make sure the 1st 6 components of the OID are present in all
names. For the ediPartyName you could say the nameAssigner must be present
in all PKCs.

If there is no way I can say with a straight face that a CA that requires a
name constraints for x400Address, ediPartyName, or registeredID is
compliant, I've got a problem with this what it says because being compliant
with RFC3280 is the gold standard; besides I think the rules are easy enough
to write I don't understand why these particular name forms were omitted
(there may be good reasons I'm unaware of).
 
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
constraints on x400Address name forms but the last sentence in the 10th 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">para last says X400Address MUST be applied to x.400 addresses. See #8.
      </pre>
    </blockquote>
    <pre wrap="">While a conforming CA MUST not impose name constraints on the 
x400Address name form, a conforming relying party MAY 
implement the ability to process  such constraints.  As with 
any other name form, if a certificate includes name 
constraint on the x400Address name form and a subsequent 
certificate in the certification path includes a 
subjectAltName extension with an x400Address name, the 
relying party MUST either process the constraint or reject 
the certification path.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
See above.
 
  </pre>
</blockquote>
<br>
</body>
</html>

Date: Wed, 05 Jul 2006 11:50:09 -0400
From: "David A. Cooper" <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sean,<br>
<br>
common in-line<br>
<br>
Turner, Sean P. wrote:
<blockquote cite="mid009001c69c4e$0395d110$0201a8c0@Wylie" type="cite">
  <pre wrap="">David comments in-line.  I snipped out the ones that you accepted or you
resolved. 
------------------

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">4. Sec 4 1st para last sentence: remove required to support a PKI.  All 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">of the internet defined extensions are optional so they can't be 
required to support a PKI for the internet community.

      </pre>
    </blockquote>
    <pre wrap="">The full sentence is "This section also defines private 
extensions required to support a PKI for the Internet 
community."  These extensions (authorityInfoAccess an 
subjectInfoAccess) are needed even though it is not necessary 
to include them in all certificates. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Exactly - they are needed but not required. I still think the sentence ought
to read: This section also defines extension to support the PKI for the
internet community.  There's no need to say required.
  </pre>
</blockquote>
I looked at the earlier RFCs and discovered that this sentence has
appeared in the PKIX certificate and CRL profile, unchanged, since RFC
2459.&nbsp; Barring evidence to the contrary, I think that indicates rough
consensus in favor of the current text.<br>
<br>
<blockquote cite="mid009001c69c4e$0395d110$0201a8c0@Wylie" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">id generation? How about striking SHA-1 from the methods and adding the 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">new sentence to both: The hash algorithm employed can be the same 
algorithm paired with the signature algorithm (e.g., SHA-1, SHA-256, SHA-384).
      </pre>
    </blockquote>
    <pre wrap="">Section 4.2.1.2 simply states that the two methods described 
are two common methods for generating key identifiers.  The 
text explicitly does not restrict CAs to using these methods.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This one didn't come across very well. I know there's no security issue and
there are just examples but sometimes people just implement the examples and
we end up getting stuck with those. Further I'm trying to avoid silly things
like somebody saying I won't use a spec that has SHA1 and they don't
understand that they're only examples.
  </pre>
  <blockquote type="cite">
    <pre wrap="">It is also not clear why one would want to use SHA-256, SHA-384, etc. 
instead of SHA-1.  There are no security issues associated 
with key identifiers, so it would seem that using a hash 
algorithm with a longer output would just make the 
certificates larger.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I wasn't clear with the use any hash algorithm part. I think the example
should still indicate that a 160bit output is used with whatever hash
algorithm is used. So for logner hash outputs they only use 160bits of it.
It doesn't matter which bits as long as the CA is consistent.
  </pre>
</blockquote>
These examples for methods of generating key identifiers also date back
to RFC 2459 and I still don't see the motivation for changing.<br>
<br>
You say that even though they are just examples, "sometimes people just
implement the examples and we end up getting stuck with those."&nbsp; Why is
that a problems is there is nothing wrong with the examples.<br>
<br>
While it is hypothetically possible that someone may claim that they
refuse to use 3280bis since it mentions the use of SHA-1 somewhere, I
don't think we should change the document just to prevent the that
possibility.<br>
<blockquote cite="mid009001c69c4e$0395d110$0201a8c0@Wylie" type="cite">
  <pre wrap="">  
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that 
since the SAN is bound to the public key that the CA MUST verify the 
each part of the SAN. I think a similar statement ought to be added to 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">the subject section (4.1.2.6) to indicate that "All parts of the 
subject name MUST be verified by the CA as it is bound to the public key". 
      </pre>
    </blockquote>
    <pre wrap="">It is my understanding the the statement in 4.2.1.6 was added 
because there were cases in which CAs were verifying the name 
they included in the subject field but not names included in 
the subjectAltName extension.  Are you aware of a similar 
problem with the subject field?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No.  It was a motherhood and apple pie statement.
  </pre>
</blockquote>
So, why does the statement need to be added?<br>
<blockquote cite="mid009001c69c4e$0395d110$0201a8c0@Wylie" type="cite"><br>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">onlyContainsAttributeCerts seems to hang. Recommend adding "In either case"
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">to the beginning of the sentence to address the case when either 
onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. 
Additionally, recommend adding the following for completeness as a new 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">last paragraph: "If the scope of the CRL only includes attribute 
certificates then the onlyContainsAttributeCerts MUST be set to TRUE 
and both onlyContainsUserCerts and onlyContainsCACerts MUST be set to FALSE."
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap=""> 

      </pre>
    </blockquote>
    <pre wrap="">This sentence was really meant to say that 
onlyContainsAttributeCerts MUST be set to FALSE in all cases, 
not just when either onlyContainsUserCerts or 
onlyContainsCACerts is set to TRUE.  In order to make this 
more clear, the sentence about onlyContainsAttributeCerts has 
been moved to the end of the paragraph and now reads:

      Conforming CRLs issuers MUST set the 
onlyContainsAttributeCerts boolean
      to FALSE.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Are we not addressing the case when the CRL is only for attribute
certificates?</pre>
</blockquote>
Correct.&nbsp; This profile only address public key certificates.<br>
<br>
In addition, the original definition of the issuingDistributionPoint
extension in X.509 did not include the onlyContainsAttributeCerts field
and the resolution to DR 305 resulted in X.509 reverting to the
original definition of the extension.&nbsp; So, the X.509 definition of the
issuingDistributionPoint extension does not include the
onlyContainsAttributeCerts field.&nbsp; Always setting this value to FALSE
ensures consistency with X.509.&nbsp; (Note that the resolution to DR 305
defined a new CRL extension for defining the scope of a CRL with
respect to attribute certificates, but that extension does not belong
in 3280bis since 3280bis only deals with public key certificates.)<br>
<br>
<blockquote cite="mid009001c69c4e$0395d110$0201a8c0@Wylie" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">6. Sec 4.2.1.6 1st para: r These identities may be included in 
addition to or in the place of the identity/These identities may be 
included in addition to or in the place of, in the case of non-CAs, the 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">identity.  The paragraph mixes SAN and IAN, but assumed the 2nd sentence addressed SAN.
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap=""> 

      </pre>
    </blockquote>
    <pre wrap="">Section 4.1.2.6 already very clearly states under what 
circumstances a non-empty DN is required.  I don't think that 
information needs to be repeated here.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I'm only hoping to clarify the 1st paragraph. It's unclear whether the
"these" refers to SAN or IAN after a couple of reads of the 1st para since
IAN is thrown in later in the paragraph.  If you add the ", in the case of
non-CAs," it's clear that the 2nd sentence refers to the SAN. 
  </pre>
</blockquote>
I don't see how "these" could be read as referring to the issuerAltName
extension.<br>
<br>
Also, note that saying "in the case of non-CAs" would be misleading
since section 4.1.2.6 states that certificates issued to CRL issuers
must also include a non-empty subject DN.<br>
<blockquote cite="mid009001c69c4e$0395d110$0201a8c0@Wylie" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">17. Sec 4.2.1.6: Add the following to clarify that there is no 
dependency in this spec between SAN and IAN: This specification places 
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">no requirement on CAs, whose certificate includes Issuer Alterative 
name, to include Subject Alternative names in certificates issued by the CA. 

      </pre>
    </blockquote>
    <pre wrap="">While this statement is certainly true, I don't understand 
the need to include it in section 4.2.1.6.  Is there any 
reason that readers of 3280bis would believe that any 
certificate that includes an issuerAltName extension would 
also need to include a subjectAltName extension?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I'm only trying to protect against something silly like somebody who assumes
that the issuer/subject fields are in all PKCs then IAN/SAN ought to be in
all certificate too. An explicit indication that there is no requirement to
include one if the other is present removes any doubt.
  </pre>
</blockquote>
<br>
As long as 3280bis is already, it would be much longer if we added
explicit statements to contradict every incorrect assumption that
anybody could imagine that someone might make.&nbsp; Although, there have
certainly been cases where people have assumed that a certain
requirement exists and then have insisted that the requirement must
exist unless the document includes an explicit statement that the
requirement does not exist (even when there is nothing in the document
that even hints at the suggestion that such a requirement exists).<br>
<br>
I think the best we can do is to try to ensure that the document does
not include statements that imply things that are incorrect.&nbsp; Explicit
statements contradicting incorrect assumptions should only be used
where there is evidence that confusion exists in that area.&nbsp; Adding
statement to deal with the hypothetical possibility that someone might
make an incorrect assumption about something, despite there being
nothing in the document that could lead to that assumption and no
evidence that people have been confused in that area, seems unnecessary.<br>
<br>
Dave<br>
<br>
</body>
</html>

Date: Wed, 05 Jul 2006 09:51:59 -0400
From: "David A. Cooper" <[email-masked]>
To: David Chadwick <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

David Chadwick wrote:

> Hi Dave
>
> at the PKIX meeting next week I will be giving a short presentation to 
> request that the AIA extension be generalised to apply to the issuer 
> of any type of certificate (not just PKCs) so that it can point to 
> information about the AA of an AC for example. Do you have a problem 
> with this?

David,

I was just looking at RFC 3281 (An Internet Attribute Certificate 
Profile for Authorization) and found the following text:

      4.3.3   Authority Key Identifier

         The authorityKeyIdentifier extension, as profiled in 
[PKIXPROF], MAY
         be used to assist the AC verifier in checking the signature of the
         AC.  The [PKIXPROF] description should be read as if "CA" meant "AC
         issuer."  As with PKCs, this extension SHOULD be included in ACs.

         Note: An AC, where the issuer field used the baseCertificateID
         CHOICE, would not need an authorityKeyIdentifier extension, as 
it is
         explicitly linked to the key in the referred certificate.  However,
         as this profile states (in section 4.2.3), ACs MUST use the v2Form
         with issuerName CHOICE, this duplication does not arise.

            name           id-ce-authorityKeyIdentifier
            OID            { id-ce 35 }
            syntax         AuthorityKeyIdentifier
            criticality    MUST be FALSE

Does this address your requirement?  I don't think this should be in 
3280bis since 3280bis only addresses public key certificates.

Dave

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>
Subject: RFC 3280bis issue: guidance on handling circularity situations of revocation checking
Date: Wed, 5 Jul 2006 20:04:55 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

After participating the recent discussion about some circularity
situations of revocation checking and after reading Santosh's
presentation slides at 2006 NIST PKI research conference,
I would like to suggest that REC 3280bis should provide
guidance on handling circularity situations of revocation checking.

(Actually, I remember that the circularity issues has raised several
times since the inital call for issues for RFC 3280bis. However,
I do not think the current of RFC 3280bis address these issues
well.)

I think maybe REC 3280bis should add a section to compile
the guidance to CA implementators and relying parties on handling
different circularity situations of revocation checking. 

At least, the following circularity situations of revocation checking
should be addressed:

1. When the Root CA re-keys, RFC 3280bis currently suggest the
    Root CA should follow procedures for "CA key update"
    specified in RFC 4210. That is the Root CA should issued
    new-with-old self-issued certificate and old-with-new self-issued
    certificate. But, neither RFC 4210 nor RFC 3280bis provide
    guidance on how the revocation info of the new-with-old and
    old-with-new certificates should be provided to relying parties.

2. When an intermediate CA re-keys, the CA might request
    a new cross-certificate from its parent CAs or the CA might
    issue a key-rollover self-issued certificate. In either situations,
    is it mandatory for the CA to continue using the old key to issue
    CRLs for old certificate signed by the old key?

3. When a CA uses another key to sign CRLs, how the revocation info
    of the certificate of the CRL signing key should be provided to relying
    parties?

4. When a CA delegates its CRL signing responsibility to other CRL
    issuers, how the revocation info of the certificate of the delegated CRL
    issuers should be provided to relying parties?

5. When a CA provide OCSP service or delegate its responsibility of
    providing revocation info to a third-party OCSP server, how the
    revocation info of the OCSP responder certificate should be provided
    to relying parties?

Any other situations?

Regards,
Wen-Cheng Wang

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>
Subject: Comments on RFC 3280bis-04
Date: Wed, 5 Jul 2006 18:51:57 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

The definition of the term 'self-issued certificate' does not take
account of the possibility that a self-issued certificate might be
an EE certificate.

For example, a CA might issue a certificate to itself for used
by its RAs to check the CA's signature of the CMP messages. This
kind of certificate will not contain a basicConstraints extension,
and therefore be an EE certificate.

Another example is a CA might itself act as an OCSP responder.
In that case, the CA will issue an OCSP responder certificate to itself.
(The issuer name and subject name of the OCSP responder certificate
are the same.)
In general, an OCSP responder certificate is considered an EE
certificate.

In the last para of section 4.1.2.4, it defines the term 'self-issued
certificate' as:
   If the names in the issuer and subject field in a
   certificate match according to the rules specified in section 7.1
   then the certificate is self-issued.

According to this definition, an certificate with its the issuer and
subject field matched is a self-issued certificate, no matter whether it
contain a basicConstraints extension with the cA boolean is
asserted.

Therefore, in practice, a self-issued certificate could be a
a self-issued EE certificate if it is a v3 certificate with
the basicConstraints extnesion absent or it contains
a basicConstraints extnesion but the cA boolean is
not asserted. Unfortunately, the current text of RFC 3280bis
is written as if a self-issued certificate must be a CA certificate.

I think RFC 3280bis should clarify this. I suggest that at least the
following note should be add to the end of section 3.2:

  Note that, a CA might sometimes issue end entity certificates to itself
  for some special purposes such as for providing CMP signing certificate
  to its RAs. In general, the basic constraints  extension will is not present
  in such certificates, or the extension is present but the cA boolean is not
  asserted. Therefore, as discussed in 4.2.1.9, the certificate must be
  treated as an EE certificate, even if its issuer name and subject name
  is the same.

(Feel free to retouch my awkward english.)

In addition, the path validation logic in section 6 needs to be checked
thoroughly  to make sure it can correctly hadle situations where
self-issued certificates are EE certificates.

Finally, there is a typo in page 100:

In para 3 of section 10, the term 'certificate practice statement'
should be 'certification practice statement'.

Regards,
Wen-Cheng Wang

Date: Wed, 05 Jul 2006 10:51:24 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt
Sender: [email-masked]

Hi Dave

at the PKIX meeting next week I will be giving a short presentation to 
request that the AIA extension be generalised to apply to the issuer of 
any type of certificate (not just PKCs) so that it can point to 
information about the AA of an AC for example. Do you have a problem 
with this?

regards

David

David A. Cooper wrote:
> 
> All,
> 
> On Friday, I submitted draft 4 of 3280bis for posting.  A diff file 
> highlighting the changes between drafts 3 and 4 is available at 
> http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-03todraft3280bis-04_diff.html. 
> 
> 
> Draft 4 includes the following changes:
> 
> 1. References to RFCs were updated as follows:
>           RFC 2247 replaced with RFC 4519
>           RFC 2253  replaced with RFC 4514
>           RFC 2252 replaced with RFC 4512
>           RFC 2255 replaced with RFC 4516
>           RFC 2510 replaced with RFC 4210
>           RFC 2587 replaced with RFC 4523
>           draft-ietf-ldapbis-strprep-07.txt replaced with RFC  4518
> 
> 2. All references to RFC 3279 now mention RFC 4055 and RFC 4491 as well. 
> (All three RFCs are listed as informative references.)
> 
> 3. Section 4.2.1.6 (subjectAltName):  Reference to section 7.5 clarified 
> to note that the section addresses email addresses that contain 
> internationalized domain names rather than internationalized email 
> addresses.
> 
> 4. Section 4.2.1.7 (issuerAltName): Text added to clarify that the 
> issuerAltName extension is not processed during certification path 
> validation (i.e., it is not used in name chaining and name constraints 
> are not enforced).
> 
> 5. Section 4.2.1.10 (nameConstraints):  Clarified that for DNS names, 
> "host.example.com" is a match for the constraint "host.example.com".  
> Also clarified that constraints of on the directoryName name form are 
> not applied to the subject field if the subject contains an empty DN.
> 
> 6. Section 7 (Processing Rules for Internationalized Names):  made 
> changes based on comments from Kurt Zeilenga.
> 
> 7. Numerous minor typographic and syntactic errors were corrected.
> 
> Dave
> 
> 

-- 

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

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

From: "Wen-Cheng Wang" <[email-masked]>
To: "Dr Stephen Henson" <[email-masked]>, <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Date: Wed, 5 Jul 2006 16:04:07 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

It seems that the current texts of X.509 and RFC3280bis do not
prohibit a CA from issuing a CRL with an empty IDP extension
present, although I think it is not a good idea to issue such
unusual CRL.

However, a CRL with an empty IDP extension is semantically
interpretable. I believe that it is semantically equal to a CRL
with the IDP extension absent.

I repeat the interpretation here: 

Since the the IDP is absent, it is a full CRL because there is no
DistributionPointName. That is it is not a partitioned CRL (a.k.a. a CRL
distribution point).

Its scope covers both EE certificates and CA certificates issued by
the CA, bacause by default onlyContainsUserCerts = FALSE
and onlyContainsCACerts = FALSE.

Its scope covers all revocation reasons, because onlySomeReasons
is absent.

It has to be issued by the CA itself (i.e., a direct CRL) bacuase by
default indirectCRL = FALSE.

Wen-Cheng Wang

----- Original Message ----- 
From: "Dr Stephen Henson" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 04, 2006 9:05 PM
Subject: Re: Question about indirect CRLs (and designated OCSP responders)

> 
> Julien Stern wrote:
> 
>> 
>> Altough, in order to nitpick a bit, what is the rule if the IDP
>> is absent? This section refers to the situation where an IDP
>> is present. In that case, I agree that a distributionPoint must
>> be present unless there is a single CRL issuer (which should probably
>> then be the CA, because as you pointed the CA must provide revocation
>> information for the CRL issuer cert otherwise).
>> 
>> But what if there is
>> - One CRL with an IDP and a distributionPoint
>> - One CRL without an IDP
>> 
>> Is that "legal"? I did not find anything in RFC3280 (or son-of)
>> that forbides it, but I might have missed something (or it could
>> just be common sense...).
>> 
> 
> On the subject of IDP. I've come across cases where the IDP extension is
> present, critical but with all optional fields not present and
> everything has a default value: i.e. it is just an empty SEQUENCE.
> 
> Is this legal?
> 
> AFAICS there is nothing that specifically forbids this but such an
> extension AFAICS doesn't serve a useful purpose other than to break
> implemenations which don't process IDP.
> 
> Steve.
>

From: "Wen-Cheng Wang" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Date: Wed, 5 Jul 2006 15:49:45 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Please see my opinions in-line.

Wen-Cheng Wang

----- Original Message ----- 
From: "Julien Stern" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 04, 2006 8:10 PM
Subject: Re: Question about indirect CRLs (and designated OCSP responders)

> 
> Altough, in order to nitpick a bit, what is the rule if the IDP
> is absent? This section refers to the situation where an IDP
> is present. In that case, I agree that a distributionPoint must
> be present unless there is a single CRL issuer (which should probably
> then be the CA, because as you pointed the CA must provide revocation
> information for the CRL issuer cert otherwise).

As Santosh pointed out if the IDP is absent, then it must be a direct full CRL
that covers all EE certificates and CA certificates issued by the CA. However,
it can be a complete full CRL or a delta CRL based on a complete full CRL,
depending on the presence of the deltaCRLIndicator extension.

To elaborate further:

According to X.509, a full CRL means "a CRL that contains entries for all
certificates that have been revoked for the given scope".

Since the the IDP is absent, it is a full CRL because there is no
DistributionPointName. That is it is not a partitioned CRL (a.k.a. a CRL
distribution point).

Its scope covers both EE certificates and CA certificates issued by
the CA, bacause by default onlyContainsUserCerts = FALSE
and onlyContainsCACerts = FALSE.

Its scope covers all revocation reasons, because onlySomeReasons
is absent.

It has to be issued by the CA itself (i.e., a direct CRL) bacuase by
default indirectCRL = FALSE.  

> 
> But what if there is
> - One CRL with an IDP and a distributionPoint
> - One CRL without an IDP
> 
> Is that "legal"? I did not find anything in RFC3280 (or son-of)
> that forbides it, but I might have missed something (or it could
> just be common sense...).
> 
I believe that it is legal. Nothing prohibits a CA from issuing a complete
full CRL and issuing its partitions at the same time. However, it is the
responsibility for the CA to make sure each partitioned CRL cover
the correct scope.

Wen-Cheng Wang

Date: Tue, 4 Jul 2006 16:59:46 +0300 (EEST)
Subject: 
From: [email-masked]
To: [email-masked]
Importance: Normal
Sender: [email-masked]

unsubscribe

Content-class: urn:content-classes:message
Subject: RE: Question about indirect CRLs (and designated OCSP responders)
Date: Tue, 4 Jul 2006 06:28:44 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

The rule is very simple when IDP is absent.

It is a full direct CRL, base or delta (depending on the presence of the
deltaCRLIndicator extension).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Stern
Sent: Tuesday, July 04, 2006 8:11 AM
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP
responders)

On Tue, Jul 04, 2006 at 06:42:28PM +0800, Wen-Cheng Wang wrote:
> 
> IDP is mandatory for a partitioned CRL and the relying
> party must check whether it match CRLDP. This is true
> even if it is a 'direct' CRL. Otherwise, there will be
> a risk that a man-in-the-middle repalces the partitioned
> CRL with other partitioned CRL issued by the same
> CA (or the same CRL issuer).
> 
> I think the Technical Corrigendium 3 of the ITU-T X.509
> standard is very clear about this. (Please see its corrigendium
> to section B5.1.4)
> 
> Section 5.2.5 of RFC 3280bis says:
> 
>   If the distributionPoint field is absent, the CRL MUST contain
>   entries for all revoked unexpired certificates issued by the CRL
>   issuer, if any, within the scope of the CRL.
>
> In that sense,  RFC 3280bis is compliant with the ITU-T X.509
> standard.

Thank you for the references.

Altough, in order to nitpick a bit, what is the rule if the IDP
is absent? This section refers to the situation where an IDP
is present. In that case, I agree that a distributionPoint must
be present unless there is a single CRL issuer (which should probably
then be the CA, because as you pointed the CA must provide revocation
information for the CRL issuer cert otherwise).

But what if there is
- One CRL with an IDP and a distributionPoint
- One CRL without an IDP

Is that "legal"? I did not find anything in RFC3280 (or son-of)
that forbides it, but I might have missed something (or it could
just be common sense...).

Regards,

--
Julien Stern

> ----- Original Message ----- 
> From: "Julien Stern" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 04, 2006 5:40 PM
> Subject: Re: Question about indirect CRLs (and designated OCSP
responders)
> 
> 
> >
> >On Tue, Jul 04, 2006 at 05:17:46PM +0800, Wen-Cheng Wang wrote:
> >>Julien,
> >>
> >>Yes, it leaves us two CRL issuers. One is the delegated (indirect)
CRL
> >>issuer, and the other is the CA itself.
> >>
> >>The CA itself is responsible for revoking the certificate for the 
> >>delegated
> >>CRL issuer. Therefore, the CA still need to issue a special CRL that
> >>at least cover the certificate for the delegated CRL issuer. In that
case,
> >>the certificate should contain a CRLDP and the special CRL should
> >>contain an matched IDP, since the special CRL is a partitioned CRL
> >>(or offically called a CRL distribution point in the ITU-T X.509 
> >>standards).
> >
> >Wen-Cheng,
> >
> >I'm a bit confused about that part: my understanding was that you did
> >not need an IDP for "direct" CRL (and this special CRL is directly
> >produced by the CA). It is just "nicer" to put it for some reason,
> >or is it mandatory because the CRL is partitioned?
> >
> >Regards,
> >
> >--
> >Julien Stern
> >
> >>The delegated CRL issuer is responsible for revoking all
certificates
> >>issued by the CA other than the certificate of itself.
> >>
> >>BTW, in the case where a CA delegate its revocation responsibility
to
> >>an OCSP responder instead of a delegated CRL issued, the same
> >>approach can also be used to revoke the certificate for the OCSP
> >>responder if it is not a short-lived certificate.
> >>
> >>What I want to emphasize is that it is inevitable that a CA still
need
> >>to issue CRLs even it has delegated its revocation responsibility to
> >>a delegated CRL issuer or an OCSP responder, unless the certificate
> >>for the delegated CRL issuer or the OCSP responder is a short-lived
> >>certificate.
> >>
> >>Regards,
> >>Wen-Cheng Wang
> >>
> >>----- Original Message ----- 
> >>From: "Julien Stern" <[email-masked]>
> >>To: <[email-masked]>
> >>Sent: Tuesday, July 04, 2006 4:44 PM
> >>Subject: Re: Question about indirect CRLs (and designated OCSP
responders)
> >>
> >>
> >>>
> >>>On Tue, Jul 04, 2006 at 09:48:32AM +0800, Wen-Cheng Wang wrote:
> >>>>In my opinion, in approach (1), the certificate for the CRL issuer
> >>>>should contain a CRLDP that points to the special CRL
> >>>>that covers only that one certificate. In addition, the special
CRL
> >>>>should contain an IDP that matches the CRLDP in the certificate.
> >>>
> >>>Wen-Cheng,
> >>>
> >>>wouldn't that leave us with two (delegated) CRL issuers for the CA
?
> >>>And then how to revoke the second delegated CRL issuer ? :)
> >>>
> >>>Regards,
> >>>
> >>>--
> >>>Julien
> >>>
> >>>>Wen-Cheng Wang
> >>>>
> >>>>----- Original Message ----- 
> >>>>From: "Kemp David P." <[email-masked]>
> >>>>To: "Julien Stern" <[email-masked]>;
<[email-masked]>
> >>>>Sent: Tuesday, July 04, 2006 3:45 AM
> >>>>Subject: RE: Question about indirect CRLs (and designated OCSP 
> >>responders)
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>Julien,
> >>>>>
> >>>>>There is a logical fallacy in your supposition which leads to
> >>>>>the problem you describe.  If the CA wishes to retain the
> >>>>>authority for deciding whether the CRL issuer is reliable, it
> >>>>>cannot delegate that authority to the CRL issuer.
> >>>>>
> >>>>>The CA could use at least two approaches to avoid the problem:
> >>>>>
> >>>>>1) produce a certificate for the CRL issuer that does not
> >>>>>contain a CRLDP, and produce a CRL that covers only that one
> >>>>>certificate (and would therefore nearly always be empty).
> >>>>>
> >>>>>2) produce a certificate for the CRL issuer with a very
> >>>>>short validity period, refreshing the certificate for as
> >>>>>long as the CRL issuer remains reliable, and rekeying it
> >>>>>occasionally.
> >>>>>
> >>>>>Any approach must begin with a goal to be accomplished,
> >>>>>and then derive from that goal the syntax used to implement
> >>>>>it.  Garbage goals in, garbage certificates out.
> >>>>>
> >>>>>
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: [email-masked] 
> >>[mailto:[email-masked]]
> >>>>>On Behalf Of Julien Stern
> >>>>>Sent: Monday, July 03, 2006 1:43 PM
> >>>>>To: [email-masked]
> >>>>>Subject: Question about indirect CRLs (and designated OCSP
responders)
> >>>>>
> >>>>>
> >>>>>Folks,
> >>>>>
> >>>>>I have a question regarding the treatment of Indirect CRLs in the
> >>>>>following case:
> >>>>>
> >>>>>Suppose that I have:
> >>>>>- one CA (that does NOT produce CRLs)
> >>>>>- one CRL issuer (that produces CRLs on behalf of that CA)
> >>>>>
> >>>>>Every certificate emitted by this CA contains the CRLDP extension
> >>>>>indicating who is the CRL issuer.
> >>>>>
> >>>>>Now, also suppose that the CRL issuer certificate is emitted by
the CA,
> >>>>>which can be useful in order to bring trust to this certificate.
> >>>>>
> >>>>>It then seems that the CRL issuer can revoke its own certificate.
> >>>>>What should be the treatment in this setting if the serial number
> >>>>>of the certificate of the CRL issuer appears in the CRL?
> >>>>>
> >>>>>Additionally, if the CRL issuer is compromised, the CA could
issue
> >>>>>a new CRL issuer certificate, and the new CRL issuer could revoke
> >>>>>the certificate of the previous CRL issuer. But then what to do
if the
> >>>>>old compromised CRL also revokes the new CRL issuer certificate?
> >>>>>It this setting simply not allowed for CRLs? If not, by what?
> >>>>>
> >>>>>
> >>>>>Also, I have exactly the same question regarding OCSP in the case
> >>>>>of a "CA Designated Responder" (RFC2560, page 2). This setting is
> >>>>>exactly the same as described above.
> >>>>>
> >>>>>What happens if the OCSP responder responds that its own
certificate is
> >>>>>revoked?
> >>>>>
> >>>>>What happens if I am presented (say in a long time archive) with
two
> >>>>>OCSP replies, each containing a "CA Designated Responder"
certificate
> >>>>>which revokes the other one?
> >>>>>
> >>>>>
> >>>>>Regards,
> >>>>>
> >>>>>--
> >>>>>Julien Stern
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> 

Date: Tue, 04 Jul 2006 14:05:43 +0100
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Sender: [email-masked]

Julien Stern wrote:

> 
> Altough, in order to nitpick a bit, what is the rule if the IDP
> is absent? This section refers to the situation where an IDP
> is present. In that case, I agree that a distributionPoint must
> be present unless there is a single CRL issuer (which should probably
> then be the CA, because as you pointed the CA must provide revocation
> information for the CRL issuer cert otherwise).
> 
> But what if there is
> - One CRL with an IDP and a distributionPoint
> - One CRL without an IDP
> 
> Is that "legal"? I did not find anything in RFC3280 (or son-of)
> that forbides it, but I might have missed something (or it could
> just be common sense...).
> 

On the subject of IDP. I've come across cases where the IDP extension is
present, critical but with all optional fields not present and
everything has a default value: i.e. it is just an empty SEQUENCE.

Is this legal?

AFAICS there is nothing that specifically forbids this but such an
extension AFAICS doesn't serve a useful purpose other than to break
implemenations which don't process IDP.

Steve.

Content-class: urn:content-classes:message
Subject: RE: Question about indirect CRLs (and designated OCSP responders)
Date: Tue, 4 Jul 2006 05:57:34 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I encourage you all to read a refereed paper we presented on the
circularity in revocation at 2006 NIST PKI research conference.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Tuesday, July 04, 2006 4:19 AM
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP
responders)

I am glad that this problem was raised again.

>In my opinion, in approach (1), the certificate for the CRL issuer
>should contain a CRLDP that points to the special CRL
>that covers only that one certificate. In addition, the special CRL
>should contain an IDP that matches the CRLDP in the certificate.

This is fine. The current draft is currently missing guidance to handle
that case.
Additional text, should be provided so that implementations can really 
support *in an interoperable way* the case where the CA is not handling 
revocation status information for all the certificates it issues.

Denis

>Wen-Cheng Wang
>
>----- Original Message ----- 
>From: "Kemp David P." <[email-masked]>
>To: "Julien Stern" <[email-masked]>; <[email-masked]>
>Sent: Tuesday, July 04, 2006 3:45 AM
>Subject: RE: Question about indirect CRLs (and designated OCSP
responders)
>
>
>> 
>> 
>> Julien,
>> 
>> There is a logical fallacy in your supposition which leads to
>> the problem you describe.  If the CA wishes to retain the
>> authority for deciding whether the CRL issuer is reliable, it
>> cannot delegate that authority to the CRL issuer.
>> 
>> The CA could use at least two approaches to avoid the problem:
>> 
>> 1) produce a certificate for the CRL issuer that does not
>> contain a CRLDP, and produce a CRL that covers only that one
>> certificate (and would therefore nearly always be empty).
>> 
>> 2) produce a certificate for the CRL issuer with a very
>> short validity period, refreshing the certificate for as
>> long as the CRL issuer remains reliable, and rekeying it
>> occasionally.
>> 
>> Any approach must begin with a goal to be accomplished,
>> and then derive from that goal the syntax used to implement
>> it.  Garbage goals in, garbage certificates out.
>> 
>> 
>> 
>> -----Original Message-----
>> From: [email-masked]
[mailto:[email-masked]]
>> On Behalf Of Julien Stern
>> Sent: Monday, July 03, 2006 1:43 PM
>> To: [email-masked]
>> Subject: Question about indirect CRLs (and designated OCSP
responders)
>> 
>> 
>> Folks,
>> 
>> I have a question regarding the treatment of Indirect CRLs in the
>> following case:
>> 
>> Suppose that I have:
>> - one CA (that does NOT produce CRLs)
>> - one CRL issuer (that produces CRLs on behalf of that CA)
>> 
>> Every certificate emitted by this CA contains the CRLDP extension
>> indicating who is the CRL issuer.
>> 
>> Now, also suppose that the CRL issuer certificate is emitted by the
CA,
>> which can be useful in order to bring trust to this certificate.
>> 
>> It then seems that the CRL issuer can revoke its own certificate.
>> What should be the treatment in this setting if the serial number
>> of the certificate of the CRL issuer appears in the CRL?
>> 
>> Additionally, if the CRL issuer is compromised, the CA could issue
>> a new CRL issuer certificate, and the new CRL issuer could revoke
>> the certificate of the previous CRL issuer. But then what to do if
the
>> old compromised CRL also revokes the new CRL issuer certificate?
>> It this setting simply not allowed for CRLs? If not, by what?
>> 
>> 
>> Also, I have exactly the same question regarding OCSP in the case
>> of a "CA Designated Responder" (RFC2560, page 2). This setting is
>> exactly the same as described above.
>> 
>> What happens if the OCSP responder responds that its own certificate
is
>> revoked?
>> 
>> What happens if I am presented (say in a long time archive) with two
>> OCSP replies, each containing a "CA Designated Responder" certificate
>> which revokes the other one?
>> 
>> 
>> Regards,
>> 
>> --
>> Julien Stern
>> 
>> 
>>
>
>

Regards,

Denis Pinkas

Date: Tue, 4 Jul 2006 14:57:09 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Comment on RFC 3280bis: id-pkix-crl-nocheck extension
Sender: [email-masked]

We currently have id-pkix-ocsp-nocheck extension.

In order to support trust anchors that issue short-lived PKCs for CRL issuers, 
there is a need to create a id-pkix-crl-nocheck extension.

Denis

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 14:27:07 +0200
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Jul 03, 2006 at 04:00:18PM -0400, Dave Engberg wrote:
> 
> Re: OCSP delegation & revocation ...
> 
> Revocation of a delegated responder cert is an underspecified area.  From
> what I've seen in various OCSP relying party software, you won't get
> consistent behavior unless you put in the id-pkix-ocsp-nocheck extension
> into your responder's cert.
> 
> In that case, revocation won't be checked, and the responder's cert should
> be appropriately short lived (e.g. a week or a month) so it will expire on a
> similar timeline as the equivalent CRL.  There's no technical reason why the
> responder certs couldn't be extremely short lived (e.g. one day), although
> this would require you to do a little work at your CA to automate the
> reissuance.

Dave,

It can be more than a little work if your CA is offline and has very
strict procedural control around the access to the private key.

I agree that the problem is not at all technical but more practical. A
Root CA (e.g. Trust Anchor) cannot be revoked, so any access to the
Root CA key should be controlled under much more stringent conditions
than the rest.

Having to access this key every day (or even every week) can be quite
unpractical. However, I agree that producing CRL or renewing the OCSP
responder certificate would both require access to the Root private key.

As Denis pointed out, pre-production of either the short lived
certificates or the CRL could be performed once, but then the problem
of the protection of this pre-produced material arises.

Regards,

--
Julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Julien Stern
> Sent: Monday, July 03, 2006 1:43 PM
> To: [email-masked]
> Subject: Question about indirect CRLs (and designated OCSP responders)
> 
> 
> Folks,
> 
> I have a question regarding the treatment of Indirect CRLs in the following
> case:
> 
> Suppose that I have:
> - one CA (that does NOT produce CRLs)
> - one CRL issuer (that produces CRLs on behalf of that CA)
>  
> Every certificate emitted by this CA contains the CRLDP extension indicating
> who is the CRL issuer.
> 
> Now, also suppose that the CRL issuer certificate is emitted by the CA,
> which can be useful in order to bring trust to this certificate.
> 
> It then seems that the CRL issuer can revoke its own certificate.
> What should be the treatment in this setting if the serial number of the
> certificate of the CRL issuer appears in the CRL?
> 
> Additionally, if the CRL issuer is compromised, the CA could issue a new CRL
> issuer certificate, and the new CRL issuer could revoke the certificate of
> the previous CRL issuer. But then what to do if the old compromised CRL also
> revokes the new CRL issuer certificate?
> It this setting simply not allowed for CRLs? If not, by what?
> 
> 
> Also, I have exactly the same question regarding OCSP in the case of a "CA
> Designated Responder" (RFC2560, page 2). This setting is exactly the same as
> described above.
> 
> What happens if the OCSP responder responds that its own certificate is
> revoked?
> 
> What happens if I am presented (say in a long time archive) with two OCSP
> replies, each containing a "CA Designated Responder" certificate which
> revokes the other one?
> 
> 
> Regards,
> 
> --
> Julien Stern
> 

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 14:10:40 +0200
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Jul 04, 2006 at 06:42:28PM +0800, Wen-Cheng Wang wrote:
> 
> IDP is mandatory for a partitioned CRL and the relying
> party must check whether it match CRLDP. This is true
> even if it is a 'direct' CRL. Otherwise, there will be
> a risk that a man-in-the-middle repalces the partitioned
> CRL with other partitioned CRL issued by the same
> CA (or the same CRL issuer).
> 
> I think the Technical Corrigendium 3 of the ITU-T X.509
> standard is very clear about this. (Please see its corrigendium
> to section B5.1.4)
> 
> Section 5.2.5 of RFC 3280bis says:
> 
>   If the distributionPoint field is absent, the CRL MUST contain
>   entries for all revoked unexpired certificates issued by the CRL
>   issuer, if any, within the scope of the CRL.
>
> In that sense,  RFC 3280bis is compliant with the ITU-T X.509
> standard.

Thank you for the references.

Altough, in order to nitpick a bit, what is the rule if the IDP
is absent? This section refers to the situation where an IDP
is present. In that case, I agree that a distributionPoint must
be present unless there is a single CRL issuer (which should probably
then be the CA, because as you pointed the CA must provide revocation
information for the CRL issuer cert otherwise).

But what if there is
- One CRL with an IDP and a distributionPoint
- One CRL without an IDP

Is that "legal"? I did not find anything in RFC3280 (or son-of)
that forbides it, but I might have missed something (or it could
just be common sense...).

Regards,

--
Julien Stern

> ----- Original Message ----- 
> From: "Julien Stern" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 04, 2006 5:40 PM
> Subject: Re: Question about indirect CRLs (and designated OCSP responders)
> 
> 
> >
> >On Tue, Jul 04, 2006 at 05:17:46PM +0800, Wen-Cheng Wang wrote:
> >>Julien,
> >>
> >>Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
> >>issuer, and the other is the CA itself.
> >>
> >>The CA itself is responsible for revoking the certificate for the 
> >>delegated
> >>CRL issuer. Therefore, the CA still need to issue a special CRL that
> >>at least cover the certificate for the delegated CRL issuer. In that case,
> >>the certificate should contain a CRLDP and the special CRL should
> >>contain an matched IDP, since the special CRL is a partitioned CRL
> >>(or offically called a CRL distribution point in the ITU-T X.509 
> >>standards).
> >
> >Wen-Cheng,
> >
> >I'm a bit confused about that part: my understanding was that you did
> >not need an IDP for "direct" CRL (and this special CRL is directly
> >produced by the CA). It is just "nicer" to put it for some reason,
> >or is it mandatory because the CRL is partitioned?
> >
> >Regards,
> >
> >--
> >Julien Stern
> >
> >>The delegated CRL issuer is responsible for revoking all certificates
> >>issued by the CA other than the certificate of itself.
> >>
> >>BTW, in the case where a CA delegate its revocation responsibility to
> >>an OCSP responder instead of a delegated CRL issued, the same
> >>approach can also be used to revoke the certificate for the OCSP
> >>responder if it is not a short-lived certificate.
> >>
> >>What I want to emphasize is that it is inevitable that a CA still need
> >>to issue CRLs even it has delegated its revocation responsibility to
> >>a delegated CRL issuer or an OCSP responder, unless the certificate
> >>for the delegated CRL issuer or the OCSP responder is a short-lived
> >>certificate.
> >>
> >>Regards,
> >>Wen-Cheng Wang
> >>
> >>----- Original Message ----- 
> >>From: "Julien Stern" <[email-masked]>
> >>To: <[email-masked]>
> >>Sent: Tuesday, July 04, 2006 4:44 PM
> >>Subject: Re: Question about indirect CRLs (and designated OCSP responders)
> >>
> >>
> >>>
> >>>On Tue, Jul 04, 2006 at 09:48:32AM +0800, Wen-Cheng Wang wrote:
> >>>>In my opinion, in approach (1), the certificate for the CRL issuer
> >>>>should contain a CRLDP that points to the special CRL
> >>>>that covers only that one certificate. In addition, the special CRL
> >>>>should contain an IDP that matches the CRLDP in the certificate.
> >>>
> >>>Wen-Cheng,
> >>>
> >>>wouldn't that leave us with two (delegated) CRL issuers for the CA ?
> >>>And then how to revoke the second delegated CRL issuer ? :)
> >>>
> >>>Regards,
> >>>
> >>>--
> >>>Julien
> >>>
> >>>>Wen-Cheng Wang
> >>>>
> >>>>----- Original Message ----- 
> >>>>From: "Kemp David P." <[email-masked]>
> >>>>To: "Julien Stern" <[email-masked]>; <[email-masked]>
> >>>>Sent: Tuesday, July 04, 2006 3:45 AM
> >>>>Subject: RE: Question about indirect CRLs (and designated OCSP 
> >>responders)
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>Julien,
> >>>>>
> >>>>>There is a logical fallacy in your supposition which leads to
> >>>>>the problem you describe.  If the CA wishes to retain the
> >>>>>authority for deciding whether the CRL issuer is reliable, it
> >>>>>cannot delegate that authority to the CRL issuer.
> >>>>>
> >>>>>The CA could use at least two approaches to avoid the problem:
> >>>>>
> >>>>>1) produce a certificate for the CRL issuer that does not
> >>>>>contain a CRLDP, and produce a CRL that covers only that one
> >>>>>certificate (and would therefore nearly always be empty).
> >>>>>
> >>>>>2) produce a certificate for the CRL issuer with a very
> >>>>>short validity period, refreshing the certificate for as
> >>>>>long as the CRL issuer remains reliable, and rekeying it
> >>>>>occasionally.
> >>>>>
> >>>>>Any approach must begin with a goal to be accomplished,
> >>>>>and then derive from that goal the syntax used to implement
> >>>>>it.  Garbage goals in, garbage certificates out.
> >>>>>
> >>>>>
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: [email-masked] 
> >>[mailto:[email-masked]]
> >>>>>On Behalf Of Julien Stern
> >>>>>Sent: Monday, July 03, 2006 1:43 PM
> >>>>>To: [email-masked]
> >>>>>Subject: Question about indirect CRLs (and designated OCSP responders)
> >>>>>
> >>>>>
> >>>>>Folks,
> >>>>>
> >>>>>I have a question regarding the treatment of Indirect CRLs in the
> >>>>>following case:
> >>>>>
> >>>>>Suppose that I have:
> >>>>>- one CA (that does NOT produce CRLs)
> >>>>>- one CRL issuer (that produces CRLs on behalf of that CA)
> >>>>>
> >>>>>Every certificate emitted by this CA contains the CRLDP extension
> >>>>>indicating who is the CRL issuer.
> >>>>>
> >>>>>Now, also suppose that the CRL issuer certificate is emitted by the CA,
> >>>>>which can be useful in order to bring trust to this certificate.
> >>>>>
> >>>>>It then seems that the CRL issuer can revoke its own certificate.
> >>>>>What should be the treatment in this setting if the serial number
> >>>>>of the certificate of the CRL issuer appears in the CRL?
> >>>>>
> >>>>>Additionally, if the CRL issuer is compromised, the CA could issue
> >>>>>a new CRL issuer certificate, and the new CRL issuer could revoke
> >>>>>the certificate of the previous CRL issuer. But then what to do if the
> >>>>>old compromised CRL also revokes the new CRL issuer certificate?
> >>>>>It this setting simply not allowed for CRLs? If not, by what?
> >>>>>
> >>>>>
> >>>>>Also, I have exactly the same question regarding OCSP in the case
> >>>>>of a "CA Designated Responder" (RFC2560, page 2). This setting is
> >>>>>exactly the same as described above.
> >>>>>
> >>>>>What happens if the OCSP responder responds that its own certificate is
> >>>>>revoked?
> >>>>>
> >>>>>What happens if I am presented (say in a long time archive) with two
> >>>>>OCSP replies, each containing a "CA Designated Responder" certificate
> >>>>>which revokes the other one?
> >>>>>
> >>>>>
> >>>>>Regards,
> >>>>>
> >>>>>--
> >>>>>Julien Stern
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> 

From: "Wen-Cheng Wang" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Date: Tue, 4 Jul 2006 19:15:33 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Denis,

How could a relying party know that no CRL is available for
short-lived certificates?

Yes, this is an interesting question.

Two options come across my mind.

Option 1 is to introduce a certificate extension similar to the
id-pkix-ocsp-nocheck extension defined in RFC 2560.

Option 2 is letting the validity period of the short-lived
certificates equal to the update period of the CRL. That is
letting the notBefore of the certificate equal thisUpdate of the
CRL and  letting the notAfter of the certificate equal
nextUpdate of the CRL. The relying party has to be smart
enough to know that since the validity period of the
short-lived certificates is equivalent to the period of
the updated revocation info is given by the CA to
the delegated CRL issuer, it is reasonable that there is no
need to check the revocation status of the short-lived
certificates.

Obviously, adopting option 2 might cause ambiguity, but
it has the advantage that there is no need to introduce
a new extension.

Regards,
Wen-Cheng Wang

From: "Denis Pinkas" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 04, 2006 6:10 PM
Subject: Re:Question about indirect CRLs (and designated OCSP responders)

> 
> 
> I jump into this interresting discussion.
> 
>>Julien,
>>
>>Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
>>issuer, and the other is the CA itself.
> 
> In case, the CA handles the revocation of the CRL issuer(s).
> Otherwise, it can issue short-lived certificates.
> 
>>The CA itself is responsible for revoking the certificate for the delegated
>>CRL issuer. Therefore, the CA still need to issue a special CRL that
>>at least cover the certificate for the delegated CRL issuer. In that case,
>>the certificate should contain a CRLDP and the special CRL should
>>contain an matched IDP, since the special CRL is a partitioned CRL
>>(or offically called a CRL distribution point in the ITU-T X.509 standards).
>>
>>The delegated CRL issuer is responsible for revoking all certificates
>>issued by the CA other than the certificate of itself.
>>
>>BTW, in the case where a CA delegate its revocation responsibility to
>>an OCSP responder instead of a delegated CRL issued, the same
>>approach can also be used to revoke the certificate for the OCSP
>>responder if it is not a short-lived certificate.
>>
>>What I want to emphasize is that it is inevitable that a CA still need
>>to issue CRLs even it has delegated its revocation responsibility to
>>a delegated CRL issuer or an OCSP responder, unless the certificate
>>for the delegated CRL issuer or the OCSP responder is a short-lived
>>certificate.
> 
> Yes, these are the two options.
> 
> - If CRLs are used, then a probably empty CRL would need to be issued each day.
> 
> - If short-lived certificates are used, then a new CRL Issuer certificate would need 
>   to be issued each day. However in that case how could a relying party know 
>   that no CRL is available ? 
> 
> For attribute certificates (AC) we have a way to indicate that no CRL is available, 
> we would need a similar indication for public key certificates (PKC).
> 
> Note : such CRLs and short-lived certificates could be issued in advance and 
> but only released every day in order to reduce the root key exposure.  
> 
> Denis
> 
> 
> 

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 12:48:49 +0200
To: "[email-masked]" <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Mail-Followup-To: Julien Stern <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

On Tue, Jul 04, 2006 at 12:10:00PM +0200, Denis Pinkas wrote:
> 
> >
> >What I want to emphasize is that it is inevitable that a CA still need
> >to issue CRLs even it has delegated its revocation responsibility to
> >a delegated CRL issuer or an OCSP responder, unless the certificate
> >for the delegated CRL issuer or the OCSP responder is a short-lived
> >certificate.
> 
> Yes, these are the two options.
> 
> [snip]

General agreement with everyone on the two options.

> Note : such CRLs and short-lived certificates could be issued in advance and 
> but only released every day in order to reduce the root key exposure.  

That note is definitely interesting. I'm precisely currently interested by
these issues.

Suppose that I'm operating a Root CA in a very secure environnement.
You know, in a bunker guarded by tanks and guards with machine guns,
and with the presence of 25 people required each time I want to perform
an operation with the Root private key (I'm kidding but you get the
point).

In that case, I do want to minimize access to this key.
It is then very tempting to pre-produce empty CRLs or short
lived-certificates, but isn't it "cheating"? That is, isn't the
exposure of this pre-produced CRLs and/or certificates a killer,
security wise? Shouldn't they be protected by essentially the same
level of security as the Root?

While they are not using any indirect CRLs, I had a quick look at the
"intermediate" CA in IE and I noticed that most of them did not include
any CRLDP (but we clearly not short lived). Those which included CRLDP
had a CRL validity period of several months.

Regards,

--
Julien

From: "Wen-Cheng Wang" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Date: Tue, 4 Jul 2006 18:42:28 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

IDP is mandatory for a partitioned CRL and the relying
party must check whether it match CRLDP. This is true
even if it is a 'direct' CRL. Otherwise, there will be
a risk that a man-in-the-middle repalces the partitioned
CRL with other partitioned CRL issued by the same
CA (or the same CRL issuer).

I think the Technical Corrigendium 3 of the ITU-T X.509
standard is very clear about this. (Please see its corrigendium
to section B5.1.4)

Section 5.2.5 of RFC 3280bis says:

   If the distributionPoint field is absent, the CRL MUST contain
   entries for all revoked unexpired certificates issued by the CRL
   issuer, if any, within the scope of the CRL.

In that sense,  RFC 3280bis is compliant with the ITU-T X.509
standard.

Wen-Cheng Wang

----- Original Message ----- 
From: "Julien Stern" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 04, 2006 5:40 PM
Subject: Re: Question about indirect CRLs (and designated OCSP responders)

> 
> On Tue, Jul 04, 2006 at 05:17:46PM +0800, Wen-Cheng Wang wrote:
>> Julien,
>> 
>> Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
>> issuer, and the other is the CA itself.
>> 
>> The CA itself is responsible for revoking the certificate for the delegated
>> CRL issuer. Therefore, the CA still need to issue a special CRL that
>> at least cover the certificate for the delegated CRL issuer. In that case,
>> the certificate should contain a CRLDP and the special CRL should
>> contain an matched IDP, since the special CRL is a partitioned CRL
>> (or offically called a CRL distribution point in the ITU-T X.509 standards).
> 
> Wen-Cheng,
> 
> I'm a bit confused about that part: my understanding was that you did
> not need an IDP for "direct" CRL (and this special CRL is directly
> produced by the CA). It is just "nicer" to put it for some reason,
> or is it mandatory because the CRL is partitioned?
> 
> Regards,
> 
> --
> Julien Stern
> 
>> The delegated CRL issuer is responsible for revoking all certificates
>> issued by the CA other than the certificate of itself.
>> 
>> BTW, in the case where a CA delegate its revocation responsibility to
>> an OCSP responder instead of a delegated CRL issued, the same
>> approach can also be used to revoke the certificate for the OCSP
>> responder if it is not a short-lived certificate.
>> 
>> What I want to emphasize is that it is inevitable that a CA still need
>> to issue CRLs even it has delegated its revocation responsibility to
>> a delegated CRL issuer or an OCSP responder, unless the certificate
>> for the delegated CRL issuer or the OCSP responder is a short-lived
>> certificate.
>> 
>> Regards,
>> Wen-Cheng Wang
>> 
>> ----- Original Message ----- 
>> From: "Julien Stern" <[email-masked]>
>> To: <[email-masked]>
>> Sent: Tuesday, July 04, 2006 4:44 PM
>> Subject: Re: Question about indirect CRLs (and designated OCSP responders)
>> 
>> 
>> >
>> >On Tue, Jul 04, 2006 at 09:48:32AM +0800, Wen-Cheng Wang wrote:
>> >>In my opinion, in approach (1), the certificate for the CRL issuer
>> >>should contain a CRLDP that points to the special CRL
>> >>that covers only that one certificate. In addition, the special CRL
>> >>should contain an IDP that matches the CRLDP in the certificate.
>> >
>> >Wen-Cheng,
>> >
>> >wouldn't that leave us with two (delegated) CRL issuers for the CA ?
>> >And then how to revoke the second delegated CRL issuer ? :)
>> >
>> >Regards,
>> >
>> >--
>> >Julien
>> >
>> >>Wen-Cheng Wang
>> >>
>> >>----- Original Message ----- 
>> >>From: "Kemp David P." <[email-masked]>
>> >>To: "Julien Stern" <[email-masked]>; <[email-masked]>
>> >>Sent: Tuesday, July 04, 2006 3:45 AM
>> >>Subject: RE: Question about indirect CRLs (and designated OCSP responders)
>> >>
>> >>
>> >>>
>> >>>
>> >>>Julien,
>> >>>
>> >>>There is a logical fallacy in your supposition which leads to
>> >>>the problem you describe.  If the CA wishes to retain the
>> >>>authority for deciding whether the CRL issuer is reliable, it
>> >>>cannot delegate that authority to the CRL issuer.
>> >>>
>> >>>The CA could use at least two approaches to avoid the problem:
>> >>>
>> >>>1) produce a certificate for the CRL issuer that does not
>> >>>contain a CRLDP, and produce a CRL that covers only that one
>> >>>certificate (and would therefore nearly always be empty).
>> >>>
>> >>>2) produce a certificate for the CRL issuer with a very
>> >>>short validity period, refreshing the certificate for as
>> >>>long as the CRL issuer remains reliable, and rekeying it
>> >>>occasionally.
>> >>>
>> >>>Any approach must begin with a goal to be accomplished,
>> >>>and then derive from that goal the syntax used to implement
>> >>>it.  Garbage goals in, garbage certificates out.
>> >>>
>> >>>
>> >>>
>> >>>-----Original Message-----
>> >>>From: [email-masked] [mailto:[email-masked]]
>> >>>On Behalf Of Julien Stern
>> >>>Sent: Monday, July 03, 2006 1:43 PM
>> >>>To: [email-masked]
>> >>>Subject: Question about indirect CRLs (and designated OCSP responders)
>> >>>
>> >>>
>> >>>Folks,
>> >>>
>> >>>I have a question regarding the treatment of Indirect CRLs in the
>> >>>following case:
>> >>>
>> >>>Suppose that I have:
>> >>>- one CA (that does NOT produce CRLs)
>> >>>- one CRL issuer (that produces CRLs on behalf of that CA)
>> >>>
>> >>>Every certificate emitted by this CA contains the CRLDP extension
>> >>>indicating who is the CRL issuer.
>> >>>
>> >>>Now, also suppose that the CRL issuer certificate is emitted by the CA,
>> >>>which can be useful in order to bring trust to this certificate.
>> >>>
>> >>>It then seems that the CRL issuer can revoke its own certificate.
>> >>>What should be the treatment in this setting if the serial number
>> >>>of the certificate of the CRL issuer appears in the CRL?
>> >>>
>> >>>Additionally, if the CRL issuer is compromised, the CA could issue
>> >>>a new CRL issuer certificate, and the new CRL issuer could revoke
>> >>>the certificate of the previous CRL issuer. But then what to do if the
>> >>>old compromised CRL also revokes the new CRL issuer certificate?
>> >>>It this setting simply not allowed for CRLs? If not, by what?
>> >>>
>> >>>
>> >>>Also, I have exactly the same question regarding OCSP in the case
>> >>>of a "CA Designated Responder" (RFC2560, page 2). This setting is
>> >>>exactly the same as described above.
>> >>>
>> >>>What happens if the OCSP responder responds that its own certificate is
>> >>>revoked?
>> >>>
>> >>>What happens if I am presented (say in a long time archive) with two
>> >>>OCSP replies, each containing a "CA Designated Responder" certificate
>> >>>which revokes the other one?
>> >>>
>> >>>
>> >>>Regards,
>> >>>
>> >>>--
>> >>>Julien Stern
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> 
>

Date: Tue, 4 Jul 2006 12:10:00 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re:Question about indirect CRLs (and designated OCSP responders)
Sender: [email-masked]

I jump into this interresting discussion.

>Julien,
>
>Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
>issuer, and the other is the CA itself.

In case, the CA handles the revocation of the CRL issuer(s).
Otherwise, it can issue short-lived certificates.

>The CA itself is responsible for revoking the certificate for the delegated
>CRL issuer. Therefore, the CA still need to issue a special CRL that
>at least cover the certificate for the delegated CRL issuer. In that case,
>the certificate should contain a CRLDP and the special CRL should
>contain an matched IDP, since the special CRL is a partitioned CRL
>(or offically called a CRL distribution point in the ITU-T X.509 standards).
>
>The delegated CRL issuer is responsible for revoking all certificates
>issued by the CA other than the certificate of itself.
>
>BTW, in the case where a CA delegate its revocation responsibility to
>an OCSP responder instead of a delegated CRL issued, the same
>approach can also be used to revoke the certificate for the OCSP
>responder if it is not a short-lived certificate.
>
>What I want to emphasize is that it is inevitable that a CA still need
>to issue CRLs even it has delegated its revocation responsibility to
>a delegated CRL issuer or an OCSP responder, unless the certificate
>for the delegated CRL issuer or the OCSP responder is a short-lived
>certificate.

Yes, these are the two options.

 - If CRLs are used, then a probably empty CRL would need to be issued each day.

 - If short-lived certificates are used, then a new CRL Issuer certificate would need 
   to be issued each day. However in that case how could a relying party know 
   that no CRL is available ? 

For attribute certificates (AC) we have a way to indicate that no CRL is available, 
we would need a similar indication for public key certificates (PKC).

Note : such CRLs and short-lived certificates could be issued in advance and 
but only released every day in order to reduce the root key exposure.  

Denis

>Regards,
>Wen-Cheng Wang
>
>----- Original Message ----- 
>From: "Julien Stern" <[email-masked]>
>To: <[email-masked]>
>Sent: Tuesday, July 04, 2006 4:44 PM
>Subject: Re: Question about indirect CRLs (and designated OCSP responders)
>
>
>> 
>> On Tue, Jul 04, 2006 at 09:48:32AM +0800, Wen-Cheng Wang wrote:
>>> In my opinion, in approach (1), the certificate for the CRL issuer
>>> should contain a CRLDP that points to the special CRL
>>> that covers only that one certificate. In addition, the special CRL
>>> should contain an IDP that matches the CRLDP in the certificate.
>> 
>> Wen-Cheng,
>> 
>> wouldn't that leave us with two (delegated) CRL issuers for the CA ?
>> And then how to revoke the second delegated CRL issuer ? :)
>> 
>> Regards,
>> 
>> --
>> Julien
>> 
>>> Wen-Cheng Wang
>>> 
>>> ----- Original Message ----- 
>>> From: "Kemp David P." <[email-masked]>
>>> To: "Julien Stern" <[email-masked]>; <[email-masked]>
>>> Sent: Tuesday, July 04, 2006 3:45 AM
>>> Subject: RE: Question about indirect CRLs (and designated OCSP responders)
>>> 
>>> 
>>> >
>>> >
>>> >Julien,
>>> >
>>> >There is a logical fallacy in your supposition which leads to
>>> >the problem you describe.  If the CA wishes to retain the
>>> >authority for deciding whether the CRL issuer is reliable, it
>>> >cannot delegate that authority to the CRL issuer.
>>> >
>>> >The CA could use at least two approaches to avoid the problem:
>>> >
>>> >1) produce a certificate for the CRL issuer that does not
>>> >contain a CRLDP, and produce a CRL that covers only that one
>>> >certificate (and would therefore nearly always be empty).
>>> >
>>> >2) produce a certificate for the CRL issuer with a very
>>> >short validity period, refreshing the certificate for as
>>> >long as the CRL issuer remains reliable, and rekeying it
>>> >occasionally.
>>> >
>>> >Any approach must begin with a goal to be accomplished,
>>> >and then derive from that goal the syntax used to implement
>>> >it.  Garbage goals in, garbage certificates out.
>>> >
>>> >
>>> >
>>> >-----Original Message-----
>>> >From: [email-masked] [mailto:[email-masked]]
>>> >On Behalf Of Julien Stern
>>> >Sent: Monday, July 03, 2006 1:43 PM
>>> >To: [email-masked]
>>> >Subject: Question about indirect CRLs (and designated OCSP responders)
>>> >
>>> >
>>> >Folks,
>>> >
>>> >I have a question regarding the treatment of Indirect CRLs in the
>>> >following case:
>>> >
>>> >Suppose that I have:
>>> >- one CA (that does NOT produce CRLs)
>>> >- one CRL issuer (that produces CRLs on behalf of that CA)
>>> >
>>> >Every certificate emitted by this CA contains the CRLDP extension
>>> >indicating who is the CRL issuer.
>>> >
>>> >Now, also suppose that the CRL issuer certificate is emitted by the CA,
>>> >which can be useful in order to bring trust to this certificate.
>>> >
>>> >It then seems that the CRL issuer can revoke its own certificate.
>>> >What should be the treatment in this setting if the serial number
>>> >of the certificate of the CRL issuer appears in the CRL?
>>> >
>>> >Additionally, if the CRL issuer is compromised, the CA could issue
>>> >a new CRL issuer certificate, and the new CRL issuer could revoke
>>> >the certificate of the previous CRL issuer. But then what to do if the
>>> >old compromised CRL also revokes the new CRL issuer certificate?
>>> >It this setting simply not allowed for CRLs? If not, by what?
>>> >
>>> >
>>> >Also, I have exactly the same question regarding OCSP in the case
>>> >of a "CA Designated Responder" (RFC2560, page 2). This setting is
>>> >exactly the same as described above.
>>> >
>>> >What happens if the OCSP responder responds that its own certificate is
>>> >revoked?
>>> >
>>> >What happens if I am presented (say in a long time archive) with two
>>> >OCSP replies, each containing a "CA Designated Responder" certificate
>>> >which revokes the other one?
>>> >
>>> >
>>> >Regards,
>>> >
>>> >--
>>> >Julien Stern
>>> >
>>> >
>>> >
>>> 
>>
>
>

Regards,

Denis Pinkas

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 11:40:12 +0200
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Jul 04, 2006 at 05:17:46PM +0800, Wen-Cheng Wang wrote:
> Julien,
> 
> Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
> issuer, and the other is the CA itself.
> 
> The CA itself is responsible for revoking the certificate for the delegated
> CRL issuer. Therefore, the CA still need to issue a special CRL that
> at least cover the certificate for the delegated CRL issuer. In that case,
> the certificate should contain a CRLDP and the special CRL should
> contain an matched IDP, since the special CRL is a partitioned CRL
> (or offically called a CRL distribution point in the ITU-T X.509 standards).

Wen-Cheng,

I'm a bit confused about that part: my understanding was that you did
not need an IDP for "direct" CRL (and this special CRL is directly
produced by the CA). It is just "nicer" to put it for some reason,
or is it mandatory because the CRL is partitioned?

Regards,

--
Julien Stern

> The delegated CRL issuer is responsible for revoking all certificates
> issued by the CA other than the certificate of itself.
> 
> BTW, in the case where a CA delegate its revocation responsibility to
> an OCSP responder instead of a delegated CRL issued, the same
> approach can also be used to revoke the certificate for the OCSP
> responder if it is not a short-lived certificate.
> 
> What I want to emphasize is that it is inevitable that a CA still need
> to issue CRLs even it has delegated its revocation responsibility to
> a delegated CRL issuer or an OCSP responder, unless the certificate
> for the delegated CRL issuer or the OCSP responder is a short-lived
> certificate.
> 
> Regards,
> Wen-Cheng Wang
> 
> ----- Original Message ----- 
> From: "Julien Stern" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 04, 2006 4:44 PM
> Subject: Re: Question about indirect CRLs (and designated OCSP responders)
> 
> 
> >
> >On Tue, Jul 04, 2006 at 09:48:32AM +0800, Wen-Cheng Wang wrote:
> >>In my opinion, in approach (1), the certificate for the CRL issuer
> >>should contain a CRLDP that points to the special CRL
> >>that covers only that one certificate. In addition, the special CRL
> >>should contain an IDP that matches the CRLDP in the certificate.
> >
> >Wen-Cheng,
> >
> >wouldn't that leave us with two (delegated) CRL issuers for the CA ?
> >And then how to revoke the second delegated CRL issuer ? :)
> >
> >Regards,
> >
> >--
> >Julien
> >
> >>Wen-Cheng Wang
> >>
> >>----- Original Message ----- 
> >>From: "Kemp David P." <[email-masked]>
> >>To: "Julien Stern" <[email-masked]>; <[email-masked]>
> >>Sent: Tuesday, July 04, 2006 3:45 AM
> >>Subject: RE: Question about indirect CRLs (and designated OCSP responders)
> >>
> >>
> >>>
> >>>
> >>>Julien,
> >>>
> >>>There is a logical fallacy in your supposition which leads to
> >>>the problem you describe.  If the CA wishes to retain the
> >>>authority for deciding whether the CRL issuer is reliable, it
> >>>cannot delegate that authority to the CRL issuer.
> >>>
> >>>The CA could use at least two approaches to avoid the problem:
> >>>
> >>>1) produce a certificate for the CRL issuer that does not
> >>>contain a CRLDP, and produce a CRL that covers only that one
> >>>certificate (and would therefore nearly always be empty).
> >>>
> >>>2) produce a certificate for the CRL issuer with a very
> >>>short validity period, refreshing the certificate for as
> >>>long as the CRL issuer remains reliable, and rekeying it
> >>>occasionally.
> >>>
> >>>Any approach must begin with a goal to be accomplished,
> >>>and then derive from that goal the syntax used to implement
> >>>it.  Garbage goals in, garbage certificates out.
> >>>
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: [email-masked] [mailto:[email-masked]]
> >>>On Behalf Of Julien Stern
> >>>Sent: Monday, July 03, 2006 1:43 PM
> >>>To: [email-masked]
> >>>Subject: Question about indirect CRLs (and designated OCSP responders)
> >>>
> >>>
> >>>Folks,
> >>>
> >>>I have a question regarding the treatment of Indirect CRLs in the
> >>>following case:
> >>>
> >>>Suppose that I have:
> >>>- one CA (that does NOT produce CRLs)
> >>>- one CRL issuer (that produces CRLs on behalf of that CA)
> >>>
> >>>Every certificate emitted by this CA contains the CRLDP extension
> >>>indicating who is the CRL issuer.
> >>>
> >>>Now, also suppose that the CRL issuer certificate is emitted by the CA,
> >>>which can be useful in order to bring trust to this certificate.
> >>>
> >>>It then seems that the CRL issuer can revoke its own certificate.
> >>>What should be the treatment in this setting if the serial number
> >>>of the certificate of the CRL issuer appears in the CRL?
> >>>
> >>>Additionally, if the CRL issuer is compromised, the CA could issue
> >>>a new CRL issuer certificate, and the new CRL issuer could revoke
> >>>the certificate of the previous CRL issuer. But then what to do if the
> >>>old compromised CRL also revokes the new CRL issuer certificate?
> >>>It this setting simply not allowed for CRLs? If not, by what?
> >>>
> >>>
> >>>Also, I have exactly the same question regarding OCSP in the case
> >>>of a "CA Designated Responder" (RFC2560, page 2). This setting is
> >>>exactly the same as described above.
> >>>
> >>>What happens if the OCSP responder responds that its own certificate is
> >>>revoked?
> >>>
> >>>What happens if I am presented (say in a long time archive) with two
> >>>OCSP replies, each containing a "CA Designated Responder" certificate
> >>>which revokes the other one?
> >>>
> >>>
> >>>Regards,
> >>>
> >>>--
> >>>Julien Stern
> >>>
> >>>
> >>>
> >>
> >
> 

From: "Wen-Cheng Wang" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Date: Tue, 4 Jul 2006 17:17:46 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Julien,

Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
issuer, and the other is the CA itself.

The CA itself is responsible for revoking the certificate for the delegated
CRL issuer. Therefore, the CA still need to issue a special CRL that
at least cover the certificate for the delegated CRL issuer. In that case,
the certificate should contain a CRLDP and the special CRL should
contain an matched IDP, since the special CRL is a partitioned CRL
(or offically called a CRL distribution point in the ITU-T X.509 standards).

The delegated CRL issuer is responsible for revoking all certificates
issued by the CA other than the certificate of itself.

BTW, in the case where a CA delegate its revocation responsibility to
an OCSP responder instead of a delegated CRL issued, the same
approach can also be used to revoke the certificate for the OCSP
responder if it is not a short-lived certificate.

What I want to emphasize is that it is inevitable that a CA still need
to issue CRLs even it has delegated its revocation responsibility to
a delegated CRL issuer or an OCSP responder, unless the certificate
for the delegated CRL issuer or the OCSP responder is a short-lived
certificate.

Regards,
Wen-Cheng Wang

----- Original Message ----- 
From: "Julien Stern" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 04, 2006 4:44 PM
Subject: Re: Question about indirect CRLs (and designated OCSP responders)

> 
> On Tue, Jul 04, 2006 at 09:48:32AM +0800, Wen-Cheng Wang wrote:
>> In my opinion, in approach (1), the certificate for the CRL issuer
>> should contain a CRLDP that points to the special CRL
>> that covers only that one certificate. In addition, the special CRL
>> should contain an IDP that matches the CRLDP in the certificate.
> 
> Wen-Cheng,
> 
> wouldn't that leave us with two (delegated) CRL issuers for the CA ?
> And then how to revoke the second delegated CRL issuer ? :)
> 
> Regards,
> 
> --
> Julien
> 
>> Wen-Cheng Wang
>> 
>> ----- Original Message ----- 
>> From: "Kemp David P." <[email-masked]>
>> To: "Julien Stern" <[email-masked]>; <[email-masked]>
>> Sent: Tuesday, July 04, 2006 3:45 AM
>> Subject: RE: Question about indirect CRLs (and designated OCSP responders)
>> 
>> 
>> >
>> >
>> >Julien,
>> >
>> >There is a logical fallacy in your supposition which leads to
>> >the problem you describe.  If the CA wishes to retain the
>> >authority for deciding whether the CRL issuer is reliable, it
>> >cannot delegate that authority to the CRL issuer.
>> >
>> >The CA could use at least two approaches to avoid the problem:
>> >
>> >1) produce a certificate for the CRL issuer that does not
>> >contain a CRLDP, and produce a CRL that covers only that one
>> >certificate (and would therefore nearly always be empty).
>> >
>> >2) produce a certificate for the CRL issuer with a very
>> >short validity period, refreshing the certificate for as
>> >long as the CRL issuer remains reliable, and rekeying it
>> >occasionally.
>> >
>> >Any approach must begin with a goal to be accomplished,
>> >and then derive from that goal the syntax used to implement
>> >it.  Garbage goals in, garbage certificates out.
>> >
>> >
>> >
>> >-----Original Message-----
>> >From: [email-masked] [mailto:[email-masked]]
>> >On Behalf Of Julien Stern
>> >Sent: Monday, July 03, 2006 1:43 PM
>> >To: [email-masked]
>> >Subject: Question about indirect CRLs (and designated OCSP responders)
>> >
>> >
>> >Folks,
>> >
>> >I have a question regarding the treatment of Indirect CRLs in the
>> >following case:
>> >
>> >Suppose that I have:
>> >- one CA (that does NOT produce CRLs)
>> >- one CRL issuer (that produces CRLs on behalf of that CA)
>> >
>> >Every certificate emitted by this CA contains the CRLDP extension
>> >indicating who is the CRL issuer.
>> >
>> >Now, also suppose that the CRL issuer certificate is emitted by the CA,
>> >which can be useful in order to bring trust to this certificate.
>> >
>> >It then seems that the CRL issuer can revoke its own certificate.
>> >What should be the treatment in this setting if the serial number
>> >of the certificate of the CRL issuer appears in the CRL?
>> >
>> >Additionally, if the CRL issuer is compromised, the CA could issue
>> >a new CRL issuer certificate, and the new CRL issuer could revoke
>> >the certificate of the previous CRL issuer. But then what to do if the
>> >old compromised CRL also revokes the new CRL issuer certificate?
>> >It this setting simply not allowed for CRLs? If not, by what?
>> >
>> >
>> >Also, I have exactly the same question regarding OCSP in the case
>> >of a "CA Designated Responder" (RFC2560, page 2). This setting is
>> >exactly the same as described above.
>> >
>> >What happens if the OCSP responder responds that its own certificate is
>> >revoked?
>> >
>> >What happens if I am presented (say in a long time archive) with two
>> >OCSP replies, each containing a "CA Designated Responder" certificate
>> >which revokes the other one?
>> >
>> >
>> >Regards,
>> >
>> >--
>> >Julien Stern
>> >
>> >
>> >
>> 
>

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 10:44:48 +0200
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Jul 04, 2006 at 09:48:32AM +0800, Wen-Cheng Wang wrote:
> In my opinion, in approach (1), the certificate for the CRL issuer
> should contain a CRLDP that points to the special CRL
> that covers only that one certificate. In addition, the special CRL
> should contain an IDP that matches the CRLDP in the certificate.

Wen-Cheng,

wouldn't that leave us with two (delegated) CRL issuers for the CA ?
And then how to revoke the second delegated CRL issuer ? :)

Regards,

--
Julien

> Wen-Cheng Wang
> 
> ----- Original Message ----- 
> From: "Kemp David P." <[email-masked]>
> To: "Julien Stern" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 04, 2006 3:45 AM
> Subject: RE: Question about indirect CRLs (and designated OCSP responders)
> 
> 
> >
> >
> >Julien,
> >
> >There is a logical fallacy in your supposition which leads to
> >the problem you describe.  If the CA wishes to retain the
> >authority for deciding whether the CRL issuer is reliable, it
> >cannot delegate that authority to the CRL issuer.
> >
> >The CA could use at least two approaches to avoid the problem:
> >
> >1) produce a certificate for the CRL issuer that does not
> >contain a CRLDP, and produce a CRL that covers only that one
> >certificate (and would therefore nearly always be empty).
> >
> >2) produce a certificate for the CRL issuer with a very
> >short validity period, refreshing the certificate for as
> >long as the CRL issuer remains reliable, and rekeying it
> >occasionally.
> >
> >Any approach must begin with a goal to be accomplished,
> >and then derive from that goal the syntax used to implement
> >it.  Garbage goals in, garbage certificates out.
> >
> >
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> >On Behalf Of Julien Stern
> >Sent: Monday, July 03, 2006 1:43 PM
> >To: [email-masked]
> >Subject: Question about indirect CRLs (and designated OCSP responders)
> >
> >
> >Folks,
> >
> >I have a question regarding the treatment of Indirect CRLs in the
> >following case:
> >
> >Suppose that I have:
> >- one CA (that does NOT produce CRLs)
> >- one CRL issuer (that produces CRLs on behalf of that CA)
> >
> >Every certificate emitted by this CA contains the CRLDP extension
> >indicating who is the CRL issuer.
> >
> >Now, also suppose that the CRL issuer certificate is emitted by the CA,
> >which can be useful in order to bring trust to this certificate.
> >
> >It then seems that the CRL issuer can revoke its own certificate.
> >What should be the treatment in this setting if the serial number
> >of the certificate of the CRL issuer appears in the CRL?
> >
> >Additionally, if the CRL issuer is compromised, the CA could issue
> >a new CRL issuer certificate, and the new CRL issuer could revoke
> >the certificate of the previous CRL issuer. But then what to do if the
> >old compromised CRL also revokes the new CRL issuer certificate?
> >It this setting simply not allowed for CRLs? If not, by what?
> >
> >
> >Also, I have exactly the same question regarding OCSP in the case
> >of a "CA Designated Responder" (RFC2560, page 2). This setting is
> >exactly the same as described above.
> >
> >What happens if the OCSP responder responds that its own certificate is
> >revoked?
> >
> >What happens if I am presented (say in a long time archive) with two
> >OCSP replies, each containing a "CA Designated Responder" certificate
> >which revokes the other one?
> >
> >
> >Regards,
> >
> >--
> >Julien Stern
> >
> >
> >
> 

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 10:36:12 +0200
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

David,

thank you for your reply.
I did felt that my scenario was "broken" in some sense.

However, this seem to imply that at the top-level, one needs a Trust
Anchor that does NOT delegate CRL production (at least if you always
want to be able to revoke everything but the TA).

A TA private key should typically be very complex to access and
manipulate for obvious security reasons, but now it should also produce
CRLs regularly, which can be a bit impractical...

Regards,

--
Julien

On Mon, Jul 03, 2006 at 03:45:19PM -0400, Kemp David P. wrote:
> 
> Julien,
> 
> There is a logical fallacy in your supposition which leads to
> the problem you describe.  If the CA wishes to retain the
> authority for deciding whether the CRL issuer is reliable, it
> cannot delegate that authority to the CRL issuer.
> 
> The CA could use at least two approaches to avoid the problem:
> 
> 1) produce a certificate for the CRL issuer that does not
> contain a CRLDP, and produce a CRL that covers only that one
> certificate (and would therefore nearly always be empty).
> 
> 2) produce a certificate for the CRL issuer with a very
> short validity period, refreshing the certificate for as
> long as the CRL issuer remains reliable, and rekeying it
> occasionally.
> 
> Any approach must begin with a goal to be accomplished,
> and then derive from that goal the syntax used to implement
> it.  Garbage goals in, garbage certificates out.
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Julien Stern
> Sent: Monday, July 03, 2006 1:43 PM
> To: [email-masked]
> Subject: Question about indirect CRLs (and designated OCSP responders)
> 
> 
> Folks,
> 
> I have a question regarding the treatment of Indirect CRLs in the
> following case:
> 
> Suppose that I have:
> - one CA (that does NOT produce CRLs)
> - one CRL issuer (that produces CRLs on behalf of that CA)
>  
> Every certificate emitted by this CA contains the CRLDP extension
> indicating who is the CRL issuer.
> 
> Now, also suppose that the CRL issuer certificate is emitted by the CA,
> which can be useful in order to bring trust to this certificate.
> 
> It then seems that the CRL issuer can revoke its own certificate.
> What should be the treatment in this setting if the serial number
> of the certificate of the CRL issuer appears in the CRL?
> 
> Additionally, if the CRL issuer is compromised, the CA could issue
> a new CRL issuer certificate, and the new CRL issuer could revoke
> the certificate of the previous CRL issuer. But then what to do if the
> old compromised CRL also revokes the new CRL issuer certificate?
> It this setting simply not allowed for CRLs? If not, by what?
> 
> 
> Also, I have exactly the same question regarding OCSP in the case
> of a "CA Designated Responder" (RFC2560, page 2). This setting is
> exactly the same as described above.
> 
> What happens if the OCSP responder responds that its own certificate is
> revoked?
> 
> What happens if I am presented (say in a long time archive) with two
> OCSP replies, each containing a "CA Designated Responder" certificate
> which revokes the other one?
> 
> 
> Regards,
> 
> --
> Julien Stern
> 

Date: Tue, 4 Jul 2006 10:18:59 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Sender: [email-masked]

I am glad that this problem was raised again.

>In my opinion, in approach (1), the certificate for the CRL issuer
>should contain a CRLDP that points to the special CRL
>that covers only that one certificate. In addition, the special CRL
>should contain an IDP that matches the CRLDP in the certificate.

This is fine. The current draft is currently missing guidance to handle that case.
Additional text, should be provided so that implementations can really 
support *in an interoperable way* the case where the CA is not handling 
revocation status information for all the certificates it issues.

Denis

>Wen-Cheng Wang
>
>----- Original Message ----- 
>From: "Kemp David P." <[email-masked]>
>To: "Julien Stern" <[email-masked]>; <[email-masked]>
>Sent: Tuesday, July 04, 2006 3:45 AM
>Subject: RE: Question about indirect CRLs (and designated OCSP responders)
>
>
>> 
>> 
>> Julien,
>> 
>> There is a logical fallacy in your supposition which leads to
>> the problem you describe.  If the CA wishes to retain the
>> authority for deciding whether the CRL issuer is reliable, it
>> cannot delegate that authority to the CRL issuer.
>> 
>> The CA could use at least two approaches to avoid the problem:
>> 
>> 1) produce a certificate for the CRL issuer that does not
>> contain a CRLDP, and produce a CRL that covers only that one
>> certificate (and would therefore nearly always be empty).
>> 
>> 2) produce a certificate for the CRL issuer with a very
>> short validity period, refreshing the certificate for as
>> long as the CRL issuer remains reliable, and rekeying it
>> occasionally.
>> 
>> Any approach must begin with a goal to be accomplished,
>> and then derive from that goal the syntax used to implement
>> it.  Garbage goals in, garbage certificates out.
>> 
>> 
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Julien Stern
>> Sent: Monday, July 03, 2006 1:43 PM
>> To: [email-masked]
>> Subject: Question about indirect CRLs (and designated OCSP responders)
>> 
>> 
>> Folks,
>> 
>> I have a question regarding the treatment of Indirect CRLs in the
>> following case:
>> 
>> Suppose that I have:
>> - one CA (that does NOT produce CRLs)
>> - one CRL issuer (that produces CRLs on behalf of that CA)
>> 
>> Every certificate emitted by this CA contains the CRLDP extension
>> indicating who is the CRL issuer.
>> 
>> Now, also suppose that the CRL issuer certificate is emitted by the CA,
>> which can be useful in order to bring trust to this certificate.
>> 
>> It then seems that the CRL issuer can revoke its own certificate.
>> What should be the treatment in this setting if the serial number
>> of the certificate of the CRL issuer appears in the CRL?
>> 
>> Additionally, if the CRL issuer is compromised, the CA could issue
>> a new CRL issuer certificate, and the new CRL issuer could revoke
>> the certificate of the previous CRL issuer. But then what to do if the
>> old compromised CRL also revokes the new CRL issuer certificate?
>> It this setting simply not allowed for CRLs? If not, by what?
>> 
>> 
>> Also, I have exactly the same question regarding OCSP in the case
>> of a "CA Designated Responder" (RFC2560, page 2). This setting is
>> exactly the same as described above.
>> 
>> What happens if the OCSP responder responds that its own certificate is
>> revoked?
>> 
>> What happens if I am presented (say in a long time archive) with two
>> OCSP replies, each containing a "CA Designated Responder" certificate
>> which revokes the other one?
>> 
>> 
>> Regards,
>> 
>> --
>> Julien Stern
>> 
>> 
>>
>
>

Regards,

Denis Pinkas

From: "Wen-Cheng Wang" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Brad Hards" <[email-masked]>, "Sharon Boeyen" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: last call for 3280bis - escape clause
Date: Tue, 4 Jul 2006 11:24:03 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

How about move the "escape clause" into the "security consideration" section.
The purpose is to warn relying parties of the risk of skipping any check in
the certificate path validation. The text might look like the following:

Some implementations (such as some IPsec products or future versions of
Microsoft Windows ;-) )of the certification path validation algorithm might
provide configuration options to disable checks required by this specification
in order to adapt to the existing/legacy PKI environment (e.g., one that consists
of non-compliant CA implementations). However, all checks on certificates exist
for a specific reason involving the security of the entire system. Therefore, all
checks MUST be enabled by default. Administrators and users ought to
understand the security purpose for the various checks, and be clear on what
security will be lost by disabling the check.

(Most parts of the text are excerpted from the pki4ipsec profile.)

Wen-Cheng Wang

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: "Brad Hards" <[email-masked]>; "Sharon Boeyen" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, June 24, 2006 8:09 PM
Subject: RE: last call for 3280bis - escape clause

> 
> Personally I feel positive about such initiative even though I fear the
> volume of debates it might cause. I would like to hear the rest of the
> WG on this.
> 
> I do acknowledge that we are facing practical problems out there that
> the standard can't solve today.
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Brad Hards
> Sent: den 23 juni 2006 14:03
> To: Sharon Boeyen
> Cc: [email-masked]
> Subject: Re: last call for 3280bis - escape clause
> 
> On Friday 23 June 2006 21:12 pm, Sharon Boeyen wrote:
>> There should not be any escape clause in 3280bis for any
> non-conformant
>> behavior. 3280bis is a profile of X.509 - it is not a narrative to
> describe
>> various types of non-conformant behavior, regardless of what it is.
> Perhaps there might be a role for an Informational RFC that explains the
> 
> various issues that are a source of concern. Ideally it would provide
> some 
> guidance on how to deal with the non-conformant behaviour. At the very
> least 
> it could explain the consequences of particular courses of action.
> 
> Brad
>

From: "Wen-Cheng Wang" <[email-masked]>
To: "Kemp David P." <[email-masked]>, "Julien Stern" <[email-masked]>, <[email-masked]>
Subject: Re: Question about indirect CRLs (and designated OCSP responders)
Date: Tue, 4 Jul 2006 09:48:32 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

In my opinion, in approach (1), the certificate for the CRL issuer
should contain a CRLDP that points to the special CRL
that covers only that one certificate. In addition, the special CRL
should contain an IDP that matches the CRLDP in the certificate.

Wen-Cheng Wang

----- Original Message ----- 
From: "Kemp David P." <[email-masked]>
To: "Julien Stern" <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 04, 2006 3:45 AM
Subject: RE: Question about indirect CRLs (and designated OCSP responders)

> 
> 
> Julien,
> 
> There is a logical fallacy in your supposition which leads to
> the problem you describe.  If the CA wishes to retain the
> authority for deciding whether the CRL issuer is reliable, it
> cannot delegate that authority to the CRL issuer.
> 
> The CA could use at least two approaches to avoid the problem:
> 
> 1) produce a certificate for the CRL issuer that does not
> contain a CRLDP, and produce a CRL that covers only that one
> certificate (and would therefore nearly always be empty).
> 
> 2) produce a certificate for the CRL issuer with a very
> short validity period, refreshing the certificate for as
> long as the CRL issuer remains reliable, and rekeying it
> occasionally.
> 
> Any approach must begin with a goal to be accomplished,
> and then derive from that goal the syntax used to implement
> it.  Garbage goals in, garbage certificates out.
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Julien Stern
> Sent: Monday, July 03, 2006 1:43 PM
> To: [email-masked]
> Subject: Question about indirect CRLs (and designated OCSP responders)
> 
> 
> Folks,
> 
> I have a question regarding the treatment of Indirect CRLs in the
> following case:
> 
> Suppose that I have:
> - one CA (that does NOT produce CRLs)
> - one CRL issuer (that produces CRLs on behalf of that CA)
> 
> Every certificate emitted by this CA contains the CRLDP extension
> indicating who is the CRL issuer.
> 
> Now, also suppose that the CRL issuer certificate is emitted by the CA,
> which can be useful in order to bring trust to this certificate.
> 
> It then seems that the CRL issuer can revoke its own certificate.
> What should be the treatment in this setting if the serial number
> of the certificate of the CRL issuer appears in the CRL?
> 
> Additionally, if the CRL issuer is compromised, the CA could issue
> a new CRL issuer certificate, and the new CRL issuer could revoke
> the certificate of the previous CRL issuer. But then what to do if the
> old compromised CRL also revokes the new CRL issuer certificate?
> It this setting simply not allowed for CRLs? If not, by what?
> 
> 
> Also, I have exactly the same question regarding OCSP in the case
> of a "CA Designated Responder" (RFC2560, page 2). This setting is
> exactly the same as described above.
> 
> What happens if the OCSP responder responds that its own certificate is
> revoked?
> 
> What happens if I am presented (say in a long time archive) with two
> OCSP replies, each containing a "CA Designated Responder" certificate
> which revokes the other one?
> 
> 
> Regards,
> 
> --
> Julien Stern
> 
> 
>

Content-class: urn:content-classes:message
Subject: RE: Question about indirect CRLs (and designated OCSP responders)
Date: Mon, 3 Jul 2006 16:00:18 -0400
From: "Dave Engberg" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Re: OCSP delegation & revocation ...

Revocation of a delegated responder cert is an underspecified area.  From
what I've seen in various OCSP relying party software, you won't get
consistent behavior unless you put in the id-pkix-ocsp-nocheck extension
into your responder's cert.

In that case, revocation won't be checked, and the responder's cert should
be appropriately short lived (e.g. a week or a month) so it will expire on a
similar timeline as the equivalent CRL.  There's no technical reason why the
responder certs couldn't be extremely short lived (e.g. one day), although
this would require you to do a little work at your CA to automate the
reissuance.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Monday, July 03, 2006 1:43 PM
To: [email-masked]
Subject: Question about indirect CRLs (and designated OCSP responders)

Folks,

I have a question regarding the treatment of Indirect CRLs in the following
case:

Suppose that I have:
- one CA (that does NOT produce CRLs)
- one CRL issuer (that produces CRLs on behalf of that CA)
 
Every certificate emitted by this CA contains the CRLDP extension indicating
who is the CRL issuer.

Now, also suppose that the CRL issuer certificate is emitted by the CA,
which can be useful in order to bring trust to this certificate.

It then seems that the CRL issuer can revoke its own certificate.
What should be the treatment in this setting if the serial number of the
certificate of the CRL issuer appears in the CRL?

Additionally, if the CRL issuer is compromised, the CA could issue a new CRL
issuer certificate, and the new CRL issuer could revoke the certificate of
the previous CRL issuer. But then what to do if the old compromised CRL also
revokes the new CRL issuer certificate?
It this setting simply not allowed for CRLs? If not, by what?

Also, I have exactly the same question regarding OCSP in the case of a "CA
Designated Responder" (RFC2560, page 2). This setting is exactly the same as
described above.

What happens if the OCSP responder responds that its own certificate is
revoked?

What happens if I am presented (say in a long time archive) with two OCSP
replies, each containing a "CA Designated Responder" certificate which
revokes the other one?

Regards,

--
Julien Stern

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

------=_NextPart_000_023A_01C69EB9.C78999E0--

Content-class: urn:content-classes:message
Subject: RE: Question about indirect CRLs (and designated OCSP responders)
Date: Mon, 3 Jul 2006 15:45:19 -0400
From: "Kemp David P." <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Julien,

There is a logical fallacy in your supposition which leads to
the problem you describe.  If the CA wishes to retain the
authority for deciding whether the CRL issuer is reliable, it
cannot delegate that authority to the CRL issuer.

The CA could use at least two approaches to avoid the problem:

1) produce a certificate for the CRL issuer that does not
contain a CRLDP, and produce a CRL that covers only that one
certificate (and would therefore nearly always be empty).

2) produce a certificate for the CRL issuer with a very
short validity period, refreshing the certificate for as
long as the CRL issuer remains reliable, and rekeying it
occasionally.

Any approach must begin with a goal to be accomplished,
and then derive from that goal the syntax used to implement
it.  Garbage goals in, garbage certificates out.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Stern
Sent: Monday, July 03, 2006 1:43 PM
To: [email-masked]
Subject: Question about indirect CRLs (and designated OCSP responders)

Folks,

I have a question regarding the treatment of Indirect CRLs in the
following case:

Suppose that I have:
- one CA (that does NOT produce CRLs)
- one CRL issuer (that produces CRLs on behalf of that CA)
 
Every certificate emitted by this CA contains the CRLDP extension
indicating who is the CRL issuer.

Now, also suppose that the CRL issuer certificate is emitted by the CA,
which can be useful in order to bring trust to this certificate.

It then seems that the CRL issuer can revoke its own certificate.
What should be the treatment in this setting if the serial number
of the certificate of the CRL issuer appears in the CRL?

Additionally, if the CRL issuer is compromised, the CA could issue
a new CRL issuer certificate, and the new CRL issuer could revoke
the certificate of the previous CRL issuer. But then what to do if the
old compromised CRL also revokes the new CRL issuer certificate?
It this setting simply not allowed for CRLs? If not, by what?

Also, I have exactly the same question regarding OCSP in the case
of a "CA Designated Responder" (RFC2560, page 2). This setting is
exactly the same as described above.

What happens if the OCSP responder responds that its own certificate is
revoked?

What happens if I am presented (say in a long time archive) with two
OCSP replies, each containing a "CA Designated Responder" certificate
which revokes the other one?

Regards,

--
Julien Stern

From: "Julien Stern" <[email-masked]>
Date: Mon, 3 Jul 2006 19:43:11 +0200
To: [email-masked]
Subject: Question about indirect CRLs (and designated OCSP responders)
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

Folks,

I have a question regarding the treatment of Indirect CRLs in the
following case:

Suppose that I have:
- one CA (that does NOT produce CRLs)
- one CRL issuer (that produces CRLs on behalf of that CA)
 
Every certificate emitted by this CA contains the CRLDP extension
indicating who is the CRL issuer.

Now, also suppose that the CRL issuer certificate is emitted by the CA,
which can be useful in order to bring trust to this certificate.

It then seems that the CRL issuer can revoke its own certificate.
What should be the treatment in this setting if the serial number
of the certificate of the CRL issuer appears in the CRL?

Additionally, if the CRL issuer is compromised, the CA could issue
a new CRL issuer certificate, and the new CRL issuer could revoke
the certificate of the previous CRL issuer. But then what to do if the
old compromised CRL also revokes the new CRL issuer certificate?
It this setting simply not allowed for CRLs? If not, by what?

Also, I have exactly the same question regarding OCSP in the case
of a "CA Designated Responder" (RFC2560, page 2). This setting is
exactly the same as described above.

What happens if the OCSP responder responds that its own certificate is
revoked?

What happens if I am presented (say in a long time archive) with two
OCSP replies, each containing a "CA Designated Responder" certificate
which revokes the other one?

Regards,

--
Julien Stern