Request to review draft-adamson-rfc2847-bis
Sam Hartman <hartmans-ietf@mit.edu> Sat, 29 July 2006 21:40 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6wYI-0003a5-LK for pkix-archive@lists.ietf.org; Sat, 29 Jul 2006 17:40:55 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6wYH-0002Pj-AZ for pkix-archive@lists.ietf.org; Sat, 29 Jul 2006 17:40:54 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6TKeIku036927; Sat, 29 Jul 2006 13:40:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6TKeIeL036926; Sat, 29 Jul 2006 13:40:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6TKeFpT036915 for <ietf-pkix@imc.org>; Sat, 29 Jul 2006 13:40:17 -0700 (MST) (envelope-from hartmans@mit.edu)
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B41D0E007D; Sat, 29 Jul 2006 16:40:57 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: kitten@ietf.org, ietf-pkix@imc.org
Subject: Request to review draft-adamson-rfc2847-bis
Date: Sat, 29 Jul 2006 16:40:57 -0400
Message-ID: <tslodv8m9eu.fsf@cz.mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
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 Received: from avigenics.com (host47-154.pool8259.interbusiness.it [82.59.154.47]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6VICMGl057339 for <ietf-pkix-archive@imc.org>; Mon, 31 Jul 2006 11:12:25 -0700 (MST) (envelope-from tiphanie@avigenics.com) Message-ID: <000001c6b4cc$65d7b000$c4b8a8c0@qaf17> Reply-To: "Tiphanie Worsley" <tiphanie@avigenics.com> From: "Tiphanie Worsley" <tiphanie@avigenics.com> To: ietf-pkix-archive@imc.org Subject: Re: mulupVijagra Date: Mon, 31 Jul 2006 11:09:00 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B491.B97B4900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> </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> </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> </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-- Received: from simon-3mykhxmj5 (c-67-165-19-23.hsd1.ct.comcast.net [67.165.19.23]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6UBJCZa097236; Sun, 30 Jul 2006 04:19:12 -0700 (MST) (envelope-from support@paypal.com) Received: from User ([12.214.18.142]) by simon-3mykhxmj5 with Microsoft SMTPSVC(5.0.2195.6713); Sun, 30 Jul 2006 07:24:26 -0400 Reply-To: <no-replay@paypal.com> From: "support@paypal.com"<support@paypal.com> Subject: PayPal - Notice : Restore Your Account Date: Sun, 30 Jul 2006 06:26:54 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Bcc: Message-ID: <SIMON-3MYKHXMJ5WHJV00000284@simon-3mykhxmj5> X-OriginalArrivalTime: 30 Jul 2006 11:24:26.0860 (UTC) FILETIME=[B76A4AC0:01C6B3CA] <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> <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> <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"> </span> <p style="margin-top:0; margin-bottom:0;"><span class="emphasis"> <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> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6TKeIku036927; Sat, 29 Jul 2006 13:40:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6TKeIeL036926; Sat, 29 Jul 2006 13:40:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6TKeFpT036915 for <ietf-pkix@imc.org>; Sat, 29 Jul 2006 13:40:17 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B41D0E007D; Sat, 29 Jul 2006 16:40:57 -0400 (EDT) From: Sam Hartman <hartmans-ietf@mit.edu> To: kitten@ietf.org, ietf-pkix@imc.org Subject: Request to review draft-adamson-rfc2847-bis Date: Sat, 29 Jul 2006 16:40:57 -0400 Message-ID: <tslodv8m9eu.fsf@cz.mit.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from brasfieldgorrie.com (pD9FFBC58.dip0.t-ipconnect.de [217.255.188.88]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6TJTcdx023456 for <ietf-pkix-archive@imc.org>; Sat, 29 Jul 2006 12:29:39 -0700 (MST) (envelope-from sawylboaz@brasfieldgorrie.com) Message-ID: <000001c6b344$daa3be30$7ef0a8c0@nqg56> Reply-To: "Sawyl Boaz" <sawylboaz@brasfieldgorrie.com> From: "Sawyl Boaz" <sawylboaz@brasfieldgorrie.com> To: ietf-pkix-archive@imc.org Subject: Re: wagiiVIAjAGRA Date: Sat, 29 Jul 2006 12:26:13 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B30A.2E44E630" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> </DIV> <DIV><DIV>CIAjALIS $3 . 75</DIV> <DIV>VIAjAGRA $3 . 35</DIV> <DIV>AMjMBIEN</DIV> <DIV>VALjLIUM $1 . 25</DIV> </DIV> <DIV> </DIV> <DIV><A = href=3D"http://www.forismone.com">http://www.forismone.com</A></DIV> <DIV> </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-- Received: from esmeraldainc.com (dsl-TN-163.93.246.61.touchtelindia.net [61.246.93.163] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6T8bZcc091328 for <ietf-pkix-archive@imc.org>; Sat, 29 Jul 2006 01:37:38 -0700 (MST) (envelope-from norinaerydber@esmeraldainc.com) Message-ID: <000001c6b2e9$bef10b30$3baca8c0@apw25> Reply-To: "Norina Rydberg" <norinaerydber@esmeraldainc.com> From: "Norina Rydberg" <norinaerydber@esmeraldainc.com> To: ietf-pkix-archive@imc.org Subject: Re: nokyqVljIAGRA Date: Sat, 29 Jul 2006 01:34:02 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B2AF.12923330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> </DIV> <DIV>VljlAGRA from 3 , 35<BR>VALIjlUM from 1 , 25<BR>CIALIjlS from 3 , = 75<BR>AMBljIEN</DIV> <DIV> </DIV> <DIV><A = href=3D"http://www.haltimbere.com">http://www.haltimbere.com</A></DIV> <DIV> </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-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6QMWJlj061136; Wed, 26 Jul 2006 15:32:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6QMWJU4061135; Wed, 26 Jul 2006 15:32:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay3.mail.uk.clara.net (relay3.mail.uk.clara.net [80.168.70.143]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6QMWGx6061128 for <ietf-pkix@imc.org>; Wed, 26 Jul 2006 15:32:19 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from [149.254.200.215] (helo=[10.33.187.22]) by relay3.mail.uk.clara.net with esmtpa (Exim 4.46) id 1G5rvK-0008Xw-Ff for ietf-pkix@imc.org; Wed, 26 Jul 2006 23:32:15 +0100 Message-ID: <44C7ED67.2000606@drh-consultancy.demon.co.uk> Date: Wed, 26 Jul 2006 23:32:07 +0100 From: Dr Stephen Henson <lists@drh-consultancy.demon.co.uk> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix <ietf-pkix@imc.org> Subject: Re: 3280bis-04.txt: Empty ASN.1 Sequences References: <001a01c6ac00$45d62f40$0301a8c0@Wylie> <44C666E7.5000700@nist.gov> In-Reply-To: <44C666E7.5000700@nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6QLnjLj052460; Wed, 26 Jul 2006 14:49:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6QLnjov052459; Wed, 26 Jul 2006 14:49:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6QLninG052437 for <ietf-pkix@imc.org>; Wed, 26 Jul 2006 14:49:44 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 35657 invoked from network); 26 Jul 2006 21:49:38 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.17.126.51 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 26 Jul 2006 21:49:38 -0000 Reply-To: <turners@ieca.com> From: "Turner, Sean P." <turners@ieca.com> To: "'David A. Cooper'" <david.cooper@nist.gov> Cc: "'pkix'" <ietf-pkix@imc.org> Subject: RE: 3280bis-04.txt: Empty ASN.1 Sequences Date: Wed, 26 Jul 2006 17:49:04 -0400 Organization: IECA, Inc. Message-ID: <005001c6b0fd$505107e0$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44C666E7.5000700@nist.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawIN/90ndiTobpTeSWasCUM/2DCwA3GsDQ Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I'd be happy if you made the changes to nameConstraints and issuingDistributionPoint extensions. spt -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 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 Received: from aldercreek.com (83stb63.codetel.net.do [66.98.13.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6Q4k6Tv038985 for <ietf-pkix-archive@imc.org>; Tue, 25 Jul 2006 21:46:11 -0700 (MST) (envelope-from ansheli@ebps.net) Message-ID: <000001c6b06d$e9c0d350$2782a8c0@jll60> Reply-To: "Anshel Hoelscher" <ansheli@ebps.net> From: "Anshel Hoelscher" <ansheli@ebps.net> To: ietf-pkix-archive@imc.org Subject: to iexag Date: Tue, 25 Jul 2006 21:42:34 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B033.3D61FB50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Antivirus: avast! (VPS 0630-1, 07/24/2006), Outbound message X-Antivirus-Status: Clean 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> </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> </P> <P> </P> <P> </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-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PJexoa058455; Tue, 25 Jul 2006 12:40:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PJexEA058454; Tue, 25 Jul 2006 12:40:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PJewMo058422 for <ietf-pkix@imc.org>; Tue, 25 Jul 2006 12:40:59 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-37.fastq.com [65.39.92.37]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id k6PJeoN85251; Tue, 25 Jul 2006 12:40:51 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "David A. Cooper" <david.cooper@nist.gov>, "Turner, Sean P." <turners@ieca.com> Cc: "pkix" <ietf-pkix@imc.org> Subject: RE: 3280bis-04.txt: Empty ASN.1 Sequences Date: Tue, 25 Jul 2006 12:39:45 -0800 Message-ID: <CCEJKFKLBCNMONJMIEAMIELPCCAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal In-Reply-To: <44C666E7.5000700@nist.gov> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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? Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PIkqRd043399; Tue, 25 Jul 2006 11:46:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6PIkqSI043398; Tue, 25 Jul 2006 11:46:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6PIknlR043391 for <ietf-pkix@imc.org>; Tue, 25 Jul 2006 11:46:51 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6PIkTSD019601; Tue, 25 Jul 2006 14:46:30 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k6PIjuLb023625; Tue, 25 Jul 2006 14:46:01 -0400 (EDT) Message-ID: <44C666E7.5000700@nist.gov> Date: Tue, 25 Jul 2006 14:45:59 -0400 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Turner, Sean P." <turners@ieca.com> CC: pkix <ietf-pkix@imc.org> Subject: Re: 3280bis-04.txt: Empty ASN.1 Sequences References: <001a01c6ac00$45d62f40$0301a8c0@Wylie> In-Reply-To: <001a01c6ac00$45d62f40$0301a8c0@Wylie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from brevardsheriffsoffice.org (ALille-152-1-65-220.w83-198.abo.wanadoo.fr [83.198.255.220]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6NMgafB003183 for <ietf-pkix-archive@imc.org>; Sun, 23 Jul 2006 15:42:47 -0700 (MST) (envelope-from keeleagunill@aricharris.com) Message-ID: <000001c6aea9$53f85ed0$aa77a8c0@lru49> Reply-To: "Gunilla Keeley" <keeleagunill@aricharris.com> From: "Gunilla Keeley" <keeleagunill@aricharris.com> To: ietf-pkix-archive@imc.org Subject: Re: yijim VljAGRA Date: Sun, 23 Jul 2006 15:42:50 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6AE6E.A79BF7D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> </DIV> <DIV>VljAGRA from 3 , 33 $</DIV> <DIV> </DIV> <A href=3D"http://www.tecenuras.com">http://www.tecenuras.com</A></DIV> <DIV> </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-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6NLboKO083265; Sun, 23 Jul 2006 14:37:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6NLbo8d083264; Sun, 23 Jul 2006 14:37:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6NLblK2083237 for <ietf-pkix@imc.org>; Sun, 23 Jul 2006 14:37:50 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AEA0.DCE86EA3" Subject: RE: End entity validity date nesting Date: Sun, 23 Jul 2006 14:42:15 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87903D0EA19@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: End entity validity date nesting Thread-Index: AcauoCMudFzyqQ85R32+7BMvDsdygg== From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Cc: "Peter Alterman \(E-mail\)" <altermap@mail.nih.gov> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org=20 [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Price, Bill=20 Sent: Wednesday, July 19, 2006 10:51 AM=20 To: Stephen Kent; Ogle Ron=20 Cc: ietf-pkix@imc.org=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: owner-ietf-pkix@mail.imc.org=20 [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent=20 Sent: Tuesday, July 18, 2006 5:49 PM=20 To: Ogle Ron=20 Cc: ietf-pkix@imc.org=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 it is difficult to enforce (and there no reason to) nested validity periods. 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. 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.<o:p></o:p></span></font></p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'>From: owner-ietf-pkix@mail.imc.org</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>[<a href=3D"mailto:owner-ietf-pkix@mail.imc.org" title=3D"mailto:owner-ietf-pkix@mail.imc.org">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: = ietf-pkix@imc.org</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> </o:p></span></font></p> <p><font size=3D2 face=3D"Times New Roman"><span = style=3D'font-size:10.0pt'> 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: = owner-ietf-pkix@mail.imc.org</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>[<a href=3D"mailto:owner-ietf-pkix@mail.imc.org" title=3D"mailto:owner-ietf-pkix@mail.imc.org">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: = ietf-pkix@imc.org</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> </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'>>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'>>whose entire = lifetime falls within the CA's lifetime? I have googled</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>>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'>>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'>></span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>>BTW, it does make = logical sense to me to do this. 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'>>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'>>over the = CA?</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>></span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>>Thanks in = advance</span></font> <br> <font size=3D2><span style=3D'font-size:10.0pt'>>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. 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> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C6AEA0.DCE86EA3-- Received: from gallop.com (abex60.neoplus.adsl.tpnet.pl [83.7.35.60]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6N8jgmt041587 for <ietf-pkix-archive@imc.org>; Sun, 23 Jul 2006 01:45:43 -0700 (MST) (envelope-from hadiybach@gallop.com) Message-ID: <000001c6ae34$69084580$47c5a8c0@nhc81> Reply-To: "Hadiya Bachelder" <hadiybach@gallop.com> From: "Hadiya Bachelder" <hadiybach@gallop.com> To: ietf-pkix-archive@imc.org Subject: Re: bunie VlzAGRA Date: Sun, 23 Jul 2006 01:45:55 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6ADF9.BCA96D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> </DIV> <DIV>VlzAGRA 3 , 33 $</DIV> <DIV> </DIV> <A = href=3D"http://www.xinfadesatin.com">http://www.xinfadesatin.com</A></DIV= > <DIV> </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-- Received: from cpgusa.com (p54B2AE30.dip0.t-ipconnect.de [84.178.174.48]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6MKWPWT084720 for <ietf-pkix-archive@imc.org>; Sat, 22 Jul 2006 13:32:30 -0700 (MST) (envelope-from lorangeulorcc@loomissayles.com) Message-ID: <000001c6adcd$f4dd90e0$2db0a8c0@iuq84> Reply-To: "Lorcca Loranger" <lorangeulorcc@loomissayles.com> From: "Lorcca Loranger" <lorangeulorcc@loomissayles.com> To: ietf-pkix-archive@imc.org Subject: to cocuj Date: Sat, 22 Jul 2006 13:32:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6AD93.487EB8E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> </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> </P> <P> </P> <P> </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-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6LJLO9q093082; Fri, 21 Jul 2006 12:21:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6LJLOk7093081; Fri, 21 Jul 2006 12:21:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from datnt07.tieto.com (mail1.tieto.com [194.110.47.24]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6LJLMaU093058 for <ietf-pkix@imc.org>; Fri, 21 Jul 2006 12:21:23 -0700 (MST) (envelope-from iesg-secretary@ietf.org) Received: from viper.eu.tieto.com ([194.110.47.167]) by datnt07.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Jul 2006 22:20:47 +0300 Received: from mail pickup service by viper.eu.tieto.com with Microsoft SMTPSVC; Fri, 21 Jul 2006 22:21:14 +0300 Received: from viper.eu.tieto.com ([194.110.47.167]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 15:53:45 +0200 Received: from veyron.eu.tieto.com ([194.110.47.230]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 16:53:45 +0300 Received: from ebb03.tieto.com ([194.142.141.100]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 16:53:44 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ebb03.tieto.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 16:53:44 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3YxT-0003us-Js; Thu, 20 Jul 2006 09:52:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3YxQ-0003tw-LI; Thu, 20 Jul 2006 09:52:52 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Ys1-0000YK-Jw; Thu, 20 Jul 2006 09:47:18 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6KDl89R020345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jul 2006 13:47:09 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3Yrs-0000Sh-Se; Thu, 20 Jul 2006 09:47:08 -0400 X-test-idtracker: no From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Message-Id: <E1G3Yrs-0000Sh-Se@stiedprstage1.ietf.org> Date: Thu, 20 Jul 2006 09:47:08 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: pkix mailing list <ietf-pkix@imc.org>, Internet Architecture Board <iab@iab.org>, pkix chair <kent@bbn.com>, RFC Editor <rfc-editor@rfc-editor.org> Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)' to Proposed Standard X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 List-Id: ietf-announce.ietf.org List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe> List-Post: <mailto:ietf-announce@ietf.org> List-Help: <mailto:ietf-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe> X-OriginalArrivalTime: 20 Jul 2006 13:53:44.0892 (UTC) FILETIME=[EAAFFFC0:01C6AC03] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce Received: from kerdowney.com (mur75-1-81-57-45-109.fbx.proxad.net [81.57.45.109]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6LIrhMm086030 for <ietf-pkix-archive@imc.org>; Fri, 21 Jul 2006 11:53:46 -0700 (MST) (envelope-from henrikkihurlbert@groverprinting.com) Message-ID: <000001c6acf6$fdb41e50$71a8a8c0@gus68> Reply-To: "Henrikki Hurlbert" <henrikkihurlbert@groverprinting.com> From: "Henrikki Hurlbert" <henrikkihurlbert@groverprinting.com> To: ietf-pkix-archive@imc.org Subject: to yuhaf Date: Fri, 21 Jul 2006 11:53:44 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6ACBC.51554650" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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> </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> </P> <P> </P> <P> </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-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6KDlPRT000914; Thu, 20 Jul 2006 06:47:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6KDlPMp000913; Thu, 20 Jul 2006 06:47:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6KDlOVi000888 for <ietf-pkix@imc.org>; Thu, 20 Jul 2006 06:47:24 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6KDl89R020345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jul 2006 13:47:09 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3Yrs-0000Sh-Se; Thu, 20 Jul 2006 09:47:08 -0400 X-test-idtracker: no From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, pkix mailing list <ietf-pkix@imc.org>, pkix chair <kent@bbn.com>, pkix chair <stefans@microsoft.com> Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)' to Proposed Standard Message-Id: <E1G3Yrs-0000Sh-Se@stiedprstage1.ietf.org> Date: Thu, 20 Jul 2006 09:47:08 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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). Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6KDSSpa095563; Thu, 20 Jul 2006 06:28:28 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6KDSS5r095562; Thu, 20 Jul 2006 06:28:28 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6KDSRJq095535 for <ietf-pkix@imc.org>; Thu, 20 Jul 2006 06:28:27 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 82331 invoked from network); 20 Jul 2006 13:28:21 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.18.255.127 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 20 Jul 2006 13:28:21 -0000 Reply-To: <turners@ieca.com> From: "Turner, Sean P." <turners@ieca.com> To: "'pkix'" <ietf-pkix@imc.org> Subject: 3280bis-04.txt: Empty ASN.1 Sequences Date: Thu, 20 Jul 2006 09:27:39 -0400 Organization: IECA, Inc. Message-ID: <001a01c6ac00$45d62f40$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcasAEWCOfkd6OWbRCelG6zu8tHgag== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6JEokdE030520; Wed, 19 Jul 2006 07:50:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6JEokmD030519; Wed, 19 Jul 2006 07:50:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6JEoj32030513 for <ietf-pkix@imc.org>; Wed, 19 Jul 2006 07:50:45 -0700 (MST) (envelope-from wprice@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id k6JEoitJ028246 for <ietf-pkix@imc.org>; Wed, 19 Jul 2006 10:50:44 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id ACD72BF7E for <ietf-pkix@imc.org>; Wed, 19 Jul 2006 10:50:44 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id k6JEoims028221; Wed, 19 Jul 2006 10:50:44 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 10:50:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: End entity validity date nesting Date: Wed, 19 Jul 2006 10:50:43 -0400 Message-ID: <F9F038204EE77C4AA9959A6B3C94AFE8C99449@IMCSRV2.MITRE.ORG> In-Reply-To: <p06230912c0e3075b67fb@[128.89.89.106]> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: End entity validity date nesting Thread-Index: AcaquvtRLunHxc9TQzK7OT3z8NxGGAAhjg4g From: "Price, Bill" <wprice@mitre.org> To: "Stephen Kent" <kent@bbn.com>, "Ogle Ron" <ron.ogle@thomson.net> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 19 Jul 2006 14:50:44.0102 (UTC) FILETIME=[B6484A60:01C6AB42] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6JEoj32030514 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Tuesday, July 18, 2006 5:49 PM To: Ogle Ron Cc: ietf-pkix@imc.org 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6J0mH4s097052; Tue, 18 Jul 2006 17:48:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6J0mHHo097051; Tue, 18 Jul 2006 17:48:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6J0mEaB097007 for <ietf-pkix@imc.org>; Tue, 18 Jul 2006 17:48:16 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1G30ES-0006Gb-3q; Tue, 18 Jul 2006 20:48:08 -0400 Mime-Version: 1.0 Message-Id: <p06230913c0e331453ac3@[128.89.89.106]> In-Reply-To: <08AD20EDD5C44148842571F730597F84BD6622@INDYSMAILMB03.am.thmulti.com> References: <08AD20EDD5C44148842571F730597F84BD6622@INDYSMAILMB03.am.thmulti.com> Date: Tue, 18 Jul 2006 20:46:57 -0400 To: "Ogle Ron" <ron.ogle@thomson.net> From: Stephen Kent <kent@bbn.com> Subject: RE: End entity validity date nesting Cc: "Joel Kazin" <jkazin@bestweb.net>, <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IMZOf9061145; Tue, 18 Jul 2006 15:35:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6IMZOYM061144; Tue, 18 Jul 2006 15:35:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from dmzraw4.extranet.tce.com (dmzraw4.extranet.tce.com [157.254.234.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IMZNv7061110 for <ietf-pkix@imc.org>; Tue, 18 Jul 2006 15:35:23 -0700 (MST) (envelope-from ron.ogle@thomson.net) Received: from indyvss4.am.thmulti.com (unknown [157.254.92.63]) by dmzraw4.extranet.tce.com (Postfix) with ESMTP id E289658AC; Tue, 18 Jul 2006 22:35:17 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss4.am.thmulti.com (Postfix) with ESMTP id BA7F88182; Tue, 18 Jul 2006 22:35:17 +0000 (GMT) X-Virus-Scanned: amavisd-new at thomson.net Received: from indyvss4.am.thmulti.com ([127.0.0.1]) by localhost (indyvss4.am.thmulti.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Eh2Orx26acRK; Tue, 18 Jul 2006 22:35:07 +0000 (GMT) Received: from indysmailcs01.am.thmulti.com (indysmailcs01.am.thmulti.com [157.254.96.5]) by indyvss4.am.thmulti.com (Postfix) with ESMTP id 8DD348180; Tue, 18 Jul 2006 22:35:01 +0000 (GMT) Received: from INDYSMAILMB03.am.thmulti.com ([157.254.96.81]) by indysmailcs01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 18:35:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: End entity validity date nesting Date: Tue, 18 Jul 2006 18:35:00 -0400 Message-ID: <08AD20EDD5C44148842571F730597F84BD6622@INDYSMAILMB03.am.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: End entity validity date nesting Thread-Index: Acaqt+279vBkeqaDSXSPv51Uwjq7xAAAdByw From: "Ogle Ron" <ron.ogle@thomson.net> To: "Joel Kazin" <jkazin@bestweb.net> Cc: <ietf-pkix@imc.org> X-OriginalArrivalTime: 18 Jul 2006 22:35:01.0655 (UTC) FILETIME=[6843CA70:01C6AABA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6IMZNv7061139 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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:jkazin@bestweb.net] Sent: Tuesday, July 18, 2006 5:44 PM To: Ogle Ron Cc: ietf-pkix@imc.org Subject: Re: End entity validity date nesting .... By the way, both Microsoft and Entrust do it the right way. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ILntTA047379; Tue, 18 Jul 2006 14:49:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6ILntNa047378; Tue, 18 Jul 2006 14:49:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ILntcb047346 for <ietf-pkix@imc.org>; Tue, 18 Jul 2006 14:49:55 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1G2xRs-0004uh-65; Tue, 18 Jul 2006 17:49:49 -0400 Mime-Version: 1.0 Message-Id: <p06230912c0e3075b67fb@[128.89.89.106]> In-Reply-To: <08AD20EDD5C44148842571F730597F84BD660C@INDYSMAILMB03.am.thmulti.com> References: <08AD20EDD5C44148842571F730597F84BD660C@INDYSMAILMB03.am.thmulti.com> Date: Tue, 18 Jul 2006 17:48:46 -0400 To: "Ogle Ron" <ron.ogle@thomson.net> From: Stephen Kent <kent@bbn.com> Subject: Re: End entity validity date nesting Cc: <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ILjugW046193; Tue, 18 Jul 2006 14:45:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6ILjuu7046192; Tue, 18 Jul 2006 14:45:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp2.bestweb.net (smtp2-3.bestweb.net [209.94.103.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ILjttq046186 for <ietf-pkix@imc.org>; Tue, 18 Jul 2006 14:45:55 -0700 (MST) (envelope-from jkazin@bestweb.net) Received: from [127.0.0.1] (pool-70-107-21-163.ny325.east.verizon.net [70.107.21.163]) by smtp2.bestweb.net (Postfix) with ESMTP id DED001CCE3; Tue, 18 Jul 2006 17:45:54 -0400 (EDT) Message-ID: <44BD560E.9080403@bestweb.net> Date: Tue, 18 Jul 2006 17:43:42 -0400 From: Joel Kazin <jkazin@bestweb.net> User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ogle Ron <ron.ogle@thomson.net> CC: ietf-pkix@imc.org Subject: Re: End entity validity date nesting References: <08AD20EDD5C44148842571F730597F84BD660C@INDYSMAILMB03.am.thmulti.com> In-Reply-To: <08AD20EDD5C44148842571F730597F84BD660C@INDYSMAILMB03.am.thmulti.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 > > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ILHla5038461; Tue, 18 Jul 2006 14:17:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6ILHliW038460; Tue, 18 Jul 2006 14:17:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from dmzraw5.extranet.tce.com (dmzraw5.extranet.tce.com [157.254.234.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6ILHkur038407 for <ietf-pkix@imc.org>; Tue, 18 Jul 2006 14:17:46 -0700 (MST) (envelope-from ron.ogle@thomson.net) Received: from indyvss4.am.thmulti.com (unknown [157.254.92.63]) by dmzraw5.extranet.tce.com (Postfix) with ESMTP id D65B912AD for <ietf-pkix@imc.org>; Tue, 18 Jul 2006 21:17:40 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss4.am.thmulti.com (Postfix) with ESMTP id 802017E19 for <ietf-pkix@imc.org>; Tue, 18 Jul 2006 21:17:40 +0000 (GMT) X-Virus-Scanned: amavisd-new at thomson.net Received: from indyvss4.am.thmulti.com ([127.0.0.1]) by localhost (indyvss4.am.thmulti.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YzE0KjIyaHBV for <ietf-pkix@imc.org>; Tue, 18 Jul 2006 21:17:36 +0000 (GMT) Received: from indysmailcs01.am.thmulti.com (indysmailcs01.am.thmulti.com [157.254.96.5]) by indyvss4.am.thmulti.com (Postfix) with ESMTP id 0F96E7E0F for <ietf-pkix@imc.org>; Tue, 18 Jul 2006 21:17:36 +0000 (GMT) Received: from INDYSMAILMB03.am.thmulti.com ([157.254.96.81]) by indysmailcs01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 17:17:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: End entity validity date nesting Date: Tue, 18 Jul 2006 17:17:35 -0400 Message-ID: <08AD20EDD5C44148842571F730597F84BD660C@INDYSMAILMB03.am.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: End entity validity date nesting Thread-Index: Acaqr5czYdBGpr2FQUeBrEwCfiMbUw== From: "Ogle Ron" <ron.ogle@thomson.net> To: <ietf-pkix@imc.org> X-OriginalArrivalTime: 18 Jul 2006 21:17:36.0475 (UTC) FILETIME=[978592B0:01C6AAAF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6ILHkur038455 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from mintron (adsl-69-233-59-211.dsl.pltn13.pacbell.net [69.233.59.211]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6IHvWUl080166; Tue, 18 Jul 2006 10:57:33 -0700 (MST) (envelope-from service@paypal.com) Received: from User ([69.128.89.26]) by mintron with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jul 2006 10:48:13 -0700 Reply-To: <service@paypal.com> From: "PayPal On-Line Services"<service@paypal.com> Subject: PayPal Case PP-X26-928-08 Account Security Measures Notification. Date: Tue, 18 Jul 2006 13:48:20 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Bcc: Message-ID: <MINTRONTaxrd696Kegi00000cbc@mintron> X-OriginalArrivalTime: 18 Jul 2006 17:48:13.0578 (UTC) FILETIME=[57739EA0:01C6AA92] <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> </td> </tr> </table> </body> </html> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6I6UJ2h085746; Mon, 17 Jul 2006 23:30:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6I6UJ75085744; Mon, 17 Jul 2006 23:30:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6I6UF2X085679 for <ietf-pkix@imc.org>; Mon, 17 Jul 2006 23:30:18 -0700 (MST) (envelope-from rybar@nbusr.sk) Message-Id: <200607180630.k6I6UF2X085679@balder-227.proper.com> Received: from IBM5E1D7F233E3 ([10.0.250.204]) by mail.nbusr.sk with esmtp; Tue, 18 Jul 2006 08:27:46 +0200 id 000114A5.44BC7F66.00005DCE From: "Peter Rybar" <rybar@nbusr.sk> To: "'Stephen Kent'" <kent@bbn.com>, "'pkix'" <ietf-pkix@imc.org> Cc: "'Carl Wallace'" <cwallace@orionsec.com>, "'David A. Cooper'" <david.cooper@nist.gov> Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt Date: Tue, 18 Jul 2006 08:30:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <p06230904c0e14582f90c@[128.89.89.106]> Thread-Index: AcaqKDTtIVp1tBtiT0OSCRctZFyYVgACieQg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6I6UI2X085739 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6HJoCRq005576; Mon, 17 Jul 2006 12:50:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6HJoCFj005575; Mon, 17 Jul 2006 12:50:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6HJoB7N005542 for <ietf-pkix@imc.org>; Mon, 17 Jul 2006 12:50:11 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6HJo29R004047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jul 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G2Z6Q-0007Zo-0f; Mon, 17 Jul 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-06.txt Message-Id: <E1G2Z6Q-0007Zo-0f@stiedprstage1.ietf.org> Date: Mon, 17 Jul 2006 15:50:02 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-17141247.I-D@ietf.org> 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: <2006-7-17141247.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6HE1gi7015041; Mon, 17 Jul 2006 07:01:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6HE1gbS015040; Mon, 17 Jul 2006 07:01:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6HE1fFZ015022 for <ietf-pkix@imc.org>; Mon, 17 Jul 2006 07:01:41 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1G2Tf9-0008My-3R; Mon, 17 Jul 2006 10:01:31 -0400 Mime-Version: 1.0 Message-Id: <p06230904c0e14582f90c@[128.89.89.106]> In-Reply-To: <44BABBBD.8070900@kent.ac.uk> References: <82D5657AE1F54347A734BDD33637C87903B7A067@EXVS01.ex.dslextreme.net> <44BABBBD.8070900@kent.ac.uk> Date: Mon, 17 Jul 2006 09:53:12 -0400 To: David Chadwick <d.w.chadwick@kent.ac.uk> From: Stephen Kent <kent@bbn.com> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt Cc: Carl Wallace <cwallace@orionsec.com>, "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Content-Type: multipart/alternative; boundary="============_-1058977606==_ma============" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --============_-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 "the authorityCertIssuer, authoritySerialNumber pair can<br> only be used to provide preference to one certificate over others during<br> path construction." 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. 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. This extension is used where an issuer has multiple signing keys (either due to multiple concurrent key pairs or due to changeover). </font></div> <div><font face="Courier" size="+2" color="#000000"><br></font></div> <div><font color="#000000">The first sentence uses the term "identifying" not "locating." 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============-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6GMeNH5092143; Sun, 16 Jul 2006 15:40:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6GMeNG9092141; Sun, 16 Jul 2006 15:40:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.32]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6GMeMOw092104 for <ietf-pkix@imc.org>; Sun, 16 Jul 2006 15:40:22 -0700 (MST) (envelope-from d.w.chadwick@kent.ac.uk) Received: from client-82-18-216-87.brnt.adsl.ntlworld.com ([82.18.216.87] helo=[192.168.0.90]) by mx1.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1G2FHK-0007X4-Sr; Sun, 16 Jul 2006 23:39:59 +0100 Message-ID: <44BAC007.6060206@kent.ac.uk> Date: Sun, 16 Jul 2006 23:39:03 +0100 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "David A. Cooper" <david.cooper@nist.gov> CC: pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <82D5657AE1F54347A734BDD33637C87903ADA0F3@EXVS01.ex.dslextreme.net> <44B7AFD7.7070907@kent.ac.uk> <44B7B8D2.6070007@nist.gov> In-Reply-To: <44B7B8D2.6070007@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: D.W.Chadwick@kent.ac.uk 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 ***************************************************************** Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6GMMJ0H088011; Sun, 16 Jul 2006 15:22:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6GMMJ8g088010; Sun, 16 Jul 2006 15:22:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx4.kent.ac.uk (mx4.kent.ac.uk [129.12.21.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6GMMGBE087965 for <ietf-pkix@imc.org>; Sun, 16 Jul 2006 15:22:19 -0700 (MST) (envelope-from d.w.chadwick@kent.ac.uk) Received: from client-82-18-216-87.brnt.adsl.ntlworld.com ([82.18.216.87] helo=[192.168.0.90]) by mx4.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1G2Ezd-0003Hp-Nt; Sun, 16 Jul 2006 23:21:45 +0100 Message-ID: <44BABBBD.8070900@kent.ac.uk> Date: Sun, 16 Jul 2006 23:20:45 +0100 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Carl Wallace <cwallace@orionsec.com> CC: "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <82D5657AE1F54347A734BDD33637C87903B7A067@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87903B7A067@EXVS01.ex.dslextreme.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: D.W.Chadwick@kent.ac.uk 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 ***************************************************************** Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EFbbAE024711; Fri, 14 Jul 2006 08:37:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6EFbbRJ024710; Fri, 14 Jul 2006 08:37:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EFbaGx024673 for <ietf-pkix@imc.org>; Fri, 14 Jul 2006 08:37:36 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt Date: Fri, 14 Jul 2006 08:37:29 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87903B7A067@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-rfc3280bis-04.txt Thread-Index: AcanVfuJn9+5OxE5TwSCLNDa25VMLAAAAzgA From: "Carl Wallace" <cwallace@orionsec.com> To: "David Chadwick" <d.w.chadwick@kent.ac.uk> Cc: "David A. Cooper" <david.cooper@nist.gov>, "pkix" <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6EFbaGx024705 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EFYhf3023801; Fri, 14 Jul 2006 08:34:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6EFYhpO023800; Fri, 14 Jul 2006 08:34:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EFYgan023789 for <ietf-pkix@imc.org>; Fri, 14 Jul 2006 08:34:42 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6EFWMSj012649; Fri, 14 Jul 2006 11:32:23 -0400 Received: from [129.6.222.3] ([129.6.222.3]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k6EFVVMD015947; Fri, 14 Jul 2006 11:31:31 -0400 (EDT) Message-ID: <44B7B8D2.6070007@nist.gov> Date: Fri, 14 Jul 2006 11:31:30 -0400 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: David Chadwick <d.w.chadwick@kent.ac.uk> CC: pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <82D5657AE1F54347A734BDD33637C87903ADA0F3@EXVS01.ex.dslextreme.net> <44B7AFD7.7070907@kent.ac.uk> In-Reply-To: <44B7AFD7.7070907@kent.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EFKLiI019570; Fri, 14 Jul 2006 08:20:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6EFKLn4019569; Fri, 14 Jul 2006 08:20:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EFKKN7019562 for <ietf-pkix@imc.org>; Fri, 14 Jul 2006 08:20:21 -0700 (MST) (envelope-from shu-jen.chang@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6EFCMGD003386; Fri, 14 Jul 2006 11:13:26 -0400 Received: from othello.nist.gov (othello.ncsl.nist.gov [129.6.54.41]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k6EF5p8Y005070; Fri, 14 Jul 2006 11:05:51 -0400 (EDT) Message-Id: <5.1.1.5.2.20060714104616.02b31648@email.nist.gov> X-Sender: sjchang@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 14 Jul 2006 11:03:52 -0400 To: shu-jen.chang@nist.gov From: Shu-jen Chang <shu-jen.chang@nist.gov> Subject: Tentative Time line of the Development of New Hash Functions Now Posted Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: shu-jen.chang@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> <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>hash-function@nist.gov </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> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EEsIIR012519; Fri, 14 Jul 2006 07:54:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6EEsINE012518; Fri, 14 Jul 2006 07:54:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx6.kent.ac.uk (mx6.kent.ac.uk [129.12.21.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EEsHV0012493 for <ietf-pkix@imc.org>; Fri, 14 Jul 2006 07:54:18 -0700 (MST) (envelope-from d.w.chadwick@kent.ac.uk) Received: from dhcp1098.ukc.ac.uk ([129.12.16.152]) by mx6.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1G1P39-0004cM-Nl; Fri, 14 Jul 2006 15:53:51 +0100 Message-ID: <44B7AFD7.7070907@kent.ac.uk> Date: Fri, 14 Jul 2006 15:53:11 +0100 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Carl Wallace <cwallace@orionsec.com> CC: "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <82D5657AE1F54347A734BDD33637C87903ADA0F3@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87903ADA0F3@EXVS01.ex.dslextreme.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: D.W.Chadwick@kent.ac.uk 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 ***************************************************************** Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EEneXA011239; Fri, 14 Jul 2006 07:49:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6EEneEb011238; Fri, 14 Jul 2006 07:49:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx5.kent.ac.uk (mx5.kent.ac.uk [129.12.21.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6EEnauD011188 for <ietf-pkix@imc.org>; Fri, 14 Jul 2006 07:49:39 -0700 (MST) (envelope-from d.w.chadwick@kent.ac.uk) Received: from dhcp1098.ukc.ac.uk ([129.12.16.152]) by mx5.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1G1Oyh-0000GI-TF; Fri, 14 Jul 2006 15:49:15 +0100 Message-ID: <44B7AEC3.3050309@kent.ac.uk> Date: Fri, 14 Jul 2006 15:48:35 +0100 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Carl Wallace <cwallace@orionsec.com> CC: "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <82D5657AE1F54347A734BDD33637C87903ADA0F3@EXVS01.ex.dslextreme.net> In-Reply-To: <82D5657AE1F54347A734BDD33637C87903ADA0F3@EXVS01.ex.dslextreme.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: D.W.Chadwick@kent.ac.uk 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 ***************************************************************** Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DJoCOi016311; Thu, 13 Jul 2006 12:50:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DJoCpT016310; Thu, 13 Jul 2006 12:50:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DJoB7S016271 for <ietf-pkix@imc.org>; Thu, 13 Jul 2006 12:50:12 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6DJo21u016990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G17CE-0003ZE-5o; Thu, 13 Jul 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-sim-08.txt Message-Id: <E1G17CE-0003ZE-5o@stiedprstage1.ietf.org> Date: Thu, 13 Jul 2006 15:50:02 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-13134020.I-D@ietf.org> 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: <2006-7-13134020.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DI1D2u085652; Thu, 13 Jul 2006 11:01:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DI1DWC085651; Thu, 13 Jul 2006 11:01:13 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DI1BZG085644 for <ietf-pkix@imc.org>; Thu, 13 Jul 2006 11:01:12 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-37.fastq.com [65.39.92.37]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id k6DI11N00135; Thu, 13 Jul 2006 11:01:01 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org> Subject: RE: draft meeting minutes have been uploaded Date: Thu, 13 Jul 2006 10:59:59 -0800 Message-ID: <CCEJKFKLBCNMONJMIEAMOEJFCCAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <p06230908c0d964e888ba@[198.18.104.95]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DEujZQ034141; Thu, 13 Jul 2006 07:56:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6DEujGJ034140; Thu, 13 Jul 2006 07:56:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DEuibv034130 for <ietf-pkix@imc.org>; Thu, 13 Jul 2006 07:56:45 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k6DEui002752 for <ietf-pkix@imc.org>; Thu, 13 Jul 2006 16:56:44 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Thu, 13 Jul 2006 16:56:44 +0200 (MET DST) Message-ID: <44B65EBF.5070307@edelweb.fr> Date: Thu, 13 Jul 2006 16:54:55 +0200 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: pkix <ietf-pkix@imc.org> Subject: SCVP question Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090107040803030708090103" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzEzMTQ1NDU1WjAjBgkqhkiG9w0B CQQxFgQUF7mzKN4M5KpxvJKCJAnP68mDM5gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAb/vIxHRPTUEsjd/w y4kNT3RYmgxWk9Nv4xuXbNy0FQJDQl7S1jQB6jS1rCd9LlvELsqE2JdDnMZtFxsh3cT4SfgV FUfv5CYQQRQCciBTXm0NcmCDGYAukYn5C3sRbDbBQPvjLzjAzWlKrnQ3aMOiUBsgBBopz4ku 329+lF+IPYIAAAAAAAA= --------------ms090107040803030708090103-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6CE6OQb061865; Wed, 12 Jul 2006 07:06:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6CE6OlP061864; Wed, 12 Jul 2006 07:06:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sottsym2.entrust.com (sottsym2.entrust.com [216.191.252.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6CE6NqA061844 for <ietf-pkix@imc.org>; Wed, 12 Jul 2006 07:06:23 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: from sottmxsecs3.entrust.com (unknown [216.191.252.14]) by sottsym2.entrust.com (Symantec Mail Security) with SMTP id E3A6916DC for <ietf-pkix@imc.org>; Wed, 12 Jul 2006 10:06:17 -0400 (EDT) Received: (qmail 16051 invoked from network); 12 Jul 2006 14:06:17 -0000 Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.4;12 Jul 2006 14:06:17 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 12 Jul 2006 14:06:16 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <NQV5VL88>; Wed, 12 Jul 2006 10:06:17 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F09EAD240@sottmxs05.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'Carl Wallace'" <cwallace@orionsec.com>, David Chadwick <d.w.chadwick@kent.ac.uk>, "David A. Cooper" <david.cooper@nist.gov> Cc: pkix <ietf-pkix@imc.org> Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt Date: Wed, 12 Jul 2006 10:06:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A5BC.4444260D" X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 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: owner-ietf-pkix@mail.imc.org [<A = HREF=3D"mailto:owner-ietf-pkix@mail.imc.org">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>> Secondly, you forgot to mention the use = of</FONT> <BR><FONT SIZE=3D2>> AuthorityKeyIdentifier which according to 3280 = is " a means </FONT> <BR><FONT SIZE=3D2>> of identifying the public key corresponding to = the private </FONT> <BR><FONT SIZE=3D2>> key used to sign a certificate." So this = precisely gives us </FONT> <BR><FONT SIZE=3D2>> the pointer we need to point to the PKC of the = issuer of the </FONT> <BR><FONT SIZE=3D2>> 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. 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.</FONT></P> <P><FONT SIZE=3D2>> This is in line with its</FONT> <BR><FONT SIZE=3D2>> current use in PKCs. Thus we do not need the = AIA to point to </FONT> <BR><FONT SIZE=3D2>> the PKC of the issuer.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> The second point means that we only need to use = the AIA to</FONT> <BR><FONT SIZE=3D2>> point to the AC of the issuer. And caissuers = can be used for </FONT> <BR><FONT SIZE=3D2>> this unambiguously if we edit the first = sentence of its </FONT> <BR><FONT SIZE=3D2>> description in 3280-bis. The current wording = does in my </FONT> <BR><FONT SIZE=3D2>> opinion rule out its use in CRLs. So it would = be advantageous </FONT> <BR><FONT SIZE=3D2>> 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. 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-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6CD6MbH048254; Wed, 12 Jul 2006 06:06:22 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6CD6M4f048253; Wed, 12 Jul 2006 06:06:22 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6CD6MJ2048224 for <ietf-pkix@imc.org>; Wed, 12 Jul 2006 06:06:22 -0700 (MST) (envelope-from cwallace@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt Date: Wed, 12 Jul 2006 06:06:12 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87903ADA0F3@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-rfc3280bis-04.txt Thread-Index: AcalB1zBQF/LIk9iTv6bDi4hQmRPCQAqjfAg From: "Carl Wallace" <cwallace@orionsec.com> To: "David Chadwick" <d.w.chadwick@kent.ac.uk>, "David A. Cooper" <david.cooper@nist.gov> Cc: "pkix" <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k6CD6MJ2048248 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BFbYJ6021411; Tue, 11 Jul 2006 08:37:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BFbYQg021409; Tue, 11 Jul 2006 08:37:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BFbX6M021380 for <ietf-pkix@imc.org>; Tue, 11 Jul 2006 08:37:33 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.104.95]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1G0KIh-0000QA-57; Tue, 11 Jul 2006 11:37:27 -0400 Mime-Version: 1.0 Message-Id: <p06230909c0d968e878d4@[198.18.104.95]> In-Reply-To: <44B3AF3A.3040908@kent.ac.uk> References: <44A033D0.1080503@nist.gov> <44AB8B9C.6020404@kent.ac.uk> <44ABC3FF.4070804@nist.gov> <44AEA9C8.2000607@kent.ac.uk> <p06230902c0d861f62353@[132.219.15.201]> <44B3AF3A.3040908@kent.ac.uk> Date: Tue, 11 Jul 2006 10:49:14 -0400 To: David Chadwick <d.w.chadwick@kent.ac.uk> From: Stephen Kent <kent@bbn.com> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt Cc: "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BFK3Ix016731; Tue, 11 Jul 2006 08:20:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BFK3t4016729; Tue, 11 Jul 2006 08:20:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx2.kent.ac.uk (mx2.kent.ac.uk [129.12.21.33]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BFK1J5016691 for <ietf-pkix@imc.org>; Tue, 11 Jul 2006 08:20:02 -0700 (MST) (envelope-from d.w.chadwick@kent.ac.uk) Received: from [66.103.220.248] (helo=[66.103.220.248]) by mx2.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1G0K13-0007No-09; Tue, 11 Jul 2006 16:19:26 +0100 Message-ID: <44B3C13A.9090703@kent.ac.uk> Date: Tue, 11 Jul 2006 16:18:18 +0100 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "David A. Cooper" <david.cooper@nist.gov> CC: pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <44A033D0.1080503@nist.gov> <44AB8B9C.6020404@kent.ac.uk> <44ABC3FF.4070804@nist.gov> <44AEA9C8.2000607@kent.ac.uk> <p06230902c0d861f62353@[132.219.15.201]> <44B3AF3A.3040908@kent.ac.uk> <44B3B82A.7030100@nist.gov> In-Reply-To: <44B3B82A.7030100@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: D.W.Chadwick@kent.ac.uk 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 ***************************************************************** Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BEeoGG006785; Tue, 11 Jul 2006 07:40:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BEeoEH006784; Tue, 11 Jul 2006 07:40:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BEenYb006777 for <ietf-pkix@imc.org>; Tue, 11 Jul 2006 07:40:50 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k6BEeeC3006101; Tue, 11 Jul 2006 10:40:41 -0400 Received: from [129.6.223.63] ([129.6.223.63]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k6BEdcVn007250; Tue, 11 Jul 2006 10:39:38 -0400 (EDT) Message-ID: <44B3B82A.7030100@nist.gov> Date: Tue, 11 Jul 2006 10:39:38 -0400 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: David Chadwick <d.w.chadwick@kent.ac.uk> CC: pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <44A033D0.1080503@nist.gov> <44AB8B9C.6020404@kent.ac.uk> <44ABC3FF.4070804@nist.gov> <44AEA9C8.2000607@kent.ac.uk> <p06230902c0d861f62353@[132.219.15.201]> <44B3AF3A.3040908@kent.ac.uk> In-Reply-To: <44B3AF3A.3040908@kent.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BEOPaw002155; Tue, 11 Jul 2006 07:24:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BEOP8W002152; Tue, 11 Jul 2006 07:24:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BEOOpq002121 for <ietf-pkix@imc.org>; Tue, 11 Jul 2006 07:24:24 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.104.95]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1G0J9u-0000r2-5D for ietf-pkix@imc.org; Tue, 11 Jul 2006 10:24:18 -0400 Mime-Version: 1.0 Message-Id: <p06230908c0d964e888ba@[198.18.104.95]> Date: Tue, 11 Jul 2006 10:24:16 -0400 To: ietf-pkix@imc.org From: Stephen Kent <kent@bbn.com> Subject: draft meeting minutes have been uploaded Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Please send comments and corrections to me over the next two weeks, so these can be finalized. Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BE3ATd096159; Tue, 11 Jul 2006 07:03:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6BE3ANM096158; Tue, 11 Jul 2006 07:03:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx3.kent.ac.uk (mx3.kent.ac.uk [129.12.21.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6BE39JA096125 for <ietf-pkix@imc.org>; Tue, 11 Jul 2006 07:03:10 -0700 (MST) (envelope-from d.w.chadwick@kent.ac.uk) Received: from [66.103.220.248] (helo=[66.103.220.248]) by mx3.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1G0IoI-00022Y-7C; Tue, 11 Jul 2006 15:02:00 +0100 Message-ID: <44B3AF3A.3040908@kent.ac.uk> Date: Tue, 11 Jul 2006 15:01:30 +0100 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com> CC: "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <44A033D0.1080503@nist.gov> <44AB8B9C.6020404@kent.ac.uk> <44ABC3FF.4070804@nist.gov> <44AEA9C8.2000607@kent.ac.uk> <p06230902c0d861f62353@[132.219.15.201]> In-Reply-To: <p06230902c0d861f62353@[132.219.15.201]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: D.W.Chadwick@kent.ac.uk 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 ***************************************************************** Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AK2KTn024750; Mon, 10 Jul 2006 13:02:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6AK2K6a024749; Mon, 10 Jul 2006 13:02:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AK2JN9024715 for <ietf-pkix@imc.org>; Mon, 10 Jul 2006 13:02:19 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[132.219.15.201]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1G01xL-00014J-6N; Mon, 10 Jul 2006 16:02:12 -0400 Mime-Version: 1.0 Message-Id: <p06230902c0d861f62353@[132.219.15.201]> In-Reply-To: <44AEA9C8.2000607@kent.ac.uk> References: <44A033D0.1080503@nist.gov> <44AB8B9C.6020404@kent.ac.uk> <44ABC3FF.4070804@nist.gov> <44AEA9C8.2000607@kent.ac.uk> Date: Mon, 10 Jul 2006 16:02:09 -0400 To: David Chadwick <d.w.chadwick@kent.ac.uk> From: Stephen Kent <kent@bbn.com> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt Cc: "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AEaj8Y039699; Mon, 10 Jul 2006 07:36:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6AEajOO039698; Mon, 10 Jul 2006 07:36:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AEahNY039691 for <ietf-pkix@imc.org>; Mon, 10 Jul 2006 07:36:44 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 15:36:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A42E.42AF2B77" Subject: Reminder - send me PKIX slides before the PKIX meeting Date: Mon, 10 Jul 2006 15:36:38 +0100 Message-ID: <BF9309599A71984CAC5BAC5ECA629944055C0B5C@EUR-MSG-11.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder - send me PKIX slides before the PKIX meeting thread-index: AcakLkBwQM5rutW6TOqcby2/VZNLwQ== From: "Stefan Santesson" <stefans@microsoft.com> To: <ietf-pkix@imc.org> X-OriginalArrivalTime: 10 Jul 2006 14:36:42.0524 (UTC) FILETIME=[42F1EDC0:01C6A42E] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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> </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> </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> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C6A42E.42AF2B77-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AC14IT097514; Mon, 10 Jul 2006 05:01:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6AC14Is097513; Mon, 10 Jul 2006 05:01:04 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AC12iG097482 for <ietf-pkix@imc.org>; Mon, 10 Jul 2006 05:01:03 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 13:00:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A418.8200B22F" Subject: Agenda Date: Mon, 10 Jul 2006 13:00:57 +0100 Message-ID: <BF9309599A71984CAC5BAC5ECA629944055C0990@EUR-MSG-11.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda thread-index: AcakGIC7i1g5U2HnSf6nESgrd5X0ow== From: "Stefan Santesson" <stefans@microsoft.com> To: <ietf-pkix@imc.org> X-OriginalArrivalTime: 10 Jul 2006 12:00:59.0651 (UTC) FILETIME=[8228A530:01C6A418] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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> </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> </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> </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> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C6A418.8200B22F-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69H5Jb4096554; Sun, 9 Jul 2006 10:05:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k69H5J0a096553; Sun, 9 Jul 2006 10:05:19 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69H5INm096517 for <ietf-pkix@imc.org>; Sun, 9 Jul 2006 10:05:19 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comment on RFC 3280bis: id-pkix-crl-nocheck extension Date: Sun, 9 Jul 2006 10:05:12 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C87903A209C3@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on RFC 3280bis: id-pkix-crl-nocheck extension thread-index: AcajbVFmJ8ZwciefR3OCTM0hTarATwADFmEQ From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k69H5JNm096548 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Sunday, July 09, 2006 10:18 AM To: ietf-pkix@imc.org 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69GbQp9089207; Sun, 9 Jul 2006 09:37:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k69GbQuS089206; Sun, 9 Jul 2006 09:37:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail4.exchange.microsoft.com (mail4.exchange.microsoft.com [131.107.1.99]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69GbPuw089183 for <ietf-pkix@imc.org>; Sun, 9 Jul 2006 09:37:25 -0700 (MST) (envelope-from david.cross@microsoft.com) Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.70.52]) by mail4.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 09:37:19 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Jul 2006 09:37:19 -0700 Received: from df-pug-msg.exchange.corp.microsoft.com (157.54.69.159) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) for IMCEAEX-_O=MICROSOFT_OU=FIRST+20ADMINISTRATIVE+20GROUP_CN=RECIPIENTS_CN=DCROSS@exchange.microsoft.com with mapi; Sun, 9 Jul 2006 09:37:19 -0700 From: David Cross <David.Cross@microsoft.com> To: "'Denis Pinkas'" <denis.pinkas@bull.net>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Date: Sun, 9 Jul 2006 09:35:27 -0700 Subject: RE: Comment on RFC 3280bis: id-pkix-crl-nocheck extension Thread-Topic: Comment on RFC 3280bis: id-pkix-crl-nocheck extension Thread-Index: AcafcdWvF0BsMJWKSQWsKgboIc49wAAGM+kw Message-ID: <1B9D48218E64584084D56A8B7859E69B024ACF1D58@df-pug-msg.exchange.corp.microsoft.com> In-Reply-To: <OFC4245A45.9E4A5991-ONC12571A1.00472778@frcl.bull.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: AcceptLanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2006 16:37:19.0648 (UTC) FILETIME=[F231AA00:01C6A375] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k69GbPuw089201 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, July 04, 2006 5:57 AM To: ietf-pkix@imc.org 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69EOQ4i052321; Sun, 9 Jul 2006 07:24:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k69EOQ6n052320; Sun, 9 Jul 2006 07:24:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k69EOObt052306 for <ietf-pkix@imc.org>; Sun, 9 Jul 2006 07:24:25 -0700 (MST) (envelope-from housley@vigilsec.com) Received: (qmail 11755 invoked by uid 0); 9 Jul 2006 14:24:21 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (132.219.17.242) by woodstock.binhost.com with SMTP; 9 Jul 2006 14:24:21 -0000 Message-Id: <7.0.0.16.2.20060709095958.07290970@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sun, 09 Jul 2006 10:17:34 -0400 To: ietf-pkix@imc.org From: Russ Housley <housley@vigilsec.com> Subject: Re: Comment on RFC 3280bis: id-pkix-crl-nocheck extension In-Reply-To: <OFC4245A45.9E4A5991-ONC12571A1.00472778@frcl.bull.fr> References: <OFC4245A45.9E4A5991-ONC12571A1.00472778@frcl.bull.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k69Ap300092100; Sun, 9 Jul 2006 03:51:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k69Ap3EQ092099; Sun, 9 Jul 2006 03:51:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from 21cn.com (send.forptr.21cn.com [202.105.45.49]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k69AoUDn091949 for <ietf-pkix@imc.org>; Sun, 9 Jul 2006 03:50:31 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 3.1.0.0) with SMTP id jm044b0fd26; Sun, 09 Jul 2006 18:53:06 +0800 Received: from 21cn.com([10.2.1.8]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Sun, 09 Jul 2006 18:53:05 +0800 Received: from balder-227.proper.com([10.2.100.7]) by 21cn.com(AIMC 3.1.0.0) with SMTP id jm22d44ac09c5; Thu, 06 Jul 2006 00:52:21 +0800 Received: from balder-227.proper.com([192.245.12.227]) by 21cn.com(AIMC 3.2.0.0) with SMTP id AISP action; Thu, 06 Jul 2006 00:37:58 +0800 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65GmOHs031717; Wed, 5 Jul 2006 09:48:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k65GmOw3031716; Wed, 5 Jul 2006 09:48:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65GmNmQ031708 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 09:48:23 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA45012 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 18:49:15 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2006070518482173:25962 ; Wed, 5 Jul 2006 18:48:21 +0200 Date: Wed, 5 Jul 2006 18:48:19 +0200 From: "Denis Pinkas" <denis.pinkas@bull.net> To: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Re: Question about indirect CRLs (and designated OCSP responders) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 05/07/2006 18:48:21, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 05/07/2006 18:48:22, Serialize complete at 05/07/2006 18:48:22 Message-ID: <OFFF92B1C2.51FAA98F-ONC12571A2.005C517D@frcl.bull.fr> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-pkix@mail.imc.org X-AIMC-Msg-ID: 9xtbKyPB X-AIMC-AUTH: (null) X-AIMC-MAILFROM: denis.pinkas@bull.net Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> >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" <denis.pinkas@bull.net> >To: <ietf-pkix@imc.org> >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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k67JmgCG096585; Fri, 7 Jul 2006 12:48:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k67Jmg3h096584; Fri, 7 Jul 2006 12:48:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.32]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k67Jmfbh096564 for <ietf-pkix@imc.org>; Fri, 7 Jul 2006 12:48:41 -0700 (MST) (envelope-from d.w.chadwick@kent.ac.uk) Received: from cpc2-hudd6-0-0-cust308.hudd.cable.ntl.com ([82.30.77.53]) by mx1.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1FywIu-0005IA-21; Fri, 07 Jul 2006 20:47:56 +0100 Message-ID: <44AEBA5D.1040809@kent.ac.uk> Date: Fri, 07 Jul 2006 20:47:41 +0100 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Stephen Farrell <stephen.farrell@cs.tcd.ie> CC: "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <44A033D0.1080503@nist.gov> <44AB8B9C.6020404@kent.ac.uk> <44ABC3FF.4070804@nist.gov> <44AEA9C8.2000607@kent.ac.uk> <44AEB1D9.9050301@cs.tcd.ie> In-Reply-To: <44AEB1D9.9050301@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: D.W.Chadwick@kent.ac.uk 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 ***************************************************************** Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k67JB5gB086324; Fri, 7 Jul 2006 12:11:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k67JB5KJ086323; Fri, 7 Jul 2006 12:11:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k67JB14f086303 for <ietf-pkix@imc.org>; Fri, 7 Jul 2006 12:11:03 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 0A709320C9; Fri, 7 Jul 2006 20:11:01 +0100 (IST) Received: from [127.0.0.1] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id k67JAxUa021373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jul 2006 20:10:59 +0100 Message-ID: <44AEB1D9.9050301@cs.tcd.ie> Date: Fri, 07 Jul 2006 20:11:21 +0100 From: Stephen Farrell <stephen.farrell@cs.tcd.ie> User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: David Chadwick <d.w.chadwick@kent.ac.uk> CC: "David A. Cooper" <david.cooper@nist.gov>, pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <44A033D0.1080503@nist.gov> <44AB8B9C.6020404@kent.ac.uk> <44ABC3FF.4070804@nist.gov> <44AEA9C8.2000607@kent.ac.uk> In-Reply-To: <44AEA9C8.2000607@kent.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 1658439 - 58caf553d593 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k67IbrAv078135; Fri, 7 Jul 2006 11:37:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k67Ibrs9078134; Fri, 7 Jul 2006 11:37:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx3.kent.ac.uk (mx3.kent.ac.uk [129.12.21.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k67Ibqr4078091 for <ietf-pkix@imc.org>; Fri, 7 Jul 2006 11:37:52 -0700 (MST) (envelope-from d.w.chadwick@kent.ac.uk) Received: from cpc2-hudd6-0-0-cust308.hudd.cable.ntl.com ([82.30.77.53]) by mx3.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1FyvCR-0005NU-MU; Fri, 07 Jul 2006 19:37:11 +0100 Message-ID: <44AEA9C8.2000607@kent.ac.uk> Date: Fri, 07 Jul 2006 19:36:56 +0100 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "David A. Cooper" <david.cooper@nist.gov> CC: pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <44A033D0.1080503@nist.gov> <44AB8B9C.6020404@kent.ac.uk> <44ABC3FF.4070804@nist.gov> In-Reply-To: <44ABC3FF.4070804@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: D.W.Chadwick@kent.ac.uk 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 ***************************************************************** Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k670hIUc010678; Thu, 6 Jul 2006 17:43:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k670hIRN010677; Thu, 6 Jul 2006 17:43:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k670hHBg010671 for <ietf-pkix@imc.org>; Thu, 6 Jul 2006 17:43:17 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from mmyerslaptop (dslstat-ppp-37.fastq.com [65.39.92.37]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id k670h6N92782; Thu, 6 Jul 2006 17:43:06 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" <mmyers@fastq.com> To: "Sharon Boeyen" <sharon.boeyen@entrust.com>, "'Kemp David P.'" <DPKemp@missi.ncsc.mil>, "David A. Cooper" <david.cooper@nist.gov>, "Turner, Sean P." <turners@ieca.com> Cc: "pkix" <ietf-pkix@imc.org> Subject: RE: name constraints on x400Address, ediPartyName, and registeredID name forms Date: Thu, 6 Jul 2006 17:41:55 -0800 Message-ID: <CCEJKFKLBCNMONJMIEAMOEHOCCAA.mmyers@fastq.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C6A123.791626E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F09EAD20F@sottmxs05.entrust.com> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 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> </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> </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> = owner-ietf-pkix@mail.imc.org=20 [mailto:owner-ietf-pkix@mail.imc.org]<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> </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 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = <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> </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> </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. But if there = is little=20 demand for names of this form there is little harm in discouraging = its use.=20 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> </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> </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 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = <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> </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. 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. =20 3280bis currently states:<BR><BR> Applications=20 conforming to this profile MUST be able to process name<BR> = =20 constraints that are imposed on the directoryName name form=20 and<BR> SHOULD be able to process name = constraints that=20 are imposed on the<BR> rfc822Name,=20 uniformResourceIdentifier, dNSName, and iPAddress name<BR> = =20 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. 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. = 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? 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"> <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"> <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"> <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"> <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"> = <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> </o:p></SPAN></FO NT></PRE><PRE><FONT face=3D"Courier = New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: = 10pt"> 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"> 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"> 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"> 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> </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. = Period. <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. 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. 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. 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"> = <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> </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 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> </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"> <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"> <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"> = <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 such constraints. 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"> <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> </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"> <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> </o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BLOCKQUOTE>= </S></FONT></FONT></BODY></HTML> ------=_NextPart_000_0006_01C6A123.791626E0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6705WeG098905; Thu, 6 Jul 2006 17:05:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6705Wi6098904; Thu, 6 Jul 2006 17:05:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k6705UL6098854 for <ietf-pkix@imc.org>; Thu, 6 Jul 2006 17:05:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 70960 invoked from network); 6 Jul 2006 23:32:30 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@70.21.27.42 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 6 Jul 2006 23:32:29 -0000 Reply-To: <turners@ieca.com> From: "Turner, Sean P." <turners@ieca.com> To: "'David A. Cooper'" <david.cooper@nist.gov> Cc: "'pkix'" <ietf-pkix@imc.org> Subject: RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt Date: Thu, 6 Jul 2006 19:32:18 -0400 Organization: IECA, Inc. Message-ID: <002e01c6a154$6c440640$0301a8c0@Wylie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C6A132.E5326640" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44ABDFB1.6000305@nist.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcagUJtNm6GiXHZUS36aHyb8/u3CTAA6OvEw Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 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> </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 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. If the=20 text doesn't add 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. = 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> </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> owner-ietf-pkix@mail.imc.org=20 [mailto:owner-ietf-pkix@mail.imc.org] <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. 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." 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. 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. So, the = X.509=20 definition of the issuingDistributionPoint extension does not include = the=20 onlyContainsAttributeCerts field. Always setting this value to = FALSE=20 ensures consistency with X.509. (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. 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. Explicit statements contradicting incorrect assumptions = should=20 only be used where there is evidence that confusion exists in that = area. =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-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k66F6scU059553; Thu, 6 Jul 2006 08:06:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k66F6s5X059550; Thu, 6 Jul 2006 08:06:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sottsym2.entrust.com (sottsym2.entrust.com [216.191.252.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k66F6pLN059524 for <ietf-pkix@imc.org>; Thu, 6 Jul 2006 08:06:51 -0700 (MST) (envelope-from sharon.boeyen@entrust.com) Received: from sottmxsecs3.entrust.com (unknown [216.191.252.14]) by sottsym2.entrust.com (Symantec Mail Security) with SMTP id 9CFC1240004 for <ietf-pkix@imc.org>; Thu, 6 Jul 2006 11:06:39 -0400 (EDT) Received: (qmail 16277 invoked from network); 6 Jul 2006 15:06:38 -0000 Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.4;06 Jul 2006 15:06:38 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 6 Jul 2006 15:06:37 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <NQV5TTQR>; Thu, 6 Jul 2006 11:06:38 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F09EAD20F@sottmxs05.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'Kemp David P.'" <DPKemp@missi.ncsc.mil>, "David A. Cooper" <david.cooper@nist.gov>, "Turner, Sean P." <turners@ieca.com> Cc: pkix <ietf-pkix@imc.org> Subject: RE: name constraints on x400Address, ediPartyName, and registered ID name forms Date: Thu, 6 Jul 2006 11:06:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A10D.666F861A" X-Brightmail-Tracker: AAAAAA== Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 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> </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> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <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> </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> </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. 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.<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> </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> </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"> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <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> </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. 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. 3280bis currently states:<BR><BR> Applications conforming to this profile MUST be able to process name<BR> constraints that are imposed on the directoryName name form and<BR> SHOULD be able to process name constraints that are imposed on the<BR> rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name<BR> 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. 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.<BR><BR>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?<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"> <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"> <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"> <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"> <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"> <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> </o:p></SPAN></FO NT></PRE><PRE><FONT face="Courier New" color=black size=2><SPAN style="FONT-SIZE: 10pt"> 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"> 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"> 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"> 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> </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. Period. <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. 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. 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. 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"> <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> </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> </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"> <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"> <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"> <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 such constraints. 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"> <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> </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"> <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> </o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C6A10D.666F861A-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65I925n051668; Wed, 5 Jul 2006 11:09:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k65I92gh051667; Wed, 5 Jul 2006 11:09:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65I90SC051636 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 11:09:00 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from gto.missi.ncsc.mil (goodman.missi.ncsc.mil [144.51.60.3]) by stingray.missi.ncsc.mil with ESMTP id k65I9M98006697; Wed, 5 Jul 2006 14:09:23 -0400 (EDT) Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 Jul 2006 14:08:53 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A05E.1310904A" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: name constraints on x400Address, ediPartyName, and registeredID name forms Date: Wed, 5 Jul 2006 14:08:52 -0400 Message-ID: <FA998122A677CF4390C1E291BFCF598904108B44@EXCH.missi.ncsc.mil> In-Reply-To: <44ABE567.1020608@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: name constraints on x400Address, ediPartyName, and registeredID name forms Thread-Index: AcagVj8FaquQJRtpTwm6497kwTu3uAAAdiYg From: "Kemp David P." <DPKemp@missi.ncsc.mil> To: "David A. Cooper" <david.cooper@nist.gov>, "Turner, Sean P." <turners@ieca.com> Cc: "pkix" <ietf-pkix@imc.org> X-OriginalArrivalTime: 05 Jul 2006 18:08:53.0896 (UTC) FILETIME=[135E6080:01C6A05E] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 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> </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'>“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=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span = style=3D'font-size: 10.0pt;font-family:Arial;color:navy'>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.<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> </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> </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'> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <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> </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. 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. 3280bis currently states:<br> <br> Applications conforming to this profile MUST be = able to process name<br> constraints that are imposed on the directoryName = name form and<br> SHOULD be able to process name constraints that are imposed on the<br> rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name<br> 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. 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.<br> <br> 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?<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'> <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'> <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'> <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'> <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'> = <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> </o:p></span></font></pre><pre><fon= t size=3D2 color=3Dblack face=3D"Courier New"><span = style=3D'font-size:10.0pt'> 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'> 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'> 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'> 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> </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. Period. = <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. 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. 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. 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'> = <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> </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> </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'> <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'> <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'> = <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 such = constraints. 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'> = <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> </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'> <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> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C6A05E.1310904A-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65GmOHs031717; Wed, 5 Jul 2006 09:48:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k65GmOw3031716; Wed, 5 Jul 2006 09:48:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65GmNmQ031708 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 09:48:23 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA45012 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 18:49:15 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2006070518482173:25962 ; Wed, 5 Jul 2006 18:48:21 +0200 Date: Wed, 5 Jul 2006 18:48:19 +0200 From: "Denis Pinkas" <denis.pinkas@bull.net> To: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Re: Question about indirect CRLs (and designated OCSP responders) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 05/07/2006 18:48:21, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 05/07/2006 18:48:22, Serialize complete at 05/07/2006 18:48:22 Message-ID: <OFFF92B1C2.51FAA98F-ONC12571A2.005C517D@frcl.bull.fr> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> >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" <denis.pinkas@bull.net> >To: <ietf-pkix@imc.org> >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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65GXfgp027967; Wed, 5 Jul 2006 09:33:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k65GXf3q027966; Wed, 5 Jul 2006 09:33:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65GXdZe027922 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 09:33:40 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id C98146807C; Wed, 5 Jul 2006 17:33:33 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A0580BC5F0D; Wed, 05 Jul 2006 17:33:33 +0100 Received: from [127.0.0.1] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id B99C46807C; Wed, 5 Jul 2006 17:33:33 +0100 (IST) Message-ID: <44ABE9F9.9050101@cs.tcd.ie> Date: Wed, 05 Jul 2006 17:34:01 +0100 From: Stephen Farrell <stephen.farrell@cs.tcd.ie> User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "David A. Cooper" <david.cooper@nist.gov> Cc: "Turner, Sean P." <turners@ieca.com>, pkix <ietf-pkix@imc.org> Subject: Re: name constraints on x400Address, ediPartyName, and registeredID name forms References: <009001c69c4e$0395d110$0201a8c0@Wylie> <44ABE567.1020608@nist.gov> In-Reply-To: <44ABE567.1020608@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A1580BC5F0D X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1245) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> David A. Cooper wrote: > What do others think? Its fine as-is IMO. Stephen. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65GEpp2023161; Wed, 5 Jul 2006 09:14:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k65GEpvC023159; Wed, 5 Jul 2006 09:14:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65GEnvn023135 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 09:14:49 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k65GEaNg016617; Wed, 5 Jul 2006 12:14:36 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k65GEGRq022357; Wed, 5 Jul 2006 12:14:17 -0400 (EDT) Message-ID: <44ABE567.1020608@nist.gov> Date: Wed, 05 Jul 2006 12:14:31 -0400 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Turner, Sean P." <turners@ieca.com> CC: pkix <ietf-pkix@imc.org> Subject: name constraints on x400Address, ediPartyName, and registeredID name forms References: <009001c69c4e$0395d110$0201a8c0@Wylie> In-Reply-To: <009001c69c4e$0395d110$0201a8c0@Wylie> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> 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. 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. 3280bis currently states:<br> <br> Applications conforming to this profile MUST be able to process name<br> constraints that are imposed on the directoryName name form and<br> SHOULD be able to process name constraints that are imposed on the<br> rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name<br> 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. 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.<br> <br> 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?<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> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65FonUZ017276; Wed, 5 Jul 2006 08:50:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k65FonHA017274; Wed, 5 Jul 2006 08:50:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65Foj7O017258 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 08:50:48 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k65FoZbJ028288; Wed, 5 Jul 2006 11:50:36 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k65Fnsvn005439; Wed, 5 Jul 2006 11:49:59 -0400 (EDT) Message-ID: <44ABDFB1.6000305@nist.gov> Date: Wed, 05 Jul 2006 11:50:09 -0400 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Turner, Sean P." <turners@ieca.com> CC: pkix <ietf-pkix@imc.org> Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt References: <009001c69c4e$0395d110$0201a8c0@Wylie> In-Reply-To: <009001c69c4e$0395d110$0201a8c0@Wylie> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> 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. 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." 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. 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. 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.)<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. 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. 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.<br> <br> Dave<br> <br> </body> </html> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65DrheO090203; Wed, 5 Jul 2006 06:53:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k65DrhZ8090202; Wed, 5 Jul 2006 06:53:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65DrfWM090190 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 06:53:42 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k65DqYVt003018; Wed, 5 Jul 2006 09:52:35 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k65Dpis2022660; Wed, 5 Jul 2006 09:51:45 -0400 (EDT) Message-ID: <44ABC3FF.4070804@nist.gov> Date: Wed, 05 Jul 2006 09:51:59 -0400 From: "David A. Cooper" <david.cooper@nist.gov> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chadwick <d.w.chadwick@kent.ac.uk> CC: pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <44A033D0.1080503@nist.gov> <44AB8B9C.6020404@kent.ac.uk> In-Reply-To: <44AB8B9C.6020404@kent.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65C5Abo063156; Wed, 5 Jul 2006 05:05:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k65C5AVx063155; Wed, 5 Jul 2006 05:05:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65C56PA063136 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 05:05:09 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id k65C52Am016416 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 20:05:02 +0800 Received: (from root@localhost) by ms20.chttl.com.tw (8.13.2/8.13.2) id k65C51dB004685 for ietf-pkix@imc.org; Wed, 5 Jul 2006 20:05:01 +0800 Received: from wcwang ([10.144.133.93]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id k65C4xHl004641 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 20:05:01 +0800 Message-ID: <033001c6a02b$3c6ca9b0$5d85900a@wcwang> From: "Wen-Cheng Wang" <wcwang@cht.com.tw> To: <ietf-pkix@imc.org> Subject: RFC 3280bis issue: guidance on handling circularity situations of revocation checking Date: Wed, 5 Jul 2006 20:04:55 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65Aq9c5043241; Wed, 5 Jul 2006 03:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k65Aq9ch043240; Wed, 5 Jul 2006 03:52:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k65Aq71D043221 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 03:52:08 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id k65Aq1cI008232 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 18:52:01 +0800 Received: (from root@localhost) by ms20.chttl.com.tw (8.13.2/8.13.2) id k65Aq0DC016568 for ietf-pkix@imc.org; Wed, 5 Jul 2006 18:52:00 +0800 Received: from wcwang ([10.144.133.93]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id k65Aq0Iv016510 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 18:52:00 +0800 Message-ID: <02a801c6a021$0935e610$5d85900a@wcwang> From: "Wen-Cheng Wang" <wcwang@cht.com.tw> To: <ietf-pkix@imc.org> Subject: Comments on RFC 3280bis-04 Date: Wed, 5 Jul 2006 18:51:57 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k659qZtm027642; Wed, 5 Jul 2006 02:52:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k659qZnu027641; Wed, 5 Jul 2006 02:52:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx3.kent.ac.uk (mx3.kent.ac.uk [129.12.21.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k659qYvc027596 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 02:52:34 -0700 (MST) (envelope-from d.w.chadwick@kent.ac.uk) Received: from cpc2-hudd6-0-0-cust308.hudd.cable.ntl.com ([82.30.77.53]) by mx3.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1Fy42j-0000Gr-R9; Wed, 05 Jul 2006 10:51:38 +0100 Message-ID: <44AB8B9C.6020404@kent.ac.uk> Date: Wed, 05 Jul 2006 10:51:24 +0100 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "David A. Cooper" <david.cooper@nist.gov> CC: pkix <ietf-pkix@imc.org> Subject: Re: draft-ietf-pkix-rfc3280bis-04.txt References: <44A033D0.1080503@nist.gov> In-Reply-To: <44A033D0.1080503@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: D.W.Chadwick@kent.ac.uk 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 ***************************************************************** Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6584OmB000477; Wed, 5 Jul 2006 01:04:24 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6584Nb8000471; Wed, 5 Jul 2006 01:04:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6584KII000404 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 01:04:21 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id k6584BhY021355; Wed, 5 Jul 2006 16:04:11 +0800 Received: (from root@localhost) by ms21.chttl.com.tw (8.13.2/8.13.2) id k6584CLL031516; Wed, 5 Jul 2006 16:04:12 +0800 Received: from wcwang ([10.144.133.93]) by ms21.chttl.com.tw (8.13.2/8.13.2) with SMTP id k6584Blw031480; Wed, 5 Jul 2006 16:04:11 +0800 Message-ID: <01da01c6a009$978df2d0$5d85900a@wcwang> From: "Wen-Cheng Wang" <wcwang@cht.com.tw> To: "Dr Stephen Henson" <lists@drh-consultancy.demon.co.uk>, <ietf-pkix@imc.org> References: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> <00ab01c69f0b$f5942060$5d85900a@wcwang> <20060704084447.GC19921@cryptolog.com> <01cf01c69f4a$b862d940$5d85900a@wcwang> <20060704094012.GE19921@cryptolog.com> <020701c69f56$8bc316a0$5d85900a@wcwang> <20060704121040.GH19921@cryptolog.com> <44AA67A7.3060200@drh-consultancy.demon.co.uk> Subject: Re: Question about indirect CRLs (and designated OCSP responders) Date: Wed, 5 Jul 2006 16:04:07 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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" <lists@drh-consultancy.demon.co.uk> To: <ietf-pkix@imc.org> 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. > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k657o2mN097194; Wed, 5 Jul 2006 00:50:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k657o2wS097189; Wed, 5 Jul 2006 00:50:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k657nwrU097135 for <ietf-pkix@imc.org>; Wed, 5 Jul 2006 00:50:00 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id k657nof4019808; Wed, 5 Jul 2006 15:49:50 +0800 Received: (from root@localhost) by ms20.chttl.com.tw (8.13.2/8.13.2) id k657nnMr012151; Wed, 5 Jul 2006 15:49:49 +0800 Received: from wcwang ([10.144.133.93]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id k657nmZE012075; Wed, 5 Jul 2006 15:49:49 +0800 Message-ID: <01ca01c6a007$9615bca0$5d85900a@wcwang> From: "Wen-Cheng Wang" <wcwang@cht.com.tw> To: "Julien Stern" <julien.stern@cryptolog.com>, <ietf-pkix@imc.org> References: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> <00ab01c69f0b$f5942060$5d85900a@wcwang> <20060704084447.GC19921@cryptolog.com> <01cf01c69f4a$b862d940$5d85900a@wcwang> <20060704094012.GE19921@cryptolog.com> <020701c69f56$8bc316a0$5d85900a@wcwang> <20060704121040.GH19921@cryptolog.com> Subject: Re: Question about indirect CRLs (and designated OCSP responders) Date: Wed, 5 Jul 2006 15:49:45 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Please see my opinions in-line. Wen-Cheng Wang ----- Original Message ----- From: "Julien Stern" <julien.stern@cryptolog.com> To: <ietf-pkix@imc.org> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64E3Eb7064287; Tue, 4 Jul 2006 07:03:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64E3EFY064286; Tue, 4 Jul 2006 07:03:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from uekae.uekae.gov.tr (uekae.uekae.tubitak.gov.tr [193.140.74.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64E3Dsf064269 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 07:03:13 -0700 (MST) (envelope-from ihasircioglu@uekae.tubitak.gov.tr) Received: from www.uekae.tubitak.gov.tr (hitit.uekae.tubitak.gov.tr [192.168.5.6]) by uekae.uekae.gov.tr (UEKAE_MAIL_SERVER_V4) with ESMTP id C9BD5490166 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 17:01:34 +0300 (EEST) Received: from 10.1.4.21 (SquirrelMail authenticated user ihasircioglu) by www.uekae.tubitak.gov.tr with HTTP; Tue, 4 Jul 2006 16:59:46 +0300 (EEST) Date: Tue, 4 Jul 2006 16:59:46 +0300 (EEST) Subject: From: ihasircioglu@uekae.tubitak.gov.tr To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-9 X-Priority: 3 (Normal) Importance: Normal Message-Id: <20060704140134.F12E1490166@uekae.uekae.gov.tr> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k64E3Esf064280 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> unsubscribe Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64DStfk052180; Tue, 4 Jul 2006 06:28:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64DSt0c052179; Tue, 4 Jul 2006 06:28:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64DSswO052147 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 06:28:54 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Question about indirect CRLs (and designated OCSP responders) Date: Tue, 4 Jul 2006 06:28:44 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879037910CA@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about indirect CRLs (and designated OCSP responders) Thread-Index: AcafbZD/rJlasNlARTGkmE4nl2BjBgAAAwtA From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k64DStwO052174 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, July 04, 2006 8:11 AM To: ietf-pkix@imc.org 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" <julien.stern@cryptolog.com> > To: <ietf-pkix@imc.org> > 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" <julien.stern@cryptolog.com> > >>To: <ietf-pkix@imc.org> > >>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." <DPKemp@missi.ncsc.mil> > >>>>To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> > >>>>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: owner-ietf-pkix@mail.imc.org > >>[mailto:owner-ietf-pkix@mail.imc.org] > >>>>>On Behalf Of Julien Stern > >>>>>Sent: Monday, July 03, 2006 1:43 PM > >>>>>To: ietf-pkix@imc.org > >>>>>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 > >>>>> > >>>>> > >>>>> > >>>> > >>> > >> > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64D5tBW044430; Tue, 4 Jul 2006 06:05:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64D5t1x044429; Tue, 4 Jul 2006 06:05:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay1.mail.uk.clara.net (relay1.mail.uk.clara.net [80.168.70.141]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64D5r6S044422 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 06:05:54 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from [149.254.200.215] (helo=[10.33.185.155]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.46) id 1Fxkb9-0006db-HN for ietf-pkix@imc.org; Tue, 04 Jul 2006 14:05:52 +0100 Message-ID: <44AA67A7.3060200@drh-consultancy.demon.co.uk> Date: Tue, 04 Jul 2006 14:05:43 +0100 From: Dr Stephen Henson <lists@drh-consultancy.demon.co.uk> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Question about indirect CRLs (and designated OCSP responders) References: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> <00ab01c69f0b$f5942060$5d85900a@wcwang> <20060704084447.GC19921@cryptolog.com> <01cf01c69f4a$b862d940$5d85900a@wcwang> <20060704094012.GE19921@cryptolog.com> <020701c69f56$8bc316a0$5d85900a@wcwang> <20060704121040.GH19921@cryptolog.com> In-Reply-To: <20060704121040.GH19921@cryptolog.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64CviO3042358; Tue, 4 Jul 2006 05:57:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64Cvi2I042357; Tue, 4 Jul 2006 05:57:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64CviX3042338 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 05:57:44 -0700 (MST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Question about indirect CRLs (and designated OCSP responders) Date: Tue, 4 Jul 2006 05:57:34 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879037910C1@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about indirect CRLs (and designated OCSP responders) Thread-Index: AcafVCTovt2vXCtWQ5CQ1e7cwP9krgAFSarg From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-pkix@imc.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k64CviX3042352 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, July 04, 2006 4:19 AM To: ietf-pkix@imc.org 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." <DPKemp@missi.ncsc.mil> >To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> >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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] >> On Behalf Of Julien Stern >> Sent: Monday, July 03, 2006 1:43 PM >> To: ietf-pkix@imc.org >> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64CvFHm042252; Tue, 4 Jul 2006 05:57:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64CvFj4042251; Tue, 4 Jul 2006 05:57:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64CvDDC042242 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 05:57:14 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA31030 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 14:58:04 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2006070414571139:11447 ; Tue, 4 Jul 2006 14:57:11 +0200 Date: Tue, 4 Jul 2006 14:57:09 +0200 From: "Denis Pinkas" <denis.pinkas@bull.net> To: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Comment on RFC 3280bis: id-pkix-crl-nocheck extension X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 04/07/2006 14:57:11, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 04/07/2006 14:57:12, Serialize complete at 04/07/2006 14:57:12 Message-ID: <OFC4245A45.9E4A5991-ONC12571A1.00472778@frcl.bull.fr> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64CRFsF032914; Tue, 4 Jul 2006 05:27:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64CRFAV032911; Tue, 4 Jul 2006 05:27:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64CRE1p032892 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 05:27:14 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id C2C6140F5B for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 14:27:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 0EADD44103 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 14:28:03 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20648-07 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 14:27:58 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id B2E6D440ED for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 14:27:57 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 4 Jul 2006 14:27:07 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Tue, 4 Jul 2006 14:27:07 +0200 To: ietf-pkix@imc.org Subject: Re: Question about indirect CRLs (and designated OCSP responders) Message-ID: <20060704122706.GI19921@cryptolog.com> Mail-Followup-To: Julien Stern <julien.stern@cryptolog.com>, ietf-pkix@imc.org References: <20060703174305.GA19921@cryptolog.com> <E2339D02A340A546998AD2E6251332D6034E46BC@csexchange1.corestreet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <E2339D02A340A546998AD2E6251332D6034E46BC@csexchange1.corestreet.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On > Behalf Of Julien Stern > Sent: Monday, July 03, 2006 1:43 PM > To: ietf-pkix@imc.org > 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 > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64CAo1F027317; Tue, 4 Jul 2006 05:10:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64CAoG6027316; Tue, 4 Jul 2006 05:10:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64CAlfG027252 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 05:10:48 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id 0C3914F3CC for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 14:10:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 8448144103 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 14:11:36 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20648-01 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 14:11:31 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id A954B440ED for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 14:11:30 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 4 Jul 2006 14:10:40 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Tue, 4 Jul 2006 14:10:40 +0200 To: ietf-pkix@imc.org Subject: Re: Question about indirect CRLs (and designated OCSP responders) Message-ID: <20060704121040.GH19921@cryptolog.com> Mail-Followup-To: Julien Stern <julien.stern@cryptolog.com>, ietf-pkix@imc.org References: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> <00ab01c69f0b$f5942060$5d85900a@wcwang> <20060704084447.GC19921@cryptolog.com> <01cf01c69f4a$b862d940$5d85900a@wcwang> <20060704094012.GE19921@cryptolog.com> <020701c69f56$8bc316a0$5d85900a@wcwang> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020701c69f56$8bc316a0$5d85900a@wcwang> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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" <julien.stern@cryptolog.com> > To: <ietf-pkix@imc.org> > 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" <julien.stern@cryptolog.com> > >>To: <ietf-pkix@imc.org> > >>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." <DPKemp@missi.ncsc.mil> > >>>>To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> > >>>>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: owner-ietf-pkix@mail.imc.org > >>[mailto:owner-ietf-pkix@mail.imc.org] > >>>>>On Behalf Of Julien Stern > >>>>>Sent: Monday, July 03, 2006 1:43 PM > >>>>>To: ietf-pkix@imc.org > >>>>>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 > >>>>> > >>>>> > >>>>> > >>>> > >>> > >> > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64BFuMA007456; Tue, 4 Jul 2006 04:15:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64BFu2d007450; Tue, 4 Jul 2006 04:15:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64BFquH007387 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 04:15:53 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id k64BFf3n017727; Tue, 4 Jul 2006 19:15:41 +0800 Received: (from root@localhost) by ms20.chttl.com.tw (8.13.2/8.13.2) id k64BFeI2009642; Tue, 4 Jul 2006 19:15:40 +0800 Received: from wcwang ([10.144.133.93]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id k64BFaso009604; Tue, 4 Jul 2006 19:15:40 +0800 Message-ID: <021d01c69f5b$2db8e490$5d85900a@wcwang> From: "Wen-Cheng Wang" <wcwang@cht.com.tw> To: "Denis Pinkas" <denis.pinkas@bull.net>, <ietf-pkix@imc.org> References: <OF62605AC9.AF0BA278-ONC12571A1.0037D9DF@frcl.bull.fr> Subject: Re: Question about indirect CRLs (and designated OCSP responders) Date: Tue, 4 Jul 2006 19:15:33 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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" <denis.pinkas@bull.net> To: <ietf-pkix@imc.org> 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 > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64AmuEe098529; Tue, 4 Jul 2006 03:48:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64Amuhs098528; Tue, 4 Jul 2006 03:48:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64AmttF098504 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 03:48:55 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id E3F9440ED6 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 12:48:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id F324C44103 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 12:49:43 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20052-09 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 12:49:40 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 25CD7440ED for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 12:49:39 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 4 Jul 2006 12:48:49 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Tue, 4 Jul 2006 12:48:49 +0200 To: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Re: Question about indirect CRLs (and designated OCSP responders) Message-ID: <20060704104848.GG19921@cryptolog.com> Mail-Followup-To: Julien Stern <julien.stern@cryptolog.com>, "ietf-pkix@imc.org" <ietf-pkix@imc.org> References: <OF62605AC9.AF0BA278-ONC12571A1.0037D9DF@frcl.bull.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <OF62605AC9.AF0BA278-ONC12571A1.0037D9DF@frcl.bull.fr> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64Agcfx096348; Tue, 4 Jul 2006 03:42:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64AgcaY096347; Tue, 4 Jul 2006 03:42:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64AgZwj096340 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 03:42:36 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id k64AgWJV013753; Tue, 4 Jul 2006 18:42:32 +0800 Received: (from root@localhost) by ms20.chttl.com.tw (8.13.2/8.13.2) id k64AgViD030230; Tue, 4 Jul 2006 18:42:31 +0800 Received: from wcwang ([10.144.133.93]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id k64AgUit030194; Tue, 4 Jul 2006 18:42:30 +0800 Message-ID: <020701c69f56$8bc316a0$5d85900a@wcwang> From: "Wen-Cheng Wang" <wcwang@cht.com.tw> To: "Julien Stern" <julien.stern@cryptolog.com>, <ietf-pkix@imc.org> References: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> <00ab01c69f0b$f5942060$5d85900a@wcwang> <20060704084447.GC19921@cryptolog.com> <01cf01c69f4a$b862d940$5d85900a@wcwang> <20060704094012.GE19921@cryptolog.com> Subject: Re: Question about indirect CRLs (and designated OCSP responders) Date: Tue, 4 Jul 2006 18:42:28 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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" <julien.stern@cryptolog.com> To: <ietf-pkix@imc.org> 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" <julien.stern@cryptolog.com> >> To: <ietf-pkix@imc.org> >> 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." <DPKemp@missi.ncsc.mil> >> >>To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> >> >>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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] >> >>>On Behalf Of Julien Stern >> >>>Sent: Monday, July 03, 2006 1:43 PM >> >>>To: ietf-pkix@imc.org >> >>>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 >> >>> >> >>> >> >>> >> >> >> > >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64AA7NP084731; Tue, 4 Jul 2006 03:10:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k64AA7Ym084730; Tue, 4 Jul 2006 03:10:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k64AA5GS084724 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 03:10:06 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA37752 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 12:10:56 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2006070412100255:7286 ; Tue, 4 Jul 2006 12:10:02 +0200 Date: Tue, 4 Jul 2006 12:10:00 +0200 From: "Denis Pinkas" <denis.pinkas@bull.net> To: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Re:Question about indirect CRLs (and designated OCSP responders) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 04/07/2006 12:10:02, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 04/07/2006 12:10:04, Serialize complete at 04/07/2006 12:10:04 Message-ID: <OF62605AC9.AF0BA278-ONC12571A1.0037D9DF@frcl.bull.fr> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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" <julien.stern@cryptolog.com> >To: <ietf-pkix@imc.org> >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." <DPKemp@missi.ncsc.mil> >>> To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> >>> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] >>> >On Behalf Of Julien Stern >>> >Sent: Monday, July 03, 2006 1:43 PM >>> >To: ietf-pkix@imc.org >>> >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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k649eLI1075962; Tue, 4 Jul 2006 02:40:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k649eLjI075961; Tue, 4 Jul 2006 02:40:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k649eJ9Z075938 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 02:40:20 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id 92AF34F432 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 11:40:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 8900A44103 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 11:41:08 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19942-03 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 11:41:04 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 050BF440ED for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 11:41:02 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 4 Jul 2006 11:40:13 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Tue, 4 Jul 2006 11:40:12 +0200 To: ietf-pkix@imc.org Subject: Re: Question about indirect CRLs (and designated OCSP responders) Message-ID: <20060704094012.GE19921@cryptolog.com> Mail-Followup-To: Julien Stern <julien.stern@cryptolog.com>, ietf-pkix@imc.org References: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> <00ab01c69f0b$f5942060$5d85900a@wcwang> <20060704084447.GC19921@cryptolog.com> <01cf01c69f4a$b862d940$5d85900a@wcwang> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01cf01c69f4a$b862d940$5d85900a@wcwang> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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" <julien.stern@cryptolog.com> > To: <ietf-pkix@imc.org> > 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." <DPKemp@missi.ncsc.mil> > >>To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> > >>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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > >>>On Behalf Of Julien Stern > >>>Sent: Monday, July 03, 2006 1:43 PM > >>>To: ietf-pkix@imc.org > >>>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 > >>> > >>> > >>> > >> > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k649I9Ve068883; Tue, 4 Jul 2006 02:18:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k649I9ok068882; Tue, 4 Jul 2006 02:18:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k649I6jn068857 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 02:18:07 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id k649HqC4004591; Tue, 4 Jul 2006 17:17:52 +0800 Received: (from root@localhost) by ms20.chttl.com.tw (8.13.2/8.13.2) id k649HqIx002335; Tue, 4 Jul 2006 17:17:52 +0800 Received: from wcwang ([10.144.133.93]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id k649HnRt002298; Tue, 4 Jul 2006 17:17:49 +0800 Message-ID: <01cf01c69f4a$b862d940$5d85900a@wcwang> From: "Wen-Cheng Wang" <wcwang@cht.com.tw> To: "Julien Stern" <julien.stern@cryptolog.com>, <ietf-pkix@imc.org> References: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> <00ab01c69f0b$f5942060$5d85900a@wcwang> <20060704084447.GC19921@cryptolog.com> Subject: Re: Question about indirect CRLs (and designated OCSP responders) Date: Tue, 4 Jul 2006 17:17:46 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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" <julien.stern@cryptolog.com> To: <ietf-pkix@imc.org> 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." <DPKemp@missi.ncsc.mil> >> To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> >> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] >> >On Behalf Of Julien Stern >> >Sent: Monday, July 03, 2006 1:43 PM >> >To: ietf-pkix@imc.org >> >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 >> > >> > >> > >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k648itI3059077; Tue, 4 Jul 2006 01:44:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k648itEd059076; Tue, 4 Jul 2006 01:44:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k648is4k059059 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 01:44:54 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id A5A8440F59 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 10:44:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 8C23244103 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 10:45:42 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19641-01 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 10:45:39 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 29A20440ED for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 10:45:38 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 4 Jul 2006 10:44:48 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Tue, 4 Jul 2006 10:44:48 +0200 To: ietf-pkix@imc.org Subject: Re: Question about indirect CRLs (and designated OCSP responders) Message-ID: <20060704084447.GC19921@cryptolog.com> Mail-Followup-To: Julien Stern <julien.stern@cryptolog.com>, ietf-pkix@imc.org References: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> <00ab01c69f0b$f5942060$5d85900a@wcwang> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ab01c69f0b$f5942060$5d85900a@wcwang> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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." <DPKemp@missi.ncsc.mil> > To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> > 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > >On Behalf Of Julien Stern > >Sent: Monday, July 03, 2006 1:43 PM > >To: ietf-pkix@imc.org > >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 > > > > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k648aK2i056248; Tue, 4 Jul 2006 01:36:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k648aKqZ056247; Tue, 4 Jul 2006 01:36:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k648aJrF056237 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 01:36:19 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id 673564F432 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 10:36:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id A5CB344103 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 10:37:07 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19431-07 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 10:37:03 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 5798B440ED for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 10:37:02 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 4 Jul 2006 10:36:12 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Tue, 4 Jul 2006 10:36:12 +0200 To: ietf-pkix@imc.org Subject: Re: Question about indirect CRLs (and designated OCSP responders) Message-ID: <20060704083610.GB19921@cryptolog.com> Mail-Followup-To: Julien Stern <julien.stern@cryptolog.com>, ietf-pkix@imc.org References: <20060703174305.GA19921@cryptolog.com> <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Julien Stern > Sent: Monday, July 03, 2006 1:43 PM > To: ietf-pkix@imc.org > 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 > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k648J5L9050671; Tue, 4 Jul 2006 01:19:06 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k648J5LB050670; Tue, 4 Jul 2006 01:19:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k648J4P8050662 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 01:19:05 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA34002 for <ietf-pkix@imc.org>; Tue, 4 Jul 2006 10:19:54 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2006070410190143:4075 ; Tue, 4 Jul 2006 10:19:01 +0200 Date: Tue, 4 Jul 2006 10:18:59 +0200 From: "Denis Pinkas" <denis.pinkas@bull.net> To: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Re: Question about indirect CRLs (and designated OCSP responders) X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 04/07/2006 10:19:01, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 04/07/2006 10:19:03, Serialize complete at 04/07/2006 10:19:03 Message-ID: <OF560728B7.7BFAA513-ONC12571A1.002DAFE1@frcl.bull.fr> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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." <DPKemp@missi.ncsc.mil> >To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> >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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] >> On Behalf Of Julien Stern >> Sent: Monday, July 03, 2006 1:43 PM >> To: ietf-pkix@imc.org >> 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k643OqcP057399; Mon, 3 Jul 2006 20:24:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k643OqEU057398; Mon, 3 Jul 2006 20:24:52 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k643Oo0t057388 for <ietf-pkix@imc.org>; Mon, 3 Jul 2006 20:24:51 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id k643OElj029351; Tue, 4 Jul 2006 11:24:14 +0800 Received: (from root@localhost) by ms21.chttl.com.tw (8.13.2/8.13.2) id k643OEg2032202; Tue, 4 Jul 2006 11:24:14 +0800 Received: from wcwang ([10.144.133.93]) by ms21.chttl.com.tw (8.13.2/8.13.2) with SMTP id k643O69G032079; Tue, 4 Jul 2006 11:24:06 +0800 Message-ID: <013901c69f19$517f16c0$5d85900a@wcwang> From: "Wen-Cheng Wang" <wcwang@cht.com.tw> To: "Stefan Santesson" <stefans@microsoft.com>, "Brad Hards" <bradh@frogmouth.net>, "Sharon Boeyen" <sharon.boeyen@entrust.com> Cc: <ietf-pkix@imc.org> References: <BF9309599A71984CAC5BAC5ECA629944053D05FC@EUR-MSG-11.europe.corp.microsoft.com> Subject: Re: last call for 3280bis - escape clause Date: Tue, 4 Jul 2006 11:24:03 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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" <stefans@microsoft.com> To: "Brad Hards" <bradh@frogmouth.net>; "Sharon Boeyen" <sharon.boeyen@entrust.com> Cc: <ietf-pkix@imc.org> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Brad Hards > Sent: den 23 juni 2006 14:03 > To: Sharon Boeyen > Cc: ietf-pkix@imc.org > 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 > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k641mt6Y024264; Mon, 3 Jul 2006 18:48:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k641mtBX024263; Mon, 3 Jul 2006 18:48:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k641mpSB024209 for <ietf-pkix@imc.org>; Mon, 3 Jul 2006 18:48:53 -0700 (MST) (envelope-from wcwang@cht.com.tw) Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id k641maiC019452; Tue, 4 Jul 2006 09:48:36 +0800 Received: (from root@localhost) by ms21.chttl.com.tw (8.13.2/8.13.2) id k641maDU019236; Tue, 4 Jul 2006 09:48:36 +0800 Received: from wcwang ([10.144.133.93]) by ms21.chttl.com.tw (8.13.2/8.13.2) with SMTP id k641mYrd019158; Tue, 4 Jul 2006 09:48:34 +0800 Message-ID: <00ab01c69f0b$f5942060$5d85900a@wcwang> From: "Wen-Cheng Wang" <wcwang@cht.com.tw> To: "Kemp David P." <DPKemp@missi.ncsc.mil>, "Julien Stern" <julien.stern@cryptolog.com>, <ietf-pkix@imc.org> References: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> Subject: Re: Question about indirect CRLs (and designated OCSP responders) Date: Tue, 4 Jul 2006 09:48:32 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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." <DPKemp@missi.ncsc.mil> To: "Julien Stern" <julien.stern@cryptolog.com>; <ietf-pkix@imc.org> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Julien Stern > Sent: Monday, July 03, 2006 1:43 PM > To: ietf-pkix@imc.org > 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 > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k63K0lIa001667; Mon, 3 Jul 2006 13:00:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k63K0lQg001664; Mon, 3 Jul 2006 13:00:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k63K0kL0001618 for <ietf-pkix@imc.org>; Mon, 3 Jul 2006 13:00:46 -0700 (MST) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Question about indirect CRLs (and designated OCSP responders) Date: Mon, 3 Jul 2006 16:00:18 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_023A_01C69EB9.C78999E0" Message-ID: <E2339D02A340A546998AD2E6251332D6034E46BC@csexchange1.corestreet.com> in-reply-to: <20060703174305.GA19921@cryptolog.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Question about indirect CRLs (and designated OCSP responders) Thread-Index: AcaeycB1AOjw6BoIRWqTrlMQWdG/ywAD6E7w From: "Dave Engberg" <dengberg@corestreet.com> To: "Julien Stern" <julien.stern@cryptolog.com>, <ietf-pkix@imc.org> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Monday, July 03, 2006 1:43 PM To: ietf-pkix@imc.org 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" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIUjCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAwgwggJxoAMCAQICAWswDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDUwNzE1MTYyNzE3WhcNMDYw NzI5MTYyNzE3WjBnMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRYwFAYD VQQDEw1EYXZpZCBFbmdiZXJnMSYwJAYJKoZIhvcNAQkBFhdkZW5nYmVyZ0Bjb3Jlc3RyZWV0LmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwNGdTqlz9yCxynq+ugIn+JW2nFkQ2CbJTDzO dvIMXbTO20RuxhND/c2i4kWNK4WAWsHLdoZBPsIrlnuzLPD5MjRaPHUQGzoa0WqattZ4yILrBX1o MrqP+LXJRbemhHy0F8+TjtXuGAykZgpzJDYOT0PvVRKoBGZE9EcY76bPM30CAwEAAaOB2DCB1TAO BgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5jb20v Y3Jscy9jb3Jlc3RyZWV0LmNybDAiBgNVHREEGzAZgRdkZW5nYmVyZ0Bjb3Jlc3RyZWV0LmNvbTAf BgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBABggrBgEFBQcBAQQ0MDIwMAYIKwYBBQUH MAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJlZXQuY29tLzANBgkqhkiG9w0BAQUFAAOB gQAQh9PhK3fLpSK70kcAcEoa2qoTBzxG+nDM5DKoytO06EFzwbGY3lJ8ngwzJpTN3eseassTXsZ2 fSWww5xYpogI+lI1UhwCVxif713+bEZDkzTzgaSRd9ykCLZj4ao6UPTtbcQ9I86PnDHQBoxCKEfY r2LijQkoDFANC4aHhfsO+DGCApkwggKVAgEBMFcwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0Nv cmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkC AWswCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNzAzMjAwMDE4WjAjBgkqhkiG9w0BCQQxFgQUQ/vpq36arPW08K5O3EaUOW8Ky74wZgYJ KwYBBAGCNxAEMVkwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkw JwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBazBnBgkqhkiG9w0BCQ8x WjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsqhkiG9w0BCRACCzFZoFcwUjEL MAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVl dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAWswDQYJKoZIhvcNAQEBBQAEgYCjX6EGbdAGq5RjAz3o VaWTXFKDu2833UdK6Z5w2lNZMV0LAopabCQr9jh006rP2oRERGwLmVEtIYxUEztHyZnWvvynaRKy JTh9n6GV48XtqMFX4TMVjC3PKkBlbeqjQHxKlA7ZkBmTiS6CECQ5JJjPs8JOulcdIuACcMSAuV3N LgAAAAAAAA== ------=_NextPart_000_023A_01C69EB9.C78999E0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k63JjdhG096578; Mon, 3 Jul 2006 12:45:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k63Jjdf8096575; Mon, 3 Jul 2006 12:45:39 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k63JjcYe096502 for <ietf-pkix@imc.org>; Mon, 3 Jul 2006 12:45:38 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Received: from gto.missi.ncsc.mil (goodman.missi.ncsc.mil [144.51.60.3]) by stingray.missi.ncsc.mil with ESMTP id k63Jjn98023417; Mon, 3 Jul 2006 15:45:49 -0400 (EDT) Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Jul 2006 15:45:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Question about indirect CRLs (and designated OCSP responders) Date: Mon, 3 Jul 2006 15:45:19 -0400 Message-ID: <FA998122A677CF4390C1E291BFCF5989041089A2@EXCH.missi.ncsc.mil> In-Reply-To: <20060703174305.GA19921@cryptolog.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about indirect CRLs (and designated OCSP responders) Thread-Index: Acaezt+5Q6NORaB7Q+GvbOV1DCJ1agAAnt+A From: "Kemp David P." <DPKemp@missi.ncsc.mil> To: "Julien Stern" <julien.stern@cryptolog.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 03 Jul 2006 19:45:20.0909 (UTC) FILETIME=[37DEFBD0:01C69ED9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k63JjcYe096567 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Monday, July 03, 2006 1:43 PM To: ietf-pkix@imc.org 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k63HiZTY036751; Mon, 3 Jul 2006 10:44:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k63HiY1m036748; Mon, 3 Jul 2006 10:44:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k63HiXLR036721 for <ietf-pkix@imc.org>; Mon, 3 Jul 2006 10:44:33 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id EF23940E27 for <ietf-pkix@imc.org>; Mon, 3 Jul 2006 19:43:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 6F12B440ED for <ietf-pkix@imc.org>; Mon, 3 Jul 2006 19:44:09 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15671-01 for <ietf-pkix@imc.org>; Mon, 3 Jul 2006 19:44:02 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 97A9744006 for <ietf-pkix@imc.org>; Mon, 3 Jul 2006 19:44:01 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon, 3 Jul 2006 19:43:11 +0200 From: "Julien Stern" <julien.stern@cryptolog.com> Date: Mon, 3 Jul 2006 19:43:11 +0200 To: ietf-pkix@imc.org Subject: Question about indirect CRLs (and designated OCSP responders) Message-ID: <20060703174305.GA19921@cryptolog.com> Mail-Followup-To: Julien Stern <julien.stern@cryptolog.com>, ietf-pkix@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> 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
![src="http://www.paypalobjects.com/en_US/i/header/t1Hdr_hpGraphic_563x115.jpg"](http://src="http://www.paypalobjects.com/en_US/i/header/t1Hdr_hpGraphic_563x115.jpg%22){kind=link}
![src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif"](http://src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif%22){kind=link}
![src="http://images.paypal.com/en_US/i/logo/email_logo.gif"](http://src="http://images.paypal.com/en_US/i/logo/email_logo.gif%22){kind=link}
![background="http://images.paypal.com/images/bg_clk.gif"](http://background="http://images.paypal.com/images/bg_clk.gif%22){kind=link}
![src="http://images.paypal.com/images/pixel.gif"](http://src="http://images.paypal.com/images/pixel.gif%22){kind=link}
- Request to review draft-adamson-rfc2847-bis Sam Hartman