From owner-ietf-pkix@mail.imc.org Fri Apr 1 16:33:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23339 for ; Fri, 1 Apr 2005 16:33:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31KR7f7003197; Fri, 1 Apr 2005 12:27:07 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31KR7VH003196; Fri, 1 Apr 2005 12:27:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31KR6hs003190 for ; Fri, 1 Apr 2005 12:27:07 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06253; Fri, 1 Apr 2005 15:27:02 -0500 (EST) Message-Id: <200504012027.PAA06253@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-01.txt Date: Fri, 01 Apr 2005 15:27:02 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-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 : Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX Author(s) : D. Brown Filename : draft-ietf-pkix-ecc-pkalgs-01.txt Pages : 25 Date : 2005-4-1 This document gives additional algorithms and associated ASN.1 identifiers for elliptic curve cryptography (ECC) used with the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (PKIX). The algorithms and identifiers here are consistent with both ANSI X9.62-1998 and X9.63-2001, and shall be consistent with the forthcoming revisions of these documents. Consistency shall also be maintained with SEC1 and SEC2, and any revisions or successors of such documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-01.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-ecc-pkalgs-01.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-ecc-pkalgs-01.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: <2005-4-1155132.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ecc-pkalgs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-1155132.I-D@ietf.org> --OtherAccess-- --NextPart-- From hankhubers@myway.com Tue Apr 5 18:31:47 2005 Received: from de-727tes58grwa (a32159.upc-a.chello.nl [62.163.32.159]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26219 for ; Tue, 5 Apr 2005 18:31:47 -0400 (EDT) Message-Id: <200504052231.SAA26219@ietf.org> From: "Skylink" To: pkix-archive@ietf.org Subject: Call for your claims Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 6 Apr 2005 00:31:38 FROM: THE DIRECTOR EUROPEAN PRIZE AWARD DEPT. REF:EL3/9318/05 BATCH:8/163/EL. Dear Sir/Madam, We are pleased to inform you of the result of the Lottery Winners International programs held on the 20/03/2005. Your e-mail address attached to ticket number: EL-23133 with serial Number: EL-123542, batch number: 8/163/EL-35, lottery Ref number: EL-9318 and drew lucky numbers 7-1-8-36-4-22 which consequently won in the 1st category, you have therefore been approved for a lump sum pay out of US$1,500,000.00 (One Million, Five Hundred Thousand United States dollars) CONGRATULATIONS!!! Due to mix up of some numbers and names, we ask that you keep your Winning information confidential until your claims has been Processed and your money Remitted to you. This is part of our Security protocol to avoid double claiming and unwarranted abuse of This program by some participants. All participants were selected through a computer ballot system drawn from over 40,000 company and 20,000,000 individual email addresses and names from all over the world. This promotional program takes place every year. This lottery was Promoted and sponsored by a group of successful electronic dealers. we hope with part of your winning, you will take part in our next year US$20 million international lottery. To file for your claim, please Contact our paying officer: Contact Person: Mr. Hank Hubers(Lottery Director) Mr. Hank Hubers Tel: +31-617-012-526 Email: hankhubers@mycity.com hankhubers@netscape.net Remember, all winning must be claimed not later than 16th of April, 2005.After this date all unclaimed funds will be included in the next stake. Please note in order to avoid unnecessary delays and complications Please remember to quote your reference number and batch numbers in all correspondence. Furthermore, should there be any change of address do inform our agent as soon as possible. Congratulations once more from our members of staff and thank you for being part of our promotional program. Note: Anybody under the age of 18 is automatically disqualified. yours Sincerely, Mr. Hank Hubers Tel: +31-617-012-526 Email: hankhubers@mycity.com hankhubers@netscape.net From owner-ietf-pkix@mail.imc.org Thu Apr 7 15:26:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00013 for ; Thu, 7 Apr 2005 15:26:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37IIV3F098488; Thu, 7 Apr 2005 11:18:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37IIV5x098486; Thu, 7 Apr 2005 11:18:31 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j37IIUdL098480 for ; Thu, 7 Apr 2005 11:18:30 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j37II0aP028643; Thu, 7 Apr 2005 14:18:01 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j37IHs9r003847; Thu, 7 Apr 2005 14:17:54 -0400 (EDT) Message-Id: <5.1.0.14.2.20050407135300.033df3c0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Apr 2005 14:19:09 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: PKIX WG Last Call: 3770bis Cc: kent@bbn.com, housley@vigilsec.com, timmoore@microsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates a *one week* working group last call for "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)". The current draft is available at http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-00.txt A one week last call has been selected due to the limited changes with respect to RFC 3770. 3770bis and RFC 3770 are identical , with one exception. RFC 3770 contained a typographical error in the object identifier for the Wireless LAN SSID Attribute Certificate Attribute. 3770bis corrects the typographical error. Thanks, Tim Polk From owner-ietf-pkix@mail.imc.org Fri Apr 8 07:46:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07612 for ; Fri, 8 Apr 2005 07:46:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38AoJ7p011118; Fri, 8 Apr 2005 03:50:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38AoJ9p011116; Fri, 8 Apr 2005 03:50:19 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j38AoHAS011095 for ; Fri, 8 Apr 2005 03:50:18 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j38Anln25787; Fri, 8 Apr 2005 12:49:47 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Fri, 8 Apr 2005 12:49:47 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j38AngX20233; Fri, 8 Apr 2005 12:49:42 +0200 (MEST) Date: Fri, 8 Apr 2005 12:49:42 +0200 (MEST) From: Peter Sylvester Message-Id: <200504081049.j38AngX20233@chandon.edelweb.fr> To: ietf-pkix@imc.org, tim.polk@nist.gov Subject: Re: PKIX WG Last Call: 3770bis Cc: kent@bbn.com, housley@vigilsec.com, timmoore@microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The text at the end of chapter two seems to allow two different treatments for an entity that KNOWS the extension depending on the criticality bit. if I compere the last two paragraphs with similar ones in rfc 2459 or 3280, it seems that the text is at least confusing. I think the best is, not to remove them here, and not try for 'convenience' to give a definition at all. Or, define a keyPurpose, say whether it is critical or not, or don't say anything, and specify the treatment when it is recognized. The text also references keyUsage, but does not say which keyUsage bits are compatible with the defined KeyPurposes. X.208 and X.209 are a bit outdated. is 1.3 necessary? It is not in rfc 3280, as far as I see. have fun. From owner-ietf-pkix@mail.imc.org Fri Apr 8 08:09:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10252 for ; Fri, 8 Apr 2005 08:09:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38BGBJc022023; Fri, 8 Apr 2005 04:16:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38BGBU4022021; Fri, 8 Apr 2005 04:16:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38BG8Hm021991 for ; Fri, 8 Apr 2005 04:16:09 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 5DC6534A64; Fri, 8 Apr 2005 23:16:07 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28382-23; Fri, 8 Apr 2005 23:16:07 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 813F334A58; Fri, 8 Apr 2005 23:16:06 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 48A3D3775A; Fri, 8 Apr 2005 23:16:06 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DJrTC-0008QM-00; Fri, 08 Apr 2005 23:16:14 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, Peter.Sylvester@edelweb.fr, tim.polk@nist.gov Subject: Re: PKIX WG Last Call: 3770bis Cc: housley@vigilsec.com, kent@bbn.com, timmoore@microsoft.com In-Reply-To: <200504081049.j38AngX20233@chandon.edelweb.fr> Message-Id: Date: Fri, 08 Apr 2005 23:16:14 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Sylvester writes: >X.208 and X.209 are a bit outdated. is 1.3 necessary? They're not just outdated, they've been withdrawn, which means that for standardisation purposes they don't exist any more. You can't refer to them in a standard, at least not in any normative sense. Peter. From owner-ietf-pkix@mail.imc.org Fri Apr 8 11:58:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06495 for ; Fri, 8 Apr 2005 11:58:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38F1pvS068819; Fri, 8 Apr 2005 08:01:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38F1pRr068818; Fri, 8 Apr 2005 08:01:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j38F1nUt068811 for ; Fri, 8 Apr 2005 08:01:49 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 28620 invoked by uid 0); 8 Apr 2005 14:53:58 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.0.141) by woodstock.binhost.com with SMTP; 8 Apr 2005 14:53:58 -0000 Message-Id: <6.2.0.14.2.20050408102716.057fd6f0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 08 Apr 2005 10:53:48 -0400 To: Peter Sylvester From: Russ Housley Subject: Re: PKIX WG Last Call: 3770bis Cc: ietf-pkix@imc.org, tim.polk@nist.gov.kent@bbn.com, timmoore@microsoft.com In-Reply-To: <200504081049.j38AngX20233@chandon.edelweb.fr> References: <200504081049.j38AngX20233@chandon.edelweb.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: List-ID: List-Unsubscribe: Peter: Given the minor change that was made, I am surprised to see substantive comments. However, I agree with your comments. I propose replacement text below. >The text at the end of chapter two seems to allow two >different treatments for an entity that KNOWS the >extension depending on the criticality bit. How about this instead: If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose. >if I compere the last two paragraphs with similar ones >in rfc 2459 or 3280, it seems that the text is at least >confusing. How about this instead: The extended key usage extension MAY, at the option of the certificate issuer, be either critical or non-critical. If the extended key usage extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that a particular purpose (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order for the certificate to be acceptable to that application. >I think the best is, not to remove them here, and not try for >'convenience' to give a definition at all. > >Or, define a keyPurpose, say whether it is critical or >not, or don't say anything, and specify the treatment when >it is recognized. I think the above proposed changes address these points. >The text also references keyUsage, but does not say which >keyUsage bits are compatible with the defined KeyPurposes. This depends on the EAP method that is employed. I propose the following: If a certificate contains a key usage extension, the KeyUsage bits that are needed depends on the EAP method that is employed; however, the keyCertSign bit and the cRLSign MUST NOT be associated with EAP method end entity certificates. >X.208 and X.209 are a bit outdated. is 1.3 necessary? >It is not in rfc 3280, as far as I see. The section is necessary to make ASN.1 a normative reference. These are the same ASN.1 references used by RFC 3280. I would rather maintain the same dependencies. Russ From owner-ietf-pkix@mail.imc.org Fri Apr 8 12:55:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13211 for ; Fri, 8 Apr 2005 12:55:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38G39iC073642; Fri, 8 Apr 2005 09:03:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38G38Q2073641; Fri, 8 Apr 2005 09:03:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j38G37OD073635 for ; Fri, 8 Apr 2005 09:03:08 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 2865 invoked by uid 0); 8 Apr 2005 15:53:35 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.7.131) by woodstock.binhost.com with SMTP; 8 Apr 2005 15:53:35 -0000 Message-Id: <6.2.0.14.2.20050408115328.044338c0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 08 Apr 2005 11:53:34 -0400 To: Peter Sylvester From: Russ Housley Subject: Re: PKIX WG Last Call: 3770bis Cc: ietf-pkix@imc.org, tim.polk@nist.gov, kent@bbn.com, timmoore@microsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter: Given the minor change that was made, I am surprised to see substantive comments. However, I agree with your comments. I propose replacement text below. >The text at the end of chapter two seems to allow two >different treatments for an entity that KNOWS the >extension depending on the criticality bit. How about this instead: If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose. >if I compere the last two paragraphs with similar ones >in rfc 2459 or 3280, it seems that the text is at least >confusing. How about this instead: The extended key usage extension MAY, at the option of the certificate issuer, be either critical or non-critical. If the extended key usage extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that a particular purpose (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order for the certificate to be acceptable to that application. >I think the best is, not to remove them here, and not try for >'convenience' to give a definition at all. > >Or, define a keyPurpose, say whether it is critical or >not, or don't say anything, and specify the treatment when >it is recognized. I think the above proposed changes address these points. >The text also references keyUsage, but does not say which >keyUsage bits are compatible with the defined KeyPurposes. This depends on the EAP method that is employed. I propose the following: If a certificate contains a key usage extension, the KeyUsage bits that are needed depends on the EAP method that is employed; however, the keyCertSign bit and the cRLSign MUST NOT be associated with EAP method end entity certificates. >X.208 and X.209 are a bit outdated. is 1.3 necessary? >It is not in rfc 3280, as far as I see. The section is necessary to make ASN.1 a normative reference. These are the same ASN.1 references used by RFC 3280. I would rather maintain the same dependencies. Russ From owner-ietf-pkix@mail.imc.org Fri Apr 8 14:21:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19936 for ; Fri, 8 Apr 2005 14:21:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38HTYBb083991; Fri, 8 Apr 2005 10:29:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38HTYh9083990; Fri, 8 Apr 2005 10:29:34 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j38HTWj6083983 for ; Fri, 8 Apr 2005 10:29:33 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j38HTMn03142; Fri, 8 Apr 2005 19:29:22 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Fri, 8 Apr 2005 19:29:22 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j38HTLY21019; Fri, 8 Apr 2005 19:29:21 +0200 (MEST) Date: Fri, 8 Apr 2005 19:29:21 +0200 (MEST) From: Peter Sylvester Message-Id: <200504081729.j38HTLY21019@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, housley@vigilsec.com Subject: Re: PKIX WG Last Call: 3770bis Cc: ietf-pkix@imc.org, tim.polk@nist.gov.kent@bbn.com, timmoore@microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for the fast reply. > > Given the minor change that was made, I am surprised to see substantive > comments. However, I agree with your comments. I propose replacement text > below. once a text becomes RFC, nobody reads it, as soon as it becomes subject for update ... > > >The text at the end of chapter two seems to allow two > >different treatments for an entity that KNOWS the > >extension depending on the criticality bit. > > How about this instead: > > If a certificate contains both a key usage extension and an extended > key usage extension, then both extensions MUST be processed > independently and the certificate MUST only be used for a purpose > consistent with both extensions. If there is no purpose consistent > with both extensions, then the certificate MUST NOT be used for any > purpose. isn't this just a copy of rfc 3280 or its *bis, there is no value added information concerning 3770bis, if is nothing in the treatment that differs from the standard one. If so, it seems to be superfluous. to me. > > >if I compere the last two paragraphs with similar ones > >in rfc 2459 or 3280, it seems that the text is at least > >confusing. > > How about this instead: > > The extended key usage extension MAY, at the option of the certificate > issuer, be either critical or non-critical. Ok. > > If the extended key usage extension is present, then the certificate > MUST only be used for one of the purposes indicated. If multiple ! !BY WHOM? This sentence is nothing special for this text. > purposes are indicated the application need not recognize all > purposes indicated, as long as the intended purpose is present. This sentence sounds ok. > Certificate using applications MAY require that a particular purpose > (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in > order for the certificate to be acceptable to that application. This one is a good one. > > >I think the best is, not to remove them here, and not try for > >'convenience' to give a definition at all. > > > >Or, define a keyPurpose, say whether it is critical or > >not, or don't say anything, and specify the treatment when > >it is recognized. > > I think the above proposed changes address these points. > > >The text also references keyUsage, but does not say which > >keyUsage bits are compatible with the defined KeyPurposes. > > This depends on the EAP method that is employed. I propose the following: > > If a certificate contains a key usage extension, the KeyUsage bits > that are needed depends on the EAP method that is employed; however, > the keyCertSign bit and the cRLSign MUST NOT be associated with > EAP method end entity certificates. This text sounds like a new feature not present before. I suggest to list the keyUasge that influence the EAP method, and not the other way around. > > >X.208 and X.209 are a bit outdated. is 1.3 necessary? > >It is not in rfc 3280, as far as I see. > > The section is necessary to make ASN.1 a normative reference. see response from Peter Gutmann. > > These are the same ASN.1 references used by RFC 3280. I would rather > maintain the same dependencies. 3280 has no reference to X.208 or else, at least not in the reference section. The syntax that you use is conformant to ASN.1, to any of the versions as far as I see. you don't use macros, or obsolete features, so referencing X.208 etc can be seen as if you require that a compiler or else is restricted to support this old version. > > Russ > > Peter From owner-ietf-pkix@mail.imc.org Fri Apr 8 15:52:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03999 for ; Fri, 8 Apr 2005 15:52:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38Iwr0x089781; Fri, 8 Apr 2005 11:58:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38IwrUw089780; Fri, 8 Apr 2005 11:58:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j38Iwmn6089770 for ; Fri, 8 Apr 2005 11:58:50 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 8258 invoked by uid 0); 8 Apr 2005 18:48:08 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.244.35) by woodstock.binhost.com with SMTP; 8 Apr 2005 18:48:08 -0000 Message-Id: <6.2.0.14.2.20050408140502.04e8bd10@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 08 Apr 2005 14:15:42 -0400 To: Peter Sylvester From: Russ Housley Subject: Re: PKIX WG Last Call: 3770bis Cc: ietf-pkix@imc.org, tim.polk@nist.gov, kent@bbn.com, timmoore@microsoft.com In-Reply-To: <200504081729.j38HTLY21019@chandon.edelweb.fr> References: <200504081729.j38HTLY21019@chandon.edelweb.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: List-ID: List-Unsubscribe: Peter: > > >The text at the end of chapter two seems to allow two > > >different treatments for an entity that KNOWS the > > >extension depending on the criticality bit. > > > > How about this instead: > > > > If a certificate contains both a key usage extension and an extended > > key usage extension, then both extensions MUST be processed > > independently and the certificate MUST only be used for a purpose > > consistent with both extensions. If there is no purpose consistent > > with both extensions, then the certificate MUST NOT be used for any > > purpose. > >isn't this just a copy of rfc 3280 or its *bis, there is no value >added information concerning 3770bis, if is nothing in the treatment >that differs from the standard one. If so, it seems to be superfluous. to me. The previous text was intended to help the reader, avoiding the need to reread RFC 3280 to get the concepts. I think this text meets this same goal. > > >if I compere the last two paragraphs with similar ones > > >in rfc 2459 or 3280, it seems that the text is at least > > >confusing. > > > > How about this instead: > > > > The extended key usage extension MAY, at the option of the certificate > > issuer, be either critical or non-critical. >Ok. > > > > > If the extended key usage extension is present, then the certificate > > MUST only be used for one of the purposes indicated. If multiple > ! > !BY WHOM? >This sentence is nothing special for this text. By any certificate user. I'll edit the sentence. > > purposes are indicated the application need not recognize all > > purposes indicated, as long as the intended purpose is present. >This sentence sounds ok. > > > Certificate using applications MAY require that a particular purpose > > (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in > > order for the certificate to be acceptable to that application. >This one is a good one. > > > > > >I think the best is, not to remove them here, and not try for > > >'convenience' to give a definition at all. > > > > > >Or, define a keyPurpose, say whether it is critical or > > >not, or don't say anything, and specify the treatment when > > >it is recognized. > > > > I think the above proposed changes address these points. > > > > >The text also references keyUsage, but does not say which > > >keyUsage bits are compatible with the defined KeyPurposes. > > > > This depends on the EAP method that is employed. I propose the following: > > > > If a certificate contains a key usage extension, the KeyUsage bits > > that are needed depends on the EAP method that is employed; however, > > the keyCertSign bit and the cRLSign MUST NOT be associated with > > EAP method end entity certificates. > >This text sounds like a new feature not present before. >I suggest to list the keyUasge that influence the EAP method, >and not the other way around. That would be listing all of the other bits. For example, EAP-TLS has the same rules as TLS, which depends on the cipher suite that is negotiated. Other EAP methods could be defined in the future that make use of the other ones. > > >X.208 and X.209 are a bit outdated. is 1.3 necessary? > > >It is not in rfc 3280, as far as I see. > > > > The section is necessary to make ASN.1 a normative reference. >see response from Peter Gutmann. > > > > These are the same ASN.1 references used by RFC 3280. I would rather > > maintain the same dependencies. > >3280 has no reference to X.208 or else, at least not in the >reference section. The syntax that you use is conformant to ASN.1, >to any of the versions as far as I see. you don't use macros, or >obsolete features, so referencing X.208 etc can be seen as if you >require that a compiler or else is restricted to support this old >version. My mistake. I'll fix it to use the same references as RFC 3280. Russ From owner-ietf-pkix@mail.imc.org Mon Apr 11 05:32:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25839 for ; Mon, 11 Apr 2005 05:32:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3B81iJD049468; Mon, 11 Apr 2005 01:01:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3B81iTx049467; Mon, 11 Apr 2005 01:01:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3B81BTB049230 for ; Mon, 11 Apr 2005 01:01:13 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA12704; Mon, 11 Apr 2005 10:14:21 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005041109592907:2109 ; Mon, 11 Apr 2005 09:59:29 +0200 Message-ID: <425A2E60.2080008@bull.net> Date: Mon, 11 Apr 2005 09:59:28 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson , Russ Housley CC: pkix Subject: Comments on X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/04/2005 09:59:29, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/04/2005 10:01:04, Serialize complete at 11/04/2005 10:01:04 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3B81ETB049269 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Stefan and Russ, It took me several hours to write this long e-mail, hence for the delay (in addition to the time for shooting a few “big five” with my camera). This e-mail identifies several security issues, which are not currently mentionned in the security considerations section. It finally proposes a rewritting of the introduction and provides a strawman for a new security considerations section (see the proposal at the end of this e-mail). Let us consider two different scenarios where this new extension would be considered. Scenario A: The relying party does not trust any CRL issuer in particular and will simply use the CRL Issuer designated by the Certificate Issuer by means of the CRL DP extension. Scenario B: The relying party trusts at least a specific CRL issuer and will get the CRLs from that CRL Issuer and then will make sure that the information contained in them matches with the designation of the Certificate Issuer. SCENARIO A In scenario A, the relying party will use the CRL DP from the target certificate to get the CRL and then will make sure that the CRL that has been retrieved from that location is signed by the right CRL Issuer. The CRL DP extension is defined as: DistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, reasons [1] ReasonFlags OPTIONAL, cRLIssuer [2] GeneralNames OPTIONAL } At least the distributionPoint field shall be present. It is supposed it contains a general name of type URI, which is a pointer to the current CRL for the associated reasons and will be issued by the associated cRLIssuer. The CRL itself shall contain an IDP (Issuing Distribution Point). The IDP extension is defined as: issuingDistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlySomeReasons [3] ReasonFlags OPTIONAL, indirectCRL [4] BOOLEAN DEFAULT FALSE, onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } A necessary but insufficient condition is that the distributionPoint field from the IDP extension shall be equal to the distributionPoint field from the CRL DP extension. This is insufficient since a URL like URL=http://corppki/crl/extranet.crl could be used by accident by two different CAs, or a CA under the same root key could maliciously use that URL or a different and re-route all packets to an address where that CRL is made available. This means that the tupple CRL DP extension from certificates and the IDP extension from CRLs even if then match are insufficient to make sure that it is the right CRL that has been retrieved. This is “normal” until some cryptographic checksums are used to make sure that this is the right information. Any CA, trusted under a root key, could use an IDP extension in a CRL matching the IDP extension from another true CRL and unless other tests are performed, would fool relying parties. This is the major reason why the current document in its current form is dangerous to be published. It incorporates verification concepts which are missing major security issues. The security consideration section attempts to tackle the issue but it misses the point. The major problem is not the definition of this new extension that could provide untrusted but “useful” information, but the concepts behind path construction. SCENARIO B In scenario B, the relying party contacts the location of a trusted CRL Issuer and wants to verify that the retrieved CRL is correctly signed. Suppose that the retrieved CRL contains the newly defined extension which specifies one or more accessLocation fields that contains references to CA certificates superior to the CRL containing this extension. Let us consider that one accessLocation field contains the following URL: http://corppki/aia/certificates.crt The relying party will access this URL to retrieve some CA certificates. Nothing at this point would prevent a network attack so that access to this URL is re-routed to another location. The question is how the relying party can figure out and what kind of tests it should make. The draft is silent about this. It does not help the end-user to define new extensions if at the same time there are no explanations or guidance to tell how are they should be used in order to build a secure system. Let us suppose that the information retrieved is just “useful” certificates at this time (i.e. untrusted). In order to build a path, a relying party needs to make sure of the name of the CRL Issuer, which means not simply knowing the DN of the CRL issuer but also all the other DNs from the upper CAs up to a root key. This kind of assumption or explanations is currently missing in the draft. Scenario B would be correctly supported if the text would mention two points: 1) the location of the “trusted CRL Issuer” must be locally known, 2) the name of the “trusted CRL Issuer” must be locally known, which means not simply knowing the DN of the CRL issuer, but also all the other DNs from the upper CAs up to a root key. Using the “useful” certificates that would be retrieved using that new extension, the relying party would then build a certification path to validate the retrieved CRL. Additional details, described nowhere, should be given so that it can be sure that it is a CRL Issuer and not a CA, etc ... Then the relying party knows that he got a correct indirect CRL and has to make sure that the name of the CA is present. Additional details would be needed to explain name matching taking into account that two CAs could be given the same DN by two different CAs. CONCLUSION: I see two ways to progress: a) “avoid” the problem *now* and leave it for later. This means saying that this extension may provide useful information that still needs to be verified to be trusted. The security considerations section would tackle the issue but not provide the full answer. b) address the issue and say how to handle CRLs when they are not signed by the CA. In case of a), that is the easiest *temporary* solution, I would propose to rewrite the introduction in the following way : RFC 3280 [PKIX1] specifies the validation of certification paths. One aspect involves the determination that a certificate has not been revoked, and one revocation checking mechanism is the Certificate Revocation List (CRL). Checking a CRL when the CRL is signed by the key of the Issuing CA is straightforward, but not necessarily otherwise. There are several legitimate scenarios where the certificate of the CRL issuer is not present, or easily discovered. Standardized methods of finding the certificate of the CRL issuer are currently available either though an accessible directory location or through use of the Subject Information Access extension in intermediary CA certificates. Directory lookup requires presence and access to a directory. The Subject Information Access extension supports building certification paths top-down (in the direction from the trust anchor to the CRL issuer), which will succeed if certificates include an appropriate Subject Information Access extension. Additional methods allowing the building of certification paths bottom-up to validate CRLs may be useful as well. This is the topic of this document. RFC 3280 [PKIX1] has provided for bottom-up discovery of certification paths through the Authority Information Access extension, where the id-ad-caIssuers access method may specify one or more accessLocation fields that contain references to CA certificates superior to the certificate containing this extension. This document permits use of the Authority Information Access extension in CRLs, enabling a CRL checking application to use the same access method (id-ad-caIssuers) to locate the certificate of the CRL issuer and complete the certification path building to an appropriate trust anchor. This extension may be used in the case when indirect CRLs are used, when the certification Authority (CA) that issued the CRL certificate changes its certificate signing key, or when the CA employs separate keys for certificate signing and CRL signing. A typo would need to be corrected in section 2: change AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax. Section 3 about Security Considerations would need to be changed. Hereafter is a proposal: 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same DN, as well as the possibility for some trusted CAs (i.e. trusted to issue their own certificates and associated revocation status information but not trusted not handle revocation information from other CAs) to purposely use URLs or CRL DPs identical to some CRL DPs from other CAs and at the same time mounting a re-routing attack. This means that finding a CA certificate at the location indicated by this new extension is insufficient to make sure that it is the right one, and by consequence that the CRL where this extension has been found is also the right one. When the CRL contains the indirectCRL boolean set to TRUE, then the relying party should locally know the URL of the CRL issuer(s) that it directly trusts and also the associated name of the trusted CRL issuer, which means not simply knowing the DN of the CRL issuer, but also all the other DNs of the upper CAs up to a root key (since two CAs might be given the same DN by two different CAs). When the CRL is a direct CRL, then relying parties shall make sure that the certificate of the CRL issuer has been issued by the same CA that has issued the target certificate. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Of course, much more could be said and an informative annex would be quite useful. In case of b), more work would need to be done. Denis From owner-ietf-pkix@mail.imc.org Mon Apr 11 11:32:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22308 for ; Mon, 11 Apr 2005 11:32:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BESlpM002427; Mon, 11 Apr 2005 07:28:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BESlGp002426; Mon, 11 Apr 2005 07:28:47 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3BESHFQ002319 for ; Mon, 11 Apr 2005 07:28:18 -0700 (PDT) (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.1802); Mon, 11 Apr 2005 15:28:11 +0100 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: Comments on Date: Mon, 11 Apr 2005 15:28:05 +0100 Message-ID: Thread-Topic: Comments on Thread-Index: AcU+ef1CHYITrah2TR6/vhvE/yrduQAJGwug From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: "pkix" X-OriginalArrivalTime: 11 Apr 2005 14:28:11.0247 (UTC) FILETIME=[B03EFFF0:01C53EA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3BESIFQ002340 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, Thanks for spending considerable time to comment on this draft. The typo is noted and will be fixed. Some generic comments before we go into the specific text proposals: You point out some well known issues related to the lack of absolute cryptographic binding between CRL and certificates where the certificate and CRL is not signed by the same key. A certificate is always authoritative to identify the correct CRL for its validation. But since the certificate is signed before the latest CRL that validates it, the certificate can't cryptographically bind (e.g. hash) the CRL but needs to identify it by verifiable attributes such as issuer name and storage location. This issue is however NOT introduced by this draft. It is simply a generic issue with RFC 3280/X.509, especially for indirect CRLs In this context I really can't see the difference between scenario A and scenario B. It seems to me that the same validation principles apply to both scenarios. Section 6.3 of RFC 3280 is dealing with CRL validation and the requirement to validate the CRL through a valid certificate path. This draft only introduces a new way to point to locate certificates that can be helpful in building this path. It seems to me from that perspective that specific requirements on CRL path building are outside the scope of this draft. >Stefan Santesson >Program Manager - Standards Liaison >Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 11 april 2005 00:59 > To: Stefan Santesson; Russ Housley > Cc: pkix > Subject: Comments on > > > Stefan and Russ, > > It took me several hours to write this long e-mail, hence for the delay > (in addition to the time for shooting a few "big five" with my camera). > > This e-mail identifies several security issues, which are not currently > mentionned in the security considerations section. It finally proposes a > rewritting of the introduction and provides a strawman for a new security > considerations section (see the proposal at the end of this e-mail). > > Let us consider two different scenarios where this new extension would be > considered. > > Scenario A: The relying party does not trust any CRL issuer in particular > and will simply use the CRL Issuer designated by the Certificate Issuer by > means of the CRL DP extension. > > Scenario B: The relying party trusts at least a specific CRL issuer and > will > get the CRLs from that CRL Issuer and then will make sure that the > information contained in them matches with the designation of the > Certificate Issuer. > > SCENARIO A > > In scenario A, the relying party will use the CRL DP from the target > certificate to get the CRL and then will make sure that the CRL that has > been retrieved from that location is signed by the right CRL Issuer. > > The CRL DP extension is defined as: > > DistributionPoint ::= SEQUENCE { > distributionPoint [0] DistributionPointName OPTIONAL, > reasons [1] ReasonFlags OPTIONAL, > cRLIssuer [2] GeneralNames OPTIONAL } > > At least the distributionPoint field shall be present. It is supposed it > contains a general name of type URI, which is a pointer to the current CRL > for the associated reasons and will be issued by the associated cRLIssuer. > > The CRL itself shall contain an IDP (Issuing Distribution Point). > > The IDP extension is defined as: > > issuingDistributionPoint ::= SEQUENCE { > distributionPoint [0] DistributionPointName OPTIONAL, > onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, > onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, > onlySomeReasons [3] ReasonFlags OPTIONAL, > indirectCRL [4] BOOLEAN DEFAULT FALSE, > onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } > > A necessary but insufficient condition is that the distributionPoint field > from the IDP extension shall be equal to the distributionPoint field from > the CRL DP extension. > > This is insufficient since a URL like URL=http://corppki/crl/extranet.crl > could be used by accident by two different CAs, or a CA under the same > root > key could maliciously use that URL or a different and re-route all packets > to an address where that CRL is made available. > > This means that the tupple CRL DP extension from certificates and the IDP > extension from CRLs even if then match are insufficient to make sure that > it > is the right CRL that has been retrieved. This is "normal" until some > cryptographic checksums are used to make sure that this is the right > information. > > Any CA, trusted under a root key, could use an IDP extension in a CRL > matching the IDP extension from another true CRL and unless other tests > are > performed, would fool relying parties. > > This is the major reason why the current document in its current form is > dangerous to be published. It incorporates verification concepts which are > missing major security issues. The security consideration section attempts > to tackle the issue but it misses the point. > > The major problem is not the definition of this new extension that could > provide untrusted but "useful" information, but the concepts behind path > construction. > > SCENARIO B > > In scenario B, the relying party contacts the location of a trusted CRL > Issuer and wants to verify that the retrieved CRL is correctly signed. > > Suppose that the retrieved CRL contains the newly defined extension which > specifies one or more accessLocation fields that contains references to CA > certificates superior to the CRL containing this extension. > > Let us consider that one accessLocation field contains the following URL: > http://corppki/aia/certificates.crt > > The relying party will access this URL to retrieve some CA certificates. > Nothing at this point would prevent a network attack so that access to > this > URL is re-routed to another location. The question is how the relying > party > can figure out and what kind of tests it should make. The draft is silent > about this. > > It does not help the end-user to define new extensions if at the same time > there are no explanations or guidance to tell how are they should be used > in > order to build a secure system. > > Let us suppose that the information retrieved is just "useful" > certificates > at this time (i.e. untrusted). > > In order to build a path, a relying party needs to make sure of the name > of > the CRL Issuer, which means not simply knowing the DN of the CRL issuer > but > also all the other DNs from the upper CAs up to a root key. This kind of > assumption or explanations is currently missing in the draft. > > Scenario B would be correctly supported if the text would mention two > points: > > 1) the location of the "trusted CRL Issuer" must be locally known, > 2) the name of the "trusted CRL Issuer" must be locally known, > which means not simply knowing the DN of the CRL issuer, > but also all the other DNs from the upper CAs up to a root key. > > Using the "useful" certificates that would be retrieved using that new > extension, the relying party would then build a certification path to > validate the retrieved CRL. Additional details, described nowhere, should > be > given so that it can be sure that it is a CRL Issuer and not a CA, etc ... > > Then the relying party knows that he got a correct indirect CRL and has to > make sure that the name of the CA is present. Additional details would be > needed to explain name matching taking into account that two CAs could be > given the same DN by two different CAs. > > > CONCLUSION: > > I see two ways to progress: > > a) "avoid" the problem *now* and leave it for later. This means > saying that this extension may provide useful information that > still needs to be verified to be trusted. The security > considerations section would tackle the issue but not provide > the full answer. > > b) address the issue and say how to handle CRLs when they are not > signed > by the CA. > > In case of a), that is the easiest *temporary* solution, I would propose > to > rewrite the introduction in the following way : > > RFC 3280 [PKIX1] specifies the validation of certification paths. > One aspect involves the determination that a certificate has not been > revoked, and one revocation checking mechanism is the Certificate > Revocation List (CRL). Checking a CRL when the CRL is signed by the > key of the Issuing CA is straightforward, but not necessarily > otherwise. > > There are several legitimate scenarios where the certificate of the > CRL issuer is not present, or easily discovered. > > Standardized methods of finding the certificate of the CRL issuer are > currently available either though an accessible directory location or > through use of the Subject Information Access extension in > intermediary CA certificates. > > Directory lookup requires presence and access to a directory. The > Subject Information Access extension supports building certification > paths top-down (in the direction from the trust anchor to the CRL > issuer), which will succeed if certificates include an appropriate > Subject Information Access extension. Additional methods allowing > the building of certification paths bottom-up to validate CRLs > may be useful as well. This is the topic of this document. > > RFC 3280 [PKIX1] has provided for bottom-up discovery of > certification paths through the Authority Information Access > extension, where the id-ad-caIssuers access method may specify one or > more accessLocation fields that contain references to CA certificates > superior to the certificate containing this extension. > > This document permits use of the Authority Information Access > extension in CRLs, enabling a CRL checking application to use the > same access method (id-ad-caIssuers) to locate the certificate of > the CRL issuer and complete the certification path building to an > appropriate trust anchor. > > This extension may be used in the case when indirect CRLs are used, > when the certification Authority (CA) that issued the CRL certificate > changes its certificate signing key, or when the CA employs separate > keys for certificate signing and CRL signing. > > A typo would need to be corrected in section 2: change > AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax. > > Section 3 about Security Considerations would need to be changed. > Hereafter is a proposal: > > 3 Security Considerations > > Implementers should take into account the possible existence of > multiple unrelated CAs and CRL issuers with the same DN, as well > as the possibility for some trusted CAs (i.e. trusted to issue > their own certificates and associated revocation status information > but not trusted not handle revocation information from other CAs) > to purposely use URLs or CRL DPs identical to some CRL DPs from > other CAs and at the same time mounting a re-routing attack. > > This means that finding a CA certificate at the location indicated > by this new extension is insufficient to make sure that it is the > right one, and by consequence that the CRL where this extension > has been found is also the right one. > > When the CRL contains the indirectCRL boolean set to TRUE, then the > relying party should locally know the URL of the CRL issuer(s) that > it directly trusts and also the associated name of the trusted CRL > issuer, which means not simply knowing the DN of the CRL issuer, > but also all the other DNs of the upper CAs up to a root key (since > two CAs might be given the same DN by two different CAs). > > When the CRL is a direct CRL, then relying parties shall make sure > that the certificate of the CRL issuer has been issued by the same > CA that has issued the target certificate. > > Implementers should always take the steps of validating the > retrieved data to ensure that the data is properly formed. > > Of course, much more could be said and an informative annex would be quite > useful. > > In case of b), more work would need to be done. > > Denis > From owner-ietf-pkix@mail.imc.org Mon Apr 11 12:40:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27572 for ; Mon, 11 Apr 2005 12:40:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BFjYfN018035; Mon, 11 Apr 2005 08:45:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BFjYmM018034; Mon, 11 Apr 2005 08:45:34 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3BFj3uH017909 for ; Mon, 11 Apr 2005 08:45:03 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3BFhpn21044; Mon, 11 Apr 2005 17:43:51 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Mon, 11 Apr 2005 17:43:51 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3BFgYI24387; Mon, 11 Apr 2005 17:42:34 +0200 (MEST) Date: Mon, 11 Apr 2005 17:42:34 +0200 (MEST) From: Peter Sylvester Message-Id: <200504111542.j3BFgYI24387@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, housley@vigilsec.com Subject: Re: PKIX WG Last Call: 3770bis Cc: ietf-pkix@imc.org, tim.polk@nist.gov, kent@bbn.com, timmoore@microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > The previous text was intended to help the reader, avoiding the need to > reread RFC 3280 to get the concepts. I think this text meets this same goal. Getting the concept may be in a non-normative section. and, as the current text shows, it can get wrong. I don't think that this text should be a tutorial for 3280. > > > > > > > > If the extended key usage extension is present, then the certificate > > > MUST only be used for one of the purposes indicated. If multiple > > ! > > !BY WHOM? > >This sentence is nothing special for this text. > > By any certificate user. I'll edit the sentence. What is a certificate user? You mean the private key owner? > > > > purposes are indicated the application need not recognize all > > > purposes indicated, as long as the intended purpose is present. > >This sentence sounds ok. I add: this is nothing special with this text. > > > > > Certificate using applications MAY require that a particular purpose > > > (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in > > > order for the certificate to be acceptable to that application. > >This one is a good one. The application is a certificate user? There are two ends? > > That would be listing all of the other bits. For example, EAP-TLS has the > same rules as TLS, which depends on the cipher suite that is > negotiated. Other EAP methods could be defined in the future that make use > of the other ones. But what is written is that it is not possible to have no keyUsage, since this would imply *ALL* usages, thus also keyCertSign. If a certificate contains a key usage extension, the KeyUsage bits that are needed depend on the EAP method that is employed. Peter From owner-ietf-pkix@mail.imc.org Mon Apr 11 16:10:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17255 for ; Mon, 11 Apr 2005 16:10:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJ8JYM059435; Mon, 11 Apr 2005 12:08:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BJ8JdY059434; Mon, 11 Apr 2005 12:08:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJ8IQa059410 for ; Mon, 11 Apr 2005 12:08:19 -0700 (PDT) (envelope-from dengberg@corestreet.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: CoreStreet IPR disclosure Date: Mon, 11 Apr 2005 15:08:36 -0400 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02BE_01C53EA8.55A82D40" Message-ID: X-MS-Has-Attach: yes Thread-Topic: CoreStreet IPR disclosure Thread-Index: AcU+ydxLEV1lYIVBSCimr5+H+d8ftQ== From: "Dave Engberg" To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_02BE_01C53EA8.55A82D40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02BF_01C53EA8.55A82D40" ------=_NextPart_001_02BF_01C53EA8.55A82D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IETF has posted CoreStreet's formal IPR disclosure regarding implementations of the SCVP protocol and three of CoreStreet's patents. This includes an offer for reasonable and non-discriminatory licensing if required by the final standard. We fully support the standardization and adoption of SCVP. The full disclosure is available here: http://www.ietf.org/ietf/IPR/corestreet-ipr-draft-ietf-pkix-scvp-18.txt Unlike some other PKI vendors, CoreStreet has never served a lawsuit (patent or non) to any other party. Our company's success stems from our innovative implementations of open standards, which attempt to address the security and scalability problems inherent in large PKIs. We believe our SCVP products will be similarly competitive. Thanks, Dave Engberg Chief Technical Officer CoreStreet, Ltd. ------=_NextPart_001_02BF_01C53EA8.55A82D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
The IETF has posted CoreStreet's formal IPR disclosure regarding implementations of the SCVP = protocol=20 and three of CoreStreet's patents.  This includes an offer for = reasonable=20 and non-discriminatory licensing if required by the final = standard.  We=20 fully support the standardization and adoption of SCVP.  The full disclosure is available=20 here:
 
    http://www.ietf.org/ietf/IPR/corestreet-ipr-draft-ietf-pkix-scvp-= 18.txt
 
Unlike some other PKI vendors, CoreStreet has = never=20 served a lawsuit (patent or = non) to=20 any other party.  Our company's success stems from our innovative=20 implementations of open standards, which attempt to address the security = and=20 scalability problems inherent in large PKIs.  We believe our SCVP=20 products will be similarly=20 competitive.
 
Thanks,
Dave=20 Engberg
Chief = Technical=20 Officer
CoreStreet,=20 Ltd.
 
------=_NextPart_001_02BF_01C53EA8.55A82D40-- ------=_NextPart_000_02BE_01C53EA8.55A82D40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1jCCAoIw 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/IR5XTP2iQYPcbxento6zCCA4wwggL1oAMCAQICARkwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzEyMTMwMjE4WhcNMDUw NzI2MTMwMjE4WjBnMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRYwFAYD VQQDEw1EYXZpZCBFbmdiZXJnMSYwJAYJKoZIhvcNAQkBFhdkZW5nYmVyZ0Bjb3Jlc3RyZWV0LmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJXX+JZ1oaEb2TCawk31rzpOIRTHZyP UGTUGNyMasqczNZATvXu2RTlon8dwEuO4evr5KE9iDe0jQSkj1g5HBEsFAH+JPU7Y0uYupm/kiyr 6FiyhBCQtWhrcNii0yahcIEbH/fBAf5V10Y2wHKFrPH6uTrj+YGhBpaXxkEZpXCe2QZtkR/kcbKa QaMCaU27vLAZ4QT6vJTf5oG/SD1KU232kYttiLeRjnePWipH8In7crGPhgJCeQP5UtE9uHDjOStt eZxXsWAzU7oW9nb9jHL2xOWPQyhBs4JaPvgSdFkenI6L8flsQm72U8lrV/4dqKu330m5pH89XTYl o2PcqIUCAwEAAaOB2DCB1TAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDov L2NybC5nZW90cnVzdC5jb20vY3Jscy9jb3Jlc3RyZWV0LmNybDAiBgNVHREEGzAZgRdkZW5nYmVy Z0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBABggrBgEF BQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJlZXQuY29t LzANBgkqhkiG9w0BAQUFAAOBgQAtAQMtzyIzARw6d/sy1qPn+Mqr7aPEJFofkSW57NE639PcrXmC E9LzVm5mtmoNkeeyHDOgla79ez8MzndDxhlwQvNdaiu124jWbgEoHC1q2K4McbaJlxjhPbCpFr7Z CzxQxOmFxXjb16XGotrxX1aj2YWuAAdt9H3x+tHBXCn+WDGCAxowggMWAgEBMFcwUjELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCARkwCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDExMTkwODM2WjAjBgkqhkiG9w0BCQQxFgQUWejatX/i lHIgQyqZgK5wUQOZVy4wZgYJKwYBBAGCNxAEMVkwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP Q29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0 eQIBGTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsq hkiG9w0BCRACCzFZoFcwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEp MCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCARkwDQYJKoZIhvcNAQEB BQAEggEAGfxeyT1e2BDmkUKrPdg7gZtddxjtLeDzz4j43W8DN0LBQz4rJ+d+QZ17oqrXdzFWi/Rz taFTLP3EdkkgptH3pJ5Ceo2eF+n7sesWSrlxU7OMY0K4ty0T5eSyJunAD0OEVUPeB8Axrph68MrP OHtXW8cOUxSj35+xUhTOUaW0S2k6hn/qQWgvJiN0L32/RPNsJ/vP2zpNWKzMamVNhpWvJSIi/tc8 FExBDmVch4Aue087qKbJTIC0DyToPXL1FDbjtGMohWOMcIYCMXEhppywJqS8/lX6y/blLpZ8sVdr JyU31CzE2JiUHIwrJiqgJcsN5Z0dWME3MIi1RNktRryCjgAAAAAAAA== ------=_NextPart_000_02BE_01C53EA8.55A82D40-- From owner-ietf-pkix@mail.imc.org Tue Apr 12 16:26:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06437 for ; Tue, 12 Apr 2005 16:26:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CJdiUB050528; Tue, 12 Apr 2005 12:39:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CJdiVQ050527; Tue, 12 Apr 2005 12:39:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CJdgbG050521 for ; Tue, 12 Apr 2005 12:39:44 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29478; Tue, 12 Apr 2005 15:39:40 -0400 (EDT) Message-Id: <200504121939.PAA29478@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt Date: Tue, 12 Apr 2005 15:39:40 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-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 : Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) Author(s) : R. Housley, T. Moore Filename : draft-ietf-pkix-rfc3770bis-01.txt Pages : 10 Date : 2005-4-12 This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-01.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-rfc3770bis-01.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-rfc3770bis-01.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: <2005-4-12161231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-rfc3770bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-rfc3770bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-12161231.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Wed Apr 13 08:40:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21785 for ; Wed, 13 Apr 2005 08:40:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DBfI82029869; Wed, 13 Apr 2005 04:41:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DBfILM029868; Wed, 13 Apr 2005 04:41:18 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3DBfHdR029850 for ; Wed, 13 Apr 2005 04:41:17 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3DBfFn29031 for ; Wed, 13 Apr 2005 13:41:15 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Wed, 13 Apr 2005 13:41:15 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3DBfFv28956 for ietf-pkix@imc.org; Wed, 13 Apr 2005 13:41:15 +0200 (MEST) Date: Wed, 13 Apr 2005 13:41:15 +0200 (MEST) From: Peter Sylvester Message-Id: <200504131141.j3DBfFv28956@chandon.edelweb.fr> To: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some more remaks: 1 *** text says: 1.3. Abstract Syntax Notation All X.509 certificate [X.509] extensions are defined using ASN.1 [X.660]. and: [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997. this looks strange to me. The encoding rules are not the asn1 syntax. Suggestion: remove 1.3 and the reference. 2 *** If a certificate contains a key usage extension, the KeyUsage bits that are needed depends on the EAP method that is employed; however, the keyCertSign bit and the cRLSign MUST NOT be associated with EAP method end entity certificates. This means that you cannot have a certificat WITHOUT keyUsage? Or, in case of a certificate without keyUsage, you could use it for CrlSigning? This restriction is new, and I don't see why this is necessary. I am not sure, but I don't know of any other purpose that has a restriction like this, and current scvp specs don't allow to check for this (you cannot specify MUST NOT). suggestion, remove the second half sentence. 3 *** chapter two should read IMO: 2. EAP Extended Key Usage Values RFC 3280 [PROFILE] specifies the extended key usage X.509 certificate extension. The extension indicates one or more purposes for which the certified public key may be used. This specification defines two KeyPurposeId values: one for EAP over PPP, and one for EAP over LAN (EAPOL). Inclusion of the EAP over PPP value indicates that the certified public key is appropriate for use with EAP in the PPP environment, and the inclusion of the EAPOL value indicates that the certified public key is appropriate for use with the EAP in the LAN environment. Inclusion of both values indicates that the certified public key is appropriate for use in either of the environments. id-kp-eapOverPPP OBJECT IDENTIFIER ::= { id-kp 13 } id-kp-eapOverLAN OBJECT IDENTIFIER ::= { id-kp 14 } The extended key usage extension MAY, at the option of the certificate issuer, be either critical or non-critical. If the extended key usage is present in a certificate, Certificate using applications MAY require that a particular purpose XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order for the certificate to be acceptable to that application. If a certificate contains a key usage extension, the KeyUsage bits that are needed depends on the EAP method that is employed. There is currently no method that require the usage of the keyCertSign or the cRLSign bit to be set. with the XXXX a little bit more specific. 4 *** The OID arcs should be imported from IMPORTS id-pe, id-kp FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } id-aca FROM PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-attribute-cert(12)} peter From owner-ietf-pkix@mail.imc.org Wed Apr 13 11:12:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04471 for ; Wed, 13 Apr 2005 11:12:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DEInpI059915; Wed, 13 Apr 2005 07:18:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DEInOR059914; Wed, 13 Apr 2005 07:18:49 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3DEImPw059900 for ; Wed, 13 Apr 2005 07:18:48 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200504131403.j3DE3SE3025133@stingray.missi.ncsc.mil> Date: Wed, 13 Apr 2005 10:18:33 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt References: <200504131141.j3DBfFv28956@chandon.edelweb.fr> In-Reply-To: <200504131141.j3DBfFv28956@chandon.edelweb.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2005 14:18:39.0422 (UTC) FILETIME=[B03CEDE0:01C54033] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit It also looks strange because ASN.1 is defined in X.680 :-). X.660 is "Procedures for the operation of OSI registration authorities: General procedures and top arcs of the ASN.1 object identifier tree". The titles of X.680 and X.690 are: X.680: Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation X.690: Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) Agree with the suggestion to remove section 1.3 and the reference. If they are retained, the reference should be changed to X.680 and its correct title. Peter Sylvester wrote: >Some more remaks: > >1 *** > >text says: > >1.3. Abstract Syntax Notation > > All X.509 certificate [X.509] extensions are defined using ASN.1 > [X.660]. > >and: > > [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 > encoding rules: Specification of Basic Encoding Rules > (BER), Canonical Encoding Rules (CER) and Distinguished > Encoding Rules (DER), 1997. > >this looks strange to me. The encoding rules are not the asn1 syntax. > >Suggestion: > >remove 1.3 and the reference. > >2 *** > > If a certificate contains a key usage extension, the KeyUsage bits > that are needed depends on the EAP method that is employed; however, > the keyCertSign bit and the cRLSign MUST NOT be associated with EAP > method end entity certificates. > >This means that you cannot have a certificat WITHOUT keyUsage? >Or, in case of a certificate without keyUsage, you could use it >for CrlSigning? > >This restriction is new, and I don't see why this is necessary. >I am not sure, but I don't know of any other purpose that has >a restriction like this, and current scvp specs don't allow to >check for this (you cannot specify MUST NOT). > >suggestion, remove the second half sentence. > > >3 *** chapter two should read IMO: > >2. EAP Extended Key Usage Values > > RFC 3280 [PROFILE] specifies the extended key usage X.509 certificate > extension. The extension indicates one or more purposes for which > the certified public key may be used. > > This specification defines two KeyPurposeId values: one for EAP over > PPP, and one for EAP over LAN (EAPOL). Inclusion of the EAP over PPP > value indicates that the certified public key is appropriate for use > with EAP in the PPP environment, and the inclusion of the EAPOL value > indicates that the certified public key is appropriate for use with > the EAP in the LAN environment. Inclusion of both values indicates > that the certified public key is appropriate for use in either of the > environments. > > id-kp-eapOverPPP OBJECT IDENTIFIER ::= { id-kp 13 } > > id-kp-eapOverLAN OBJECT IDENTIFIER ::= { id-kp 14 } > > The extended key usage extension MAY, at the option of the > certificate issuer, be either critical or non-critical. > > If the extended key usage is present in a certificate, > Certificate using applications MAY require that a particular purpose > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order > for the certificate to be acceptable to that application. > > If a certificate contains a key usage extension, the KeyUsage bits > that are needed depends on the EAP method that is employed. > There is currently no method that require the usage of the keyCertSign > or the cRLSign bit to be set. > >with the XXXX a little bit more specific. > >4 *** The OID arcs should be imported from > > >IMPORTS > > id-pe, id-kp > FROM PKIX1Explicit88 { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > id-mod(0) id-pkix1-explicit(18) } > > id-aca FROM > PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-attribute-cert(12)} > > >peter > > > > From owner-ietf-pkix@mail.imc.org Wed Apr 13 12:22:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10750 for ; Wed, 13 Apr 2005 12:22:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DFaJVG070314; Wed, 13 Apr 2005 08:36:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DFaJor070313; Wed, 13 Apr 2005 08:36:19 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3DFaHvV070306 for ; Wed, 13 Apr 2005 08:36:18 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3DFaGn04040; Wed, 13 Apr 2005 17:36:16 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Wed, 13 Apr 2005 17:36:16 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3DFaEl29892; Wed, 13 Apr 2005 17:36:14 +0200 (MEST) Date: Wed, 13 Apr 2005 17:36:14 +0200 (MEST) From: Peter Sylvester Message-Id: <200504131536.j3DFaEl29892@chandon.edelweb.fr> To: dpkemp@missi.ncsc.mil, david.cooper@nist.gov Subject: rfc3280 bis Cc: ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think this comment is also relevant somehow for 3280bis > > It also looks strange because ASN.1 is defined in X.680 :-). X.660 is > "Procedures > for the operation of OSI registration authorities: General procedures > and top arcs of > the ASN.1 object identifier tree". > > The titles of X.680 and X.690 are: > X.680: Information Technology - Abstract Syntax Notation One (ASN.1): > Specification of basic notation > X.690: Information Technology - ASN.1 encoding rules: Specification of > Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and > Distinguished Encoding Rules (DER) > From owner-ietf-pkix@mail.imc.org Wed Apr 13 17:30:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08749 for ; Wed, 13 Apr 2005 17:30:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DKiWtv090731; Wed, 13 Apr 2005 13:44:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DKiWPv090729; Wed, 13 Apr 2005 13:44:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3DKiWUF090718 for ; Wed, 13 Apr 2005 13:44:32 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 4465 invoked by uid 0); 13 Apr 2005 20:22:58 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.187.101) by woodstock.binhost.com with SMTP; 13 Apr 2005 20:22:58 -0000 Message-Id: <6.2.0.14.2.20050413161050.048ca720@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 13 Apr 2005 16:22:49 -0400 To: Peter Sylvester , ietf-pkix@imc.org From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt In-Reply-To: <200504131141.j3DBfFv28956@chandon.edelweb.fr> References: <200504131141.j3DBfFv28956@chandon.edelweb.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: List-ID: List-Unsubscribe: Peter: Some more remaks: >1 *** > >text says: > >1.3. Abstract Syntax Notation > > All X.509 certificate [X.509] extensions are defined using ASN.1 > [X.660]. > >and: > > [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 > encoding rules: Specification of Basic Encoding Rules > (BER), Canonical Encoding Rules (CER) and Distinguished > Encoding Rules (DER), 1997. > >this looks strange to me. The encoding rules are not the asn1 syntax. > >Suggestion: > >remove 1.3 and the reference. I have heard from Peter Sylvester and Peter Gutmann on this point. Anyone else have an opinion? >2 *** > > If a certificate contains a key usage extension, the KeyUsage bits > that are needed depends on the EAP method that is employed; however, > the keyCertSign bit and the cRLSign MUST NOT be associated with EAP > method end entity certificates. > >This means that you cannot have a certificat WITHOUT keyUsage? >Or, in case of a certificate without keyUsage, you could use it >for CrlSigning? No. The paragraph only talks about the key usage extension in support of EAP methods. The question you are asking is beyond the scope of the paragraph and the whole document. >This restriction is new, and I don't see why this is necessary. >I am not sure, but I don't know of any other purpose that has >a restriction like this, and current scvp specs don't allow to >check for this (you cannot specify MUST NOT). The IETF (or anyone else for that matter) should not specify EAP methods that expect either of these key usage bits to be set. >suggestion, remove the second half sentence. > > >3 *** chapter two should read IMO: > >2. EAP Extended Key Usage Values > > RFC 3280 [PROFILE] specifies the extended key usage X.509 certificate > extension. The extension indicates one or more purposes for which > the certified public key may be used. > > This specification defines two KeyPurposeId values: one for EAP over > PPP, and one for EAP over LAN (EAPOL). Inclusion of the EAP over PPP > value indicates that the certified public key is appropriate for use > with EAP in the PPP environment, and the inclusion of the EAPOL value > indicates that the certified public key is appropriate for use with > the EAP in the LAN environment. Inclusion of both values indicates > that the certified public key is appropriate for use in either of the > environments. > > id-kp-eapOverPPP OBJECT IDENTIFIER ::= { id-kp 13 } > > id-kp-eapOverLAN OBJECT IDENTIFIER ::= { id-kp 14 } > > The extended key usage extension MAY, at the option of the > certificate issuer, be either critical or non-critical. > > If the extended key usage is present in a certificate, > Certificate using applications MAY require that a particular purpose > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order > for the certificate to be acceptable to that application. > > If a certificate contains a key usage extension, the KeyUsage bits > that are needed depends on the EAP method that is employed. > There is currently no method that require the usage of the keyCertSign > or the cRLSign bit to be set. > >with the XXXX a little bit more specific. You are primarily asking for sentence to be deleted. The sentences that you would like to see go away are in RFC 3770, so I think that the removal needs to be justified. >4 *** The OID arcs should be imported from > > >IMPORTS > > id-pe, id-kp > FROM PKIX1Explicit88 { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > id-mod(0) id-pkix1-explicit(18) } > > id-aca FROM > PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-attribute-cert(12)} This is a matter of taste. Neither approach leads to implementation issues. Russ From owner-ietf-pkix@mail.imc.org Wed Apr 13 20:08:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22022 for ; Wed, 13 Apr 2005 20:08:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DNRDBj005190; Wed, 13 Apr 2005 16:27:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DNRDLB005189; Wed, 13 Apr 2005 16:27:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from amos.eb2bcom.com (cust3103.vic01.dataco.com.au [202.63.62.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DNRBXp005176 for ; Wed, 13 Apr 2005 16:27:12 -0700 (PDT) (envelope-from steven.legg@eb2bcom.com) Received: from [192.168.1.156] (10.1.2.225) by amos.eb2bcom.com (7.1.016.1) (authenticated as steven.legg) id 4236430A000028B8; Thu, 14 Apr 2005 09:33:07 +1000 Message-ID: <425DA9C8.2000601@eb2bcom.com> Date: Thu, 14 Apr 2005 09:22:48 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Housley CC: Peter Sylvester , ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt References: <200504131141.j3DBfFv28956@chandon.edelweb.fr> <6.2.0.14.2.20050413161050.048ca720@mail.binhost.com> In-Reply-To: <6.2.0.14.2.20050413161050.048ca720@mail.binhost.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, Russ Housley wrote: > > Peter: > > Some more remaks: > >> 1 *** >> >> text says: >> >> 1.3. Abstract Syntax Notation >> >> All X.509 certificate [X.509] extensions are defined using ASN.1 >> [X.660]. >> >> and: >> >> [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 >> encoding rules: Specification of Basic Encoding Rules >> (BER), Canonical Encoding Rules (CER) and Distinguished >> Encoding Rules (DER), 1997. >> >> this looks strange to me. The encoding rules are not the asn1 syntax. >> >> Suggestion: >> >> remove 1.3 and the reference. > > > I have heard from Peter Sylvester and Peter Gutmann on this point. > Anyone else have an opinion? Firstly, the reference is incorrect. BER/CER/DER are defined in X.690, not X.660. X.660 is about registration procedures for OIDs. Secondly, the reference is inappropriate. ASN.1's basic notation is defined in X.680. ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation Since knowledge of ASN.1 is required to interpret the specification, a normative reference to X.680 is obligatory. Regards, Steven From owner-ietf-pkix@mail.imc.org Thu Apr 14 05:04:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16801 for ; Thu, 14 Apr 2005 05:04:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E8AKig019658; Thu, 14 Apr 2005 01:10:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E8AKU2019657; Thu, 14 Apr 2005 01:10:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E8AGoZ019585 for ; Thu, 14 Apr 2005 01:10:18 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA16066; Thu, 14 Apr 2005 10:24:29 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005041410095678:1203 ; Thu, 14 Apr 2005 10:09:56 +0200 Message-ID: <425E2552.4090207@bull.net> Date: Thu, 14 Apr 2005 10:09:54 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: Russ Housley , pkix Subject: Re: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 14/04/2005 10:09:56, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 14/04/2005 10:09:59, Serialize complete at 14/04/2005 10:09:59 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan, > Denis, > Thanks for spending considerable time to comment on this draft. > The typo is noted and will be fixed. Thank you so much, for accepting to correct the typo. :-| > Some generic comments before we go into the specific text proposals: > You point out some well known issues related to the lack of absolute > cryptographic binding between CRL and certificates where the certificate > and CRL is not signed by the same key. Not really. It is indeed possible to have an absolute cryptographic binding between CRL and certificates where the certificate and CRL is not signed by the same key, but the key point is that proposed extension is *not* the means to provide such a binding (and you agree with this further down in this e-mail). The proposed extension is simply a means to find a possible certificate candidates, but not a means to make sure that the candidate is acceptable. > A certificate is always authoritative to identify the correct CRL for > its validation. While this is true in general, this is not always true. When indirect CRLs are used, a directly trusted CRL Issuer may be used. For other cases, your statement is correct. > But since the certificate is signed before the latest > CRL that validates it, the certificate can't cryptographically bind > (e.g. hash) the CRL but needs to identify it by verifiable attributes > such as issuer name and storage location. As you say, only issuer name or location may be used. Location cannot be used as this has been demonstrated in the previous e-mail, since a network attack could be performed. So only the issuer name can be used. Let us look, how: The CRL DP extension is defined as: DistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, reasons [1] ReasonFlags OPTIONAL, cRLIssuer [2] GeneralNames OPTIONAL } Secure binding may be obtained using cRLIssuer where GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName with GeneralName ::= CHOICE { otherName [0] AnotherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } where Name ::= CHOICE { RDNSequence } RFC 3280 states: " If the certificate issuer is not the CRL Issuer, then the cRLIssuer field MUST be present and contain the Name of the CRL issuer". A name is uniquely assigned to an entity, only if the name of the CA which has allocated it is known. Recursively, the DN of that CA is uniquely assigned to an entity, only if the DN of the CA which has allocated that DN it is known. This process ends up until the trust anchor that has issued the first CA certificate of the certification path is known. > This issue is however NOT introduced by this draft. It is simply a > generic issue with RFC 3280/X.509, especially for indirect CRLs > In this context I really can't see the difference between scenario A and > scenario B. It seems to me that the same validation principles apply to > both scenarios. Not exactly. From what is said above, it can be said that cRLIssuer DN has been uniquely assigned to that entity, if it is known that this DN has been issued by the CA that has issued the target certificate. This is scenario A which means that the trust conditions from the relying party are simple and well known. The problem is that with scenario B, no document provides the trust conditions to be used by the relying party and that there can be many different trust conditions, some of them may be secure, while some of them may be insecure depending upon the context. This is why it is important to make a difference between scenario A and B. > Section 6.3 of RFC 3280 is dealing with CRL validation and the > requirement to validate the CRL through a valid certificate path. ... but that section is lacking of further details that would allow two different imlplementations to end up with the same result. > This draft only introduces a new way to point to locate certificates > that can be helpful in building this path. At least one sentence of which we both agree ! It should be copied and pasted in the abstract. > It seems to me from that > perspective that specific requirements on CRL path building are outside > the scope of this draft. Since scenario B has so many possible options, it is not possible to cover all of them and the intent is not to describe and prescribe all of them. However, scenarion A is much simpler and may be described. I have many problems with the current introduction. I am restating my previous proposal for a revised introduction along the lines that "this draft only introduces a new way to point to locate certificates that can be helpful in building this path". If you have problems with that text, please propose revisions to it. If you can live with it, then we are solved with the introduction. RFC 3280 [PKIX1] specifies the validation of certification paths. One aspect involves the determination that a certificate has not been revoked, and one revocation checking mechanism is the Certificate Revocation List (CRL). Checking a CRL when the CRL is signed by the key of the Issuing CA is straightforward, but not necessarily otherwise. There are several legitimate scenarios where the certificate of the CRL issuer is not present, or easily discovered. Standardized methods of finding the certificate of the CRL issuer are currently available either though an accessible directory location or through use of the Subject Information Access extension in intermediary CA certificates. Directory lookup requires presence and access to a directory. The Subject Information Access extension supports building certification paths top-down (in the direction from the trust anchor to the CRL issuer), which will succeed if certificates include an appropriate Subject Information Access extension. Additional methods allowing the building of certification paths bottom-up to validate CRLs may be useful as well. This is the topic of this document. RFC 3280 [PKIX1] has provided for bottom-up discovery of certification paths through the Authority Information Access extension, where the id-ad-caIssuers access method may specify one or more accessLocation fields that contain references to CA certificates superior to the certificate containing this extension. This document permits use of the Authority Information Access extension in CRLs, enabling a CRL checking application to use the same access method (id-ad-caIssuers) to locate the certificate of the CRL issuer and complete the certification path building to an appropriate trust anchor. This extension may be used in the case when indirect CRLs are used, when the certification Authority (CA) that issued the CRL certificate changes its certificate signing key, or when the CA employs separate keys for certificate signing and CRL signing. Now the security considerations section still contains incorrect text. I have revised my previous proposal. If you have problems with that text, please propose revisions to it. If you can live with it, then we are solved with section 3. 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same DN, as well as the possibility for some trusted CAs (i.e. trusted to issue their own certificates and associated revocation status information but not trusted not handle revocation information from other CAs) to purposely use URLs or CRL DPs identical to some CRL DPs from other CAs and at the same time mounting a re-routing attack. This means that finding a CA certificate at the location indicated by this new extension is insufficient to make sure that it is the right one, and by consequence that the CRL where this extension has been found is also the right one. When the CRL is a direct CRL, relying parties shall make sure that the certificate of the CRL issuer has been issued by the same CA that has issued the target certificate. When the CRL contains the indirectCRL boolean set to TRUE, relying parties should locally know the URL of the CRL issuer(s) that they directly trust and use local trust conditions to make sure that the CRL that has been retrieved has indeed be issued by a directly trusted CRL Issuer. In particular, care should be taken in case two CAs would be using the same DN for two different CAs. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Indeed, more could be said about indirect CRLs, so if you want to add some more text, please do it. Denis >>Stefan Santesson >>Program Manager - Standards Liaison >>Windows Security > > > >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > >>On Behalf Of Denis Pinkas >>Sent: den 11 april 2005 00:59 >>To: Stefan Santesson; Russ Housley >>Cc: pkix >>Subject: Comments on >> >> >>Stefan and Russ, >> >>It took me several hours to write this long e-mail, hence for the > > delay > >>(in addition to the time for shooting a few "big five" with my > > camera). > >>This e-mail identifies several security issues, which are not > > currently > >>mentionned in the security considerations section. It finally proposes > > a > >>rewritting of the introduction and provides a strawman for a new > > security > >>considerations section (see the proposal at the end of this e-mail). >> >>Let us consider two different scenarios where this new extension would > > be > >>considered. >> >>Scenario A: The relying party does not trust any CRL issuer in > > particular > >>and will simply use the CRL Issuer designated by the Certificate > > Issuer by > >>means of the CRL DP extension. >> >>Scenario B: The relying party trusts at least a specific CRL issuer > > and > >>will >>get the CRLs from that CRL Issuer and then will make sure that the >>information contained in them matches with the designation of the >>Certificate Issuer. >> >>SCENARIO A >> >>In scenario A, the relying party will use the CRL DP from the target >>certificate to get the CRL and then will make sure that the CRL that > > has > >>been retrieved from that location is signed by the right CRL Issuer. >> >>The CRL DP extension is defined as: >> >> DistributionPoint ::= SEQUENCE { >> distributionPoint [0] DistributionPointName > > OPTIONAL, > >> reasons [1] ReasonFlags OPTIONAL, >> cRLIssuer [2] GeneralNames OPTIONAL } >> >>At least the distributionPoint field shall be present. It is supposed > > it > >>contains a general name of type URI, which is a pointer to the current > > CRL > >>for the associated reasons and will be issued by the associated > > cRLIssuer. > >>The CRL itself shall contain an IDP (Issuing Distribution Point). >> >>The IDP extension is defined as: >> >> issuingDistributionPoint ::= SEQUENCE { >> distributionPoint [0] DistributionPointName > > OPTIONAL, > >> onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, >> onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, >> onlySomeReasons [3] ReasonFlags OPTIONAL, >> indirectCRL [4] BOOLEAN DEFAULT FALSE, >> onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } >> >>A necessary but insufficient condition is that the distributionPoint > > field > >>from the IDP extension shall be equal to the distributionPoint field > > from > >>the CRL DP extension. >> >>This is insufficient since a URL like > > URL=http://corppki/crl/extranet.crl > >>could be used by accident by two different CAs, or a CA under the same >>root >>key could maliciously use that URL or a different and re-route all > > packets > >>to an address where that CRL is made available. >> >>This means that the tupple CRL DP extension from certificates and the > > IDP > >>extension from CRLs even if then match are insufficient to make sure > > that > >>it >>is the right CRL that has been retrieved. This is "normal" until some >>cryptographic checksums are used to make sure that this is the right >>information. >> >>Any CA, trusted under a root key, could use an IDP extension in a CRL >>matching the IDP extension from another true CRL and unless other > > tests > >>are >>performed, would fool relying parties. >> >>This is the major reason why the current document in its current form > > is > >>dangerous to be published. It incorporates verification concepts which > > are > >>missing major security issues. The security consideration section > > attempts > >>to tackle the issue but it misses the point. >> >>The major problem is not the definition of this new extension that > > could > >>provide untrusted but "useful" information, but the concepts behind > > path > >>construction. >> >>SCENARIO B >> >>In scenario B, the relying party contacts the location of a trusted > > CRL > >>Issuer and wants to verify that the retrieved CRL is correctly signed. >> >>Suppose that the retrieved CRL contains the newly defined extension > > which > >>specifies one or more accessLocation fields that contains references > > to CA > >>certificates superior to the CRL containing this extension. >> >>Let us consider that one accessLocation field contains the following > > URL: > >>http://corppki/aia/certificates.crt >> >>The relying party will access this URL to retrieve some CA > > certificates. > >>Nothing at this point would prevent a network attack so that access to >>this >>URL is re-routed to another location. The question is how the relying >>party >>can figure out and what kind of tests it should make. The draft is > > silent > >>about this. >> >>It does not help the end-user to define new extensions if at the same > > time > >>there are no explanations or guidance to tell how are they should be > > used > >>in >>order to build a secure system. >> >>Let us suppose that the information retrieved is just "useful" >>certificates >>at this time (i.e. untrusted). >> >>In order to build a path, a relying party needs to make sure of the > > name > >>of >>the CRL Issuer, which means not simply knowing the DN of the CRL > > issuer > >>but >>also all the other DNs from the upper CAs up to a root key. This kind > > of > >>assumption or explanations is currently missing in the draft. >> >>Scenario B would be correctly supported if the text would mention two >>points: >> >> 1) the location of the "trusted CRL Issuer" must be locally known, >> 2) the name of the "trusted CRL Issuer" must be locally known, >> which means not simply knowing the DN of the CRL issuer, >> but also all the other DNs from the upper CAs up to a root key. >> >>Using the "useful" certificates that would be retrieved using that new >>extension, the relying party would then build a certification path to >>validate the retrieved CRL. Additional details, described nowhere, > > should > >>be >>given so that it can be sure that it is a CRL Issuer and not a CA, etc > > ... > >>Then the relying party knows that he got a correct indirect CRL and > > has to > >>make sure that the name of the CA is present. Additional details would > > be > >>needed to explain name matching taking into account that two CAs could > > be > >>given the same DN by two different CAs. >> >> >>CONCLUSION: >> >>I see two ways to progress: >> >> a) "avoid" the problem *now* and leave it for later. This means >> saying that this extension may provide useful information that >> still needs to be verified to be trusted. The security >> considerations section would tackle the issue but not provide >> the full answer. >> >> b) address the issue and say how to handle CRLs when they are not >>signed >> by the CA. >> >>In case of a), that is the easiest *temporary* solution, I would > > propose > >>to >>rewrite the introduction in the following way : >> >> RFC 3280 [PKIX1] specifies the validation of certification paths. >> One aspect involves the determination that a certificate has not > > been > >> revoked, and one revocation checking mechanism is the Certificate >> Revocation List (CRL). Checking a CRL when the CRL is signed by > > the > >> key of the Issuing CA is straightforward, but not necessarily >> otherwise. >> >> There are several legitimate scenarios where the certificate of > > the > >> CRL issuer is not present, or easily discovered. >> >> Standardized methods of finding the certificate of the CRL issuer > > are > >> currently available either though an accessible directory location > > or > >> through use of the Subject Information Access extension in >> intermediary CA certificates. >> >> Directory lookup requires presence and access to a directory. The >> Subject Information Access extension supports building > > certification > >> paths top-down (in the direction from the trust anchor to the CRL >> issuer), which will succeed if certificates include an appropriate >> Subject Information Access extension. Additional methods allowing >> the building of certification paths bottom-up to validate CRLs >> may be useful as well. This is the topic of this document. >> >> RFC 3280 [PKIX1] has provided for bottom-up discovery of >> certification paths through the Authority Information Access >> extension, where the id-ad-caIssuers access method may specify one > > or > >> more accessLocation fields that contain references to CA > > certificates > >> superior to the certificate containing this extension. >> >> This document permits use of the Authority Information Access >> extension in CRLs, enabling a CRL checking application to use the >> same access method (id-ad-caIssuers) to locate the certificate of >> the CRL issuer and complete the certification path building to an >> appropriate trust anchor. >> >> This extension may be used in the case when indirect CRLs are > > used, > >> when the certification Authority (CA) that issued the CRL > > certificate > >> changes its certificate signing key, or when the CA employs > > separate > >> keys for certificate signing and CRL signing. >> >>A typo would need to be corrected in section 2: change >>AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax. >> >>Section 3 about Security Considerations would need to be changed. >>Hereafter is a proposal: >> >>3 Security Considerations >> >> Implementers should take into account the possible existence of >> multiple unrelated CAs and CRL issuers with the same DN, as well >> as the possibility for some trusted CAs (i.e. trusted to issue >> their own certificates and associated revocation status > > information > >> but not trusted not handle revocation information from other > > CAs) > >> to purposely use URLs or CRL DPs identical to some CRL DPs from >> other CAs and at the same time mounting a re-routing attack. >> >> This means that finding a CA certificate at the location > > indicated > >> by this new extension is insufficient to make sure that it is > > the > >> right one, and by consequence that the CRL where this extension >> has been found is also the right one. >> >> When the CRL contains the indirectCRL boolean set to TRUE, then > > the > >> relying party should locally know the URL of the CRL issuer(s) > > that > >> it directly trusts and also the associated name of the trusted > > CRL > >> issuer, which means not simply knowing the DN of the CRL issuer, >> but also all the other DNs of the upper CAs up to a root key > > (since > >> two CAs might be given the same DN by two different CAs). >> >> When the CRL is a direct CRL, then relying parties shall make > > sure > >> that the certificate of the CRL issuer has been issued by the > > same > >> CA that has issued the target certificate. >> >> Implementers should always take the steps of validating the >> retrieved data to ensure that the data is properly formed. >> >>Of course, much more could be said and an informative annex would be > > quite > >>useful. >> >>In case of b), more work would need to be done. >> >>Denis >> > > > From owner-ietf-pkix@mail.imc.org Thu Apr 14 05:30:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18058 for ; Thu, 14 Apr 2005 05:30:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E8o4g4033430; Thu, 14 Apr 2005 01:50:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E8o4Li033429; Thu, 14 Apr 2005 01:50:04 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3E8o26Y033410 for ; Thu, 14 Apr 2005 01:50:03 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3E8njn17084; Thu, 14 Apr 2005 10:49:45 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Thu, 14 Apr 2005 10:49:45 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3E8nim01640; Thu, 14 Apr 2005 10:49:44 +0200 (MEST) Date: Thu, 14 Apr 2005 10:49:44 +0200 (MEST) From: Peter Sylvester Message-Id: <200504140849.j3E8nim01640@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, ietf-pkix@imc.org, housley@vigilsec.com Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >1 *** I think there were two other answers. > >2 *** > > > > If a certificate contains a key usage extension, the KeyUsage bits > > that are needed depends on the EAP method that is employed; however, > > the keyCertSign bit and the cRLSign MUST NOT be associated with EAP > > method end entity certificates. > > > >This means that you cannot have a certificat WITHOUT keyUsage? > >Or, in case of a certificate without keyUsage, you could use it > >for CrlSigning? > > No. The paragraph only talks about the key usage extension in support of > EAP methods. The question you are asking is beyond the scope of the > paragraph and the whole document. > oops, I made a mistake. i wanted to ask "could you use a certificate that has no keyUsage for EAP methods?' > >This restriction is new, and I don't see why this is necessary. > >I am not sure, but I don't know of any other purpose that has > >a restriction like this, and current scvp specs don't allow to > >check for this (you cannot specify MUST NOT). > > The IETF (or anyone else for that matter) should not specify EAP methods > that expect either of these key usage bits to be set. > > You are primarily asking for sentence to be deleted. The sentences that you > would like to see go away are in RFC 3770, so I think that the removal > needs to be justified. The initial text was an inconsistent adoption from something of 2459 and 3280. This demonstrates the problematics of copying text portions "for convenience." Correcting the text as is still does not give a complete picture since it is only a subset of rfc 3280. This kind of 'layman guide to 3280' doesn't seem appropriate to me here. Also, 3280 is under revision, if it happens that the corresponding text gets clarified in some way, one would have something considered unprecise elsewhere. > >4 *** The OID arcs should be imported from > > > > > >IMPORTS > > > > id-pe, id-kp > > FROM PKIX1Explicit88 { iso(1) identified-organization(3) > > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > > id-mod(0) id-pkix1-explicit(18) } > > > > id-aca FROM > > PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) > > internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) > > id-mod-attribute-cert(12)} > > This is a matter of taste. Neither approach leads to implementation issues. Since, as you say, there are no implmentation issues. but this is not a matter of taste. Importing the correct definition is something else that making the 'hopefully' identical one. There is ONE authoritive place to have 'this' id-aca defined. (and another id-aca elsewhere) From owner-ietf-pkix@mail.imc.org Thu Apr 14 11:38:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25221 for ; Thu, 14 Apr 2005 11:38:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EEhe77027819; Thu, 14 Apr 2005 07:43:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EEhePl027818; Thu, 14 Apr 2005 07:43:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EEhdft027812 for ; Thu, 14 Apr 2005 07:43:39 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 25643 invoked by uid 0); 14 Apr 2005 14:01:09 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.114) by woodstock.binhost.com with SMTP; 14 Apr 2005 14:01:09 -0000 Message-Id: <6.2.0.14.2.20050414095731.05c082b0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 14 Apr 2005 10:01:08 -0400 To: Peter Sylvester From: Russ Housley Subject: draft-ietf-pkix-rfc3770bis-01: key usage extension Cc: ietf-pkix@imc.org In-Reply-To: <200504140849.j3E8nim01640@chandon.edelweb.fr> References: <200504140849.j3E8nim01640@chandon.edelweb.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: List-ID: List-Unsubscribe: Note: I am starting a separate thread for each of the unresolved issues. I hope this draws more people into the discussion. Peter: > > >2 *** > > > > > > If a certificate contains a key usage extension, the KeyUsage bits > > > that are needed depends on the EAP method that is employed; however, > > > the keyCertSign bit and the cRLSign MUST NOT be associated with EAP > > > method end entity certificates. > > > > > >This means that you cannot have a certificat WITHOUT keyUsage? > > >Or, in case of a certificate without keyUsage, you could use it > > >for CrlSigning? > > > > No. The paragraph only talks about the key usage extension in support of > > EAP methods. The question you are asking is beyond the scope of the > > paragraph and the whole document. > > > >oops, I made a mistake. i wanted to ask "could you use a certificate >that has no keyUsage for EAP methods?' Yes. In this case, the certificate is not providing any constraints on the key usage. Russ From owner-ietf-pkix@mail.imc.org Thu Apr 14 12:28:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29039 for ; Thu, 14 Apr 2005 12:28:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EFh1q4035360; Thu, 14 Apr 2005 08:43:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EFh1JJ035359; Thu, 14 Apr 2005 08:43:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EFh0x0035353 for ; Thu, 14 Apr 2005 08:43:00 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 4038 invoked by uid 0); 14 Apr 2005 14:47:54 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.114) by woodstock.binhost.com with SMTP; 14 Apr 2005 14:47:54 -0000 Message-Id: <6.2.0.14.2.20050414104520.05029b50@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 14 Apr 2005 10:47:49 -0400 To: Peter Sylvester From: Russ Housley Subject: draft-ietf-pkix-rfc3770bis-01: Section 2 Cc: ietf-pkix@imc.org In-Reply-To: <200504140849.j3E8nim01640@chandon.edelweb.fr> References: <200504140849.j3E8nim01640@chandon.edelweb.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: List-ID: List-Unsubscribe: Note: I am starting a separate thread for each of the unresolved issues. I hope this draws more people into the discussion. Peter: > > >This restriction is new, and I don't see why this is necessary. > > >I am not sure, but I don't know of any other purpose that has > > >a restriction like this, and current scvp specs don't allow to > > >check for this (you cannot specify MUST NOT). > > > > The IETF (or anyone else for that matter) should not specify EAP methods > > that expect either of these key usage bits to be set. > > > > You are primarily asking for sentence to be deleted. The sentences that > you > > would like to see go away are in RFC 3770, so I think that the removal > > needs to be justified. > >The initial text was an inconsistent adoption from something of 2459 and 3280. >This demonstrates the problematics of copying text portions "for convenience." >Correcting the text as is still does not give a complete picture since it >is only a subset of rfc 3280. This kind of 'layman guide to 3280' doesn't >seem appropriate to me here. > >Also, 3280 is under revision, if it happens that the corresponding text >gets clarified in some way, one would have something considered >unprecise elsewhere. I do not understand the harm that you believe is being caused. Russ From owner-ietf-pkix@mail.imc.org Thu Apr 14 12:50:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01603 for ; Thu, 14 Apr 2005 12:50:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EG0lCL036753; Thu, 14 Apr 2005 09:00:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EG0klD036752; Thu, 14 Apr 2005 09:00:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EG0jB1036744 for ; Thu, 14 Apr 2005 09:00:45 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 17427 invoked by uid 0); 14 Apr 2005 15:00:39 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.114) by woodstock.binhost.com with SMTP; 14 Apr 2005 15:00:39 -0000 Message-Id: <6.2.0.14.2.20050414104914.0505b020@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 14 Apr 2005 11:00:39 -0400 To: Peter Sylvester From: Russ Housley Subject: draft-ietf-pkix-rfc3770bis-01: OID Import Cc: ietf-pkix@imc.org In-Reply-To: <200504140849.j3E8nim01640@chandon.edelweb.fr> References: <200504140849.j3E8nim01640@chandon.edelweb.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: List-ID: List-Unsubscribe: Note: I am starting a separate thread for each of the unresolved issues. I hope this draws more people into the discussion. Peter: > > >4 *** The OID arcs should be imported from > > > > > > > > >IMPORTS > > > > > > id-pe, id-kp > > > FROM PKIX1Explicit88 { iso(1) identified-organization(3) > > > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > > > id-mod(0) id-pkix1-explicit(18) } > > > > > > id-aca FROM > > > PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) > > > internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) > > > id-mod-attribute-cert(12)} > > > > This is a matter of taste. Neither approach leads to implementation > issues. > >Since, as you say, there are no implmentation issues. but this is not >a matter of taste. Importing the correct definition is something else >that making the 'hopefully' identical one. > >There is ONE authoritive place to have 'this' id-aca defined. >(and another id-aca elsewhere) I do not know about other people, but would rather avoid IMPORT statements for simple things. IMPORT is a great tool for complex structures, but for a simple constant, it is not worth the effort. I have had to make edits to old ASN.1 modules to avoid errors that are introduced when one modules imports stuff from another that imports stuff from another that imports stuff from another. The changes are almost always in parts that are not needed for the part that is needed. I'll give a recent example. RFC 2634 imports from CMS. The ASN.1 module says: -- RFC 2630: Cryptographic Message Syntax (CMS) ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } I needed to change this to: -- RFC 3852: Cryptographic Message Syntax (CMS) ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } Why? It did not have anything to do with ContentType, IssuerAndSerialNumber, or SubjectKeyIdentifier. It had to do with something else in the RFC 2630 module. I would rather not have to make these kinds of edits, so I prefer to duplicate simple constants like OID arcs. Russ From owner-ietf-pkix@mail.imc.org Thu Apr 14 13:22:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03864 for ; Thu, 14 Apr 2005 13:22:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EGakcS038851; Thu, 14 Apr 2005 09:36:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EGakmf038850; Thu, 14 Apr 2005 09:36:46 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3EGaicW038840 for ; Thu, 14 Apr 2005 09:36:45 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3EGahn25792; Thu, 14 Apr 2005 18:36:43 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Thu, 14 Apr 2005 18:36:43 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3EGafb02347; Thu, 14 Apr 2005 18:36:41 +0200 (MEST) Date: Thu, 14 Apr 2005 18:36:41 +0200 (MEST) From: Peter Sylvester Message-Id: <200504141636.j3EGafb02347@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, housley@vigilsec.com Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension Cc: ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > > >2 *** > > > > > > > > If a certificate contains a key usage extension, the KeyUsage bits > > > > that are needed depends on the EAP method that is employed; however, > > > > the keyCertSign bit and the cRLSign MUST NOT be associated with EAP > > > > method end entity certificates. > > > > > > > >This means that you cannot have a certificat WITHOUT keyUsage? > > > >Or, in case of a certificate without keyUsage, you could use it > > > >for CrlSigning? > > > > > > No. The paragraph only talks about the key usage extension in support of > > > EAP methods. The question you are asking is beyond the scope of the > > > paragraph and the whole document. > > > > > > >oops, I made a mistake. i wanted to ask "could you use a certificate > >that has no keyUsage for EAP methods?' > > Yes. In this case, the certificate is not providing any constraints on the > key usage. > > Russ take a cert with all bit on. This is equivalent to having no keyUsage at all as far as I remember. in this case the keyCertSign bit and the cRLSign are set, and the above 'MUST NOT' prohibits use of this cert. is this what you intend? I don't think so. Isn't the right wording: no known EAP usage requires keyCertSign or cRLSign? From owner-ietf-pkix@mail.imc.org Thu Apr 14 13:26:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04092 for ; Thu, 14 Apr 2005 13:26:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EGmGYm039656; Thu, 14 Apr 2005 09:48:16 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EGmGSI039655; Thu, 14 Apr 2005 09:48:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EGmFK8039649 for ; Thu, 14 Apr 2005 09:48:15 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 29332 invoked by uid 0); 14 Apr 2005 15:57:40 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.97.235) by woodstock.binhost.com with SMTP; 14 Apr 2005 15:57:40 -0000 Message-Id: <6.2.0.14.2.20050414114650.0662cd50@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 14 Apr 2005 11:57:35 -0400 To: Denis Pinkas , Stefan Santesson From: Russ Housley Subject: Re: Comments on Cc: pkix In-Reply-To: <425A2E60.2080008@bull.net> References: <425A2E60.2080008@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis: When a certificate issuer is using Indirect CRLs, the CRLDP identifies the CRL issuer. In this situation, the cRLIssuer field in the CRLDP identifies the signer of the forthcoming CRLs. So, in your Scenario A, the CRL Issuer is explicitly identified in the CRLDP. However, the CRL Issuer's certificate is not necessarily available from the information in the CRLDP. Thus, the CRL AIA allows the certificate user to obtain it. In this situation the verification must make sure that the cRLIssuer in the CRLDP must match the subject/subjectAltName in the certificate that is fetched via the CRL AIA. In my view, this scenario validates the need for this document. Russ >Stefan and Russ, > >It took me several hours to write this long e-mail, hence for the delay >(in addition to the time for shooting a few “big five” with my camera). > >This e-mail identifies several security issues, which are not currently >mentionned in the security considerations section. It finally proposes a >rewritting of the introduction and provides a strawman for a new security >considerations section (see the proposal at the end of this e-mail). > >Let us consider two different scenarios where this new extension would be >considered. > >Scenario A: The relying party does not trust any CRL issuer in particular >and will simply use the CRL Issuer designated by the Certificate Issuer by >means of the CRL DP extension. > >Scenario B: The relying party trusts at least a specific CRL issuer and >will get the CRLs from that CRL Issuer and then will make sure that the >information contained in them matches with the designation of the >Certificate Issuer. > >SCENARIO A > >In scenario A, the relying party will use the CRL DP from the target >certificate to get the CRL and then will make sure that the CRL that has >been retrieved from that location is signed by the right CRL Issuer. > >The CRL DP extension is defined as: > > DistributionPoint ::= SEQUENCE { > distributionPoint [0] DistributionPointName OPTIONAL, > reasons [1] ReasonFlags OPTIONAL, > cRLIssuer [2] GeneralNames OPTIONAL } > >At least the distributionPoint field shall be present. It is supposed it >contains a general name of type URI, which is a pointer to the current CRL >for the associated reasons and will be issued by the associated cRLIssuer. > >The CRL itself shall contain an IDP (Issuing Distribution Point). > >The IDP extension is defined as: > > issuingDistributionPoint ::= SEQUENCE { > distributionPoint [0] DistributionPointName OPTIONAL, > onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, > onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, > onlySomeReasons [3] ReasonFlags OPTIONAL, > indirectCRL [4] BOOLEAN DEFAULT FALSE, > onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } > >A necessary but insufficient condition is that the distributionPoint field >from the IDP extension shall be equal to the distributionPoint field from >the CRL DP extension. > >This is insufficient since a URL like URL=http://corppki/crl/extranet.crl >could be used by accident by two different CAs, or a CA under the same >root key could maliciously use that URL or a different and re-route all >packets to an address where that CRL is made available. > >This means that the tupple CRL DP extension from certificates and the IDP >extension from CRLs even if then match are insufficient to make sure that >it is the right CRL that has been retrieved. This is “normal” until >some cryptographic checksums are used to make sure that this is the right >information. > >Any CA, trusted under a root key, could use an IDP extension in a CRL >matching the IDP extension from another true CRL and unless other tests >are performed, would fool relying parties. > >This is the major reason why the current document in its current form is >dangerous to be published. It incorporates verification concepts which are >missing major security issues. The security consideration section attempts >to tackle the issue but it misses the point. > >The major problem is not the definition of this new extension that could >provide untrusted but “useful” information, but the concepts behind >path construction. > >SCENARIO B > >In scenario B, the relying party contacts the location of a trusted CRL >Issuer and wants to verify that the retrieved CRL is correctly signed. > >Suppose that the retrieved CRL contains the newly defined extension which >specifies one or more accessLocation fields that contains references to CA >certificates superior to the CRL containing this extension. > >Let us consider that one accessLocation field contains the following URL: >http://corppki/aia/certificates.crt > >The relying party will access this URL to retrieve some CA certificates. >Nothing at this point would prevent a network attack so that access to >this URL is re-routed to another location. The question is how the relying >party can figure out and what kind of tests it should make. The draft is >silent about this. > >It does not help the end-user to define new extensions if at the same time >there are no explanations or guidance to tell how are they should be used >in order to build a secure system. > >Let us suppose that the information retrieved is just “useful” >certificates at this time (i.e. untrusted). > >In order to build a path, a relying party needs to make sure of the name >of the CRL Issuer, which means not simply knowing the DN of the CRL issuer >but also all the other DNs from the upper CAs up to a root key. This kind >of assumption or explanations is currently missing in the draft. > >Scenario B would be correctly supported if the text would mention two points: > > 1) the location of the “trusted CRL Issuer” must be locally known, > 2) the name of the “trusted CRL Issuer” must be locally known, > which means not simply knowing the DN of the CRL issuer, > but also all the other DNs from the upper CAs up to a root key. > >Using the “useful” certificates that would be retrieved using that new >extension, the relying party would then build a certification path to >validate the retrieved CRL. Additional details, described nowhere, should >be given so that it can be sure that it is a CRL Issuer and not a CA, etc ... > >Then the relying party knows that he got a correct indirect CRL and has to >make sure that the name of the CA is present. Additional details would be >needed to explain name matching taking into account that two CAs could be >given the same DN by two different CAs. > > >CONCLUSION: > >I see two ways to progress: > > a) “avoid” the problem *now* and leave it for later. This means > saying that this extension may provide useful information that > still needs to be verified to be trusted. The security > considerations section would tackle the issue but not provide > the full answer. > > b) address the issue and say how to handle CRLs when they are not signed > by the CA. > >In case of a), that is the easiest *temporary* solution, I would propose >to rewrite the introduction in the following way : > > RFC 3280 [PKIX1] specifies the validation of certification paths. > One aspect involves the determination that a certificate has not been > revoked, and one revocation checking mechanism is the Certificate > Revocation List (CRL). Checking a CRL when the CRL is signed by the > key of the Issuing CA is straightforward, but not necessarily > otherwise. > > There are several legitimate scenarios where the certificate of the > CRL issuer is not present, or easily discovered. > > Standardized methods of finding the certificate of the CRL issuer are > currently available either though an accessible directory location or > through use of the Subject Information Access extension in > intermediary CA certificates. > > Directory lookup requires presence and access to a directory. The > Subject Information Access extension supports building certification > paths top-down (in the direction from the trust anchor to the CRL > issuer), which will succeed if certificates include an appropriate > Subject Information Access extension. Additional methods allowing > the building of certification paths bottom-up to validate CRLs > may be useful as well. This is the topic of this document. > > RFC 3280 [PKIX1] has provided for bottom-up discovery of > certification paths through the Authority Information Access > extension, where the id-ad-caIssuers access method may specify one or > more accessLocation fields that contain references to CA certificates > superior to the certificate containing this extension. > > This document permits use of the Authority Information Access > extension in CRLs, enabling a CRL checking application to use the > same access method (id-ad-caIssuers) to locate the certificate of > the CRL issuer and complete the certification path building to an > appropriate trust anchor. > > This extension may be used in the case when indirect CRLs are used, > when the certification Authority (CA) that issued the CRL certificate > changes its certificate signing key, or when the CA employs separate > keys for certificate signing and CRL signing. > >A typo would need to be corrected in section 2: change >AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax. > >Section 3 about Security Considerations would need to be changed. >Hereafter is a proposal: > >3 Security Considerations > > Implementers should take into account the possible existence of > multiple unrelated CAs and CRL issuers with the same DN, as well > as the possibility for some trusted CAs (i.e. trusted to issue > their own certificates and associated revocation status information > but not trusted not handle revocation information from other CAs) > to purposely use URLs or CRL DPs identical to some CRL DPs from > other CAs and at the same time mounting a re-routing attack. > > This means that finding a CA certificate at the location indicated > by this new extension is insufficient to make sure that it is the > right one, and by consequence that the CRL where this extension > has been found is also the right one. > > When the CRL contains the indirectCRL boolean set to TRUE, then the > relying party should locally know the URL of the CRL issuer(s) that > it directly trusts and also the associated name of the trusted CRL > issuer, which means not simply knowing the DN of the CRL issuer, > but also all the other DNs of the upper CAs up to a root key (since > two CAs might be given the same DN by two different CAs). > > When the CRL is a direct CRL, then relying parties shall make sure > that the certificate of the CRL issuer has been issued by the same > CA that has issued the target certificate. > > Implementers should always take the steps of validating the > retrieved data to ensure that the data is properly formed. > >Of course, much more could be said and an informative annex would be quite >useful. > >In case of b), more work would need to be done. > >Denis > From owner-ietf-pkix@mail.imc.org Thu Apr 14 13:51:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06198 for ; Thu, 14 Apr 2005 13:51:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EH7Yr5041191; Thu, 14 Apr 2005 10:07:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EH7YvM041190; Thu, 14 Apr 2005 10:07:34 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3EH7WP0041182 for ; Thu, 14 Apr 2005 10:07:33 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3EH7Un26281; Thu, 14 Apr 2005 19:07:30 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Thu, 14 Apr 2005 19:07:30 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3EH7Uj02411; Thu, 14 Apr 2005 19:07:30 +0200 (MEST) Date: Thu, 14 Apr 2005 19:07:30 +0200 (MEST) From: Peter Sylvester Message-Id: <200504141707.j3EH7Uj02411@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, housley@vigilsec.com Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import Cc: ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Note: I am starting a separate thread for each of the unresolved > issues. I hope this draws more people into the discussion. > > Peter: > > > > >4 *** The OID arcs should be imported from > > > > > > > > > > > >IMPORTS > > > > > > > > id-pe, id-kp > > > > FROM PKIX1Explicit88 { iso(1) identified-organization(3) > > > > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > > > > id-mod(0) id-pkix1-explicit(18) } > > > > > > > > id-aca FROM > > > > PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) > > > > internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) > > > > id-mod-attribute-cert(12)} > > > > > > This is a matter of taste. Neither approach leads to implementation > > issues. > > > >Since, as you say, there are no implmentation issues. but this is not > >a matter of taste. Importing the correct definition is something else > >that making the 'hopefully' identical one. > > > >There is ONE authoritive place to have 'this' id-aca defined. > >(and another id-aca elsewhere) > > I do not know about other people, but would rather avoid IMPORT statements > for simple things. IMPORT is a great tool for complex structures, but for > a simple constant, it is not worth the effort. Now you say that it is not a matter of taste. By the way, further down the example is an import of something that is NOT SIMPLE. Using this technique requires to keep track of all copies, and IF a copied definitions changes slightly in the main definition module THEN you get inconsistencies. > I have had to make edits to old ASN.1 modules to avoid errors that are > introduced when one modules imports stuff from another that imports stuff > from another that imports stuff from another. The changes are almost > always in parts that are not needed for the part that is needed. I'll give > a recent example. > > RFC 2634 imports from CMS. The ASN.1 module says: > > -- RFC 2630: Cryptographic Message Syntax (CMS) > ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier > FROM CryptographicMessageSyntax > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs-9(9) smime(16) modules(0) cms(1) } > > I needed to change this to: > > -- RFC 3852: Cryptographic Message Syntax (CMS) > ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier > FROM CryptographicMessageSyntax2004 > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs-9(9) smime(16) modules(0) cms-2004(24) } > > Why? It did not have anything to do with ContentType, > IssuerAndSerialNumber, or SubjectKeyIdentifier. It had to do with > something else in the RFC 2630 module. Do you mean the usage of 'Name' which is used in IssuerAndSerialNumber? You don't change the definition of a module. You make a new one. I don't see the point. > I would rather not have to make these kinds of edits, so I prefer to > duplicate simple constants like OID arcs. And what has this to do with an import of a constant? From owner-ietf-pkix@mail.imc.org Thu Apr 14 14:27:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09328 for ; Thu, 14 Apr 2005 14:27:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EHlGLo044223; Thu, 14 Apr 2005 10:47:16 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EHlGp8044222; Thu, 14 Apr 2005 10:47:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EHlFTJ044213 for ; Thu, 14 Apr 2005 10:47:15 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 17861 invoked by uid 0); 14 Apr 2005 17:24:49 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.97.235) by woodstock.binhost.com with SMTP; 14 Apr 2005 17:24:49 -0000 Message-Id: <6.2.0.14.2.20050414132213.039a9ae0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 14 Apr 2005 13:24:48 -0400 To: Peter Sylvester , Peter.Sylvester@edelweb.fr From: Russ Housley Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension Cc: ietf-pkix@imc.org In-Reply-To: <200504141636.j3EGafb02347@chandon.edelweb.fr> References: <200504141636.j3EGafb02347@chandon.edelweb.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: List-ID: List-Unsubscribe: Peter: > > > > >2 *** > > > > > > > > > > If a certificate contains a key usage extension, the KeyUsage bits > > > > > that are needed depends on the EAP method that is employed; > however, > > > > > the keyCertSign bit and the cRLSign MUST NOT be associated > with EAP > > > > > method end entity certificates. > > > > > > > > > >This means that you cannot have a certificat WITHOUT keyUsage? > > > > >Or, in case of a certificate without keyUsage, you could use it > > > > >for CrlSigning? > > > > > > > > No. The paragraph only talks about the key usage extension in > support of > > > > EAP methods. The question you are asking is beyond the scope of the > > > > paragraph and the whole document. > > > > > > > > > >oops, I made a mistake. i wanted to ask "could you use a certificate > > >that has no keyUsage for EAP methods?' > > > > Yes. In this case, the certificate is not providing any constraints on > the > > key usage. > > > > Russ > >take a cert with all bit on. This is equivalent to having no keyUsage at all >as far as I remember. in this case the keyCertSign bit and the cRLSign are >set, >and the above 'MUST NOT' prohibits use of this cert. is this what you intend? >I don't think so. > >Isn't the right wording: no known EAP usage requires keyCertSign or cRLSign? How about: ... however, EAP methods MUST NOT require the keyCertSign bit or the cRLSign to be set in end entity certificates. Russ From owner-ietf-pkix@mail.imc.org Thu Apr 14 15:09:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13310 for ; Thu, 14 Apr 2005 15:09:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EIEa9b046528; Thu, 14 Apr 2005 11:14:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EIEa7S046527; Thu, 14 Apr 2005 11:14:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EIEZDT046520 for ; Thu, 14 Apr 2005 11:14:35 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 17835 invoked by uid 0); 14 Apr 2005 17:47:29 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.36.30) by woodstock.binhost.com with SMTP; 14 Apr 2005 17:47:29 -0000 Message-Id: <6.2.0.14.2.20050414133627.06d4a5b0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 14 Apr 2005 13:45:59 -0400 To: Peter Sylvester From: Russ Housley Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import Cc: ietf-pkix@imc.org In-Reply-To: <200504141707.j3EH7Uj02411@chandon.edelweb.fr> References: <200504141707.j3EH7Uj02411@chandon.edelweb.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: List-ID: List-Unsubscribe: Peter: > > Note: I am starting a separate thread for each of the unresolved > > issues. I hope this draws more people into the discussion. > > > > Peter: > > > > > > >4 *** The OID arcs should be imported from > > > > > > > > > > > > > > >IMPORTS > > > > > > > > > > id-pe, id-kp > > > > > FROM PKIX1Explicit88 { iso(1) identified-organization(3) > > > > > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > > > > > id-mod(0) id-pkix1-explicit(18) } > > > > > > > > > > id-aca FROM > > > > > PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) > > > > > internet(1) security(5) mechanisms(5) pkix(7) > id-mod(0) > > > > > id-mod-attribute-cert(12)} > > > > > > > > This is a matter of taste. Neither approach leads to implementation > > > issues. > > > > > >Since, as you say, there are no implmentation issues. but this is not > > >a matter of taste. Importing the correct definition is something else > > >that making the 'hopefully' identical one. > > > > > >There is ONE authoritive place to have 'this' id-aca defined. > > >(and another id-aca elsewhere) > > > > I do not know about other people, but would rather avoid IMPORT statements > > for simple things. IMPORT is a great tool for complex structures, but for > > a simple constant, it is not worth the effort. > >Now you say that it is not a matter of taste. No. I shared the reason that I prefer to include the OIDs rather than IMPORTing them. They both work. >By the way, further down the example is an import of something that is NOT >SIMPLE. > >Using this technique requires to keep track of all copies, and IF a >copied definitions changes slightly in the main definition module >THEN you get inconsistencies. True. Neither of the alternatives is perfect. They have different kinds of pain. > > I have had to make edits to old ASN.1 modules to avoid errors that are > > introduced when one modules imports stuff from another that imports stuff > > from another that imports stuff from another. The changes are almost > > always in parts that are not needed for the part that is needed. I'll > give > > a recent example. > > > > RFC 2634 imports from CMS. The ASN.1 module says: > > > > -- RFC 2630: Cryptographic Message Syntax (CMS) > > ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier > > FROM CryptographicMessageSyntax > > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > > pkcs-9(9) smime(16) modules(0) cms(1) } > > > > I needed to change this to: > > > > -- RFC 3852: Cryptographic Message Syntax (CMS) > > ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier > > FROM CryptographicMessageSyntax2004 > > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > > pkcs-9(9) smime(16) modules(0) cms-2004(24) } > > > > Why? It did not have anything to do with ContentType, > > IssuerAndSerialNumber, or SubjectKeyIdentifier. It had to do with > > something else in the RFC 2630 module. > >Do you mean the usage of 'Name' which is used in IssuerAndSerialNumber? >You don't change the definition of a module. You make a new one. >I don't see the point. This module also had in import from RFC 3280, and the RFC 2634 imported from RFC 2630, which had an import from RFC 2459, there was some conflict. I do not recall more detail than that. By shifting the import to RFC 3852, the subordinate import shifted to RFC 3280, resolving the conflict. Russ From owner-ietf-pkix@mail.imc.org Fri Apr 15 04:09:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04594 for ; Fri, 15 Apr 2005 04:09:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F7CZa8057733; Fri, 15 Apr 2005 00:12:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F7CZkm057732; Fri, 15 Apr 2005 00:12:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F7CVSf057651 for ; Fri, 15 Apr 2005 00:12:32 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA31896; Fri, 15 Apr 2005 09:26:37 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005041509120448:1885 ; Fri, 15 Apr 2005 09:12:04 +0200 Message-ID: <425F6943.3050204@bull.net> Date: Fri, 15 Apr 2005 09:12:03 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: Stefan Santesson , pkix Subject: Re: Comments on References: <425A2E60.2080008@bull.net> <6.2.0.14.2.20050414114650.0662cd50@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/04/2005 09:12:04, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/04/2005 09:12:06, Serialize complete at 15/04/2005 09:12:06 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3F7CYSf057722 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Russ, > Denis: > When a certificate issuer is using Indirect CRLs, the CRLDP identifies > the CRL issuer. To correct the language, "a certificate issuer is not using Indirect CRLs" but "a certificate issuer may nominate a CRL Issuer which issues Indirect CRLs". This sentence also depends upon the content of the CRL DP. > In this situation, the cRLIssuer field in the CRLDP > identifies the signer of the forthcoming CRLs. So, in your Scenario A, > the CRL Issuer is explicitly identified in the CRLDP. However, the CRL > Issuer's certificate is not necessarily available from the information > in the CRLDP. Thus, the CRL AIA allows the certificate user to obtain > it. Not exactly, but "the CRL AIA allows the certificate user to obtain an address that the certificate user can query to obtain information that may or may not be the right one". > In this situation the verification must make sure that the > cRLIssuer in the CRLDP must match the subject/subjectAltName in the > certificate that is fetched via the CRL AIA. This is exactly the kind of information that is currently lacking in the document, with in addition how this assurance can be obtained. > In my view, this scenario validates the need for this document. I am not challening the usefulness (I would not use the term "need") of this document, since I am proposing text changes to the document. Please take a look at my text proposals. Denis > Russ > >> Stefan and Russ, >> >> It took me several hours to write this long e-mail, hence for the delay >> (in addition to the time for shooting a few “big five” with my >> camera). >> >> This e-mail identifies several security issues, which are not >> currently mentionned in the security considerations section. It >> finally proposes a rewritting of the introduction and provides a >> strawman for a new security considerations section (see the proposal >> at the end of this e-mail). >> >> Let us consider two different scenarios where this new extension would >> be considered. >> >> Scenario A: The relying party does not trust any CRL issuer in >> particular and will simply use the CRL Issuer designated by the >> Certificate Issuer by means of the CRL DP extension. >> >> Scenario B: The relying party trusts at least a specific CRL issuer >> and will get the CRLs from that CRL Issuer and then will make sure >> that the information contained in them matches with the designation of >> the Certificate Issuer. >> >> SCENARIO A >> >> In scenario A, the relying party will use the CRL DP from the target >> certificate to get the CRL and then will make sure that the CRL that >> has been retrieved from that location is signed by the right CRL Issuer. >> >> The CRL DP extension is defined as: >> >> DistributionPoint ::= SEQUENCE { >> distributionPoint [0] DistributionPointName OPTIONAL, >> reasons [1] ReasonFlags OPTIONAL, >> cRLIssuer [2] GeneralNames OPTIONAL } >> >> At least the distributionPoint field shall be present. It is supposed >> it contains a general name of type URI, which is a pointer to the >> current CRL for the associated reasons and will be issued by the >> associated cRLIssuer. >> >> The CRL itself shall contain an IDP (Issuing Distribution Point). >> >> The IDP extension is defined as: >> >> issuingDistributionPoint ::= SEQUENCE { >> distributionPoint [0] DistributionPointName OPTIONAL, >> onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, >> onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, >> onlySomeReasons [3] ReasonFlags OPTIONAL, >> indirectCRL [4] BOOLEAN DEFAULT FALSE, >> onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } >> >> A necessary but insufficient condition is that the distributionPoint >> field from the IDP extension shall be equal to the distributionPoint >> field from the CRL DP extension. >> >> This is insufficient since a URL like >> URL=http://corppki/crl/extranet.crl could be used by accident by two >> different CAs, or a CA under the same root key could maliciously use >> that URL or a different and re-route all packets to an address where >> that CRL is made available. >> >> This means that the tupple CRL DP extension from certificates and the >> IDP extension from CRLs even if then match are insufficient to make >> sure that it is the right CRL that has been retrieved. This is >> “normal” until some cryptographic checksums are used to make sure >> that this is the right information. >> >> Any CA, trusted under a root key, could use an IDP extension in a CRL >> matching the IDP extension from another true CRL and unless other >> tests are performed, would fool relying parties. >> >> This is the major reason why the current document in its current form >> is dangerous to be published. It incorporates verification concepts >> which are missing major security issues. The security consideration >> section attempts to tackle the issue but it misses the point. >> >> The major problem is not the definition of this new extension that >> could provide untrusted but “useful” information, but the concepts >> behind path construction. >> >> SCENARIO B >> >> In scenario B, the relying party contacts the location of a trusted >> CRL Issuer and wants to verify that the retrieved CRL is correctly >> signed. >> >> Suppose that the retrieved CRL contains the newly defined extension >> which specifies one or more accessLocation fields that contains >> references to CA certificates superior to the CRL containing this >> extension. >> >> Let us consider that one accessLocation field contains the following >> URL: http://corppki/aia/certificates.crt >> >> The relying party will access this URL to retrieve some CA certificates. >> Nothing at this point would prevent a network attack so that access to >> this URL is re-routed to another location. The question is how the >> relying party can figure out and what kind of tests it should make. >> The draft is silent about this. >> >> It does not help the end-user to define new extensions if at the same >> time there are no explanations or guidance to tell how are they should >> be used in order to build a secure system. >> >> Let us suppose that the information retrieved is just “useful” >> certificates at this time (i.e. untrusted). >> >> In order to build a path, a relying party needs to make sure of the >> name of the CRL Issuer, which means not simply knowing the DN of the >> CRL issuer but also all the other DNs from the upper CAs up to a root >> key. This kind of assumption or explanations is currently missing in >> the draft. >> >> Scenario B would be correctly supported if the text would mention two >> points: >> >> 1) the location of the “trusted CRL Issuer” must be locally known, >> 2) the name of the “trusted CRL Issuer” must be locally known, >> which means not simply knowing the DN of the CRL issuer, >> but also all the other DNs from the upper CAs up to a root key. >> >> Using the “useful” certificates that would be retrieved using that >> new extension, the relying party would then build a certification path >> to validate the retrieved CRL. Additional details, described nowhere, >> should be given so that it can be sure that it is a CRL Issuer and not >> a CA, etc ... >> >> Then the relying party knows that he got a correct indirect CRL and >> has to make sure that the name of the CA is present. Additional >> details would be needed to explain name matching taking into account >> that two CAs could be given the same DN by two different CAs. >> >> >> CONCLUSION: >> >> I see two ways to progress: >> >> a) “avoid” the problem *now* and leave it for later. This means >> saying that this extension may provide useful information that >> still needs to be verified to be trusted. The security >> considerations section would tackle the issue but not provide >> the full answer. >> >> b) address the issue and say how to handle CRLs when they are not >> signed >> by the CA. >> >> In case of a), that is the easiest *temporary* solution, I would >> propose to rewrite the introduction in the following way : >> >> RFC 3280 [PKIX1] specifies the validation of certification paths. >> One aspect involves the determination that a certificate has not been >> revoked, and one revocation checking mechanism is the Certificate >> Revocation List (CRL). Checking a CRL when the CRL is signed by the >> key of the Issuing CA is straightforward, but not necessarily >> otherwise. >> >> There are several legitimate scenarios where the certificate of the >> CRL issuer is not present, or easily discovered. >> >> Standardized methods of finding the certificate of the CRL issuer are >> currently available either though an accessible directory location or >> through use of the Subject Information Access extension in >> intermediary CA certificates. >> >> Directory lookup requires presence and access to a directory. The >> Subject Information Access extension supports building certification >> paths top-down (in the direction from the trust anchor to the CRL >> issuer), which will succeed if certificates include an appropriate >> Subject Information Access extension. Additional methods allowing >> the building of certification paths bottom-up to validate CRLs >> may be useful as well. This is the topic of this document. >> >> RFC 3280 [PKIX1] has provided for bottom-up discovery of >> certification paths through the Authority Information Access >> extension, where the id-ad-caIssuers access method may specify one or >> more accessLocation fields that contain references to CA certificates >> superior to the certificate containing this extension. >> >> This document permits use of the Authority Information Access >> extension in CRLs, enabling a CRL checking application to use the >> same access method (id-ad-caIssuers) to locate the certificate of >> the CRL issuer and complete the certification path building to an >> appropriate trust anchor. >> >> This extension may be used in the case when indirect CRLs are used, >> when the certification Authority (CA) that issued the CRL certificate >> changes its certificate signing key, or when the CA employs separate >> keys for certificate signing and CRL signing. >> >> A typo would need to be corrected in section 2: change >> AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax. >> >> Section 3 about Security Considerations would need to be changed. >> Hereafter is a proposal: >> >> 3 Security Considerations >> >> Implementers should take into account the possible existence of >> multiple unrelated CAs and CRL issuers with the same DN, as well >> as the possibility for some trusted CAs (i.e. trusted to issue >> their own certificates and associated revocation status information >> but not trusted not handle revocation information from other CAs) >> to purposely use URLs or CRL DPs identical to some CRL DPs from >> other CAs and at the same time mounting a re-routing attack. >> >> This means that finding a CA certificate at the location indicated >> by this new extension is insufficient to make sure that it is the >> right one, and by consequence that the CRL where this extension >> has been found is also the right one. >> >> When the CRL contains the indirectCRL boolean set to TRUE, then the >> relying party should locally know the URL of the CRL issuer(s) that >> it directly trusts and also the associated name of the trusted CRL >> issuer, which means not simply knowing the DN of the CRL issuer, >> but also all the other DNs of the upper CAs up to a root key (since >> two CAs might be given the same DN by two different CAs). >> >> When the CRL is a direct CRL, then relying parties shall make sure >> that the certificate of the CRL issuer has been issued by the same >> CA that has issued the target certificate. >> >> Implementers should always take the steps of validating the >> retrieved data to ensure that the data is properly formed. >> >> Of course, much more could be said and an informative annex would be >> quite useful. >> >> In case of b), more work would need to be done. >> >> Denis >> > From owner-ietf-pkix@mail.imc.org Fri Apr 15 05:00:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08856 for ; Fri, 15 Apr 2005 05:00:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8An5C078823; Fri, 15 Apr 2005 01:10:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F8AnEv078822; Fri, 15 Apr 2005 01:10:49 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8AlkP078774 for ; Fri, 15 Apr 2005 01:10:48 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3F8Ajn07800; Fri, 15 Apr 2005 10:10:45 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 10:10:45 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3F8Aja03429; Fri, 15 Apr 2005 10:10:45 +0200 (MEST) Date: Fri, 15 Apr 2005 10:10:45 +0200 (MEST) From: Peter Sylvester Message-Id: <200504150810.j3F8Aja03429@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, housley@vigilsec.com Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension Cc: ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > >take a cert with all bit on. This is equivalent to having no keyUsage at all > >as far as I remember. in this case the keyCertSign bit and the cRLSign are > >set, > >and the above 'MUST NOT' prohibits use of this cert. is this what you intend? > >I don't think so. > > > >Isn't the right wording: no known EAP usage requires keyCertSign or cRLSign? > > How about: ... however, EAP methods MUST NOT require the keyCertSign bit or > the cRLSign to be set in end entity certificates. - the initial text had no keyUsage restriction. - the current has a restriction that technically doesn't make any sense and is incompatible with the standard. - Above you propose something that is a restriction for EAP methods which was not in 3770. Can you justify this change, please. Peter PS: Would it be possible to instruct your mail user agent not to send me two copies just because I am twice in the To list, or else. Thanks From owner-ietf-pkix@mail.imc.org Fri Apr 15 05:01:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09210 for ; Fri, 15 Apr 2005 05:01:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8PKp1083822; Fri, 15 Apr 2005 01:25:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F8PKqo083821; Fri, 15 Apr 2005 01:25:20 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8PIMf083805 for ; Fri, 15 Apr 2005 01:25:18 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3F8PHn07998; Fri, 15 Apr 2005 10:25:17 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 10:25:17 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3F8PGB03451; Fri, 15 Apr 2005 10:25:16 +0200 (MEST) Date: Fri, 15 Apr 2005 10:25:16 +0200 (MEST) From: Peter Sylvester Message-Id: <200504150825.j3F8PGB03451@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, housley@vigilsec.com Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import Cc: ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > >Now you say that it is not a matter of taste. > > No. I shared the reason that I prefer to include the OIDs rather than > IMPORTing them. They both work. I say that what you give as a reason is not a matter of taste. And your reasoning tries to just justify technical hack. What you are technically doing is to define a new element in the pkix kp arc in this module. I have not see that you have obtained authorisation to do this from the owner of the pkix kp arc. > >By the way, further down the example is an import of something that is NOT > >SIMPLE. > > > >Using this technique requires to keep track of all copies, and IF a > >copied definitions changes slightly in the main definition module > >THEN you get inconsistencies. > > True. Neither of the alternatives is perfect. They have different kinds > of pain. There is nothing wrong in IMPORT in this particular case. IMO it is PERFECTLY in line with all (what I know) of ASN1 etc. We are not etalking about pains created by difficulties of correct organisation of ASN.1 modules or using current and non-obsolete syntax versions. > > > I have had to make edits to old ASN.1 modules to avoid errors that are > > > introduced when one modules imports stuff from another that imports stuff > > > from another that imports stuff from another. The changes are almost > > > always in parts that are not needed for the part that is needed. I'll > > give > > > a recent example. > > > > > > RFC 2634 imports from CMS. The ASN.1 module says: > > > > > > -- RFC 2630: Cryptographic Message Syntax (CMS) > > > ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier > > > FROM CryptographicMessageSyntax > > > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > > > pkcs-9(9) smime(16) modules(0) cms(1) } > > > > > > I needed to change this to: > > > > > > -- RFC 3852: Cryptographic Message Syntax (CMS) > > > ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier > > > FROM CryptographicMessageSyntax2004 > > > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > > > pkcs-9(9) smime(16) modules(0) cms-2004(24) } > > > > > > Why? It did not have anything to do with ContentType, > > > IssuerAndSerialNumber, or SubjectKeyIdentifier. It had to do with > > > something else in the RFC 2630 module. > > > >Do you mean the usage of 'Name' which is used in IssuerAndSerialNumber? > >You don't change the definition of a module. You make a new one. > >I don't see the point. > > This module also had in import from RFC 3280, and the RFC 2634 imported > from RFC 2630, which had an import from RFC 2459, there was some > conflict. I do not recall more detail than that. By shifting the import > to RFC 3852, the subordinate import shifted to RFC 3280, resolving the > conflict. Sorry, arguments that are not explained have no meaning to me. Anyway, if there was a problem and a REAL conflict, i.e. a different definition, then duplication of the elements using same name would have created more problems because you don't keep track. if in your case the definitions do not change, I don't see why you need to import then from a different place. From owner-ietf-pkix@mail.imc.org Fri Apr 15 05:19:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10650 for ; Fri, 15 Apr 2005 05:19:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8bZss087994; Fri, 15 Apr 2005 01:37:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F8bZNA087993; Fri, 15 Apr 2005 01:37:35 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8bXvT087975 for ; Fri, 15 Apr 2005 01:37:34 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3F8bWn08105 for ; Fri, 15 Apr 2005 10:37:32 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 10:37:32 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3F8bWD03468 for ietf-pkix@imc.org; Fri, 15 Apr 2005 10:37:32 +0200 (MEST) Date: Fri, 15 Apr 2005 10:37:32 +0200 (MEST) From: Peter Sylvester Message-Id: <200504150837.j3F8bWD03468@chandon.edelweb.fr> To: ietf-pkix@imc.org Subject: Re: draft-ietf-pkix-rfc3770bis-01: Section 2 X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I realized that the following did not get to the list. > >Also, 3280 is under revision, if it happens that the corresponding text > >gets clarified in some way, one would have something considered > >unprecise elsewhere. > > I do not understand the harm that you believe is being caused. The same type as with the text in 3370 can be definetely avoided by not copying text which may be subject to clarifications. If clarifications (not changes!!) are made in rfc3280bis in order to address common misunderstandings or unprecise wording in the majority of non-native english speaking world, then these updates don't get into the other text. From owner-ietf-pkix@mail.imc.org Fri Apr 15 07:51:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21799 for ; Fri, 15 Apr 2005 07:51:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FAs7bk031946; Fri, 15 Apr 2005 03:54:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FAs7Lh031945; Fri, 15 Apr 2005 03:54:07 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3FAs3f7031895 for ; Fri, 15 Apr 2005 03:54:04 -0700 (PDT) (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.211); Fri, 15 Apr 2005 11:54:27 +0100 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: Comments on Date: Fri, 15 Apr 2005 11:53:55 +0100 Message-ID: Thread-Topic: Comments on Thread-Index: AcVAyX3Ui4Yj/r7gTGS3E8JSSTn8EwA3bvgQ From: "Stefan Santesson" To: "Denis Pinkas" Cc: "Russ Housley" , "pkix" X-OriginalArrivalTime: 15 Apr 2005 10:54:27.0126 (UTC) FILETIME=[7E206D60:01C541A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3FAs4f7031926 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, I will come back and comment on your text proposals, but before that, a few questions/comments: > > You point out some well known issues related to the lack of absolute > > cryptographic binding between CRL and certificates where the certificate > > and CRL is not signed by the same key. > > Not really. It is indeed possible to have an absolute cryptographic > binding > between CRL and certificates where the certificate and CRL is not signed > by > the same key, but the key point is that proposed extension is *not* the > means to provide such a binding (and you agree with this further down in > this e-mail). We agree that this extension does not add to the concept of cryptographic binding. But how do you mean it can be done? > > This draft only introduces a new way to locate certificates > > that can be helpful in building this path. > > At least one sentence of which we both agree ! > It should be copied and pasted in the abstract. Good, then I suggest that we leave unrelated topics out of this draft and focus on the issues that are related to this limited scope. Stefan Santesson Program Manager - Standards Liaison Windows Security > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 14 april 2005 10:10 > To: Stefan Santesson > Cc: Russ Housley; pkix > Subject: Re: Comments on > > Stefan, > > > Denis, > > > Thanks for spending considerable time to comment on this draft. > > > The typo is noted and will be fixed. > > Thank you so much, for accepting to correct the typo. :-| > > > Some generic comments before we go into the specific text proposals: > > > You point out some well known issues related to the lack of absolute > > cryptographic binding between CRL and certificates where the certificate > > and CRL is not signed by the same key. > > Not really. It is indeed possible to have an absolute cryptographic > binding > between CRL and certificates where the certificate and CRL is not signed > by > the same key, but the key point is that proposed extension is *not* the > means to provide such a binding (and you agree with this further down in > this e-mail). > > The proposed extension is simply a means to find a possible certificate > candidates, but not a means to make sure that the candidate is acceptable. > > > A certificate is always authoritative to identify the correct CRL for > > its validation. > > While this is true in general, this is not always true. When indirect CRLs > are used, a directly trusted CRL Issuer may be used. For other cases, your > statement is correct. > > > But since the certificate is signed before the latest > > CRL that validates it, the certificate can't cryptographically bind > > (e.g. hash) the CRL but needs to identify it by verifiable attributes > > such as issuer name and storage location. > > As you say, only issuer name or location may be used. Location cannot be > used as this has been demonstrated in the previous e-mail, since a network > attack could be performed. So only the issuer name can be used. Let us > look, > how: > > The CRL DP extension is defined as: > > DistributionPoint ::= SEQUENCE { > distributionPoint [0] DistributionPointName OPTIONAL, > reasons [1] ReasonFlags OPTIONAL, > cRLIssuer [2] GeneralNames OPTIONAL } > > Secure binding may be obtained using cRLIssuer where > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > with > > GeneralName ::= CHOICE { > otherName [0] AnotherName, > rfc822Name [1] IA5String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID [8] OBJECT IDENTIFIER } > > where Name ::= CHOICE { > RDNSequence } > > RFC 3280 states: > > " If the certificate issuer is not the CRL Issuer, then the cRLIssuer > field MUST be present and contain the Name of the CRL issuer". > > A name is uniquely assigned to an entity, only if the name of the CA which > has allocated it is known. Recursively, the DN of that CA is uniquely > assigned to an entity, only if the DN of the CA which has allocated that > DN > it is known. This process ends up until the trust anchor that has issued > the > first CA certificate of the certification path is known. > > > This issue is however NOT introduced by this draft. It is simply a > > generic issue with RFC 3280/X.509, especially for indirect CRLs > > > In this context I really can't see the difference between scenario A and > > scenario B. It seems to me that the same validation principles apply to > > both scenarios. > > Not exactly. From what is said above, it can be said that cRLIssuer DN has > been uniquely assigned to that entity, if it is known that this DN has > been > issued by the CA that has issued the target certificate. This is scenario > A > which means that the trust conditions from the relying party are simple > and > well known. > > The problem is that with scenario B, no document provides the trust > conditions to be used by the relying party and that there can be many > different trust conditions, some of them may be secure, while some of them > may be insecure depending upon the context. > > This is why it is important to make a difference between scenario A and B. > > > Section 6.3 of RFC 3280 is dealing with CRL validation and the > > requirement to validate the CRL through a valid certificate path. > > ... but that section is lacking of further details that would allow two > different imlplementations to end up with the same result. > > > This draft only introduces a new way to point to locate certificates > > that can be helpful in building this path. > > At least one sentence of which we both agree ! > It should be copied and pasted in the abstract. > > > It seems to me from that > > perspective that specific requirements on CRL path building are outside > > the scope of this draft. > > Since scenario B has so many possible options, it is not possible to cover > all of them and the intent is not to describe and prescribe all of them. > However, scenarion A is much simpler and may be described. > > I have many problems with the current introduction. I am restating my > previous proposal for a revised introduction along the lines that "this > draft only introduces a new way to point to locate certificates that can > be > helpful in building this path". If you have problems with that text, > please > propose revisions to it. If you can live with it, then we are solved with > the introduction. > > > RFC 3280 [PKIX1] specifies the validation of certification paths. > One aspect involves the determination that a certificate has not been > revoked, and one revocation checking mechanism is the Certificate > Revocation List (CRL). Checking a CRL when the CRL is signed by the > key of the Issuing CA is straightforward, but not necessarily > otherwise. > > There are several legitimate scenarios where the certificate of the > CRL issuer is not present, or easily discovered. > > Standardized methods of finding the certificate of the CRL issuer are > currently available either though an accessible directory location or > through use of the Subject Information Access extension in > intermediary CA certificates. > > Directory lookup requires presence and access to a directory. The > Subject Information Access extension supports building certification > paths top-down (in the direction from the trust anchor to the CRL > issuer), which will succeed if certificates include an appropriate > Subject Information Access extension. Additional methods allowing > the building of certification paths bottom-up to validate CRLs > may be useful as well. This is the topic of this document. > > RFC 3280 [PKIX1] has provided for bottom-up discovery of > certification paths through the Authority Information Access > extension, where the id-ad-caIssuers access method may specify one or > more accessLocation fields that contain references to CA certificates > superior to the certificate containing this extension. > > This document permits use of the Authority Information Access > extension in CRLs, enabling a CRL checking application to use the > same access method (id-ad-caIssuers) to locate the certificate of > the CRL issuer and complete the certification path building to an > appropriate trust anchor. > > This extension may be used in the case when indirect CRLs are used, > when the certification Authority (CA) that issued the CRL certificate > changes its certificate signing key, or when the CA employs separate > keys for certificate signing and CRL signing. > > > Now the security considerations section still contains incorrect text. > I have revised my previous proposal. If you have problems with that text, > please propose revisions to it. If you can live with it, then we are > solved with section 3. > > 3 Security Considerations > > Implementers should take into account the possible existence of > multiple unrelated CAs and CRL issuers with the same DN, as well > as the possibility for some trusted CAs (i.e. trusted to issue > their own certificates and associated revocation status information > but not trusted not handle revocation information from other CAs) > to purposely use URLs or CRL DPs identical to some CRL DPs from > other CAs and at the same time mounting a re-routing attack. > > This means that finding a CA certificate at the location indicated > by this new extension is insufficient to make sure that it is the > right one, and by consequence that the CRL where this extension > has been found is also the right one. > > When the CRL is a direct CRL, relying parties shall make sure > that the certificate of the CRL issuer has been issued by the same > CA that has issued the target certificate. > > When the CRL contains the indirectCRL boolean set to TRUE, > relying parties should locally know the URL of the CRL issuer(s) > that they directly trust and use local trust conditions to make > sure that the CRL that has been retrieved has indeed be issued > by a directly trusted CRL Issuer. In particular, care should be > taken > in case two CAs would be using the same DN for two different CAs. > > Implementers should always take the steps of validating the > retrieved data to ensure that the data is properly formed. > > > Indeed, more could be said about indirect CRLs, so if you want to add some > more text, please do it. > > Denis > > >>Stefan Santesson > >>Program Manager - Standards Liaison > >>Windows Security > > > > > > > >>-----Original Message----- > >>From: owner-ietf-pkix@mail.imc.org > > > > [mailto:owner-ietf-pkix@mail.imc.org] > > > >>On Behalf Of Denis Pinkas > >>Sent: den 11 april 2005 00:59 > >>To: Stefan Santesson; Russ Housley > >>Cc: pkix > >>Subject: Comments on > >> > >> > >>Stefan and Russ, > >> > >>It took me several hours to write this long e-mail, hence for the > > > > delay > > > >>(in addition to the time for shooting a few "big five" with my > > > > camera). > > > >>This e-mail identifies several security issues, which are not > > > > currently > > > >>mentionned in the security considerations section. It finally proposes > > > > a > > > >>rewritting of the introduction and provides a strawman for a new > > > > security > > > >>considerations section (see the proposal at the end of this e-mail). > >> > >>Let us consider two different scenarios where this new extension would > > > > be > > > >>considered. > >> > >>Scenario A: The relying party does not trust any CRL issuer in > > > > particular > > > >>and will simply use the CRL Issuer designated by the Certificate > > > > Issuer by > > > >>means of the CRL DP extension. > >> > >>Scenario B: The relying party trusts at least a specific CRL issuer > > > > and > > > >>will > >>get the CRLs from that CRL Issuer and then will make sure that the > >>information contained in them matches with the designation of the > >>Certificate Issuer. > >> > >>SCENARIO A > >> > >>In scenario A, the relying party will use the CRL DP from the target > >>certificate to get the CRL and then will make sure that the CRL that > > > > has > > > >>been retrieved from that location is signed by the right CRL Issuer. > >> > >>The CRL DP extension is defined as: > >> > >> DistributionPoint ::= SEQUENCE { > >> distributionPoint [0] DistributionPointName > > > > OPTIONAL, > > > >> reasons [1] ReasonFlags OPTIONAL, > >> cRLIssuer [2] GeneralNames OPTIONAL } > >> > >>At least the distributionPoint field shall be present. It is supposed > > > > it > > > >>contains a general name of type URI, which is a pointer to the current > > > > CRL > > > >>for the associated reasons and will be issued by the associated > > > > cRLIssuer. > > > >>The CRL itself shall contain an IDP (Issuing Distribution Point). > >> > >>The IDP extension is defined as: > >> > >> issuingDistributionPoint ::= SEQUENCE { > >> distributionPoint [0] DistributionPointName > > > > OPTIONAL, > > > >> onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, > >> onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, > >> onlySomeReasons [3] ReasonFlags OPTIONAL, > >> indirectCRL [4] BOOLEAN DEFAULT FALSE, > >> onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } > >> > >>A necessary but insufficient condition is that the distributionPoint > > > > field > > > >>from the IDP extension shall be equal to the distributionPoint field > > > > from > > > >>the CRL DP extension. > >> > >>This is insufficient since a URL like > > > > URL=http://corppki/crl/extranet.crl > > > >>could be used by accident by two different CAs, or a CA under the same > >>root > >>key could maliciously use that URL or a different and re-route all > > > > packets > > > >>to an address where that CRL is made available. > >> > >>This means that the tupple CRL DP extension from certificates and the > > > > IDP > > > >>extension from CRLs even if then match are insufficient to make sure > > > > that > > > >>it > >>is the right CRL that has been retrieved. This is "normal" until some > >>cryptographic checksums are used to make sure that this is the right > >>information. > >> > >>Any CA, trusted under a root key, could use an IDP extension in a CRL > >>matching the IDP extension from another true CRL and unless other > > > > tests > > > >>are > >>performed, would fool relying parties. > >> > >>This is the major reason why the current document in its current form > > > > is > > > >>dangerous to be published. It incorporates verification concepts which > > > > are > > > >>missing major security issues. The security consideration section > > > > attempts > > > >>to tackle the issue but it misses the point. > >> > >>The major problem is not the definition of this new extension that > > > > could > > > >>provide untrusted but "useful" information, but the concepts behind > > > > path > > > >>construction. > >> > >>SCENARIO B > >> > >>In scenario B, the relying party contacts the location of a trusted > > > > CRL > > > >>Issuer and wants to verify that the retrieved CRL is correctly signed. > >> > >>Suppose that the retrieved CRL contains the newly defined extension > > > > which > > > >>specifies one or more accessLocation fields that contains references > > > > to CA > > > >>certificates superior to the CRL containing this extension. > >> > >>Let us consider that one accessLocation field contains the following > > > > URL: > > > >>http://corppki/aia/certificates.crt > >> > >>The relying party will access this URL to retrieve some CA > > > > certificates. > > > >>Nothing at this point would prevent a network attack so that access to > >>this > >>URL is re-routed to another location. The question is how the relying > >>party > >>can figure out and what kind of tests it should make. The draft is > > > > silent > > > >>about this. > >> > >>It does not help the end-user to define new extensions if at the same > > > > time > > > >>there are no explanations or guidance to tell how are they should be > > > > used > > > >>in > >>order to build a secure system. > >> > >>Let us suppose that the information retrieved is just "useful" > >>certificates > >>at this time (i.e. untrusted). > >> > >>In order to build a path, a relying party needs to make sure of the > > > > name > > > >>of > >>the CRL Issuer, which means not simply knowing the DN of the CRL > > > > issuer > > > >>but > >>also all the other DNs from the upper CAs up to a root key. This kind > > > > of > > > >>assumption or explanations is currently missing in the draft. > >> > >>Scenario B would be correctly supported if the text would mention two > >>points: > >> > >> 1) the location of the "trusted CRL Issuer" must be locally known, > >> 2) the name of the "trusted CRL Issuer" must be locally known, > >> which means not simply knowing the DN of the CRL issuer, > >> but also all the other DNs from the upper CAs up to a root key. > >> > >>Using the "useful" certificates that would be retrieved using that new > >>extension, the relying party would then build a certification path to > >>validate the retrieved CRL. Additional details, described nowhere, > > > > should > > > >>be > >>given so that it can be sure that it is a CRL Issuer and not a CA, etc > > > > ... > > > >>Then the relying party knows that he got a correct indirect CRL and > > > > has to > > > >>make sure that the name of the CA is present. Additional details would > > > > be > > > >>needed to explain name matching taking into account that two CAs could > > > > be > > > >>given the same DN by two different CAs. > >> > >> > >>CONCLUSION: > >> > >>I see two ways to progress: > >> > >> a) "avoid" the problem *now* and leave it for later. This means > >> saying that this extension may provide useful information that > >> still needs to be verified to be trusted. The security > >> considerations section would tackle the issue but not provide > >> the full answer. > >> > >> b) address the issue and say how to handle CRLs when they are not > >>signed > >> by the CA. > >> > >>In case of a), that is the easiest *temporary* solution, I would > > > > propose > > > >>to > >>rewrite the introduction in the following way : > >> > >> RFC 3280 [PKIX1] specifies the validation of certification paths. > >> One aspect involves the determination that a certificate has not > > > > been > > > >> revoked, and one revocation checking mechanism is the Certificate > >> Revocation List (CRL). Checking a CRL when the CRL is signed by > > > > the > > > >> key of the Issuing CA is straightforward, but not necessarily > >> otherwise. > >> > >> There are several legitimate scenarios where the certificate of > > > > the > > > >> CRL issuer is not present, or easily discovered. > >> > >> Standardized methods of finding the certificate of the CRL issuer > > > > are > > > >> currently available either though an accessible directory location > > > > or > > > >> through use of the Subject Information Access extension in > >> intermediary CA certificates. > >> > >> Directory lookup requires presence and access to a directory. The > >> Subject Information Access extension supports building > > > > certification > > > >> paths top-down (in the direction from the trust anchor to the CRL > >> issuer), which will succeed if certificates include an appropriate > >> Subject Information Access extension. Additional methods allowing > >> the building of certification paths bottom-up to validate CRLs > >> may be useful as well. This is the topic of this document. > >> > >> RFC 3280 [PKIX1] has provided for bottom-up discovery of > >> certification paths through the Authority Information Access > >> extension, where the id-ad-caIssuers access method may specify one > > > > or > > > >> more accessLocation fields that contain references to CA > > > > certificates > > > >> superior to the certificate containing this extension. > >> > >> This document permits use of the Authority Information Access > >> extension in CRLs, enabling a CRL checking application to use the > >> same access method (id-ad-caIssuers) to locate the certificate of > >> the CRL issuer and complete the certification path building to an > >> appropriate trust anchor. > >> > >> This extension may be used in the case when indirect CRLs are > > > > used, > > > >> when the certification Authority (CA) that issued the CRL > > > > certificate > > > >> changes its certificate signing key, or when the CA employs > > > > separate > > > >> keys for certificate signing and CRL signing. > >> > >>A typo would need to be corrected in section 2: change > >>AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax. > >> > >>Section 3 about Security Considerations would need to be changed. > >>Hereafter is a proposal: > >> > >>3 Security Considerations > >> > >> Implementers should take into account the possible existence of > >> multiple unrelated CAs and CRL issuers with the same DN, as well > >> as the possibility for some trusted CAs (i.e. trusted to issue > >> their own certificates and associated revocation status > > > > information > > > >> but not trusted not handle revocation information from other > > > > CAs) > > > >> to purposely use URLs or CRL DPs identical to some CRL DPs from > >> other CAs and at the same time mounting a re-routing attack. > >> > >> This means that finding a CA certificate at the location > > > > indicated > > > >> by this new extension is insufficient to make sure that it is > > > > the > > > >> right one, and by consequence that the CRL where this extension > >> has been found is also the right one. > >> > >> When the CRL contains the indirectCRL boolean set to TRUE, then > > > > the > > > >> relying party should locally know the URL of the CRL issuer(s) > > > > that > > > >> it directly trusts and also the associated name of the trusted > > > > CRL > > > >> issuer, which means not simply knowing the DN of the CRL issuer, > >> but also all the other DNs of the upper CAs up to a root key > > > > (since > > > >> two CAs might be given the same DN by two different CAs). > >> > >> When the CRL is a direct CRL, then relying parties shall make > > > > sure > > > >> that the certificate of the CRL issuer has been issued by the > > > > same > > > >> CA that has issued the target certificate. > >> > >> Implementers should always take the steps of validating the > >> retrieved data to ensure that the data is properly formed. > >> > >>Of course, much more could be said and an informative annex would be > > > > quite > > > >>useful. > >> > >>In case of b), more work would need to be done. > >> > >>Denis > >> > > > > > > > From owner-ietf-pkix@mail.imc.org Fri Apr 15 11:07:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07886 for ; Fri, 15 Apr 2005 11:07:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FEF28D077624; Fri, 15 Apr 2005 07:15:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FEF21D077623; Fri, 15 Apr 2005 07:15:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FEF2dA077603 for ; Fri, 15 Apr 2005 07:15:02 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200504151359.j3FDxWE3004848@stingray.missi.ncsc.mil> Date: Fri, 15 Apr 2005 10:14:47 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import References: <200504150825.j3F8PGB03451@chandon.edelweb.fr> In-Reply-To: <200504150825.j3F8PGB03451@chandon.edelweb.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 14:14:55.0768 (UTC) FILETIME=[7FC18980:01C541C5] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter Sylvester wrote: >We are not etalking about pains created by difficulties of correct >organisation of ASN.1 modules or using current and non-obsolete syntax >versions. > > This gets to the real problem. If the entire pkix OID registry (http://www.imc.org/ietf-pkix/pkix-oid.asn) were maintained as an ASN.1 module and always IMPORTed, this would eliminate problems caused by importing modules containing both structures and OIDs when only the OIDs are needed. Given that there is not yet a "pkix-useful-definitions" module, Russ' strategy of local definitions is a reasonable workaround: 1) an OID, once assigned, can never change so there is no danger of an initially-correct copy getting out of sync with the original. (An OID can be deprecated, but its meaning cannot be modified.) 2) the name assigned to an OID has only local scope, and many names can be assigned to the same OID without causing problems (other than confusing readers). One module can locally define "id-bogus-aca" and use that name within the module and still interoperate successfully with a different module that IMPORTs "id-aca" from PKIXAttributeCertificate. Recommendation: create a module containing only PKIX constant definitions (OIDs, bounds, etc). Start importing it into other modules as they are revised for other reasons. From owner-ietf-pkix@mail.imc.org Fri Apr 15 12:03:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16723 for ; Fri, 15 Apr 2005 12:03:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FFINJP081842; Fri, 15 Apr 2005 08:18:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FFINoK081841; Fri, 15 Apr 2005 08:18:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FFIMhb081834 for ; Fri, 15 Apr 2005 08:18:22 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 16797 invoked by uid 0); 15 Apr 2005 14:38:56 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.14.33) by woodstock.binhost.com with SMTP; 15 Apr 2005 14:38:56 -0000 Message-Id: <6.2.0.14.2.20050415103508.08d3bb50@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 15 Apr 2005 10:38:24 -0400 To: ietf-pkix@imc.org From: Russ Housley Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension In-Reply-To: <200504150810.j3F8Aja03429@chandon.edelweb.fr> References: <200504150810.j3F8Aja03429@chandon.edelweb.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: List-ID: List-Unsubscribe: Peter: You are the one that complained that there was not discussion of the key usage extension. I am happy to delete the whole paragraph ... you are the one who asked for the topic to be covered. How about this: If a certificate contains a key usage extension, the KeyUsage bits that are needed depends on the EAP method that is employed. Russ At 04:10 AM 4/15/2005, Peter Sylvester wrote: > > > > > >take a cert with all bit on. This is equivalent to having no keyUsage > at all > > >as far as I remember. in this case the keyCertSign bit and the cRLSign > are > > >set, > > >and the above 'MUST NOT' prohibits use of this cert. is this what you > intend? > > >I don't think so. > > > > > >Isn't the right wording: no known EAP usage requires keyCertSign or > cRLSign? > > > > How about: ... however, EAP methods MUST NOT require the keyCertSign bit or > > the cRLSign to be set in end entity certificates. > > >- the initial text had no keyUsage restriction. > >- the current has a restriction that technically doesn't make any > sense and is incompatible with the standard. > >- Above you propose something that is a restriction for EAP methods > which was not in 3770. Can you justify this change, please. > > >Peter >PS: Would it be possible to instruct your mail user agent not to send >me two copies just because I am twice in the To list, or else. Thanks From owner-ietf-pkix@mail.imc.org Fri Apr 15 12:32:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19361 for ; Fri, 15 Apr 2005 12:32:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FFkpuj084050; Fri, 15 Apr 2005 08:46:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FFkp2r084049; Fri, 15 Apr 2005 08:46:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FFko7w084043 for ; Fri, 15 Apr 2005 08:46:50 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 25367 invoked by uid 0); 15 Apr 2005 15:06:13 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.4.116) by woodstock.binhost.com with SMTP; 15 Apr 2005 15:06:13 -0000 Message-Id: <6.2.0.14.2.20050415110032.08d6cd20@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 15 Apr 2005 11:03:46 -0400 To: "Dave Engberg" , From: Russ Housley Subject: Re: CoreStreet IPR disclosure In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave:

I am confused by the IPR disclosure.  SCVP includes two major feature sets: DPD and DPV.  A quick skim of the patents indicate that they are related to DPV.  (I am not a lawyer, and I am not trying to play one here.)  If this is correct, then I am not sure what CoreStreet is promising.

Russ


At 03:08 PM 4/11/2005, Dave Engberg wrote:
 
The IETF has posted CoreStreet's formal IPR disclosure regarding implementations of the SCVP protocol and three of CoreStreet's patents.  This includes an offer for reasonable and non-discriminatory licensing if required by the final standard.  We fully support the standardization and adoption of SCVP.  The full disclosure is available here:
 
    http://www.ietf.org/ietf/IPR/corestreet-ipr-draft-ietf-pkix-scvp-18.txt
 
Unlike some other PKI vendors, CoreStreet has never served a lawsuit (patent or non) to any other party.  Our company's success stems from our innovative implementations of open standards, which attempt to address the security and scalability problems inherent in large PKIs.  We believe our SCVP products will be similarly competitive.
 
Thanks,
Dave Engberg
Chief Technical Officer
CoreStreet, Ltd.
 
From owner-ietf-pkix@mail.imc.org Fri Apr 15 13:04:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21611 for ; Fri, 15 Apr 2005 13:04:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGLKQF086689; Fri, 15 Apr 2005 09:21:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FGLKPF086688; Fri, 15 Apr 2005 09:21:20 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGLIfD086681 for ; Fri, 15 Apr 2005 09:21:19 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3FGKnn16212; Fri, 15 Apr 2005 18:20:49 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 18:20:49 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3FGKm004293; Fri, 15 Apr 2005 18:20:48 +0200 (MEST) Date: Fri, 15 Apr 2005 18:20:48 +0200 (MEST) From: Peter Sylvester Message-Id: <200504151620.j3FGKm004293@chandon.edelweb.fr> To: ietf-pkix@imc.org, housley@vigilsec.com Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Peter: > > You are the one that complained that there was not discussion of the key > usage extension. I am happy to delete the whole paragraph ... you are the > one who asked for the topic to be covered. Your name is not Bismarck, and this is not the Emser Depesche. :-) I have 'remarked' that there was no discussion of keyUsage in your text. You have introduced a restriction that was not in 3370. Since both versions of your proposals seem wrong to me I had already proposed to delete the second half of the sentence that talks about keyusages of crlsign or keyCertSign. I also had asked whether it is true that 'Currently no EAP methods require keyCertSign or crlSign'. I have the feeling that this is what you wanted to express. > How about this: > > If a certificate contains a key usage extension, the KeyUsage bits > that are needed depends on the EAP method that is employed. > > Russ This text is what I had proposed to you yesterday in a reponse that didn't went to the list since you did not answered the question above (unless I have missed it). I can live with an with that. Peter From owner-ietf-pkix@mail.imc.org Fri Apr 15 13:04:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21612 for ; Fri, 15 Apr 2005 13:04:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGUZf9087742; Fri, 15 Apr 2005 09:30:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FGUZ9x087741; Fri, 15 Apr 2005 09:30:35 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGUXit087735 for ; Fri, 15 Apr 2005 09:30:34 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3FGUMn16599; Fri, 15 Apr 2005 18:30:22 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 18:30:22 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3FGUMw04316; Fri, 15 Apr 2005 18:30:22 +0200 (MEST) Date: Fri, 15 Apr 2005 18:30:22 +0200 (MEST) From: Peter Sylvester Message-Id: <200504151630.j3FGUMw04316@chandon.edelweb.fr> To: ietf-pkix@imc.org, housley@vigilsec.com Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: in addition to what I just said. It seems that some mail from me got lost somewhere. > > Peter: > > You are the one that complained that there was not discussion of the key > usage extension. I am happy to delete the whole paragraph ... you are the > one who asked for the topic to be covered. > > How about this: > > If a certificate contains a key usage extension, the KeyUsage bits > that are needed depends on the EAP method that is employed. > > Russ > From owner-ietf-pkix@mail.imc.org Fri Apr 15 13:15:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22633 for ; Fri, 15 Apr 2005 13:15:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGf5kQ089929; Fri, 15 Apr 2005 09:41:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FGf4Vv089875; Fri, 15 Apr 2005 09:41:04 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGeqWZ089764 for ; Fri, 15 Apr 2005 09:40:57 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3FGeln16749; Fri, 15 Apr 2005 18:40:48 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 18:40:48 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3FGek004324; Fri, 15 Apr 2005 18:40:46 +0200 (MEST) Date: Fri, 15 Apr 2005 18:40:46 +0200 (MEST) From: Peter Sylvester Message-Id: <200504151640.j3FGek004324@chandon.edelweb.fr> To: ietf-pkix@imc.org, dpkemp@missi.ncsc.mil Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Recommendation: create a module containing only PKIX > constant definitions (OIDs, bounds, etc). Start importing > it into other modules as they are revised for other reasons. I think that is a good idea for an update of 3280. And then this means that we will have an update of 3370bis :-) I think I'll get a beer now. :-) From owner-ietf-pkix@mail.imc.org Fri Apr 15 16:18:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19124 for ; Fri, 15 Apr 2005 16:18:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FJaYVC001364; Fri, 15 Apr 2005 12:36:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FJaYGD001363; Fri, 15 Apr 2005 12:36:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FJaWoO001356 for ; Fri, 15 Apr 2005 12:36:33 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09042; Fri, 15 Apr 2005 15:36:30 -0400 (EDT) Message-Id: <200504151936.PAA09042@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-00.txt Date: Fri, 15 Apr 2005 15:36:30 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-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 Certificate and Certificate Revocation List (CRL) Profile Author(s) : D. Cooper, et al. Filename : draft-ietf-pkix-rfc3280bis-00.txt Pages : 138 Date : 2005-4-15 This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail, and required extensions are defined. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-00.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-rfc3280bis-00.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-rfc3280bis-00.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: <2005-4-15152550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-rfc3280bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-15152550.I-D@ietf.org> --OtherAccess-- --NextPart--