From owner-ietf-pkix Sun Jan 2 21:11:12 2005 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 j035BCv4029020; Sun, 2 Jan 2005 21:11:12 -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 j035BAVV029004; Sun, 2 Jan 2005 21:11:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035B5pY028813; Sun, 2 Jan 2005 21:11:05 -0800 (PST) (envelope-from kseo@bbn.com) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0359wjf003765; Mon, 3 Jan 2005 00:09:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 3 Jan 2005 00:13:09 -0500 To: ietf-enroll@mit.edu, inch@nic.surfnet.nl, ipsec@ietf.org, ipseckey@ietf.org, ipsec-policy@vpnc.org, isms@ietf.org, kitten@lists.ietf.org, ietf-kink@vpnc.org, ietf-krb-wg@anl.gov, ietf-ltans@imc.org, mobike@machshav.com, msec@securemulticast.org, ietf-openpgp@imc.org, pki4ipsec@icsalabs.com, ietf-pkix@imc.org, ietf-sacred@imc.org, ietf-sasl@imc.org, ietf-ssh@netbsd.org, ietf-smime@imc.org, authtime@nist.gov, syslog-sec@employees.org, ietf-tls@lists.certicom.com From: Karen Seo Subject: 2005 Network and Distributed System Security Symposium (NDSS '05) Cc: kseo@bbn.com Content-Type: multipart/alternative; boundary="============_-1107393303==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-1107393303==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" ** My apologies if you receive multiple copies of this message. ** ANNOUNCING THE INTERNET SOCIETY'S 2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05) February 2, 2005 - Pre Conference Workshop February 3-4, 2005 - Symposium Catamaran Resort Hotel, San Diego, California General Chair: Eric Harder, National Security Agency Program co-Chairs: Dan Simon, Microsoft Research Dan Boneh, Stanford University ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/ The 12th annual NDSS Symposium brings together innovative and forward thinking members of the Internet community including leading edge security researchers and implementers, globally recognized security technology experts, and users from both the private and public sectors who design, develop, exploit, and deploy the technologies that define network and distributed system security. NDSS'05 provides a balanced mix of technical papers (with a strong emphasis on implementation) that cover new and practical approaches to security problems that are endemic to network and distributed systems. THIS YEAR'S TOPICS INCLUDE: * Cryptography in Network Security * Denial of Service Attacks, * Peer to Peer Approaches * Internet Defense * Intrusion Detection * Platform Security. FEATURED GUEST SPEAKER: * Amit Yoran, who was responsible for coordinating cyber-security activities for Homeland Security, will speak on "Security Challenges and Opportunities of the Future Enterprise" PRE CONFERENCE WORKSHOP TOPICS INCLUDE: * Security in handling mobility on the internet * Security in wireless LANs * Security for telephony or voice over IP * Trust relations in ad hoc networks * Key management strategies to support mobility * Security in RFID. More information is available at: http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml Parties interested in submitting papers should see the above web page for directions REGISTER EARLY FOR BEST PRICING Registration for NDSS'05 is now open. Student rates are available for both the workshop and symposium. See the web site for more information -- http://www.isoc.org/ndss05/ Registration fees: * November 31, 2004-January 10, 2005 $625. * After January 10, 2005 $695. SPONSORSHIP OPPORTUNITIES AVAILABLE! If your organization would like to help support NDSS and gain visibility through sponsoring, please contact: sponsor-ndss@isoc.org. Information is also available at http://www.isoc.org/ndss05/ Karen Seo NDSS'05 Publicity Chair --============_-1107393303==_ma============ Content-Type: text/html; charset="us-ascii" 2005 Network and Distributed System Security Symposium (ND
  ** My apologies if you receive multiple copies of this message. **

               ANNOUNCING THE INTERNET SOCIETY'S
2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05)

February 2, 2005 - Pre Conference Workshop
February 3-4, 2005 - Symposium
Catamaran Resort Hotel, San Diego, California
General Chair:  Eric Harder, National Security Agency
Program co-Chairs: Dan Simon, Microsoft Research
                   Dan Boneh, Stanford University

ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/

    The 12th annual NDSS Symposium brings together innovative and
    forward thinking members of the Internet community including
    leading edge security researchers and implementers, globally
    recognized security technology experts, and users from both
    the private and public sectors who design, develop, exploit,
    and deploy the technologies that define network and distributed
    system security.

    NDSS'05 provides a balanced mix of technical papers (with a
    strong emphasis on implementation) that cover new and practical
    approaches to security problems that are endemic to network and
    distributed systems. 

THIS YEAR'S TOPICS INCLUDE:
     * Cryptography in Network Security
      * Denial of Service Attacks,
    * Peer to Peer Approaches
       * Internet Defense
      * Intrusion Detection
   * Platform Security.
FEATURED GUEST SPEAKER:
        * Amit Yoran, who was responsible for coordinating cyber-security
          activities for Homeland Security, will speak on "Security
          Challenges and Opportunities of the Future Enterprise"

PRE CONFERENCE WORKSHOP TOPICS INCLUDE:
* Security in handling mobility on the internet
        * Security in wireless LANs
     * Security for telephony or voice over IP
       * Trust relations in ad hoc networks
    * Key management strategies to support mobility
        * Security in RFID.
     More information is available at:
        http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml
     Parties interested in submitting papers should see the above
        web page for directions

REGISTER EARLY FOR BEST PRICING
     Registration for NDSS'05 is now open. Student rates are available
     for both the workshop and symposium. See the web site for more
     information -- http://www.isoc.org/ndss05/  Registration fees:
        *  November 31, 2004-January 10, 2005   $625.
        *  After January 10, 2005               $695.

SPONSORSHIP OPPORTUNITIES AVAILABLE!
     If your organization would like to help support NDSS and gain
     visibility through sponsoring, please contact:
     sponsor-ndss@isoc.org.  Information is also available at   
     http://www.isoc.org/ndss05/


Karen Seo
NDSS'05 Publicity Chair
--============_-1107393303==_ma============-- From owner-ietf-pkix Mon Jan 3 00:59:38 2005 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 j038xcSZ088526; Mon, 3 Jan 2005 00:59:38 -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 j038xcou088525; Mon, 3 Jan 2005 00:59:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from bacchus.pvv.ntnu.no (bacchus.pvv.ntnu.no [129.241.210.178]) by above.proper.com (8.12.11/8.12.9) with SMTP id j038xWCY088384 for ; Mon, 3 Jan 2005 00:59:33 -0800 (PST) (envelope-from josteitv@pvv.ntnu.no) Received: (qmail 47400 invoked by uid 32454); 3 Jan 2005 08:59:31 -0000 To: ietf-pkix@imc.org Cc: Russ Housley Subject: Re: RFC 3280 and multiple Organization (O) fields in DN References: <6.1.2.0.2.20041222091035.0565e600@mail.binhost.com> From: Jostein Tveit Organization: Norwegian University of Science and Technology Date: Mon, 03 Jan 2005 09:59:31 +0100 In-Reply-To: <6.1.2.0.2.20041222091035.0565e600@mail.binhost.com> (Russ Housley's message of "Wed, 22 Dec 2004 09:13:04 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: > Early versions of the CCITT (wkich is now called ITU-T) included > an informative state machine about name construction. So many > people took the state machine as normative that it was dropped > from the later versions of the document to avoid confusion. Do you mean the state machine in Annex B in X.521? If so, it is still in the standard. -- Jostein Tveit From owner-ietf-pkix Mon Jan 3 06:19:50 2005 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 j03EJovG017271; Mon, 3 Jan 2005 06:19:50 -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 j03EJoFL017270; Mon, 3 Jan 2005 06:19:50 -0800 (PST) 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.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id j03EJj7t017218 for ; Mon, 3 Jan 2005 06:19:50 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 10713 invoked by uid 0); 3 Jan 2005 14:19:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.186) by woodstock.binhost.com with SMTP; 3 Jan 2005 14:19:07 -0000 Message-Id: <6.2.0.14.2.20050103091347.05805b10@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 03 Jan 2005 09:15:00 -0500 To: Jostein Tveit , ietf-pkix@imc.org From: Russ Housley Subject: Re: RFC 3280 and multiple Organization (O) fields in DN In-Reply-To: References: <6.1.2.0.2.20041222091035.0565e600@mail.binhost.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: It used to be in Annex B of X.521 (the 1988 version). Obviously I have not tracked this carefully. I was told that it was dropped due to the confusion that is caused. Russ At 03:59 AM 1/3/2005, Jostein Tveit wrote: >Russ Housley writes: > > > Early versions of the CCITT (wkich is now called ITU-T) included > > an informative state machine about name construction. So many > > people took the state machine as normative that it was dropped > > from the later versions of the document to avoid confusion. > >Do you mean the state machine in Annex B in X.521? >If so, it is still in the standard. > >-- >Jostein Tveit From owner-ietf-pkix Mon Jan 3 15:18:19 2005 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 j03NIJiv003917; Mon, 3 Jan 2005 15:18:19 -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 j03NIJsx003916; Mon, 3 Jan 2005 15:18:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j03NIEqq003788 for ; Mon, 3 Jan 2005 15:18:14 -0800 (PST) (envelope-from skip.slone@lmco.com) Received: from emss03g01.ems.lmco.com (relay3.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.12.10/8.12.10) with ESMTP id j03Kn4UO023339; Mon, 3 Jan 2005 15:49:05 -0500 (EST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0I9R00601KQGXS@lmco.com>; Mon, 03 Jan 2005 18:18:16 -0500 (EST) Received: from EMSS03I00.us.lmco.com ([166.27.250.234]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0I9R00AE6KQFMA@lmco.com>; Mon, 03 Jan 2005 18:18:15 -0500 (EST) Received: from EMSS03M09.us.lmco.com ([166.27.250.218]) by EMSS03I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 03 Jan 2005 18:18:15 -0500 Date: Mon, 03 Jan 2005 18:18:15 -0500 From: "Slone, Skip" Subject: RE: RFC 3280 and multiple Organization (O) fields in DN To: Russ Housley , Jostein Tveit , ietf-pkix@imc.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-Topic: RFC 3280 and multiple Organization (O) fields in DN Thread-index: AcTxrM2gobQYvgHRR9yL5c9904aQxQAO4emw Content-Class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 03 Jan 2005 23:18:15.0473 (UTC) FILETIME=[808F4210:01C4F1EA] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI, the annex in question is NOT being dropped -- instead, it is being updated in the upcoming fifth edition to include domainComponent and to add the following statement, applicable to the whole annex: "This example is for illustrative purposes only, and is not intended to limit the types of names that can be validly constructed in the Directory." As mentioned below, it was (and remains) an informative annex, but common mythology has for years treated it as normative and limiting. According to the myth, names that include domainComponent RDNs are not valid X.500 names. Obviously, we on the X.500/X.509 committee disagree with the myth and would like to see it go away. Hope this helps, -- Skip -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Monday, January 03, 2005 9:15 AM To: Jostein Tveit; ietf-pkix@imc.org Subject: Re: RFC 3280 and multiple Organization (O) fields in DN It used to be in Annex B of X.521 (the 1988 version). Obviously I have not tracked this carefully. I was told that it was dropped due to the confusion that is caused. Russ At 03:59 AM 1/3/2005, Jostein Tveit wrote: >Russ Housley writes: > > > Early versions of the CCITT (wkich is now called ITU-T) included > > an informative state machine about name construction. So many > > people took the state machine as normative that it was dropped > > from the later versions of the document to avoid confusion. > >Do you mean the state machine in Annex B in X.521? >If so, it is still in the standard. > >-- >Jostein Tveit From owner-ietf-pkix Wed Jan 5 04:46:30 2005 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 j05CkUcA020799; Wed, 5 Jan 2005 04:46:30 -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 j05CkUxA020798; Wed, 5 Jan 2005 04:46:30 -0800 (PST) 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 j05CkRoZ020628 for ; Wed, 5 Jan 2005 04:46:28 -0800 (PST) (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 NAA51114; Wed, 5 Jan 2005 13:58:51 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005010513455259:171 ; Wed, 5 Jan 2005 13:45:52 +0100 Message-ID: <41DBE19A.2080100@bull.net> Date: Wed, 05 Jan 2005 13:46:18 +0100 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: Trevor Freeman CC: ietf-pkix@imc.org Subject: Re: SCVP 16 comments deadline References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/05/2005 01:45:52 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/05/2005 01:45:54 PM, Serialize complete at 01/05/2005 01:45:54 PM 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 j05CkUoZ020791 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Trevor, Here are my responses on 17-45. There are still many major points on which we do not agree. The MAJOR one has still to do with the deletion of the validation ALGORITHM so that all validation POLICY dependant parameters can be placed under the validation policy reference. 17. On top of page 7, the relationship between the validation policy and the basic certification path algorithm is not explained. Then in section 1.4 The concept of validation algorithm is introduced but its relationship with the validation policy is not explained. This is confusing. Later on when observing the ASN.1 syntax it may be discovered that two OIDs are being used: - one for the validation policy (ValidationPolRef) and - one for the validation algorithm (ValidationAlg). This is overcomplicated and unnecessary. [TF] Is there a specific issue with the current draft such as a scenario which is not addressed ? [DP] I do not believe that raising this question is a good way to solve my concern. The “S” from SCVP was supposed to mean “Simple”. The current description is the description of CCVP ”Complex Certificate Validation Protocol”. Now, since you asked, CCVP is unable to support the validation algorithm described in section 6.2 of RFC 3280 (with many trust points, each one with its set of parameters). Adding more complexity to solve it would not be the right answer. A major simplification is obtained if there is an OID to define the validation policy while there may be or not be additional parameters. We sould then have: valPolByOID::= SEQUENCE { valPolId OBJECT IDENTIFIER, parameters ANY DEFINED BY ValPolId OPTIONAL } Specifying a path processing compliant with section 6.1 of RFC 3280 would not be possible in the general case, since the current text from RFC 3280 is too vague/ambiguous to support the case where a CRL is *not* signed by the CA. It would be desirable to be able to communicate easily and in a standard way the parameters that may be set in section 6.1 from RFC 3280. In addition, key usage should be added to that list. The document should then define a bundle of all these previous useful parameters and allow for the addition of other parameters. It is thus proposed to define an OID for a validation policy compliant with section 6.1 of RFC 3280 (some differences with section 6 from 3280bis, i.e. adding precision, may be expected). It is thus proposed to modify the text starting from : " The inputs to the basic certification path processing algorithm used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise" up to the end of section 1.3 with the following: "For clients able to specify the parameters of a validation policy, it may be useful to define a standard data structure (using a bundle) able to support the parameters of the basic certification path processing algorithm defined by in section 6.1.1 from [PKIX-1] : - a set of Trust Anchors (by value or by reference), - the initial Certificate Policy set, - initial Certificate Policy mapping setting, - initial any-Policy setting, - initial explicit Certificate Policy setting. as well as : - the usage of the key contained in the certificate (e.g., key encipherment, key agreement, signature) This will be done using a bundle which encapsulates all these parameters. Other application-specific purposes parameters may be added". 18. Section 1.4 is about a "Validation Algorithm". Given what was said before, the header of this section should be changed. If we make a subsection 1.3.1 called "1.3.1. General" for encapsulating the previous text, then we can introduce a new section 1.3.2 called: "1.3.2. Validation policy according to section 6.1 of RFC 3280" [TF] See comment to 17 [DP] See my response above. Some of the text present in the current section 1.4 has been used to build the new text that is proposed below: "1.3.2. Validation policy according to section 6.1 of RFC 3280 SCVP defines a specific validation policy which implements the certification path validation algorithm as defined in section 6.1 of [PKIX-1]. This specific validation policy, called "rfc-3280 basic validation policy" uses the parameters defined in the bundle mentioned above. Note that this algorithm does not support in its full generality the algorithm described in section 6.2 of [PKIX-1] since, when more than one trust anchor is being defined, all the conditions that are specified apply to all trust anchors, whereas section 6.2 allows to have different conditions for every trust anchor. The rfc-3280 basic validation policy may be the default validation policy supported by the server, but does not need to". 19. Section 2 "Protocol Overview" In order to allow for interoperability and testing a common protocol needs to be supported. It should be defined. [TF] There is plenty of precedence for this to be in a separate document. CMS itself just defines the syntax. [DP] Would you be more explicit ? 20. Section 3 "Validation Request" The unsigned request form is not explained and there is a confusion for the signed request which indeed authenticates the client and is thus not anonymous. The current text is : "A signed request is used to authenticate the client to the server or to provide an anonymous client integrity over the request-response pair." It should be rephrased as: "An unsigned request provides an anonymous client integrity over the request since the hash of the request or the full request is incorporated in the response. A signed request is used to authenticate the client to the server". [TF] Since by definition the anonymous client has to sign the request as well this does not make sense. A server can also return a cached response in which case there is no hash of the request in the response. How about : An anonymous client signs the request to provide integrity over the request. A identifiable signs the request to authenticate itself to the server. [DP] This does not make sense. If the response is a live response (not cached) then including the hash of the request in the response is fine and the request does not need to be signed. If the response is a cached response, then the cached response must include “sufficient” information to make sure for the client that it is not a replay from a too old response. The only way is to copy all the parameters of the original request. In either case, signing the request does not help. 21. Page 13. Section 3.1.2 "checks" The following sentence adds nothing and should be removed: "A server may still choose to perform revocation status checks when performing path construction, although this information cannot be returned to the client." [TF] I think it reinforces that with some checks, don't require revocation status checking but a server may still elect to do so. [DP] I disagree. A server SHALL do what the client asks, no more no less. Please, delete the sentence. 22. Page 15. Section 3.1.3 "wantBack" The text states: - Proof of revocation status for each certificate in the AC issuer certification path; It would be important to refer the section of the RFC which explains how to check the "revocation status for each certificate in the AC issuer certification path". [TF] OK, I will add a reference to 3281 section 5. [DP] RFC 3281 is “An Internet Attribute Certificate Profile for Authorization ». I do not believe that it is the correct reference. The basic problem is that there exists no RFC that explains how to check the "revocation status for each certificate in the AC issuer certification path". So leaving details to the validation policy is the only solution. 23. Page 15. Section 3.1.3 "wantBack" The text states: The client can also request a non-cached response to the request by including wantback id-swb-non-cached-resp in the request. The default behavior should be the reverse: fresh information is provided, unless the client accept cached information. The item should be changed into: id-swb-cached-resp [TF] This has been moved to response flags and the default is non-cached. [DP] Fine, finally one point on which we agree. 24. Page 15. Section 3.1.3 "wantBack" The text states: id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13} It should be mentioned that this item is only possible for DPD. [TF] Why is this only possible with DPD? [DP] Because DPV returns only the fist valid path (i.e. a single path) 25. Page 16. Section 3.1.4 validationPolicy The following sentence is talking of an agreement whereas such agreement does not exist. Delete the sentence: "The client and server can optionally agree on a set of parameters which may fully or partially define a validation policy". [TF] OK 26. Page 16. Section 3.1.4 validationPolicy The text states: "If a partial set of parameters has been agreed upon, then the client supplies a reference to the policy plus whatever parameters are necessary to complete the request in this item. This should be replaced with: "If the validation policy does not define all parameters necessary for processing an SCVP request, then the client need to supply these parameters". [TF] Thats is not true. The client can omit whatever parameters match the server default value. [DP] This would mean that the default validation policy always have a full set of parameters. In that case the quoted sentence is still incorrect since it states “ a partial set of parameters”. That sentence still needs to be corrected. What about:” The client supplies a reference to the policy plus whatever parameters which are allowed to change the default parameters". 27. Page 16. Section 3.1.4 validationPolicy The syntax of the validationPolicy item is defined as: ValidationPolicy ::= SEQUENCE { validationPolRef ValidationPolRef, validationAlg [0] ValidationAlg OPTIONAL, userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL, inhibitPolicyMapping [2] BOOLEAN OPTIONAL, requireExplicitPolicy [3] BOOLEAN OPTIONAL, inhibitAnyPolicy [4] BOOLEAN OPTIONAL, isCA [5] BOOLEAN OPTIONAL, trustAnchors [6] TrustAnchors OPTIONAL, keyUsages [7] SEQUENCE SIZE (1..MAX) OF KeyUsage OPTIONAL, extendedKeyUsages [8] ExtKeyUsageSyntax OPTIONAL} This structure is quite odd, because it only allows to pass additional parameters as parameters of the validationAlg. Suppressing the validationAlg item add adding validationParamExtensions would be a simpler and cleaner way. [TF] The only way to include other parameters is because the algorithm needs them. You cannot introduce new parameters without at the same time defining there use. Therefore mandating additional parameters be passed which the corresponding identifier for their is the right thing to do. [DP] I disagree. I could say: the only way to include other parameters is to place them as parameters of the validation policy because the validation policy needs them. Your response is placed too early and does not consider the proposal made just after. See the proposal hereafter and please reconsider your position. This is one of the major issues. Each validation policies uses its own parameters. We should have something like : ValPolByOID ::= SEQUENCE { valPolgId OBJECT IDENTIFIER, parameters ANY DEFINED BY valPolId OPTIONAL } More details follow. 28. It is highly debatable if URIs should be supported or not to reference a validation policy. URIs are not stable over time and thus unless there are dereferenced and a hash value is computed over them, it is insecure to use them. There is a discussion in the security consideration section, but no warning and no pointer here. If we keep them, we should warn the user. [TF] The argument over the stability of URIs is discussed in the security section - which is the appropriate place. The reality is in many organizations are stable enough and much more manageable. The issue over dereferencing and hashing is bogus. Both OID and URI are both opaque stings for this purpose and rely on you trusting the management doing the right thing. [DP] Anyway a reference to the security consideration section is missing. If you believe that a URI is opaque, it should be said, because dereferencing is very often announced by some people as being an advantage. You can place that information in the security considerations section if you wish and then let the IESG decide. If the WG should decides that they should be supported (and if the IESG agrees) on page 17, the ASN.1 description should then be: ValidationPolicy ::= CHOICE { valPolByOID [0] ValPolByOID, valPolByURI [1] ValPolByURI } ValPolByOID ::= SEQUENCE { valPolgId OBJECT IDENTIFIER, parameters ANY DEFINED BY valPolId OPTIONAL } ValPolByURI ::= SEQUENCE { uri IA5String, hashAlgo OBJECT IDENTIFIER, hashValue OCTET STRING} 29. It is proposed to define the following bundle: ValidationParamBundle ::= SEQUENCE { certificatePolicySet [0] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL, inhibitPolicyMapping [1] BOOLEAN OPTIONAL, requireExplicitPolicy [2] BOOLEAN OPTIONAL, inhibitAnyPolicy [3] BOOLEAN OPTIONAL, isCA [4] BOOLEAN OPTIONAL, trustAnchors [5] TrustAnchors OPTIONAL, keyUsages [6] SEQUENCE SIZE (1..MAX) OF KeyUsage OPTIONAL, extendedKeyUsages [7] ExtKeyUsageSyntax OPTIONAL, extensions [8] EXPLICIT Extensions OPTIONAL } Note that userPolicySet" is unclear and has been changed into "certificatePolicySet". [TF] The use of userPolicySet aligns with 3280. I don't think the name to the existing structure is ambiguous or misleading. [DP] Your response arguments about the note but omits to respond to the main argument of this comment. So I consider that a response to this comment is still awaited. BTW, userPolicySet is not a term used in RFC 3280, so you cant’t say it aligns with RFC 3280. The text would need to be aligned with the new structure and, of course the parameters of the rfc-3280 basic validation policy will simply include the bundle above as its parameters. It should also be mentioned somewhere in the document that the support of the rfc-3280 basic validation policy is not mandatory for conformance but, if supported then the bundle needs to be supported. 30. Page 17. Section 3.1.5 validationAlg should be deleted. [TF] Already done [DP] Let us see what the next text will look like to know whether this comment is solved or not. I fear it is not. 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be deleted and replaced by a section later on the "rfc-3280 basic validation policy", which should have its OID defined under the scvp tree for OIDs. [TF] the basic validation algorithm references the 3280 section 6. [DP] What you call the basic validation algorithm is one of the many elements of the rfc-3280 basic validation policy. It is buried within the validation policy and does not need to be identified independently of the validation policy. The default Validation Algorithm still needs to be deleted. This relates to comment 17. 32. Page 17. Section 3.1.5.1. Some text of this section might be re-used to build a new section on the rfc-3280 basic validation policy. Note that the last sentence at the bottom of page 17, should be removed. This sentence is: "The default validation policy MUST use the basic validation algorithm". Any default validation policy can be used. [TF] See answer to 31 [DP] See my response above. 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !) should be as well deleted. [TF] The duplicate has been deleted 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm This goal of this section seems to introduce an additional test to the basic "rfc-3280 basic validation policy". It would come naturally as an extension of ValidationParamBundle, rather than as a parameter of the validationAlgo which has been proposed to be removed. The text should be modified accordingly. [TF] See answer 27. [DP] See my response: your response does not consider the proposal made in comment 27. 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm NameValidationAlgParms ::= SEQUENCE { keyPurposeId KeyPurposeId, validationNames GeneralNames } This construct is artificial since KeyPurposeId is about the Extended Key Usage and has nothing to do with name validation. [TF] Its simple reuses and existing practice. [DP] I do not understand the argument about “existing practice”. It could indeed be interesting to test the Extended Key Usage extension of a certificate, but this should be supported as an extension of ValidationParamBundle. The text should be modified accordingly. 36. Page 22. Section 3.1.5.3 userPolicySet userPolicySet should be changed everywhere into certificatePolicySet. [TF] userPolicySet aligns with 3280 section 6. [DP] userPolicySet is not a term used in RFC 3280, so you cant’t say it aligns with RFC 3280 section 6. You are probably reading a different document. 37. Page 22. Section 3.1.5.3 userPolicySet The text has many sentences like: SCVP clients SHOULD support userPolicySet item in requests, and SCVP servers MUST support userPolicySet item in requests. These requirements only apply for the rfc-3280 basic validation policy, and this should be clearly mentioned. [TF] Since all validation polices contain userPolicySet, it can be in any policy. [DP] I disagree. There may be some validation policies where no parameter at all can be changed by the client. I would expect that most clients will use OIDs for validation policies with no parameter at all. A client is not necessarily allowed to change any parameter of a validation policy. In some cases clients will be allowed to specify only some parameters (but not all). 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping The text states: By default the server allows policy mapping as part of certification path validation. For simplicity, this should be the reverse. Replace with: "By default the server does not perform policy mapping as part of certification path validation. If the client wants the server to support policy mapping, allowPolicyMapping must be set to TRUE in the request". [TF] This conflicts with 3280 section 6. [DP] It does not. Section 6 does not mandate policy mapping. The default is simplicity: no policy mapping. 39. Page 24. Section 3.1.5.8 trustAnchors The text states: "A certificate reference can be used to identify the trust anchor by certificate hash and optionally a distinguished name with serial number". This is not consistent with the ASN.1 definition of PKCReference which is: PKCReference ::= CHOICE { cert [0] Certificate, pkcRef [1] ESSCertID } Please correct. [DP] A response is missing. 40. Page 25. Section 3.1.6 responseRefHash The text states: "By default, the server includes a hash of the request in the response. If the client wants the server to include the full request in the response, responseRefHash is set to FALSE." The server shall always include a hash of the request in the response. [TF] A server cannot include a hash of the request in a cached response. [DP] See my new response to comment 20. If the response is a live response (not cached) then including the hash of the request in the response is fine. If the response is a cached response, then the cached response must include “sufficient” information to make sure for the client that it is not a replay from a too old response. The only way is to copy all the parameters of the original request. This is an easy way to allow to test the integrity of the request. Since the full description of the validation policy may be much longer a flag should be used to say that the full validation policy is not returned unless requested. [TF] There is one, it is responseValidationPolByRef. The response flags now has a FullRequestInResponse in place of the requestRefHash. [DP] Let us see what the full new proposal is. If you agree with my response to comment 20, maybe we are converging. It is thus proposed to have instead the following: "3.1.6.1 fullRequestInResponse The fullRequestInResponse controls if the client wants the server to include the full request in the response. By default, fullRequestInResponse is set to FALSE. If the client wants back the full request then it must set this parameter to TRUE. The main reason a client would request the server to include the full request in the response is to archive the request-response exchange in a single object. That is, the client wants to archive a single object which includes both request and response". 41. Page 26. Section 3.1.6.2 responseValidationPolByRef This item should be renamed: fullValPolInResponse The text should be changed into: "The fullValPolInResponse controls whether the response includes the identifier of the validation policy with all the parameters that have been used by the server, i.e. all the variable parameters independent from the fact that there were specified by the client or defaulted if not specified. By default, fullValPolInResponse is set to FALSE. If the client wants the full validation policy to be included, then fullValPolInResponse is set to TRUE. The main reason a client would request the server to include validation policy to be included by value is to archive the request-response exchange in a single object. That is, the client wants to archive the CVResponse and have it include every aspect of the validation policy." [TF] I have not changed the name, but the section now reads The responseValidationPolByRef controls whether the response includes just a reference to the policy or the reference to the policy plus all the parameters by value of the policy used to process the request. the response MUST contain references to the validation policy. If the client wants the validation policy parameters to be also included by value, then the responseValidationPolByRef is set to FALSE. The main reason a client would request the server to include validation policy to be included by value is to archive the request-response exchange in a single object. That is, the client wants to archive the CVResponse and have it include every aspect of the validation policy. [DP] This new proposed text is still incorrect: “just a reference to the validation policy” does not help, (unless the validation policy has no variable parameter). We need to have a mechanism for replay protection and/or for making sure that the response relates to the right request: “just a reference to the validation policy” does not provide this property. However, my proposal provides that property. Please reconsider my text. The ResponseFlags should be changed as follows: ResponseFlags ::= SEQUENCE { fullRequestInResponse BOOLEAN DEFAULT FALSE, fullValPolInResponse BOOLEAN DEFAULT FALSE, signResponse BOOLEAN DEFAULT TRUE } 42. Page 28. Section 3.1.9 intermediateCerts. Minor. Change: The optional intermediateCerts item helps the SCVP server create valid certification paths. into: The optional intermediateCerts item may help the SCVP server to create valid certification paths. [TF] Fixed 43. Page 29. Section 3.1.11. producedAt Last sentence. Change: SCVP server SHOULD support the producedAt values in the request. into: SCVP server MAY support the producedAt values in the request. Reason: cached responses should not need to be implemented in order to be compliant with the specification. [TF] Fixed 44. Page 32. Section 3.5 dhPublicKey The text states: "For the server to compute the shared secret, it must lean the public values the client generates, therefore the client MUST include this in the request if it uses this mechanism to integrity protect the request- response pair." Replace: "to integrity protect the request-response pair" with : "to authenticate and integrity protect the first response and authenticate and integrity protect subsequent request-response pairs". [TF] draft now read " integrity protect the request and the subsequent response." The use of DH does not necessarily authenticate the request. 45. Page 32. Section 3.6 SCVP Request Authentication The text states: "It is a matter of local policy what validation policy is used by the server when validating requests". This sentence could be misinterpreted because the word "validating" is being used. Change into: It is a matter of local policy what validation policy is used by the server when authentication requests". [TF] Fixed END OF COMMENTS Denis From owner-ietf-pkix Fri Jan 7 12:39:57 2005 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 j07KdvR5062372; Fri, 7 Jan 2005 12:39:57 -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 j07Kdvmv062369; Fri, 7 Jan 2005 12:39:57 -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 j07KduQ5062305 for ; Fri, 7 Jan 2005 12:39:56 -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 PAA21483; Fri, 7 Jan 2005 15:39:54 -0500 (EST) Message-Id: <200501072039.PAA21483@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-certpathbuild-05.txt Date: Fri, 07 Jan 2005 15:39:14 -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 : Internet X.509 Public Key Infrastructure: Certification Path Building Author(s) : M. Cooper, et al. Filename : draft-ietf-pkix-certpathbuild-05.txt Pages : 77 Date : 2005-1-7 This document was written to provide guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate enabled application that can build valid certification paths across a wide range of PKI environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-05.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-certpathbuild-05.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-certpathbuild-05.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-1-7152206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-certpathbuild-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-certpathbuild-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-7152206.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Fri Jan 7 13:04:07 2005 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 j07L47Pw095906; Fri, 7 Jan 2005 13:04: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 j07L47FR095905; Fri, 7 Jan 2005 13:04:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j07L42pQ095521 for ; Fri, 7 Jan 2005 13:04:02 -0800 (PST) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j07L3tjf010093; Fri, 7 Jan 2005 16:03:55 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20041213212151.DFBC97030B@smtp1.pacifier.net> References: <20041213212151.DFBC97030B@smtp1.pacifier.net> Date: Fri, 7 Jan 2005 16:03:37 -0500 To: From: Stephen Kent Subject: Re: Draft-ietf-pkix-rfc2511bis-07 Cc: "IETF-PKIX" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, Jim sent this message in mid-December and I have seen no response on the list, so far. if nobody responds to Jim, Tim and I will interpret this as implicit authorization for Jim to proceed as he see fit on this topics. Steve >As advertized this draft is now under new editorship. As the new editor >there are a number of issues that I fill still need to be resolved before >this draft can go to last call. If there is no help forth coming then I >will be making arbitrary decions on these issue. > >Additionally, if anyone has kept any of the final reports from the interop >trials for CMP, I would like to see the sections that relate to CRMF. > >You can easily find the open issues and questions by searching for [[[ in >the document. > >1. Section 4.1 - I have a partial answer for this question dealing with non >DN style names that are authenticated, but are not actually either subject >names (DNs) or subject alt names (General Names). The only real question at >this point is should this rational be documented. > >2. Section 4.2 - I am worried about the possiblity of somebody copying an >encrypted private key being sent to the CA/RA and then copying it into their >own certificate request. They could then later request a key recovery from >the CA/RA and get back somebody elses private key. This is the reason that >I am worried about how a POP proof is done here. One potential answer is to >include the authenticated identity along with the private key in the >encrypted block. > >3. Section 4.2 - We MUST solve the question of what the contents of the >encrypted blob look like. One potential answer is to obsolete thisMessage >and reaplace it with an EnvelopedData then all that needs to be covered is >the format of the encrypted key plus any POP info required. > >4. Section 4.3 - Does the DH section need to be expanded so that any key >agreement key pair can be used? This can be done by adding a MAC alg and >value pair to the end of the POPOPrivKey choice (and potentially obsoleting >the dhMAC element). > >5. Section 4.4 - Two questions regarding guidence for the number of >iterations and the amount of salt to be used. We need a cryptographer to >give us some guidelines for these details, or atleast need to set some >minimums. > >6. Section 6.1 & 6.2 - The content of these controls is not well defined >and a couple of questions regarding this are asked. This may have been >addressed in the interop by adding some undocumented restrictions. > >7. Section 6.4 - There are a couple of archive questions here. At this >point my inclination is to kill the entire section unless somebody wants to >make it acutally work. > >8. Section 6.8 - Ditto here. > >9. Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%" The parsing is >difficult (but not impossible) due to the overload of the % token. > >Jim From owner-ietf-pkix Mon Jan 10 08:14:42 2005 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 j0AGEfi0039145; Mon, 10 Jan 2005 08:14:41 -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 j0AGEfZX039144; Mon, 10 Jan 2005 08:14:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0AGEeu4039101 for ; Mon, 10 Jan 2005 08:14:40 -0800 (PST) (envelope-from apache@megatron.ietf.org) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Co25S-0001da-9t; Mon, 10 Jan 2005 11:08:10 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , pkix mailing list , pkix chair , pkix chair Subject: Document Action: 'Internet X.509 Public Key Infrastructure: Certification Path Building' to Informational RFC Message-Id: Date: Mon, 10 Jan 2005 11:08:10 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Internet X.509 Public Key Infrastructure: Certification Path Building ' as an Informational RFC This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Russ Housley and Sam Hartman. Technical Summary This document provides guidance and recommendations to developers who need to build X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths in a wide range of PKI environments. Working Group Summary The PKIX Working Group reached consensus on this document. Protocol Quality This document was reviewed by Russ Housley for the IESG. From owner-ietf-pkix Tue Jan 11 07:07:41 2005 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 j0BF7fmQ041291; Tue, 11 Jan 2005 07:07:41 -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 j0BF7fvd041290; Tue, 11 Jan 2005 07:07:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0BF7cLo041053 for ; Tue, 11 Jan 2005 07:07:39 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm441e4634c; Tue, 11 Jan 2005 23:10:19 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd41df3ffe; Sat, 08 Jan 2005 05:10:01 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm341df6741; Sat, 08 Jan 2005 05:09:59 +0800 Received: from megatron.ietf.org([132.151.6.71]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 08 Jan 2005 05:09:59 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0vU-0004eP-V5; Fri, 07 Jan 2005 15:41:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0ts-0003my-2S for i-d-announce@megatron.ietf.org; Fri, 07 Jan 2005 15:40:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21483; Fri, 7 Jan 2005 15:39:54 -0500 (EST) Message-Id: <200501072039.PAA21483@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 07 Jan 2005 15:39:14 -0500 Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-05.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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: Certification Path Building Author(s) : M. Cooper, et al. Filename : draft-ietf-pkix-certpathbuild-05.txt Pages : 77 Date : 2005-1-7 This document was written to provide guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate enabled application that can build valid certification paths across a wide range of PKI environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-05.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-certpathbuild-05.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-certpathbuild-05.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-1-7152206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-certpathbuild-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-certpathbuild-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-7152206.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ietf-pkix Sun Jan 23 21:08:55 2005 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 j0O58qDo066087; Sun, 23 Jan 2005 21:08:54 -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 j0O58oC7066012; Sun, 23 Jan 2005 21:08:50 -0800 (PST) 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 j0O58jcf065925 for ; Sun, 23 Jan 2005 21:08:46 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 7164 invoked by uid 0); 23 Jan 2005 22:31:36 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.35.173) by woodstock.binhost.com with SMTP; 23 Jan 2005 22:31:36 -0000 Message-Id: <6.2.0.14.2.20050122130213.02fcb820@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 22 Jan 2005 13:11:51 -0500 To: rfc-editor@rfc-editor.org From: Russ Housley Subject: RFC 3770 Errata Cc: ietf-pkix@imc.org 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: Dear RFC Editor: Section 4 of RFC 3770 contains a significant error. There is a typographical error in the object identifier. Please publish this errata as soon as possible. OLD: The WLAN SSID attribute certificate attribute is identified by id-aca-wlanSSID. id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 } id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 } NEW: The WLAN SSID attribute certificate attribute is identified by id-aca-wlanSSID. id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 } id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 } This same error is repeated in the ASN.1 Module (Section 8). OLD: id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 } NEW: id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 } Thanks, Russ From owner-ietf-pkix Mon Jan 24 14:21:25 2005 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 j0OMLPaS092182; Mon, 24 Jan 2005 14:21:25 -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 j0OMLPsw092181; Mon, 24 Jan 2005 14:21:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0OMLKd6092168 for ; Mon, 24 Jan 2005 14:21:24 -0800 (PST) (envelope-from ietf@augustcellars.com) Received: from romans (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id D60088282E for ; Mon, 24 Jan 2005 14:21:17 -0800 (PST) Reply-To: From: "Jim Schaad" To: "IETF-PKIX" Subject: Draft-ietf-pkix-rfc2511bis-08 Date: Mon, 24 Jan 2005 14:31:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcThWwept5M0OIEuR8enDSXlEmbtFAhB/doA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <20041213212151.DFBC97030B@smtp1.pacifier.net> Message-Id: <20050124222117.D60088282E@smtp2.pacifier.net> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new draft of this document has been submitted All of the issues listed below have been addressed or removed from the document. Thoses people who have CMP implementations need to look carefully at the updated document as I am sure, not being a CMP guru, that I have changed how things work in some cases. This may not affect any current implemenations but I don't know that. Except for one issue, this document is ready for last call. The remaining issue is to address and pickup any further changes that CMP made to CRMF without actually specifying it as such. If anyone knows the rational and syntax associated with id-regCtrl-altCertTemplate which is partially specified in the RFC 2510 bis document but not documented please let me know. If no one speaks up I will put the syntax into CRMF document and deprecate it. jim > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Jim Schaad > Sent: Monday, December 13, 2004 1:31 PM > To: IETF-PKIX > Subject: Draft-ietf-pkix-rfc2511bis-07 > > > As advertized this draft is now under new editorship. As the > new editor there are a number of issues that I fill still > need to be resolved before this draft can go to last call. > If there is no help forth coming then I will be making > arbitrary decions on these issue. > > Additionally, if anyone has kept any of the final reports > from the interop trials for CMP, I would like to see the > sections that relate to CRMF. > > You can easily find the open issues and questions by > searching for [[[ in the document. > > 1. Section 4.1 - I have a partial answer for this question > dealing with non DN style names that are authenticated, but > are not actually either subject names (DNs) or subject alt > names (General Names). The only real question at this point > is should this rational be documented. > > 2. Section 4.2 - I am worried about the possiblity of > somebody copying an encrypted private key being sent to the > CA/RA and then copying it into their own certificate request. > They could then later request a key recovery from the CA/RA > and get back somebody elses private key. This is the reason > that I am worried about how a POP proof is done here. One > potential answer is to include the authenticated identity > along with the private key in the encrypted block. > > 3. Section 4.2 - We MUST solve the question of what the > contents of the encrypted blob look like. One potential > answer is to obsolete thisMessage and reaplace it with an > EnvelopedData then all that needs to be covered is the format > of the encrypted key plus any POP info required. > > 4. Section 4.3 - Does the DH section need to be expanded so > that any key agreement key pair can be used? This can be > done by adding a MAC alg and value pair to the end of the > POPOPrivKey choice (and potentially obsoleting the dhMAC element). > > 5. Section 4.4 - Two questions regarding guidence for the > number of iterations and the amount of salt to be used. We > need a cryptographer to give us some guidelines for these > details, or atleast need to set some minimums. > > 6. Section 6.1 & 6.2 - The content of these controls is not > well defined and a couple of questions regarding this are > asked. This may have been addressed in the interop by adding > some undocumented restrictions. > > 7. Section 6.4 - There are a couple of archive questions > here. At this point my inclination is to kill the entire > section unless somebody wants to make it acutally work. > > 8. Section 6.8 - Ditto here. > > 9. Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%" > The parsing is > difficult (but not impossible) due to the overload of the % token. > > Jim > > > > > > From owner-ietf-pkix Tue Jan 25 13:08:30 2005 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 j0PL8U37017783; Tue, 25 Jan 2005 13:08:30 -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 j0PL8UsL017782; Tue, 25 Jan 2005 13:08:30 -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 j0PL8TXu017775 for ; Tue, 25 Jan 2005 13:08:29 -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 QAA07940; Tue, 25 Jan 2005 16:08:23 -0500 (EST) Message-Id: <200501252108.QAA07940@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-00.txt Date: Tue, 25 Jan 2005 16:08:23 -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 : 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-00.txt Pages : 10 Date : 2005-1-25 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-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-rfc3770bis-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-rfc3770bis-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-1-25163312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-rfc3770bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-rfc3770bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-25163312.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Tue Jan 25 13:09:06 2005 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 j0PL96NC017823; Tue, 25 Jan 2005 13:09:06 -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 j0PL96DV017822; Tue, 25 Jan 2005 13:09:06 -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 j0PL95wH017816 for ; Tue, 25 Jan 2005 13:09:06 -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 QAA08070; Tue, 25 Jan 2005 16:09:02 -0500 (EST) Message-Id: <200501252109.QAA08070@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-rfc2511bis-08.txt Date: Tue, 25 Jan 2005 16:09: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 : Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) Author(s) : J. Schaad Filename : draft-ietf-pkix-rfc2511bis-08.txt Pages : 33 Date : 2005-1-25 This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and associated registration information. This document does not define a certificate request protocol A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-rfc2511bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-rfc2511bis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-25163339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-rfc2511bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-rfc2511bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-25163339.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Wed Jan 26 12:32:32 2005 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 j0QKWW7J046429; Wed, 26 Jan 2005 12:32:32 -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 j0QKWWIC046428; Wed, 26 Jan 2005 12:32:32 -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 j0QKWVkx046422 for ; Wed, 26 Jan 2005 12:32:32 -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 PAA12289; Wed, 26 Jan 2005 15:32:27 -0500 (EST) Message-Id: <200501262032.PAA12289@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-crlaia-00.txt Date: Wed, 26 Jan 2005 15:32:27 -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 : Internet X.509 Public Key Infrastructure Authority Information Access CRL Extension Author(s) : S. Santesson, R. Housley Filename : draft-ietf-pkix-crlaia-00.txt Pages : 7 Date : 2005-1-26 This document updates RFC 3280 by defining the Authority Information Access Certificate Revocation Lists (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-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-crlaia-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-crlaia-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-1-26155611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-crlaia-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-crlaia-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-26155611.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Fri Jan 28 15:08:31 2005 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 j0SN8Vvn098842; Fri, 28 Jan 2005 15:08:31 -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 j0SN8Vvt098841; Fri, 28 Jan 2005 15:08:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SN8UDV098826 for ; Fri, 28 Jan 2005 15:08:31 -0800 (PST) (envelope-from kent@bbn.com) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0SN8Ijf017460 for ; Fri, 28 Jan 2005 18:08:19 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Fri, 28 Jan 2005 18:08:16 -0500 To: ietf-pkix@imc.org From: Stephen Kent Subject: WG last call Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new version of RFC 3770 needs to be issued to address an OID assignment collision, for the data item: id-aca-wlanSSID. The new I-D is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-00.txt This should not require any discussion, since the only change is fixing the duplicate OID assignment, but we want to conduct the Wg last call for procedural consistency. The last call starts today and end on 2/7, a week from now. Thanks, Steve From owner-ietf-pkix Tue Feb 1 12:50:01 2005 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 j11Ko1L0054911; Tue, 1 Feb 2005 12:50:01 -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 j11Ko14k054910; Tue, 1 Feb 2005 12:50:01 -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 j11Knx2Q054901 for ; Tue, 1 Feb 2005 12:50:00 -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 PAA18287; Tue, 1 Feb 2005 15:49:56 -0500 (EST) Message-Id: <200502012049.PAA18287@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-cmc-archive-01.txt Date: Tue, 01 Feb 2005 15:49:56 -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 : CMC Extensions: Server Side Key Generation and Key Escrow Author(s) : J. Schaad Filename : draft-ietf-pkix-cmc-archive-01.txt Pages : 24 Date : 2005-2-1 This document defines a set of extensions to the CMC (Certificate Management over CMS) protocol that address the desire for having two additional services: 1) Server side generation of keys, 2) server-side escrow and subsequent recovery of key material. These services are provided by the definition of additional control statements within the CMC architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-archive-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-cmc-archive-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-cmc-archive-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-2-1142456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-cmc-archive-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-cmc-archive-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-1142456.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Wed Feb 2 05:17:54 2005 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 j12DHsnR066183; Wed, 2 Feb 2005 05:17:54 -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 j12DHsJO066182; Wed, 2 Feb 2005 05:17:54 -0800 (PST) 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 j12DHrOT066165 for ; Wed, 2 Feb 2005 05:17:53 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 12089 invoked by uid 0); 2 Feb 2005 13:17:50 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.17.29) by woodstock.binhost.com with SMTP; 2 Feb 2005 13:17:50 -0000 Message-Id: <6.2.0.14.2.20050202081639.041c4b20@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 02 Feb 2005 08:17:47 -0500 To: ietf-pkix@imc.org From: Russ Housley Subject: Fwd: I-D ACTION:draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt 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: This group may be interested in this Internet-Draft. Russ >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Tue, 01 Feb 2005 15:48:49 -0500 >Subject: I-D ACTION:draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Additional Algorithms and Identifiers for use of > Elliptic Curve Cryptography with PKIX (Explicit > Identification of One-Way Hash Functions) > Author(s) : R. Housley > Filename : draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt > Pages : 6 > Date : 2005-2-1 > >Dan Brown from Certicom has submitted a specification for Additional > Algorithms and Identifiers for use of Elliptic Curve Cryptography > with PKIX. This document proposes a different approach for > identifying the one-way hash function used with the ECDSA signature > algorithm. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt From owner-ietf-pkix Wed Feb 2 12:58:55 2005 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 j12Kwtdb005766; Wed, 2 Feb 2005 12:58:55 -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 j12Kwt0Q005765; Wed, 2 Feb 2005 12:58:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KwsB9005757 for ; Wed, 2 Feb 2005 12:58:54 -0800 (PST) (envelope-from ietf@augustcellars.com) Received: from romans (ip165.131.du.eli.iinet.com [67.136.131.165]) by smtp3.pacifier.net (Postfix) with ESMTP id 811276E460 for ; Wed, 2 Feb 2005 12:58:52 -0800 (PST) Reply-To: From: "Jim Schaad" To: Subject: RE: I-D ACTION:draft-ietf-pkix-cmc-archive-01.txt Date: Wed, 2 Feb 2005 13:08:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUIpe5E5YtpFX8QQQaTgqoYNEf3UwAxKzYA In-Reply-To: <200502012049.PAA18287@ietf.org> Message-Id: <20050202205852.811276E460@smtp3.pacifier.net> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I assume somewhere along the line the rest of the CMC drafts should appear. They have been submitted for release. The archive draft was published so that I could get some feedback. There is a big QUESTION in the middle of the document that I would like people to look at. It basically deals with the best way to return multiple private keys in a single message. Whether they should be masked in a single encrypted blob, or seperated into multiple encrypted blobs and if a single encrypted blob whether we should extend the structure defined in the CRMF draft (thus requiring a fast update to it) or not. Jim From owner-ietf-pkix Thu Feb 3 08:12:05 2005 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 j13GC58x016666; Thu, 3 Feb 2005 08:12:05 -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 j13GC5WK016665; Thu, 3 Feb 2005 08:12:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from whisky.linagora.com (whisky.linagora.com [62.23.27.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13GC29c016647 for ; Thu, 3 Feb 2005 08:12:03 -0800 (PST) (envelope-from yquenechdu@linagora.com) Received: from localhost (localhost [127.0.0.1]) by whisky.linagora.com (Postfix) with ESMTP id 0A01F9DDC1 for ; Thu, 3 Feb 2005 17:11:44 +0100 (CET) Received: from whisky.linagora.com ([127.0.0.1]) by localhost (whisky [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09428-10 for ; Thu, 3 Feb 2005 17:11:32 +0100 (CET) Received: from tomate.linagora.lan (sgi2.linagora.com [195.68.36.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by whisky.linagora.com (Postfix) with ESMTP id AC4AA9DDC7 for ; Thu, 3 Feb 2005 17:11:28 +0100 (CET) Received: from 192.168.1.254 (proxying for 145.242.3.30) (SquirrelMail authenticated user yquenechdu@linagora.com); by tomate.linagora.lan with HTTP; Thu, 3 Feb 2005 17:11:45 +0100 (CET) Message-ID: <49863.192.168.1.254.1107447105.squirrel@192.168.1.254> Date: Thu, 3 Feb 2005 17:11:45 +0100 (CET) Subject: Question about RFC3379 From: yquenechdu@linagora.com To: ietf-pkix@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at linagora.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, a small question about in the RFC3379, Why there is not definition in ASN.1 format for request and the response to the client and server DPV and DPD, as one can see it in the RFC2560. It is a deliberated choice? Thanks. Yannick Quenec'hdu From owner-ietf-pkix Thu Feb 3 10:40:17 2005 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 j13IeHXA038913; Thu, 3 Feb 2005 10:40:17 -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 j13IeH9C038912; Thu, 3 Feb 2005 10:40:17 -0800 (PST) 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 j13IeGcr038906 for ; Thu, 3 Feb 2005 10:40:17 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 23647 invoked by uid 0); 3 Feb 2005 18:40:11 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.143.32) by woodstock.binhost.com with SMTP; 3 Feb 2005 18:40:11 -0000 Message-Id: <6.2.0.14.2.20050203133916.060fe610@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 03 Feb 2005 13:40:13 -0500 To: yquenechdu@linagora.com, ietf-pkix@imc.org From: Russ Housley Subject: Re: Question about RFC3379 In-Reply-To: <49863.192.168.1.254.1107447105.squirrel@192.168.1.254> References: <49863.192.168.1.254.1107447105.squirrel@192.168.1.254> 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: RFC 3379 specifies protocol requirements, not a protocol. SCVP is the protocol that is intended to satisfy the protocol requirements. Russ At 11:11 AM 2/3/2005, yquenechdu@linagora.com wrote: >Hello, > >a small question about in the RFC3379, Why there is not definition in >ASN.1 format for request and the response to the client and server DPV and >DPD, as one can see it in the RFC2560. It is a deliberated choice? > >Thanks. >Yannick Quenec'hdu From owner-ietf-pkix Thu Feb 3 12:15:42 2005 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 j13KFgor046509; Thu, 3 Feb 2005 12:15:42 -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 j13KFg3c046508; Thu, 3 Feb 2005 12:15:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KFfnZ046500 for ; Thu, 3 Feb 2005 12:15:42 -0800 (PST) (envelope-from mcooper@orionsec.com) Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j13KFeRW014485; Thu, 3 Feb 2005 15:15:40 -0500 Message-Id: <200502032015.j13KFeRW014485@host13.websitesource.com> From: "Matt Cooper" To: , Cc: Subject: draft-ietf-pkix-crlaia-00.txt comments Date: Thu, 3 Feb 2005 15:15:04 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C50A03.264D7FC0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUKLQl3j9ejZ5CaRAyGNTfn2tmAkg== 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_00A2_01C50A03.264D7FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit First, I'd like to say I'm happy to see this come out, this is a needed addition for CRLs. All my comments refer to the following snippet extracted from the draft (http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt): ===begin=== When the http scheme is specified, the URI MUST point to a certificate file. The certificate file MUST contain either a single DER encoded certificate (indicated by the .cer file extension) or contain a certification path (indicated by the .p7c file extension): .cer A single DER encoded certificate as specified in RFC 2585 [PKIX-CERT]. .p7c A MIME encoded application/pkcs7-mime "certs-only" file as specified in RFC 2797 [CMC]. ===end=== Unless this has been required in another document that I am unaware of, we should use not use "MIME encoded" for this purpose for the following reasons: 1. It creates burden on the client. Why should the client need a MIME decoder to verify a CRL? 2. It creates burden for CA's and CA operators. They may have to learn how to manually encode a PKCS#7 in a MIME structure if their CA does not output this for them. This is error prone and may lead to problems. 3. Clients must handle one case as binary and the other case as text 4. Web servers already return MIME types for data; another MIME layer is not needed It is not too much to expect that the relying party software can distinguish between a binary cert and a binary p7c file. (For example, MS CAPI already does this for AIA) However, to make life easier for the client, could we throw in appropriate use of MIME types on the web server? Perhaps something like this: "HTTP server implementations accessed via the URI SHOULD use the appropriate MIME content-type for the certificate file. Specifically, the HTTP server SHOULD return the content-type application/pkix-cert for a single DER encoded certificate and application/pkcs7-mime for a certs-only PKCS#7. Consuming clients SHOULD use the MIME type as a hint, but should not depend solely on the presence of the correct MIME type in the server response." Calling for the contents of the p7c to be "a certification path" is too restrictive in my mind. It would be better to leave this wide open and say something like "contain one or more certificates that may be helpful to the relying party." This leaves it up to the implementer to put in any certificates that may be useful for path construction regardless of whether we have common trusted roots. (They may also wish to not include the entire path, but instead only the CRL signer cert, which then has another AIA in it.) Suggest rewording the text something like this : When the HTTP scheme is specified, the URI MUST point to a certificate file. The certificate file MUST be either a single binary DER encoded certificate (indicated by the .cer file extension) or a single binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file extension) containing one or more certificates that may be helpful to the relying party. Matt Cooper Orion Security Solutions 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (Mob) 703.981.2269 (Off) 703.917.0060 x. 30 (Fax) 703.917.0260 Visit our website! http://www.orionsec.com ------=_NextPart_000_00A2_01C50A03.264D7FC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
First, I'd like = to say I'm=20 happy to see this come out, this is a needed addition for=20 CRLs.
 
All my comments = refer to=20 the following snippet extracted from the draft
(http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt):=
 
=3D=3D=3Dbegin=3D=3D=3D
   When the http scheme is specified, = the URI=20 MUST point to a
   certificate file.  The certificate = file=20 MUST contain either a single
   DER encoded certificate = (indicated=20 by the .cer file extension) or
   contain a certification = path=20 (indicated by the .p7c file = extension):

     =20 .cer   A single DER encoded certificate as specified=20 in
           &= nbsp;=20 RFC 2585 [PKIX-CERT].

      = .p7c   A=20 MIME encoded application/pkcs7-mime "certs-only"=20 file
           = ; =20 as specified in RFC 2797 [CMC].
=3D=3D=3Dend=3D=3D=3D
 
Unless this has = been=20 required in another document that I am unaware of, we should use not use = "MIME=20 encoded" for this purpose for the following reasons:
1. It creates = burden on the=20 client.  Why should the client need a MIME decoder to verify a=20 CRL?
2. It creates = burden for=20 CA's and CA operators.  They may have to learn how to manually=20 encode a PKCS#7 in a MIME structure if their CA does not = output=20 this for them. This is error prone and may lead to=20 problems.
3. = Clients must handle=20 one case as binary and the other case as text
4. Web servers already return MIME types for = data;=20 another MIME layer is not needed
 
It is not = too much to=20 expect that the relying party software can distinguish between a binary = cert and=20 a binary p7c file. (For example, MS CAPI already does this for = AIA) =20 However, to make life easier for the client, could we throw in = appropriate use=20 of MIME types on the web server? Perhaps something like=20 this:
 
"HTTP server=20 implementations accessed via the URI SHOULD use the = appropriate MIME=20 content-type for the certificate file.  Specifically, the HTTP = server=20 SHOULD return the = content-type=20 application/pkix-cert for a single DER encoded certificate and=20 application/pkcs7-mime for a certs-only PKCS#7.  Consuming clients = SHOULD=20 use the MIME type as a hint, but should not depend solely on the = presence of the=20 correct MIME type in the server response."
 
Calling for the = contents of=20 the p7c to be "a certification path" is too restrictive in my = mind.  It=20 would be better to leave this wide open and say something like "contain = one or=20 more certificates that may be helpful to the relying party."  This = leaves=20 it up to the implementer to put in any certificates that may = be useful=20 for path construction regardless of whether we have common trusted = roots. =20 (They may also wish to not include the entire path, but instead only the = CRL=20 signer cert, which then has another AIA in it.)
 
Suggest = rewording the text=20 something like this :
 
When the HTTP = scheme is=20 specified, the URI MUST point to a certificate file. The = certificate file=20 MUST be either a single binary DER encoded certificate = (indicated by=20 the .cer file extension) or a single binary DER=20 encoded certs-only PKCS#7 file (indicated by the .p7c file = extension)=20 containing one or more certificates that may be helpful to the relying=20 party.
 
 
Matt Cooper
Orion Security = Solutions
1489=20 Chain Bridge Road, Suite 300
McLean, Virginia 22101
(Mob)=20 703.981.2269
(Off) 703.917.0060 x. 30
(Fax) = 703.917.0260
Visit our website!
http://www.orionsec.com
 
 
------=_NextPart_000_00A2_01C50A03.264D7FC0-- From owner-ietf-pkix Thu Feb 3 12:41:14 2005 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 j13KfEVB048991; Thu, 3 Feb 2005 12:41:14 -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 j13KfE2M048990; Thu, 3 Feb 2005 12:41:14 -0800 (PST) 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 j13KfDfb048982 for ; Thu, 3 Feb 2005 12:41:13 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 9023 invoked by uid 0); 3 Feb 2005 20:41:06 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.143.32) by woodstock.binhost.com with SMTP; 3 Feb 2005 20:41:06 -0000 Message-Id: <6.2.0.14.2.20050203153553.0631deb0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 03 Feb 2005 15:38:46 -0500 To: "Matt Cooper" , From: Russ Housley Subject: Re: draft-ietf-pkix-crlaia-00.txt comments Cc: In-Reply-To: <200502032015.j13KFeRW014485@host13.websitesource.com> References: <200502032015.j13KFeRW014485@host13.websitesource.com> 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: Matt:

We were not clear.  We did not intend to eliminate the MIME encoding which is normally present with HTTP.  The MIME types are specified in the referenced documents, I believe.  Rather, we were also stating a naming convention for the files that are obtained.

Russ

At 03:15 PM 2/3/2005, Matt Cooper wrote:
First, I'd like to say I'm happy to see this come out, this is a needed addition for CRLs.
 
All my comments refer to the following snippet extracted from the draft
( http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt ):
 
===begin===
   When the http scheme is specified, the URI MUST point to a
   certificate file.  The certificate file MUST contain either a single
   DER encoded certificate (indicated by the .cer file extension) or
   contain a certification path (indicated by the .p7c file extension):

      .cer   A single DER encoded certificate as specified in
             RFC 2585 [PKIX-CERT].

      .p7c   A MIME encoded application/pkcs7-mime "certs-only" file
             as specified in RFC 2797 [CMC].
===end===
 
Unless this has been required in another document that I am unaware of, we should use not use "MIME encoded" for this purpose for the following reasons:
1. It creates burden on the client.  Why should the client need a MIME decoder to verify a CRL?
2. It creates burden for CA's and CA operators.  They may have to learn how to manually encode a PKCS#7 in a MIME structure if their CA does not output this for them. This is error prone and may lead to problems.
3. Clients must handle one case as binary and the other case as text
4. Web servers already return MIME types for data; another MIME layer is not needed
 
It is not too much to expect that the relying party software can distinguish between a binary cert and a binary p7c file. (For example, MS CAPI already does this for AIA)  However, to make life easier for the client, could we throw in appropriate use of MIME types on the web server? Perhaps something like this:
 
"HTTP server implementations accessed via the URI SHOULD use the appropriate MIME content-type for the certificate file.  Specifically, the HTTP server SHOULD return the content-type application/pkix-cert for a single DER encoded certificate and application/pkcs7-mime for a certs-only PKCS#7.  Consuming clients SHOULD use the MIME type as a hint, but should not depend solely on the presence of the correct MIME type in the server response."
 
Calling for the contents of the p7c to be "a certification path" is too restrictive in my mind.  It would be better to leave this wide open and say something like "contain one or more certificates that may be helpful to the relying party."  This leaves it up to the implementer to put in any certificates that may be useful for path construction regardless of whether we have common trusted roots.  (They may also wish to not include the entire path, but instead only the CRL signer cert, which then has another AIA in it.)
 
Suggest rewording the text something like this :
 
When the HTTP scheme is specified, the URI MUST point to a certificate file. The certificate file MUST be either a single binary DER encoded certificate (indicated by the .cer file extension) or a single binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file extension) containing one or more certificates that may be helpful to the relying party.
 
 
Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060 x. 30
(Fax) 703.917.0260
Visit our website!
http://www.orionsec.com
 
 
From owner-ietf-pkix Thu Feb 3 15:30:09 2005 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 j13NU9qM064341; Thu, 3 Feb 2005 15:30:09 -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 j13NU9vH064340; Thu, 3 Feb 2005 15:30:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13NU3Br064329 for ; Thu, 3 Feb 2005 15:30:04 -0800 (PST) (envelope-from mcooper@orionsec.com) Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j13NTvRX022430; Thu, 3 Feb 2005 18:29:59 -0500 Message-Id: <200502032329.j13NTvRX022430@host13.websitesource.com> From: "Matt Cooper" To: "'Russ Housley'" , Cc: Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Date: Thu, 3 Feb 2005 18:29:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.2.0.14.2.20050203153553.0631deb0@mail.binhost.com> Thread-Index: AcUKMLMiKTc97gy5Q12zIO3eWeictQACZjbA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Perhaps I was not clear either. I didn't think you were attempting to eliminate the HTTP MIME encoding. And believe me, I'm the first one to cheer having a naming convention for this purpose! Are you saying that your intent was only to apply the MIME encoding to how the HTTP server should be serving up the files to the client? Not trying to be difficult, I just want to be sure we're on the same page as the text reads quite differently to me. It reads (to me) that you intend for the hosted file to be MIME encoded rather than binary. Specifically, as [A MIME encoded application/pkcs7-mime "certs-only" file as specified in RFC 2797 [CMC]"]. When I read this it indicated to me that I am supposed to MIME encode the PKCS#7 and name the resultant MIME text file with a .p7c extension. E.g., place the following file content on my web server: MIME-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type="certs-only"; name="cacerts.p7c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cacerts.p7c" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/+Q29u dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ ... BhcnA=== Matt Cooper Orion Security Solutions 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (Mob) 703.981.2269 (Off) 703.917.0060 x. 30 (Fax) 703.917.0260 Visit our website! http://www.orionsec.com ________________________________ From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, February 03, 2005 3:39 PM To: Matt Cooper; stefans@microsoft.com Cc: ietf-pkix@imc.org Subject: Re: draft-ietf-pkix-crlaia-00.txt comments Matt: We were not clear. We did not intend to eliminate the MIME encoding which is normally present with HTTP. The MIME types are specified in the referenced documents, I believe. Rather, we were also stating a naming convention for the files that are obtained. Russ At 03:15 PM 2/3/2005, Matt Cooper wrote: First, I'd like to say I'm happy to see this come out, this is a needed addition for CRLs. All my comments refer to the following snippet extracted from the draft ( http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt ): ===begin=== When the http scheme is specified, the URI MUST point to a certificate file. The certificate file MUST contain either a single DER encoded certificate (indicated by the .cer file extension) or contain a certification path (indicated by the .p7c file extension): .cer A single DER encoded certificate as specified in RFC 2585 [PKIX-CERT]. .p7c A MIME encoded application/pkcs7-mime "certs-only" file as specified in RFC 2797 [CMC]. ===end=== Unless this has been required in another document that I am unaware of, we should use not use "MIME encoded" for this purpose for the following reasons: 1. It creates burden on the client. Why should the client need a MIME decoder to verify a CRL? 2. It creates burden for CA's and CA operators. They may have to learn how to manually encode a PKCS#7 in a MIME structure if their CA does not output this for them. This is error prone and may lead to problems. 3. Clients must handle one case as binary and the other case as text 4. Web servers already return MIME types for data; another MIME layer is not needed It is not too much to expect that the relying party software can distinguish between a binary cert and a binary p7c file. (For example, MS CAPI already does this for AIA) However, to make life easier for the client, could we throw in appropriate use of MIME types on the web server? Perhaps something like this: "HTTP server implementations accessed via the URI SHOULD use the appropriate MIME content-type for the certificate file. Specifically, the HTTP server SHOULD return the content-type application/pkix-cert for a single DER encoded certificate and application/pkcs7-mime for a certs-only PKCS#7. Consuming clients SHOULD use the MIME type as a hint, but should not depend solely on the presence of the correct MIME type in the server response." Calling for the contents of the p7c to be "a certification path" is too restrictive in my mind. It would be better to leave this wide open and say something like "contain one or more certificates that may be helpful to the relying party." This leaves it up to the implementer to put in any certificates that may be useful for path construction regardless of whether we have common trusted roots. (They may also wish to not include the entire path, but instead only the CRL signer cert, which then has another AIA in it.) Suggest rewording the text something like this : When the HTTP scheme is specified, the URI MUST point to a certificate file. The certificate file MUST be either a single binary DER encoded certificate (indicated by the .cer file extension) or a single binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file extension) containing one or more certificates that may be helpful to the relying party. Matt Cooper Orion Security Solutions 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (Mob) 703.981.2269 (Off) 703.917.0060 x. 30 (Fax) 703.917.0260 Visit our website! http://www.orionsec.com From owner-ietf-pkix Fri Feb 4 05:21:07 2005 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 j14DL6Cu048679; Fri, 4 Feb 2005 05:21:06 -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 j14DL6ds048678; Fri, 4 Feb 2005 05:21:06 -0800 (PST) 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 j14DL5Us048665 for ; Fri, 4 Feb 2005 05:21:06 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 25593 invoked by uid 0); 4 Feb 2005 13:21:03 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.237) by woodstock.binhost.com with SMTP; 4 Feb 2005 13:21:03 -0000 Message-Id: <6.2.0.14.2.20050204081930.05a73950@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 04 Feb 2005 08:21:01 -0500 To: "Matt Cooper" , From: Russ Housley Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Cc: In-Reply-To: <200502032329.j13NTvRX022430@host13.websitesource.com> References: <6.2.0.14.2.20050203153553.0631deb0@mail.binhost.com> <200502032329.j13NTvRX022430@host13.websitesource.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: Matt: MIME supports many encoding types, including binary and base64. I think that binary will be used in this case, but base64 and other encodings are not prohibited. We should probably say that binary encoding MUST be supported. Russ At 06:29 PM 2/3/2005, Matt Cooper wrote: >Perhaps I was not clear either. I didn't think you were attempting to >eliminate the HTTP MIME encoding. And believe me, I'm the first one to >cheer having a naming convention for this purpose! > >Are you saying that your intent was only to apply the MIME encoding to how >the HTTP server should be serving up the files to the client? Not trying to >be difficult, I just want to be sure we're on the same page as the text >reads quite differently to me. > >It reads (to me) that you intend for the hosted file to be MIME encoded >rather than binary. Specifically, as [A MIME encoded application/pkcs7-mime >"certs-only" file as specified in RFC 2797 [CMC]"]. When I read this it >indicated to me that I am supposed to MIME encode the PKCS#7 and name the >resultant MIME text file with a .p7c extension. E.g., place the following >file content on my web server: > >MIME-Version: 1.0 >Content-Type: application/pkcs7-mime; > smime-type="certs-only"; > name="cacerts.p7c" >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; > filename="cacerts.p7c" > >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/+Q29u >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ >... >BhcnA=== > > >Matt Cooper >Orion Security Solutions >1489 Chain Bridge Road, Suite 300 >McLean, Virginia 22101 >(Mob) 703.981.2269 >(Off) 703.917.0060 x. 30 >(Fax) 703.917.0260 >Visit our website! >http://www.orionsec.com > > >________________________________ > >From: Russ Housley [mailto:housley@vigilsec.com] >Sent: Thursday, February 03, 2005 3:39 PM >To: Matt Cooper; stefans@microsoft.com >Cc: ietf-pkix@imc.org >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments > > >Matt: > >We were not clear. We did not intend to eliminate the MIME encoding which >is normally present with HTTP. The MIME types are specified in the >referenced documents, I believe. Rather, we were also stating a naming >convention for the files that are obtained. > >Russ > >At 03:15 PM 2/3/2005, Matt Cooper wrote: > > > First, I'd like to say I'm happy to see this come out, this is a >needed addition for CRLs. > > All my comments refer to the following snippet extracted from the >draft > ( http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt > ): > > ===begin=== > When the http scheme is specified, the URI MUST point to a > certificate file. The certificate file MUST contain either a >single > DER encoded certificate (indicated by the .cer file extension) or > contain a certification path (indicated by the .p7c file >extension): > > .cer A single DER encoded certificate as specified in > RFC 2585 [PKIX-CERT]. > > .p7c A MIME encoded application/pkcs7-mime "certs-only" file > as specified in RFC 2797 [CMC]. > ===end=== > > Unless this has been required in another document that I am unaware >of, we should use not use "MIME encoded" for this purpose for the following >reasons: > 1. It creates burden on the client. Why should the client need a >MIME decoder to verify a CRL? > 2. It creates burden for CA's and CA operators. They may have to >learn how to manually encode a PKCS#7 in a MIME structure if their CA does >not output this for them. This is error prone and may lead to problems. > 3. Clients must handle one case as binary and the other case as text > 4. Web servers already return MIME types for data; another MIME >layer is not needed > > It is not too much to expect that the relying party software can >distinguish between a binary cert and a binary p7c file. (For example, MS >CAPI already does this for AIA) However, to make life easier for the >client, could we throw in appropriate use of MIME types on the web server? >Perhaps something like this: > > "HTTP server implementations accessed via the URI SHOULD use the >appropriate MIME content-type for the certificate file. Specifically, the >HTTP server SHOULD return the content-type application/pkix-cert for a >single DER encoded certificate and application/pkcs7-mime for a certs-only >PKCS#7. Consuming clients SHOULD use the MIME type as a hint, but should >not depend solely on the presence of the correct MIME type in the server >response." > > Calling for the contents of the p7c to be "a certification path" is >too restrictive in my mind. It would be better to leave this wide open and >say something like "contain one or more certificates that may be helpful to >the relying party." This leaves it up to the implementer to put in any >certificates that may be useful for path construction regardless of whether >we have common trusted roots. (They may also wish to not include the entire >path, but instead only the CRL signer cert, which then has another AIA in >it.) > > Suggest rewording the text something like this : > > When the HTTP scheme is specified, the URI MUST point to a >certificate file. The certificate file MUST be either a single binary DER >encoded certificate (indicated by the .cer file extension) or a single >binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file >extension) containing one or more certificates that may be helpful to the >relying party. > > > Matt Cooper > Orion Security Solutions > 1489 Chain Bridge Road, Suite 300 > McLean, Virginia 22101 > (Mob) 703.981.2269 > (Off) 703.917.0060 x. 30 > (Fax) 703.917.0260 > Visit our website! > http://www.orionsec.com > > From owner-ietf-pkix Fri Feb 4 06:39:02 2005 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 j14Ed2Pb062691; Fri, 4 Feb 2005 06:39:02 -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 j14Ed2k5062690; Fri, 4 Feb 2005 06:39:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sam.dfn-cert.de (sam.dfn-cert.de [193.174.13.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Ed1g2062683 for ; Fri, 4 Feb 2005 06:39:02 -0800 (PST) (envelope-from brauckmann@dfn-cert.de) Message-ID: <420388E6.5060504@dfn-cert.de> Date: Fri, 04 Feb 2005 15:38:30 +0100 From: Juergen Brauckmann Organization: DFN-CERT Services GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: AIA and draft-ietf-pkix-crlaia-00.txt References: <200502032015.j13KFeRW014485@host13.websitesource.com> In-Reply-To: <200502032015.j13KFeRW014485@host13.websitesource.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hi. In Chapter 1 you are saying: 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. That is, the intention of id-ad-caIssuers is to provide a link to the direct issuer of the certificate containing the extension, and to CA certificates that are further up the chain. But chapter 4.2.1.1 in RFC 3280 says (4th paragraph): The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to the CA that issued the certificate containing this extension. If I'm reading this sentence, I understand that you should only provide a link to the *issuer* of the CA of the certificate containing the extension, one level higher up in the hierarchy. => Is my interpretation of the sentence wrong? Please correct me... . Regards, Juergen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBQgOI5tbYU3wuWc8tAQE3Jgf+K+4rBYoYZ157ZtKVhdVBBzxqecV8wTeO o2lnTF+PrgdxrLErSykC7IelS9qDv9tV382ZiX2jRSTEqe3rwr1gWILRby6n3lup QkhU8w3LzsN8lhcTpo9RhsWaZJ+4ReTSFPN4rIGQBd9qiOB3FNw/Jug84pzI/hV3 FFNH4B/dSkmsSoY8SvcqRxa2GZrWOQKjPPEFtZIaIVYR1g6h6+PBkj5WyMwyE4Rw h0+mO2/gRfL5YRTbfKMFjW03PCXuAr/C6RalQJJuzoObE7fiHE//DqpIK6lV7EKX QmGrf3GzvwIv+mBZqzhhW6sMGtZstUIwm2l9QrNL0U4j+kfbt+Js8A== =WC/B -----END PGP SIGNATURE----- From owner-ietf-pkix Fri Feb 4 11:44:06 2005 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 j14Ji6iq090358; Fri, 4 Feb 2005 11:44:06 -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 j14Ji6FF090357; Fri, 4 Feb 2005 11:44:06 -0800 (PST) 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 j14JhvXn090299 for ; Fri, 4 Feb 2005 11:44:01 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 6898 invoked by uid 0); 4 Feb 2005 19:43:24 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.44.43) by woodstock.binhost.com with SMTP; 4 Feb 2005 19:43:24 -0000 Message-Id: <6.2.0.14.2.20050204143947.06072a30@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 04 Feb 2005 14:41:42 -0500 To: Juergen Brauckmann , ietf-pkix@imc.org From: Russ Housley Subject: Re: AIA and draft-ietf-pkix-crlaia-00.txt In-Reply-To: <420388E6.5060504@dfn-cert.de> References: <200502032015.j13KFeRW014485@host13.websitesource.com> <420388E6.5060504@dfn-cert.de> 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: Juergen: The Authority Information Access Extension provides information about the issuer of the certificate that contains the extension. Russ At 09:38 AM 2/4/2005, Juergen Brauckmann wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >Hi. > >In Chapter 1 you are saying: > 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. > >That is, the intention of id-ad-caIssuers is to provide a link to the >direct issuer of the certificate containing the extension, and to CA >certificates that are further up the chain. > >But chapter 4.2.1.1 in RFC 3280 says (4th paragraph): > The id-ad-caIssuers OID is used when the additional information lists > CAs that have issued certificates superior to the CA that issued the > certificate containing this extension. > >If I'm reading this sentence, I understand that you should only provide >a link to the *issuer* of the CA of the certificate containing the >extension, one level higher up in the hierarchy. >=> Is my interpretation of the sentence wrong? > >Please correct me... . > >Regards, > Juergen >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iQEVAwUBQgOI5tbYU3wuWc8tAQE3Jgf+K+4rBYoYZ157ZtKVhdVBBzxqecV8wTeO >o2lnTF+PrgdxrLErSykC7IelS9qDv9tV382ZiX2jRSTEqe3rwr1gWILRby6n3lup >QkhU8w3LzsN8lhcTpo9RhsWaZJ+4ReTSFPN4rIGQBd9qiOB3FNw/Jug84pzI/hV3 >FFNH4B/dSkmsSoY8SvcqRxa2GZrWOQKjPPEFtZIaIVYR1g6h6+PBkj5WyMwyE4Rw >h0+mO2/gRfL5YRTbfKMFjW03PCXuAr/C6RalQJJuzoObE7fiHE//DqpIK6lV7EKX >QmGrf3GzvwIv+mBZqzhhW6sMGtZstUIwm2l9QrNL0U4j+kfbt+Js8A== >=WC/B >-----END PGP SIGNATURE----- From owner-ietf-pkix Fri Feb 4 13:35:38 2005 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 j14LZcBN099269; Fri, 4 Feb 2005 13:35:38 -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 j14LZc02099268; Fri, 4 Feb 2005 13:35:38 -0800 (PST) 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 j14LZbOq099248 for ; Fri, 4 Feb 2005 13:35:37 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Feb 2005 21:36:58 +0000 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: draft-ietf-pkix-crlaia-00.txt comments Date: Fri, 4 Feb 2005 21:35:00 -0000 Message-ID: <0C3042E92D8A714783E2C44AB9936E1D019BC779@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-crlaia-00.txt comments thread-index: AcUKz4KgFsFUT136QGK2avMXYo/tzwAMTy7w From: "Stefan Santesson" To: "Russ Housley" , "Matt Cooper" Cc: X-OriginalArrivalTime: 04 Feb 2005 21:36:58.0687 (UTC) FILETIME=[A7BB4CF0:01C50B01] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j14LZbOq099263 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, we just want to express that which is the current practice. I guess that limits to binary and base64 encoded .cer file and binary .p7c Except from this I agree to Matt that it would be nice to loosen up the requirement on what certificates that is included in a .p7c file. Maybe "certificate path" is too restrictive. I have no problem with Matt's suggested change here. Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Russ Housley > Sent: den 4 februari 2005 05:21 > To: Matt Cooper; Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > > Matt: > > MIME supports many encoding types, including binary and base64. I think > that binary will be used in this case, but base64 and other encodings are > not prohibited. > > We should probably say that binary encoding MUST be supported. > > Russ > > At 06:29 PM 2/3/2005, Matt Cooper wrote: > > >Perhaps I was not clear either. I didn't think you were attempting to > >eliminate the HTTP MIME encoding. And believe me, I'm the first one to > >cheer having a naming convention for this purpose! > > > >Are you saying that your intent was only to apply the MIME encoding to > how > >the HTTP server should be serving up the files to the client? Not trying > to > >be difficult, I just want to be sure we're on the same page as the text > >reads quite differently to me. > > > >It reads (to me) that you intend for the hosted file to be MIME encoded > >rather than binary. Specifically, as [A MIME encoded application/pkcs7- > mime > >"certs-only" file as specified in RFC 2797 [CMC]"]. When I read this it > >indicated to me that I am supposed to MIME encode the PKCS#7 and name the > >resultant MIME text file with a .p7c extension. E.g., place the > following > >file content on my web server: > > > >MIME-Version: 1.0 > >Content-Type: application/pkcs7-mime; > > smime-type="certs-only"; > > name="cacerts.p7c" > >Content-Transfer-Encoding: base64 > >Content-Disposition: attachment; > > filename="cacerts.p7c" > > > >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/ +Q > 29u > >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05 le > HRQ > >... > >BhcnA=== > > > > > >Matt Cooper > >Orion Security Solutions > >1489 Chain Bridge Road, Suite 300 > >McLean, Virginia 22101 > >(Mob) 703.981.2269 > >(Off) 703.917.0060 x. 30 > >(Fax) 703.917.0260 > >Visit our website! > >http://www.orionsec.com > > > > > >________________________________ > > > >From: Russ Housley [mailto:housley@vigilsec.com] > >Sent: Thursday, February 03, 2005 3:39 PM > >To: Matt Cooper; stefans@microsoft.com > >Cc: ietf-pkix@imc.org > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments > > > > > >Matt: > > > >We were not clear. We did not intend to eliminate the MIME encoding > which > >is normally present with HTTP. The MIME types are specified in the > >referenced documents, I believe. Rather, we were also stating a naming > >convention for the files that are obtained. > > > >Russ > > > >At 03:15 PM 2/3/2005, Matt Cooper wrote: > > > > > > First, I'd like to say I'm happy to see this come out, this is a > >needed addition for CRLs. > > > > All my comments refer to the following snippet extracted from > the > >draft > > ( http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia- > 00.txt > > ): > > > > ===begin=== > > When the http scheme is specified, the URI MUST point to a > > certificate file. The certificate file MUST contain either a > >single > > DER encoded certificate (indicated by the .cer file > extension) or > > contain a certification path (indicated by the .p7c file > >extension): > > > > .cer A single DER encoded certificate as specified in > > RFC 2585 [PKIX-CERT]. > > > > .p7c A MIME encoded application/pkcs7-mime "certs-only" > file > > as specified in RFC 2797 [CMC]. > > ===end=== > > > > Unless this has been required in another document that I am > unaware > >of, we should use not use "MIME encoded" for this purpose for the > following > >reasons: > > 1. It creates burden on the client. Why should the client need > a > >MIME decoder to verify a CRL? > > 2. It creates burden for CA's and CA operators. They may have > to > >learn how to manually encode a PKCS#7 in a MIME structure if their CA > does > >not output this for them. This is error prone and may lead to problems. > > 3. Clients must handle one case as binary and the other case as > text > > 4. Web servers already return MIME types for data; another MIME > >layer is not needed > > > > It is not too much to expect that the relying party software can > >distinguish between a binary cert and a binary p7c file. (For example, MS > >CAPI already does this for AIA) However, to make life easier for the > >client, could we throw in appropriate use of MIME types on the web > server? > >Perhaps something like this: > > > > "HTTP server implementations accessed via the URI SHOULD use the > >appropriate MIME content-type for the certificate file. Specifically, > the > >HTTP server SHOULD return the content-type application/pkix-cert for a > >single DER encoded certificate and application/pkcs7-mime for a certs- > only > >PKCS#7. Consuming clients SHOULD use the MIME type as a hint, but should > >not depend solely on the presence of the correct MIME type in the server > >response." > > > > Calling for the contents of the p7c to be "a certification path" > is > >too restrictive in my mind. It would be better to leave this wide open > and > >say something like "contain one or more certificates that may be helpful > to > >the relying party." This leaves it up to the implementer to put in any > >certificates that may be useful for path construction regardless of > whether > >we have common trusted roots. (They may also wish to not include the > entire > >path, but instead only the CRL signer cert, which then has another AIA in > >it.) > > > > Suggest rewording the text something like this : > > > > When the HTTP scheme is specified, the URI MUST point to a > >certificate file. The certificate file MUST be either a single binary DER > >encoded certificate (indicated by the .cer file extension) or a single > >binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file > >extension) containing one or more certificates that may be helpful to the > >relying party. > > > > > > Matt Cooper > > Orion Security Solutions > > 1489 Chain Bridge Road, Suite 300 > > McLean, Virginia 22101 > > (Mob) 703.981.2269 > > (Off) 703.917.0060 x. 30 > > (Fax) 703.917.0260 > > Visit our website! > > http://www.orionsec.com > > > > From owner-ietf-pkix Fri Feb 4 13:55:21 2005 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 j14LtLvl000592; Fri, 4 Feb 2005 13:55:21 -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 j14LtLgH000591; Fri, 4 Feb 2005 13:55:21 -0800 (PST) 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 j14LtKiY000585 for ; Fri, 4 Feb 2005 13:55:21 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 24365 invoked by uid 0); 4 Feb 2005 21:55:12 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.44.43) by woodstock.binhost.com with SMTP; 4 Feb 2005 21:55:12 -0000 Message-Id: <6.2.0.14.2.20050204165424.0782ab70@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 04 Feb 2005 16:54:57 -0500 To: "Stefan Santesson" , "Matt Cooper" From: Russ Housley Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Cc: In-Reply-To: <0C3042E92D8A714783E2C44AB9936E1D019BC779@EUR-MSG-03.europe .corp.microsoft.com> References: <0C3042E92D8A714783E2C44AB9936E1D019BC779@EUR-MSG-03.europe.corp.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: I have no problem including certificate that may be useful in path construction in the .p7c. Russ At 04:35 PM 2/4/2005, Stefan Santesson wrote: >Yes, we just want to express that which is the current practice. > >I guess that limits to binary and base64 encoded .cer file and binary >.p7c > >Except from this I agree to Matt that it would be nice to loosen up the >requirement on what certificates that is included in a .p7c file. Maybe >"certificate path" is too restrictive. I have no problem with Matt's >suggested change here. > >Stefan Santesson >Microsoft Security Center of Excellence (SCOE) > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Russ Housley > > Sent: den 4 februari 2005 05:21 > > To: Matt Cooper; Stefan Santesson > > Cc: ietf-pkix@imc.org > > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > > > > > Matt: > > > > MIME supports many encoding types, including binary and base64. I >think > > that binary will be used in this case, but base64 and other encodings >are > > not prohibited. > > > > We should probably say that binary encoding MUST be supported. > > > > Russ > > > > At 06:29 PM 2/3/2005, Matt Cooper wrote: > > > > >Perhaps I was not clear either. I didn't think you were attempting >to > > >eliminate the HTTP MIME encoding. And believe me, I'm the first one >to > > >cheer having a naming convention for this purpose! > > > > > >Are you saying that your intent was only to apply the MIME encoding >to > > how > > >the HTTP server should be serving up the files to the client? Not >trying > > to > > >be difficult, I just want to be sure we're on the same page as the >text > > >reads quite differently to me. > > > > > >It reads (to me) that you intend for the hosted file to be MIME >encoded > > >rather than binary. Specifically, as [A MIME encoded >application/pkcs7- > > mime > > >"certs-only" file as specified in RFC 2797 [CMC]"]. When I read >this it > > >indicated to me that I am supposed to MIME encode the PKCS#7 and name >the > > >resultant MIME text file with a .p7c extension. E.g., place the > > following > > >file content on my web server: > > > > > >MIME-Version: 1.0 > > >Content-Type: application/pkcs7-mime; > > > smime-type="certs-only"; > > > name="cacerts.p7c" > > >Content-Transfer-Encoding: base64 > > >Content-Disposition: attachment; > > > filename="cacerts.p7c" > > > > > > >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/ >+Q > > 29u > > > >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05 >le > > HRQ > > >... > > >BhcnA=== > > > > > > > > >Matt Cooper > > >Orion Security Solutions > > >1489 Chain Bridge Road, Suite 300 > > >McLean, Virginia 22101 > > >(Mob) 703.981.2269 > > >(Off) 703.917.0060 x. 30 > > >(Fax) 703.917.0260 > > >Visit our website! > > >http://www.orionsec.com > > > > > > > > >________________________________ > > > > > >From: Russ Housley [mailto:housley@vigilsec.com] > > >Sent: Thursday, February 03, 2005 3:39 PM > > >To: Matt Cooper; stefans@microsoft.com > > >Cc: ietf-pkix@imc.org > > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments > > > > > > > > >Matt: > > > > > >We were not clear. We did not intend to eliminate the MIME encoding > > which > > >is normally present with HTTP. The MIME types are specified in the > > >referenced documents, I believe. Rather, we were also stating a >naming > > >convention for the files that are obtained. > > > > > >Russ > > > > > >At 03:15 PM 2/3/2005, Matt Cooper wrote: > > > > > > > > > First, I'd like to say I'm happy to see this come out, this >is a > > >needed addition for CRLs. > > > > > > All my comments refer to the following snippet extracted >from > > the > > >draft > > > ( >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia- > > 00.txt > > > >): > > > > > > ===begin=== > > > When the http scheme is specified, the URI MUST point to >a > > > certificate file. The certificate file MUST contain >either a > > >single > > > DER encoded certificate (indicated by the .cer file > > extension) or > > > contain a certification path (indicated by the .p7c file > > >extension): > > > > > > .cer A single DER encoded certificate as specified >in > > > RFC 2585 [PKIX-CERT]. > > > > > > .p7c A MIME encoded application/pkcs7-mime >"certs-only" > > file > > > as specified in RFC 2797 [CMC]. > > > ===end=== > > > > > > Unless this has been required in another document that I am > > unaware > > >of, we should use not use "MIME encoded" for this purpose for the > > following > > >reasons: > > > 1. It creates burden on the client. Why should the client >need > > a > > >MIME decoder to verify a CRL? > > > 2. It creates burden for CA's and CA operators. They may >have > > to > > >learn how to manually encode a PKCS#7 in a MIME structure if their CA > > does > > >not output this for them. This is error prone and may lead to >problems. > > > 3. Clients must handle one case as binary and the other case >as > > text > > > 4. Web servers already return MIME types for data; another >MIME > > >layer is not needed > > > > > > It is not too much to expect that the relying party software >can > > >distinguish between a binary cert and a binary p7c file. (For >example, MS > > >CAPI already does this for AIA) However, to make life easier for the > > >client, could we throw in appropriate use of MIME types on the web > > server? > > >Perhaps something like this: > > > > > > "HTTP server implementations accessed via the URI SHOULD use >the > > >appropriate MIME content-type for the certificate file. >Specifically, > > the > > >HTTP server SHOULD return the content-type application/pkix-cert for >a > > >single DER encoded certificate and application/pkcs7-mime for a >certs- > > only > > >PKCS#7. Consuming clients SHOULD use the MIME type as a hint, but >should > > >not depend solely on the presence of the correct MIME type in the >server > > >response." > > > > > > Calling for the contents of the p7c to be "a certification >path" > > is > > >too restrictive in my mind. It would be better to leave this wide >open > > and > > >say something like "contain one or more certificates that may be >helpful > > to > > >the relying party." This leaves it up to the implementer to put in >any > > >certificates that may be useful for path construction regardless of > > whether > > >we have common trusted roots. (They may also wish to not include the > > entire > > >path, but instead only the CRL signer cert, which then has another >AIA in > > >it.) > > > > > > Suggest rewording the text something like this : > > > > > > When the HTTP scheme is specified, the URI MUST point to a > > >certificate file. The certificate file MUST be either a single binary >DER > > >encoded certificate (indicated by the .cer file extension) or a >single > > >binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file > > >extension) containing one or more certificates that may be helpful to >the > > >relying party. > > > > > > > > > Matt Cooper > > > Orion Security Solutions > > > 1489 Chain Bridge Road, Suite 300 > > > McLean, Virginia 22101 > > > (Mob) 703.981.2269 > > > (Off) 703.917.0060 x. 30 > > > (Fax) 703.917.0260 > > > Visit our website! > > > http://www.orionsec.com > > > > > > From owner-ietf-pkix Mon Feb 7 06:19:29 2005 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 j17EJTmX019068; Mon, 7 Feb 2005 06:19:29 -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 j17EJTH9019067; Mon, 7 Feb 2005 06:19:29 -0800 (PST) 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 j17EJOBv019047 for ; Mon, 7 Feb 2005 06:19:26 -0800 (PST) (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 PAA51292; Mon, 7 Feb 2005 15:32:27 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005020715185603:2318 ; Mon, 7 Feb 2005 15:18:56 +0100 Message-ID: <420778ED.7090803@bull.net> Date: Mon, 07 Feb 2005 15:19:25 +0100 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: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt References: <200501262032.PAA12289@ietf.org> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/02/2005 15:18:56, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/02/2005 15:18:59, Serialize complete at 07/02/2005 15:18:59 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 j17EJTBv019062 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments on 1. The title and the scope of the document are not in accordance with the content of the document. The document is not simply defining a new extension that may help to find out a CRL, but is defining a new way to verify that a CRL is correct. 2. The new way to verify that a CRL is correct is not aligned with the current documents. According to RFC 3280, page 7, a CRL issuer is an “optional system to which a CA delegates the publication of certificate revocation lists”. This means that the CA is responsible of the CRL issuance but may delegate the publication to another entity, while being still legally responsible of the issuance of the CRLs. The CRL distribution points extension, defined in section 4.2.1.14 of RFC 3280, is the means for the CA to designate the appropriate CRL Issuer. When the CA is not the CRL issuer, then the cRLIssuer field MUST be present and contain the Name of the CRL issuer. This field has the syntax GeneralNames. GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 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 } Since a name is only unambiguous when certified by a CA (two CAs can certify two different entities but might use the same name for each of them), the straightforward rule to make sure that the name is unambiguous is to use a certificate for that name that has been issued by the CA which has designated the CRL Issuer. This is not explicitly stated in RFC 3280 for CRL issuers, but it is for OCSP responderx which play a similar function. In page 3 of RFC 2560 we have: All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following: -- (...) -- (...) -- a CA Designated Responder (Authorized Responder) who holds a *specially marked certificate issued directly by the CA*, indicating that the responder may issue OCSP responses for that CA. This means that the CRL Issuer must have a *specially marked certificate issued directly by the CA*, indicating that the CRL isssuer may issue CRLs for that CA. Having said this, many portions of the text are not acceptable. Only a few examples will be given hereafter. 3. The abstract is misleading. The text states: “The CRL extension provides a means of discovering and retrieving CRL issuer certificates.” It should say :“The CRL extension provides an additional means of discovering and retrieving CRL issuer certificates.” 4. The introduction is misleading. The text states: “ CRL validation is also specified in RFC 3280, which involves the constructions of a valid certification path for the CRL issuer”. There is no concept of “construction of valid certification path for the CRL issuer”. There is however the concept of a certification path which is a chain of certificates from a “certificate-to—be-tested” up to one of the root keys trusted under the validation policy. For each certificate of the certification path, it must be tested that it is not revoked. As said above, the CRL issuer is designated by the CA and thus there is the need to locate, get and verify the CRL issuer certificate that has been issued by the CA. For each certificate of the certification path, there may be the need to capture just ONE CRL issuer certificate and no more. The next sentences are inappropriate as well and should be deleted. 5. The introduction states: “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. These methods are however not generally applicable, and they do not provide a generic solution to the problem.” This text is biased and is incorrect. SIA is equally applicable and also provides a generic solution to the problem. It has simply to do with using an extension which points downwards or upwards. The key point is that the certification path (as described in RFC 3280) needs first to be build. Once it is built, and only once this is done, the question is whether or not all certificates of the path are not revoked. This means that it is possible to look up in every certificate of the certification path and find out the extensions which are present. There is no superiority to the new proposed extension, if SIA is populated. 6. The introduction states: This document provides a straightforward and generic solution to the CRL issuer certification path building problem by permitting 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, if necessary, complete the CRL issuer certification path building to an appropriate trust anchor. Based on the previous arguments, this text is incorrect as well since there is no “CRL issuer certification path building problem”. Major changes to this document are required to go any further. Until an agreement can be reached on the previous issues, it does not make sense to discuss the remaining of the document. Denis > 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 Authority > Information Access CRL Extension > Author(s) : S. Santesson, R. Housley > Filename : draft-ietf-pkix-crlaia-00.txt > Pages : 7 > Date : 2005-1-26 > > This document updates RFC 3280 by defining the Authority Information > Access Certificate Revocation Lists (CRL) extension. RFC 3280 > defines the Authority Information Access certificate extension using > the same syntax. The CRL extension provides a means of discovering > and retrieving CRL issuer certificates. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt From owner-ietf-pkix Mon Feb 7 06:56:52 2005 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 j17Euqtb022900; Mon, 7 Feb 2005 06:56:52 -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 j17EuqQZ022899; Mon, 7 Feb 2005 06:56:52 -0800 (PST) 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 j17EuoC1022872 for ; Mon, 7 Feb 2005 06:56:51 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 7 Feb 2005 14:56:40 +0000 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt Date: Mon, 7 Feb 2005 14:56:27 -0000 Message-ID: <0C3042E92D8A714783E2C44AB9936E1D019BCB43@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt thread-index: AcUNIA6T5J+BNWCSRIeIrLrA/s3ttAAA/xlw From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: "pkix" X-OriginalArrivalTime: 07 Feb 2005 14:56:40.0834 (UTC) FILETIME=[3B370620:01C50D25] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j17EupC1022894 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, It is obvious that you base your objections on the assumption that a CRL issuer cert MUST be issued by the CA issuing the validated subject cert. But you also admit that this is what you think the stand should say but do not say (at least not explicitly). Quote from your text: "This is not explicitly stated in RFC 3280 for CRL issuers, but it is for OCSP responders" I guess it will be useless to get into details before we have sorted out this major cause of disagreement. But since even you admit that there is no such requirement in RFC 3280 (nor X.509), I'm not sure what there is to discuss. Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 7 februari 2005 06:19 > To: Stefan Santesson; Russ Housley > Cc: pkix > Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > > Comments on > > 1. The title and the scope of the document are not in accordance with the > content of the document. The document is not simply defining a new > extension > that may help to find out a CRL, but is defining a new way to verify that > a > CRL is correct. > > > 2. The new way to verify that a CRL is correct is not aligned with the > current documents. > > According to RFC 3280, page 7, a CRL issuer is an "optional system to > which > a CA delegates the publication of certificate revocation lists". > > This means that the CA is responsible of the CRL issuance but may delegate > the publication to another entity, while being still legally responsible > of > the issuance of the CRLs. > > The CRL distribution points extension, defined in section 4.2.1.14 of RFC > 3280, is the means for the CA to designate the appropriate CRL Issuer. > When > the CA is not the CRL issuer, then the cRLIssuer field MUST be present and > contain the Name of the CRL issuer. This field has the syntax > GeneralNames. > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > 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 } > > Since a name is only unambiguous when certified by a CA (two CAs can > certify > two different entities but might use the same name for each of them), the > straightforward rule to make sure that the name is unambiguous is to use a > certificate for that name that has been issued by the CA which has > designated the CRL Issuer. > > This is not explicitly stated in RFC 3280 for CRL issuers, but it is for > OCSP responderx which play a similar function. In page 3 of RFC 2560 we > have: > > All definitive response messages SHALL be digitally signed. The key > used to sign the response MUST belong to one of the following: > > -- (...) > -- (...) > -- a CA Designated Responder (Authorized Responder) who holds a > *specially marked certificate issued directly by the CA*, > indicating > that the responder may issue OCSP responses for that CA. > > This means that the CRL Issuer must have a *specially marked certificate > issued directly by the CA*, indicating that the CRL isssuer may issue CRLs > for that CA. > > Having said this, many portions of the text are not acceptable. Only a few > examples will be given hereafter. > > > 3. The abstract is misleading. The text states: > "The CRL extension provides a means of discovering and retrieving CRL > issuer > certificates." It should say :"The CRL extension provides an additional > means of discovering and retrieving CRL issuer certificates." > > > 4. The introduction is misleading. The text states: > > " CRL validation is also specified in RFC 3280, which involves the > constructions of a valid certification path for the CRL issuer". > > There is no concept of "construction of valid certification path for the > CRL > issuer". There is however the concept of a certification path which is a > chain of certificates from a "certificate-to-be-tested" up to one of the > root keys trusted under the validation policy. For each certificate of the > certification path, it must be tested that it is not revoked. As said > above, > the CRL issuer is designated by the CA and thus there is the need to > locate, > get and verify the CRL issuer certificate that has been issued by the CA. > > For each certificate of the certification path, there may be the need to > capture just ONE CRL issuer certificate and no more. > > The next sentences are inappropriate as well and should be deleted. > > > 5. The introduction states: > > "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. These methods are however not > generally applicable, and they do not provide a generic solution to > the problem." > > This text is biased and is incorrect. SIA is equally applicable and also > provides a generic solution to the problem. It has simply to do with using > an extension which points downwards or upwards. > > The key point is that the certification path (as described in RFC 3280) > needs first to be build. Once it is built, and only once this is done, the > question is whether or not all certificates of the path are not revoked. > This means that it is possible to look up in every certificate of the > certification path and find out the extensions which are present. There is > no superiority to the new proposed extension, if SIA is populated. > > > 6. The introduction states: > > This document provides a straightforward and generic solution to the > CRL issuer certification path building problem by permitting 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, if necessary, > complete the CRL issuer certification path building to an appropriate > trust anchor. > > Based on the previous arguments, this text is incorrect as well since > there > is no "CRL issuer certification path building problem". > > Major changes to this document are required to go any further. Until an > agreement can be reached on the previous issues, it does not make sense to > discuss the remaining of the document. > > Denis > > > > 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 Authority > > Information Access CRL Extension > > Author(s) : S. Santesson, R. Housley > > Filename : draft-ietf-pkix-crlaia-00.txt > > Pages : 7 > > Date : 2005-1-26 > > > > This document updates RFC 3280 by defining the Authority Information > > Access Certificate Revocation Lists (CRL) extension. RFC 3280 > > defines the Authority Information Access certificate extension using > > the same syntax. The CRL extension provides a means of discovering > > and retrieving CRL issuer certificates. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt > From owner-ietf-pkix Mon Feb 7 09:28:24 2005 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 j17HSORN039376; Mon, 7 Feb 2005 09:28:24 -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 j17HSOtI039375; Mon, 7 Feb 2005 09:28:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HSNVh039364 for ; Mon, 7 Feb 2005 09:28:23 -0800 (PST) (envelope-from mcooper@orionsec.com) Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j17HSBmY026352; Mon, 7 Feb 2005 12:28:18 -0500 Message-Id: <200502071728.j17HSBmY026352@host13.websitesource.com> From: "Matt Cooper" To: "'Russ Housley'" , Cc: Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Date: Mon, 7 Feb 2005 12:27:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.2.0.14.2.20050204081930.05a73950@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUKvGEmY2Yqj9F1Rg+JCl0qj9UeigABqH2A Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, TRUE|FALSE: On the server, you intend for the certificate file (stored on the server's hard disk) to be MIME encoded. The question has nothing to do with HTTP. It could be FTP or NFS for all it matters. What the draft says (to me at least) is that you are supposed to MIME encode the data *BEFORE* the protocol encoding ever enters the picture. This results in the client receiving a MIME encoded file regardless of transport protocol. Best Regards, Matt Cooper Orion Security Solutions 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (Mob) 703.981.2269 (Off) 703.917.0060 x. 30 (Fax) 703.917.0260 Visit our website! http://www.orionsec.com -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Friday, February 04, 2005 8:21 AM To: Matt Cooper; stefans@microsoft.com Cc: ietf-pkix@imc.org Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Matt: MIME supports many encoding types, including binary and base64. I think that binary will be used in this case, but base64 and other encodings are not prohibited. We should probably say that binary encoding MUST be supported. Russ At 06:29 PM 2/3/2005, Matt Cooper wrote: >Perhaps I was not clear either. I didn't think you were attempting to >eliminate the HTTP MIME encoding. And believe me, I'm the first one to >cheer having a naming convention for this purpose! > >Are you saying that your intent was only to apply the MIME encoding to >how the HTTP server should be serving up the files to the client? Not >trying to be difficult, I just want to be sure we're on the same page >as the text reads quite differently to me. > >It reads (to me) that you intend for the hosted file to be MIME encoded >rather than binary. Specifically, as [A MIME encoded >application/pkcs7-mime "certs-only" file as specified in RFC 2797 >[CMC]"]. When I read this it indicated to me that I am supposed to >MIME encode the PKCS#7 and name the resultant MIME text file with a >.p7c extension. E.g., place the following file content on my web server: > >MIME-Version: 1.0 >Content-Type: application/pkcs7-mime; > smime-type="certs-only"; > name="cacerts.p7c" >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; > filename="cacerts.p7c" > >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/ >+Q29u >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05 >leHRQ >... >BhcnA=== > > >Matt Cooper >Orion Security Solutions >1489 Chain Bridge Road, Suite 300 >McLean, Virginia 22101 >(Mob) 703.981.2269 >(Off) 703.917.0060 x. 30 >(Fax) 703.917.0260 >Visit our website! >http://www.orionsec.com > > >________________________________ > >From: Russ Housley [mailto:housley@vigilsec.com] >Sent: Thursday, February 03, 2005 3:39 PM >To: Matt Cooper; stefans@microsoft.com >Cc: ietf-pkix@imc.org >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments > > >Matt: > >We were not clear. We did not intend to eliminate the MIME encoding >which is normally present with HTTP. The MIME types are specified in >the referenced documents, I believe. Rather, we were also stating a >naming convention for the files that are obtained. > >Russ > >At 03:15 PM 2/3/2005, Matt Cooper wrote: > > > First, I'd like to say I'm happy to see this come out, this is >a needed addition for CRLs. > > All my comments refer to the following snippet extracted from >the draft > ( >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt > ): > > ===begin=== > When the http scheme is specified, the URI MUST point to a > certificate file. The certificate file MUST contain either >a single > DER encoded certificate (indicated by the .cer file extension) or > contain a certification path (indicated by the .p7c file >extension): > > .cer A single DER encoded certificate as specified in > RFC 2585 [PKIX-CERT]. > > .p7c A MIME encoded application/pkcs7-mime "certs-only" file > as specified in RFC 2797 [CMC]. > ===end=== > > Unless this has been required in another document that I am >unaware of, we should use not use "MIME encoded" for this purpose for >the following >reasons: > 1. It creates burden on the client. Why should the client >need a MIME decoder to verify a CRL? > 2. It creates burden for CA's and CA operators. They may have >to learn how to manually encode a PKCS#7 in a MIME structure if their >CA does not output this for them. This is error prone and may lead to problems. > 3. Clients must handle one case as binary and the other case as text > 4. Web servers already return MIME types for data; another >MIME layer is not needed > > It is not too much to expect that the relying party software >can distinguish between a binary cert and a binary p7c file. (For >example, MS CAPI already does this for AIA) However, to make life >easier for the client, could we throw in appropriate use of MIME types on the web server? >Perhaps something like this: > > "HTTP server implementations accessed via the URI SHOULD use >the appropriate MIME content-type for the certificate file. >Specifically, the HTTP server SHOULD return the content-type >application/pkix-cert for a single DER encoded certificate and >application/pkcs7-mime for a certs-only PKCS#7. Consuming clients >SHOULD use the MIME type as a hint, but should not depend solely on the >presence of the correct MIME type in the server response." > > Calling for the contents of the p7c to be "a certification >path" is too restrictive in my mind. It would be better to leave this >wide open and say something like "contain one or more certificates that >may be helpful to the relying party." This leaves it up to the >implementer to put in any certificates that may be useful for path >construction regardless of whether we have common trusted roots. (They >may also wish to not include the entire path, but instead only the CRL >signer cert, which then has another AIA in >it.) > > Suggest rewording the text something like this : > > When the HTTP scheme is specified, the URI MUST point to a >certificate file. The certificate file MUST be either a single binary >DER encoded certificate (indicated by the .cer file extension) or a >single binary DER encoded certs-only PKCS#7 file (indicated by the .p7c >file >extension) containing one or more certificates that may be helpful to >the relying party. > > > Matt Cooper > Orion Security Solutions > 1489 Chain Bridge Road, Suite 300 > McLean, Virginia 22101 > (Mob) 703.981.2269 > (Off) 703.917.0060 x. 30 > (Fax) 703.917.0260 > Visit our website! > http://www.orionsec.com > > From owner-ietf-pkix Mon Feb 7 10:27:15 2005 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 j17IREZ6046171; Mon, 7 Feb 2005 10:27:14 -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 j17IREBk046170; Mon, 7 Feb 2005 10:27:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nb2.stroeder.com (d4-238.dip.isp-service.de [83.121.4.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IR05F046049 for ; Mon, 7 Feb 2005 10:27:05 -0800 (PST) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 1264E77059; Mon, 7 Feb 2005 18:26:26 +0100 (CET) Received: from nb2.stroeder.com ([127.0.0.1]) by localhost (nb2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08069-06; Mon, 7 Feb 2005 18:26:21 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id F35F67706C; Mon, 7 Feb 2005 18:26:18 +0100 (CET) Message-ID: <4207A4BA.5010606@stroeder.com> Date: Mon, 07 Feb 2005 18:26:18 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Russ Housley Cc: Matt Cooper , ietf-pkix@imc.org Subject: Re: draft-ietf-pkix-crlaia-00.txt comments References: <6.2.0.14.2.20050203153553.0631deb0@mail.binhost.com> <200502032329.j13NTvRX022430@host13.websitesource.com> <6.2.0.14.2.20050204081930.05a73950@mail.binhost.com> In-Reply-To: <6.2.0.14.2.20050204081930.05a73950@mail.binhost.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at stroeder.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley wrote: > > At 06:29 PM 2/3/2005, Matt Cooper wrote: > >> When I read this it >> indicated to me that I am supposed to MIME encode the PKCS#7 and name the >> resultant MIME text file with a .p7c extension. E.g., place the >> following >> file content on my web server: >> >> MIME-Version: 1.0 >> Content-Type: application/pkcs7-mime; >> smime-type="certs-only"; >> name="cacerts.p7c" >> Content-Transfer-Encoding: base64 >> Content-Disposition: attachment; >> filename="cacerts.p7c" >> >> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/+Q29u >> dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ >> ... >> BhcnA=== > > MIME supports many encoding types, including binary and base64. I think > that binary will be used in this case, but base64 and other encodings > are not prohibited. > > We should probably say that binary encoding MUST be supported. Russ, it's still not clear to me whether you and Matt are talking about the same thing: I think Matt is talking about the file containing yet another encapsulated MIME part. As I understand the example he gave the header lines would *not* be the HTTP header lines. These would be the header of an additional MIME part stored in the certificate file. Ciao, Michael. From owner-ietf-pkix Tue Feb 8 10:33:24 2005 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 j18IXOrU027608; Tue, 8 Feb 2005 10:33:24 -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 j18IXOl6027607; Tue, 8 Feb 2005 10:33:24 -0800 (PST) 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 j18IXKLP027595 for ; Tue, 8 Feb 2005 10:33:23 -0800 (PST) (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 j18IXDn18446; Tue, 8 Feb 2005 19:33:13 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 8 Feb 2005 19:33:13 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j18IXCn20472; Tue, 8 Feb 2005 19:33:12 +0100 (MET) Date: Tue, 8 Feb 2005 19:33:12 +0100 (MET) From: Peter Sylvester Message-Id: <200502081833.j18IXCn20472@chandon.edelweb.fr> To: housley@vigilsec.com, stefans@microsoft.com Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt 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: - The abstract says that the defined extension has the same syntax as for certificats. This seems slightly misleading for me since the texts also defines data formats, and does not reuse the existing id-ad-caIssuers. - The id-ad-caIssuers definition in 3280 defines the usage of ftp, http, ldap (but fails together with operationl protocols to completely define the data formats for http and ftp. I am not sure that p7c in the current text is really intended to have another mime encapsulation (as mentioned by D.C.), but if so, what would this be good for? - Shouldn't the data format be met into an updated operational protocols? This would also allow to say a little bit more about what an http client is supposed to implement as a minimal profile for http. - It doesn't seem extremely useful to me to have several different formats to access to certificat list via http, on for certificats in general (done by Peter Gutmann's text) and another in this text. - Using a suffix .cer or .p7c to determine the content type behind an http uri seems not ok to me, for this AFAIK, http uses mime types. - Yes, I know, we might end with a debate whether a list of certs can be provided best as: - SEQUENCE OF Certificate - a p7c cert only PKCS7/CMS file - a mime multipart containing several individual certificats - same result as with ldap... Well, so be it, ==> 'n' mime types (defined with their file suffix) a an http client can set a list of acceptable mime types, and the server must return the data in that way. Using undefined length encoding, the first and the second simply mean to encode a fixed prefix and suffix, the third is a bit more complicated, etc. Peter From owner-ietf-pkix Tue Feb 8 10:50:24 2005 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 j18IoOLe028509; Tue, 8 Feb 2005 10:50:24 -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 j18IoOAr028508; Tue, 8 Feb 2005 10:50:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IoNeN028498 for ; Tue, 8 Feb 2005 10:50:23 -0800 (PST) (envelope-from mcooper@orionsec.com) Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j18IoJmX016108; Tue, 8 Feb 2005 13:50:19 -0500 Message-Id: <200502081850.j18IoJmX016108@host13.websitesource.com> From: "Matt Cooper" To: "'Russ Housley'" , Cc: Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Date: Tue, 8 Feb 2005 13:49:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.2.0.14.2.20050208131630.06239290@mail.binhost.com> Thread-Index: AcUODdTzr6d8YJ+YShK0qLy6m4+QfQAACXaQ Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I knew we would get to the same page eventually. :) I'm glad to hear the answer is negative. I, and several others I have spoken to, took the text in the draft to indicate this extra MIME encoding was the proposed requirement. So, I think we simply need to reword that section to be very clear on this point. Best Regards, Matt Cooper Orion Security Solutions 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (Mob) 703.981.2269 (Off) 703.917.0060 x. 30 (Fax) 703.917.0260 Visit our website! http://www.orionsec.com -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Tuesday, February 08, 2005 1:41 PM To: Matt Cooper; stefans@microsoft.com Cc: ietf-pkix@imc.org Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Matt: Now I understand the issue. Sorry it took so long for me to understand the comment. FALSE. I expect the server to store a binary .cer and .p7c file. The only MIME encoding will be applied by the transport protocol. HTTP will MIME encode. FTP will not. Russ At 12:27 PM 2/7/2005, Matt Cooper wrote: >Russ, > >TRUE|FALSE: On the server, you intend for the certificate file (stored >TRUE|on >the server's hard disk) to be MIME encoded. > >The question has nothing to do with HTTP. It could be FTP or NFS for >all it matters. What the draft says (to me at least) is that you are >supposed to MIME encode the data *BEFORE* the protocol encoding ever enters the picture. >This results in the client receiving a MIME encoded file regardless of >transport protocol. > >Best Regards, > >Matt Cooper >Orion Security Solutions >1489 Chain Bridge Road, Suite 300 >McLean, Virginia 22101 >(Mob) 703.981.2269 >(Off) 703.917.0060 x. 30 >(Fax) 703.917.0260 >Visit our website! >http://www.orionsec.com > > >-----Original Message----- >From: Russ Housley [mailto:housley@vigilsec.com] >Sent: Friday, February 04, 2005 8:21 AM >To: Matt Cooper; stefans@microsoft.com >Cc: ietf-pkix@imc.org >Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > >Matt: > >MIME supports many encoding types, including binary and base64. I >think that binary will be used in this case, but base64 and other >encodings are not prohibited. > >We should probably say that binary encoding MUST be supported. > >Russ > >At 06:29 PM 2/3/2005, Matt Cooper wrote: > > >Perhaps I was not clear either. I didn't think you were attempting > >to eliminate the HTTP MIME encoding. And believe me, I'm the first > >one to cheer having a naming convention for this purpose! > > > >Are you saying that your intent was only to apply the MIME encoding > >to how the HTTP server should be serving up the files to the client? > >Not trying to be difficult, I just want to be sure we're on the same > >page as the text reads quite differently to me. > > > >It reads (to me) that you intend for the hosted file to be MIME > >encoded rather than binary. Specifically, as [A MIME encoded > >application/pkcs7-mime "certs-only" file as specified in RFC 2797 > >[CMC]"]. When I read this it indicated to me that I am supposed to > >MIME encode the PKCS#7 and name the resultant MIME text file with a > >.p7c extension. E.g., place the following file content on my web server: > > > >MIME-Version: 1.0 > >Content-Type: application/pkcs7-mime; > > smime-type="certs-only"; > > name="cacerts.p7c" > >Content-Transfer-Encoding: base64 > >Content-Disposition: attachment; > > filename="cacerts.p7c" > > > >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg > >g/ > >+Q29u > >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X > >05 > >leHRQ > >... > >BhcnA=== > > > > > >Matt Cooper > >Orion Security Solutions > >1489 Chain Bridge Road, Suite 300 > >McLean, Virginia 22101 > >(Mob) 703.981.2269 > >(Off) 703.917.0060 x. 30 > >(Fax) 703.917.0260 > >Visit our website! > >http://www.orionsec.com > > > > > >________________________________ > > > >From: Russ Housley [mailto:housley@vigilsec.com] > >Sent: Thursday, February 03, 2005 3:39 PM > >To: Matt Cooper; stefans@microsoft.com > >Cc: ietf-pkix@imc.org > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments > > > > > >Matt: > > > >We were not clear. We did not intend to eliminate the MIME encoding > >which is normally present with HTTP. The MIME types are specified in > >the referenced documents, I believe. Rather, we were also stating a > >naming convention for the files that are obtained. > > > >Russ > > > >At 03:15 PM 2/3/2005, Matt Cooper wrote: > > > > > > First, I'd like to say I'm happy to see this come out, this > >is a needed addition for CRLs. > > > > All my comments refer to the following snippet extracted > >from the draft > > ( > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt > > ): > > > > ===begin=== > > When the http scheme is specified, the URI MUST point to a > > certificate file. The certificate file MUST contain > >either a single > > DER encoded certificate (indicated by the .cer file > >extension) >or > > contain a certification path (indicated by the .p7c file > >extension): > > > > .cer A single DER encoded certificate as specified in > > RFC 2585 [PKIX-CERT]. > > > > .p7c A MIME encoded application/pkcs7-mime "certs-only" >file > > as specified in RFC 2797 [CMC]. > > ===end=== > > > > Unless this has been required in another document that I am > >unaware of, we should use not use "MIME encoded" for this purpose for > >the following > >reasons: > > 1. It creates burden on the client. Why should the client > >need a MIME decoder to verify a CRL? > > 2. It creates burden for CA's and CA operators. They may > >have to learn how to manually encode a PKCS#7 in a MIME structure if > >their CA does not output this for them. This is error prone and may > >lead to >problems. > > 3. Clients must handle one case as binary and the other case > > as >text > > 4. Web servers already return MIME types for data; another > >MIME layer is not needed > > > > It is not too much to expect that the relying party software > >can distinguish between a binary cert and a binary p7c file. (For > >example, MS CAPI already does this for AIA) However, to make life > >easier for the client, could we throw in appropriate use of MIME > >types on >the web server? > >Perhaps something like this: > > > > "HTTP server implementations accessed via the URI SHOULD use > >the appropriate MIME content-type for the certificate file. > >Specifically, the HTTP server SHOULD return the content-type > >application/pkix-cert for a single DER encoded certificate and > >application/pkcs7-mime for a certs-only PKCS#7. Consuming clients > >SHOULD use the MIME type as a hint, but should not depend solely on > >the presence of the correct MIME type in the server response." > > > > Calling for the contents of the p7c to be "a certification > >path" is too restrictive in my mind. It would be better to leave > >this wide open and say something like "contain one or more > >certificates that may be helpful to the relying party." This leaves > >it up to the implementer to put in any certificates that may be > >useful for path construction regardless of whether we have common > >trusted roots. (They may also wish to not include the entire path, > >but instead only the CRL signer cert, which then has another AIA in > >it.) > > > > Suggest rewording the text something like this : > > > > When the HTTP scheme is specified, the URI MUST point to a > >certificate file. The certificate file MUST be either a single binary > >DER encoded certificate (indicated by the .cer file extension) or a > >single binary DER encoded certs-only PKCS#7 file (indicated by the > >.p7c file > >extension) containing one or more certificates that may be helpful to > >the relying party. > > > > > > Matt Cooper > > Orion Security Solutions > > 1489 Chain Bridge Road, Suite 300 > > McLean, Virginia 22101 > > (Mob) 703.981.2269 > > (Off) 703.917.0060 x. 30 > > (Fax) 703.917.0260 > > Visit our website! > > http://www.orionsec.com > > > > From owner-ietf-pkix Tue Feb 8 10:41:48 2005 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 j18Ifmob028053; Tue, 8 Feb 2005 10:41:48 -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 j18IfmVn028052; Tue, 8 Feb 2005 10:41:48 -0800 (PST) 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 j18IflDa028040 for ; Tue, 8 Feb 2005 10:41:47 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 9173 invoked by uid 0); 8 Feb 2005 18:41:36 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.128.119) by woodstock.binhost.com with SMTP; 8 Feb 2005 18:41:36 -0000 Message-Id: <6.2.0.14.2.20050208131630.06239290@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Feb 2005 13:41:22 -0500 To: "Matt Cooper" , stefans@microsoft.com From: Russ Housley Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Cc: ietf-pkix@imc.org In-Reply-To: <200502071728.j17HSBmY026352@host13.websitesource.com> References: <6.2.0.14.2.20050204081930.05a73950@mail.binhost.com> <200502071728.j17HSBmY026352@host13.websitesource.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: Matt: Now I understand the issue. Sorry it took so long for me to understand the comment. FALSE. I expect the server to store a binary .cer and .p7c file. The only MIME encoding will be applied by the transport protocol. HTTP will MIME encode. FTP will not. Russ At 12:27 PM 2/7/2005, Matt Cooper wrote: >Russ, > >TRUE|FALSE: On the server, you intend for the certificate file (stored on >the server's hard disk) to be MIME encoded. > >The question has nothing to do with HTTP. It could be FTP or NFS for all it >matters. What the draft says (to me at least) is that you are supposed to >MIME encode the data *BEFORE* the protocol encoding ever enters the picture. >This results in the client receiving a MIME encoded file regardless of >transport protocol. > >Best Regards, > >Matt Cooper >Orion Security Solutions >1489 Chain Bridge Road, Suite 300 >McLean, Virginia 22101 >(Mob) 703.981.2269 >(Off) 703.917.0060 x. 30 >(Fax) 703.917.0260 >Visit our website! >http://www.orionsec.com > > >-----Original Message----- >From: Russ Housley [mailto:housley@vigilsec.com] >Sent: Friday, February 04, 2005 8:21 AM >To: Matt Cooper; stefans@microsoft.com >Cc: ietf-pkix@imc.org >Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > >Matt: > >MIME supports many encoding types, including binary and base64. I think >that binary will be used in this case, but base64 and other encodings are >not prohibited. > >We should probably say that binary encoding MUST be supported. > >Russ > >At 06:29 PM 2/3/2005, Matt Cooper wrote: > > >Perhaps I was not clear either. I didn't think you were attempting to > >eliminate the HTTP MIME encoding. And believe me, I'm the first one to > >cheer having a naming convention for this purpose! > > > >Are you saying that your intent was only to apply the MIME encoding to > >how the HTTP server should be serving up the files to the client? Not > >trying to be difficult, I just want to be sure we're on the same page > >as the text reads quite differently to me. > > > >It reads (to me) that you intend for the hosted file to be MIME encoded > >rather than binary. Specifically, as [A MIME encoded > >application/pkcs7-mime "certs-only" file as specified in RFC 2797 > >[CMC]"]. When I read this it indicated to me that I am supposed to > >MIME encode the PKCS#7 and name the resultant MIME text file with a > >.p7c extension. E.g., place the following file content on my web server: > > > >MIME-Version: 1.0 > >Content-Type: application/pkcs7-mime; > > smime-type="certs-only"; > > name="cacerts.p7c" > >Content-Transfer-Encoding: base64 > >Content-Disposition: attachment; > > filename="cacerts.p7c" > > > >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/ > >+Q29u > >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05 > >leHRQ > >... > >BhcnA=== > > > > > >Matt Cooper > >Orion Security Solutions > >1489 Chain Bridge Road, Suite 300 > >McLean, Virginia 22101 > >(Mob) 703.981.2269 > >(Off) 703.917.0060 x. 30 > >(Fax) 703.917.0260 > >Visit our website! > >http://www.orionsec.com > > > > > >________________________________ > > > >From: Russ Housley [mailto:housley@vigilsec.com] > >Sent: Thursday, February 03, 2005 3:39 PM > >To: Matt Cooper; stefans@microsoft.com > >Cc: ietf-pkix@imc.org > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments > > > > > >Matt: > > > >We were not clear. We did not intend to eliminate the MIME encoding > >which is normally present with HTTP. The MIME types are specified in > >the referenced documents, I believe. Rather, we were also stating a > >naming convention for the files that are obtained. > > > >Russ > > > >At 03:15 PM 2/3/2005, Matt Cooper wrote: > > > > > > First, I'd like to say I'm happy to see this come out, this is > >a needed addition for CRLs. > > > > All my comments refer to the following snippet extracted from > >the draft > > ( > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt > > ): > > > > ===begin=== > > When the http scheme is specified, the URI MUST point to a > > certificate file. The certificate file MUST contain either > >a single > > DER encoded certificate (indicated by the .cer file extension) >or > > contain a certification path (indicated by the .p7c file > >extension): > > > > .cer A single DER encoded certificate as specified in > > RFC 2585 [PKIX-CERT]. > > > > .p7c A MIME encoded application/pkcs7-mime "certs-only" >file > > as specified in RFC 2797 [CMC]. > > ===end=== > > > > Unless this has been required in another document that I am > >unaware of, we should use not use "MIME encoded" for this purpose for > >the following > >reasons: > > 1. It creates burden on the client. Why should the client > >need a MIME decoder to verify a CRL? > > 2. It creates burden for CA's and CA operators. They may have > >to learn how to manually encode a PKCS#7 in a MIME structure if their > >CA does not output this for them. This is error prone and may lead to >problems. > > 3. Clients must handle one case as binary and the other case as >text > > 4. Web servers already return MIME types for data; another > >MIME layer is not needed > > > > It is not too much to expect that the relying party software > >can distinguish between a binary cert and a binary p7c file. (For > >example, MS CAPI already does this for AIA) However, to make life > >easier for the client, could we throw in appropriate use of MIME types on >the web server? > >Perhaps something like this: > > > > "HTTP server implementations accessed via the URI SHOULD use > >the appropriate MIME content-type for the certificate file. > >Specifically, the HTTP server SHOULD return the content-type > >application/pkix-cert for a single DER encoded certificate and > >application/pkcs7-mime for a certs-only PKCS#7. Consuming clients > >SHOULD use the MIME type as a hint, but should not depend solely on the > >presence of the correct MIME type in the server response." > > > > Calling for the contents of the p7c to be "a certification > >path" is too restrictive in my mind. It would be better to leave this > >wide open and say something like "contain one or more certificates that > >may be helpful to the relying party." This leaves it up to the > >implementer to put in any certificates that may be useful for path > >construction regardless of whether we have common trusted roots. (They > >may also wish to not include the entire path, but instead only the CRL > >signer cert, which then has another AIA in > >it.) > > > > Suggest rewording the text something like this : > > > > When the HTTP scheme is specified, the URI MUST point to a > >certificate file. The certificate file MUST be either a single binary > >DER encoded certificate (indicated by the .cer file extension) or a > >single binary DER encoded certs-only PKCS#7 file (indicated by the .p7c > >file > >extension) containing one or more certificates that may be helpful to > >the relying party. > > > > > > Matt Cooper > > Orion Security Solutions > > 1489 Chain Bridge Road, Suite 300 > > McLean, Virginia 22101 > > (Mob) 703.981.2269 > > (Off) 703.917.0060 x. 30 > > (Fax) 703.917.0260 > > Visit our website! > > http://www.orionsec.com > > > > From owner-ietf-pkix Tue Feb 8 11:17:33 2005 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 j18JHWs4030410; Tue, 8 Feb 2005 11:17:32 -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 j18JHWQn030409; Tue, 8 Feb 2005 11:17:32 -0800 (PST) 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 j18JHV8G030397 for ; Tue, 8 Feb 2005 11:17:31 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 19:17:26 +0000 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: draft-ietf-pkix-crlaia-00.txt comments Date: Tue, 8 Feb 2005 19:17:20 -0000 Message-ID: <0C3042E92D8A714783E2C44AB9936E1D019BCFD1@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-crlaia-00.txt comments thread-index: AcUODdTzr6d8YJ+YShK0qLy6m4+QfQAACXaQAAEnVSA= From: "Stefan Santesson" To: "Matt Cooper" , "Russ Housley" Cc: X-OriginalArrivalTime: 08 Feb 2005 19:17:26.0084 (UTC) FILETIME=[D2EC7840:01C50E12] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18JHV8G030404 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Matt, Do you have any proposed wording? Feel free to make a suggestion. Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: Matt Cooper [mailto:mcooper@orionsec.com] > Sent: den 8 februari 2005 19:50 > To: 'Russ Housley'; Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > I knew we would get to the same page eventually. :) > > I'm glad to hear the answer is negative. I, and several others I have > spoken > to, took the text in the draft to indicate this extra MIME encoding was > the > proposed requirement. So, I think we simply need to reword that section to > be very clear on this point. > > Best Regards, > > Matt Cooper > Orion Security Solutions > 1489 Chain Bridge Road, Suite 300 > McLean, Virginia 22101 > (Mob) 703.981.2269 > (Off) 703.917.0060 x. 30 > (Fax) 703.917.0260 > Visit our website! > http://www.orionsec.com > > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Tuesday, February 08, 2005 1:41 PM > To: Matt Cooper; stefans@microsoft.com > Cc: ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > Matt: > > Now I understand the issue. Sorry it took so long for me to understand > the > comment. > > FALSE. > > I expect the server to store a binary .cer and .p7c file. The only MIME > encoding will be applied by the transport protocol. HTTP will MIME > encode. > FTP will not. > > Russ > > At 12:27 PM 2/7/2005, Matt Cooper wrote: > >Russ, > > > >TRUE|FALSE: On the server, you intend for the certificate file (stored > >TRUE|on > >the server's hard disk) to be MIME encoded. > > > >The question has nothing to do with HTTP. It could be FTP or NFS for > >all it matters. What the draft says (to me at least) is that you are > >supposed to MIME encode the data *BEFORE* the protocol encoding ever > enters > the picture. > >This results in the client receiving a MIME encoded file regardless of > >transport protocol. > > > >Best Regards, > > > >Matt Cooper > >Orion Security Solutions > >1489 Chain Bridge Road, Suite 300 > >McLean, Virginia 22101 > >(Mob) 703.981.2269 > >(Off) 703.917.0060 x. 30 > >(Fax) 703.917.0260 > >Visit our website! > >http://www.orionsec.com > > > > > >-----Original Message----- > >From: Russ Housley [mailto:housley@vigilsec.com] > >Sent: Friday, February 04, 2005 8:21 AM > >To: Matt Cooper; stefans@microsoft.com > >Cc: ietf-pkix@imc.org > >Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > > >Matt: > > > >MIME supports many encoding types, including binary and base64. I > >think that binary will be used in this case, but base64 and other > >encodings are not prohibited. > > > >We should probably say that binary encoding MUST be supported. > > > >Russ > > > >At 06:29 PM 2/3/2005, Matt Cooper wrote: > > > > >Perhaps I was not clear either. I didn't think you were attempting > > >to eliminate the HTTP MIME encoding. And believe me, I'm the first > > >one to cheer having a naming convention for this purpose! > > > > > >Are you saying that your intent was only to apply the MIME encoding > > >to how the HTTP server should be serving up the files to the client? > > >Not trying to be difficult, I just want to be sure we're on the same > > >page as the text reads quite differently to me. > > > > > >It reads (to me) that you intend for the hosted file to be MIME > > >encoded rather than binary. Specifically, as [A MIME encoded > > >application/pkcs7-mime "certs-only" file as specified in RFC 2797 > > >[CMC]"]. When I read this it indicated to me that I am supposed to > > >MIME encode the PKCS#7 and name the resultant MIME text file with a > > >.p7c extension. E.g., place the following file content on my web > server: > > > > > >MIME-Version: 1.0 > > >Content-Type: application/pkcs7-mime; > > > smime-type="certs-only"; > > > name="cacerts.p7c" > > >Content-Transfer-Encoding: base64 > > >Content-Disposition: attachment; > > > filename="cacerts.p7c" > > > > > >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg > > >g/ > > >+Q29u > > >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X > > >05 > > >leHRQ > > >... > > >BhcnA=== > > > > > > > > >Matt Cooper > > >Orion Security Solutions > > >1489 Chain Bridge Road, Suite 300 > > >McLean, Virginia 22101 > > >(Mob) 703.981.2269 > > >(Off) 703.917.0060 x. 30 > > >(Fax) 703.917.0260 > > >Visit our website! > > >http://www.orionsec.com > > > > > > > > >________________________________ > > > > > >From: Russ Housley [mailto:housley@vigilsec.com] > > >Sent: Thursday, February 03, 2005 3:39 PM > > >To: Matt Cooper; stefans@microsoft.com > > >Cc: ietf-pkix@imc.org > > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments > > > > > > > > >Matt: > > > > > >We were not clear. We did not intend to eliminate the MIME encoding > > >which is normally present with HTTP. The MIME types are specified in > > >the referenced documents, I believe. Rather, we were also stating a > > >naming convention for the files that are obtained. > > > > > >Russ > > > > > >At 03:15 PM 2/3/2005, Matt Cooper wrote: > > > > > > > > > First, I'd like to say I'm happy to see this come out, this > > >is a needed addition for CRLs. > > > > > > All my comments refer to the following snippet extracted > > >from the draft > > > ( > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt > > > ): > > > > > > ===begin=== > > > When the http scheme is specified, the URI MUST point to a > > > certificate file. The certificate file MUST contain > > >either a single > > > DER encoded certificate (indicated by the .cer file > > >extension) > >or > > > contain a certification path (indicated by the .p7c file > > >extension): > > > > > > .cer A single DER encoded certificate as specified in > > > RFC 2585 [PKIX-CERT]. > > > > > > .p7c A MIME encoded application/pkcs7-mime "certs- > only" > >file > > > as specified in RFC 2797 [CMC]. > > > ===end=== > > > > > > Unless this has been required in another document that I am > > >unaware of, we should use not use "MIME encoded" for this purpose for > > >the following > > >reasons: > > > 1. It creates burden on the client. Why should the client > > >need a MIME decoder to verify a CRL? > > > 2. It creates burden for CA's and CA operators. They may > > >have to learn how to manually encode a PKCS#7 in a MIME structure if > > >their CA does not output this for them. This is error prone and may > > >lead to > >problems. > > > 3. Clients must handle one case as binary and the other case > > > as > >text > > > 4. Web servers already return MIME types for data; another > > >MIME layer is not needed > > > > > > It is not too much to expect that the relying party software > > >can distinguish between a binary cert and a binary p7c file. (For > > >example, MS CAPI already does this for AIA) However, to make life > > >easier for the client, could we throw in appropriate use of MIME > > >types on > >the web server? > > >Perhaps something like this: > > > > > > "HTTP server implementations accessed via the URI SHOULD use > > >the appropriate MIME content-type for the certificate file. > > >Specifically, the HTTP server SHOULD return the content-type > > >application/pkix-cert for a single DER encoded certificate and > > >application/pkcs7-mime for a certs-only PKCS#7. Consuming clients > > >SHOULD use the MIME type as a hint, but should not depend solely on > > >the presence of the correct MIME type in the server response." > > > > > > Calling for the contents of the p7c to be "a certification > > >path" is too restrictive in my mind. It would be better to leave > > >this wide open and say something like "contain one or more > > >certificates that may be helpful to the relying party." This leaves > > >it up to the implementer to put in any certificates that may be > > >useful for path construction regardless of whether we have common > > >trusted roots. (They may also wish to not include the entire path, > > >but instead only the CRL signer cert, which then has another AIA in > > >it.) > > > > > > Suggest rewording the text something like this : > > > > > > When the HTTP scheme is specified, the URI MUST point to a > > >certificate file. The certificate file MUST be either a single binary > > >DER encoded certificate (indicated by the .cer file extension) or a > > >single binary DER encoded certs-only PKCS#7 file (indicated by the > > >.p7c file > > >extension) containing one or more certificates that may be helpful to > > >the relying party. > > > > > > > > > Matt Cooper > > > Orion Security Solutions > > > 1489 Chain Bridge Road, Suite 300 > > > McLean, Virginia 22101 > > > (Mob) 703.981.2269 > > > (Off) 703.917.0060 x. 30 > > > (Fax) 703.917.0260 > > > Visit our website! > > > http://www.orionsec.com > > > > > > From owner-ietf-pkix Tue Feb 8 11:42:09 2005 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 j18Jg9ff032196; Tue, 8 Feb 2005 11:42:09 -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 j18Jg9lb032195; Tue, 8 Feb 2005 11:42:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Jg8aP032176 for ; Tue, 8 Feb 2005 11:42:08 -0800 (PST) (envelope-from trevorf@exchange.microsoft.com) Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 11:41:55 -0800 Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Tue, 8 Feb 2005 11:41:45 -0800 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 11:41:52 -0800 Received: from df-courage-msg.exchange.corp.microsoft.com ([157.54.4.14]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 11:41:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7408.0 X-OriginalArrivalTime: 08 Feb 2005 19:41:57.0922 (UTC) FILETIME=[40352020:01C50E16] Subject: FW: SCVP 16 comments Date: Tue, 8 Feb 2005 11:41:54 -0800 Message-ID: <7AC1A67CDDE6934C8D6142D7CD6952640CE188@df-courage-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCVP 16 comments Thread-Index: AcTpahOp8ttidUfRQ0GpWe4rjEFaeAkqId9wAADlVaA= From: "Trevor Freeman" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18Jg8aP032190 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * -----Original Message----- * From: Trevor Freeman * Sent: Tuesday, February 08, 2005 11:36 AM * To: 'Wen-Cheng Wang' * Subject: RE: SCVP 16 comments * * * Hi Wen-Cheng, * Thanks for these comments. SCVP 17 should be shortly posted * See below for answers * Trevor * * -----Original Message----- * * From: Wen-Cheng Wang [mailto:wcwang@cht.com.tw] * * Sent: Thursday, December 23, 2004 7:40 PM * * To: Trevor Freeman * * Subject: Fw: SCVP 16 comments * * * * Trevor, * * * * I would like to remind you that you have not yet responded * * to my comments on SCVP ID 16. * * * * Wen-Cheng Wang * * * * ----- Original Message ----- * * From: "Wen-Cheng Wang" * * To: * * Sent: Thursday, December 16, 2004 1:13 AM * * Subject: SCVP 16 comments * * * * * * > * * > Here are my comments on SCVP ID 16. * * > * * > 1. Page 11: * * > * * > The responseRefHash, responseValidationPolByRef, and * * > signResponse items are now grouped into the the * * > responseFlags item. * * > * * > Therefore, the sentence: * * > * * > " A query * * > MUST contain a sequence of one or more queriedCerts items as well * * > as one checks, one wantBack and one validationPolicy item; and a * * > query MAY also contain responseRefHash, responseValidationPolByRef, * * > signResponse, serverContextInfo, validationTime, intermediateCerts, * * > revInfos, producedAt, and queryExtensions items." * * > * * > should be changed to: * * > * * > " A query * * > MUST contain a sequence of one or more queriedCerts items as well * * > as one checks, one wantBack and one validationPolicy item; and a * * > query MAY also contain responseFlags, serverContextInfo, * * > validationTime, intermediateCerts, revInfos, producedAt, and * * > queryExtensions items." * [TF] Fixed * * > * * > 2. Page 12: * * > * * > For the same reason, the sentence: * * > * * > " The requestRefHash, responseValidationPolByRef * * > and signResponse items allow the client to request optional * * > features for the response." * * > * * > should be changed to: * * > * * > " The responseFlags item allows the client to request optional * * > features for the response." * [TF] Fixed * * > * * > 3. Page 13: * * > * * > When a client want to build/validate/do revocation check on the * * > certification path for the AC issuer, it is not clear that whether * * > the reference to the AC itself or the AC issuer's PKC need to be * * > send to the server? * * > * * > Also, there are no OIDs defined for * * > * * > - Build a certification path to a trust anchor; * * > - Build a certification path to a trust anchor for the AC * * > issuer * [TF] the following OID are already defined * id-stc-build-pkc-path: Build a certification path to a trust anchor; * id-stc-build-status-checked-aa-path: Build a validated certification path * to a trust anchor for the AC issuer and perform * * > * * > And I think the following statement is not correct. * * > * * > "Also, building a validated certification path does * * > not imply revocation status checks." * * > * * > If the server does not perform revocation status checks, * * > how does it know the certification path is valid or not? * * > * * > 4. Page 17: * * > The following paragraph should not appear in section 3.1.4.1: * * > * * > " SCVP servers SHOULD support serverContextInfo. SCVP clients MAY * * > support serverContextInfo" * [TF] Fixed * * > * * > 5. Page 18: * * > * * > The following paragraph should be moved to section 3.1.4.1: * * > * * > " Neither the clients nor server MUST dereference the URI during SCVP * * > request processing. The URI is simply used as a reference for the * * > validation policy. Clients and server MAY dereference the URI as * * > part of configuration." * [TF] Fixed * * > * * > 6. Page 19, 20, 21, 22: * * > OID names are not consistent. The following substutions are * * > recommended: * * > * * > id-bvae-notYetValid -> id-bvae-not-yet-valid * * > * * > id-bvae-wrong-Anchor -> id-bvae-wrong-anchor * * > * * > id-bvae-invalid-Key-Usage -> id-bvae-invalid-key-usage * * > * * > id-bvae-invalid-Purpose -> id-bvae-invalid-purpose * * > * * > id-bvae-invalid-Policy -> id-bvae-invalid-cert-policy * * > * * > id-bvae-invalid-Name -> id-bvae-invalid-name * * > * * > id-bvae-invalid-Entity -> id-bvae-invalid-entity * * > * * > id-bvae-invalid-Depth -> id-bvae-invalid-path-length * * > * * > id-bvae-invalidPurpose -> id-bvae-invalid-purpose * * > * * > id-bvae-invalidCertPolicy -> id-bvae-invalid-cert-policy * * > * * > id-bvae-invalidName -> id-bvae-invalid-name * * > * * > id-bvae-invalidEntity -> id-bvae-invalid-entity * * > * * > id-bvae-invalidPathDepth -> id-bvae-invalid-path-length * * > * * > id-nvae-unknown-pupose -> id-nvae-unknown-purpose * * > * * > id-nvae-nameMismatch -> id-nvae-name-mismatch * * > * * > id-nvae-noCertName -> id-nvae-no-name * * > * * > id-nvae-unknownPupose -> id-nvae-unknown-purpose * * > * * > id-nvae-badName -> id-nvae-bad-name * * > * * > id-nvae-badNameType -> id-nvae-bad-name-type * * > * * > id-nvae-mixedNames -> id-nvae-mixed-names * [TF] Fixed * * > * * > 7. Page 22: * * > * * > The following paragraph should not appear in section 3.1.5.2.4: * * > * * > " The userPolicySet item specifies a list of policy identifiers that * * > the SCVP server MUST use when forming and validating a certificate * * > If certPolicies is not specified, then any-policy MUST be used." * [TF] Fixed * * > * * > 8. Page 64: * * > * * > In the last paragraph of page 64: * * > * * > "serverContextInformation" should be "serverContextInfo". * [TF] Fixed * * > * * > * * > Wen-Cheng Wang * * > From owner-ietf-pkix Tue Feb 8 11:38:48 2005 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 j18Jcmqs031961; Tue, 8 Feb 2005 11:38:48 -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 j18JcmFM031960; Tue, 8 Feb 2005 11:38:48 -0800 (PST) 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 j18Jclac031949 for ; Tue, 8 Feb 2005 11:38:47 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 8 Feb 2005 19:38:39 +0000 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt Date: Tue, 8 Feb 2005 19:38:50 -0000 Message-ID: <0C3042E92D8A714783E2C44AB9936E1D019BCFD5@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt thread-index: AcUODLjPSAmJJorSQ2mbUWsc2kofggABiRpA From: "Stefan Santesson" To: "Peter Sylvester" , Cc: X-OriginalArrivalTime: 08 Feb 2005 19:38:39.0542 (UTC) FILETIME=[C9F6BD60:01C50E15] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18Jcmac031955 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Thanks for the comments. Comments in-line; Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] > Sent: den 8 februari 2005 19:33 > To: housley@vigilsec.com; Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > > > - The abstract says that the defined extension has the same syntax > as for certificats. > This seems slightly misleading for me since the texts also defines > data formats, and does not reuse the existing id-ad-caIssuers. > [Stefan] AIA in Certificates and in CRLs share the same ASN.1 syntax even if we choose to populate the extension with different data. I think that is perfectly fine and true for many extensions. I.e. when you use an extension to serve purpose A you may fill that extension with different parameters and data than if the extension serve purpose B. Yet the same extension OID is maintained for both cases and the same syntax is used. > - The id-ad-caIssuers definition in 3280 defines the usage of ftp, http, > ldap (but fails together with operationl protocols to completely > define the data formats for http and ftp. > [Stefan] This is the initial suggestion but it is debatable. We started with the minimum set to see whether there was a strong need for anything else that was not included in version 0. Do you see a strong reason to expand the proposed set of schemas? If yes, then why? > I am not sure that p7c in the current text is really intended to have > another mime encapsulation (as mentioned by D.C.), but if so, what > would this be good for? [Stefan] Hopefully this has been sorted out in recent exchange on the topic. > > - Shouldn't the data format be met into an updated operational > protocols? This would also allow to say a little bit more > about what an http client is supposed to implement as a minimal > profile for http. > [Stefan] What we ant to do is to describe what is already widely deployed for AIA. This is what the text tries to capture. If the text fails to do that, then we are more than happy to receive suggested improvements to the text. > - It doesn't seem extremely useful to me to have several different > formats to access to certificat list via http, on for certificats > in general (done by Peter Gutmann's text) and another in this > text. [Stefan] This is the fine balance. We want to limit the set as much as possible but still support current deployments that have been deployed in conformity with RFC 3280 in good faith. There is simply too much use of the .p7c file format to ignore it and declare it non-conformant. There is also the aspect of efficiency, where the p7c format may reveal a complete chain. > > - Using a suffix .cer or .p7c to determine the content type behind > an http uri seems not ok to me, for this AFAIK, http uses mime types. [Stefan] I think/hope this one has been sorted out. > > - Yes, I know, we might end with a debate whether a list of certs > can be provided best as: > > - SEQUENCE OF Certificate > - a p7c cert only PKCS7/CMS file > - a mime multipart containing several individual certificats > - same result as with ldap... > > Well, so be it, ==> 'n' mime types (defined with their file suffix) > a an http client can set a list of acceptable mime types, and the server > must return the data in that way. Using undefined length encoding, > the first and the second simply mean to encode a fixed prefix and > suffix, > the third is a bit more complicated, etc. > [Stefan] We all agree that the information is stored in raw format and that MIME encoding is an issue for the transport protocol. Is there anything more to say about this? > Peter > > > > > > > > > > > From owner-ietf-pkix Tue Feb 8 12:39:38 2005 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 j18KdcZh036520; Tue, 8 Feb 2005 12:39:38 -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 j18Kdcg4036519; Tue, 8 Feb 2005 12:39:38 -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 j18Kdb2n036511 for ; Tue, 8 Feb 2005 12:39:38 -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 PAA15200; Tue, 8 Feb 2005 15:39:35 -0500 (EST) Message-Id: <200502082039.PAA15200@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-gost-cppk-02.txt Date: Tue, 08 Feb 2005 15:39:35 -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 : Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. Author(s) : S. Leontiev, D. Shefanovskij Filename : draft-ietf-pkix-gost-cppk-02.txt Pages : 19 Date : 2005-2-8 This document describes identifiers and appropriate parameters for the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, and also ASN.1 encoding scheme for digital signatures and public keys, used in Internet X.509 Public Key Infrastructure (PKI). This specification extends [RFC3279], 'Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' and, correspondingly, [RFC3280], 'Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile'. All implementations of this specification MUST also satisfy the requirements of [RFC3280]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-02.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-gost-cppk-02.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-gost-cppk-02.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-2-8160509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-gost-cppk-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-gost-cppk-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-8160509.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Tue Feb 8 17:33:02 2005 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 j191X2Gf052285; Tue, 8 Feb 2005 17:33:02 -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 j191X2wp052284; Tue, 8 Feb 2005 17:33:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j191X1Jv052269 for ; Tue, 8 Feb 2005 17:33:01 -0800 (PST) (envelope-from mcooper@orionsec.com) Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j191WnmX026094; Tue, 8 Feb 2005 20:32:50 -0500 Message-Id: <200502090132.j191WnmX026094@host13.websitesource.com> From: "Matt Cooper" To: "'Stefan Santesson'" , "'Russ Housley'" Cc: Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Date: Tue, 8 Feb 2005 20:32:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUODdTzr6d8YJ+YShK0qLy6m4+QfQAACXaQAAEnVSAABGswMA== In-Reply-To: <0C3042E92D8A714783E2C44AB9936E1D019BCFD1@EUR-MSG-03.europe.corp.microsoft.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Stefan, One nit with regard to the wording - The way you have used "certificate file" makes it seem like a new term when I read it. Is this used in other docs to collectively describe multiple file types containing certificates? If no, I think you may want to find a different way to say this so it doesn't sound like new terminology, or, if not, should it be defined explicitly? Fairly minor point in any event. You can decide what to do with the above comment; I stuck with that terminology below. I was thinking something along these lines: ------- When the HTTP scheme is specified, the URI MUST specify the location of a certificate file. The certificate file MUST be either a single binary DER encoded certificate (indicated by the .cer file extension) file or a single binary DER encoded certs-only PKCS#7 [ref] file (indicated by the .p7c file extension) containing one or more certificates. HTTP server implementations accessed via the URI SHOULD use the appropriate MIME [ref] content-type for the certificate file. Specifically, the HTTP server SHOULD use the content-type application/pkix-cert [ref] for a single DER encoded certificate and application/pkcs7-mime [ref] for a certs-only PKCS#7. Consuming clients may use the MIME type and file extension as a hint to the file content, but should not depend solely on the presence of the correct MIME type or file extension in the server response. ------- Best Regards, Matt Cooper Orion Security Solutions 1489 Chain Bridge Road, Suite 300 McLean, Virginia 22101 (Mob) 703.981.2269 (Off) 703.917.0060 x. 30 (Fax) 703.917.0260 Visit our website! http://www.orionsec.com -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Tuesday, February 08, 2005 2:17 PM To: Matt Cooper; Russ Housley Cc: ietf-pkix@imc.org Subject: RE: draft-ietf-pkix-crlaia-00.txt comments Matt, Do you have any proposed wording? Feel free to make a suggestion. Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: Matt Cooper [mailto:mcooper@orionsec.com] > Sent: den 8 februari 2005 19:50 > To: 'Russ Housley'; Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > I knew we would get to the same page eventually. :) > > I'm glad to hear the answer is negative. I, and several others I have > spoken to, took the text in the draft to indicate this extra MIME > encoding was > the > proposed requirement. So, I think we simply need to reword that section to > be very clear on this point. > > Best Regards, > > Matt Cooper > Orion Security Solutions > 1489 Chain Bridge Road, Suite 300 > McLean, Virginia 22101 > (Mob) 703.981.2269 > (Off) 703.917.0060 x. 30 > (Fax) 703.917.0260 > Visit our website! > http://www.orionsec.com > > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Tuesday, February 08, 2005 1:41 PM > To: Matt Cooper; stefans@microsoft.com > Cc: ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > Matt: > > Now I understand the issue. Sorry it took so long for me to understand > the > comment. > > FALSE. > > I expect the server to store a binary .cer and .p7c file. The only MIME > encoding will be applied by the transport protocol. HTTP will MIME > encode. > FTP will not. > > Russ > > At 12:27 PM 2/7/2005, Matt Cooper wrote: > >Russ, > > > >TRUE|FALSE: On the server, you intend for the certificate file (stored > >TRUE|on > >the server's hard disk) to be MIME encoded. > > > >The question has nothing to do with HTTP. It could be FTP or NFS for > >all it matters. What the draft says (to me at least) is that you are > >supposed to MIME encode the data *BEFORE* the protocol encoding ever > enters > the picture. > >This results in the client receiving a MIME encoded file regardless of > >transport protocol. > > > >Best Regards, > > > >Matt Cooper > >Orion Security Solutions > >1489 Chain Bridge Road, Suite 300 > >McLean, Virginia 22101 > >(Mob) 703.981.2269 > >(Off) 703.917.0060 x. 30 > >(Fax) 703.917.0260 > >Visit our website! > >http://www.orionsec.com > > > > > >-----Original Message----- > >From: Russ Housley [mailto:housley@vigilsec.com] > >Sent: Friday, February 04, 2005 8:21 AM > >To: Matt Cooper; stefans@microsoft.com > >Cc: ietf-pkix@imc.org > >Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > > >Matt: > > > >MIME supports many encoding types, including binary and base64. I > >think that binary will be used in this case, but base64 and other > >encodings are not prohibited. > > > >We should probably say that binary encoding MUST be supported. > > > >Russ > > > >At 06:29 PM 2/3/2005, Matt Cooper wrote: > > > > >Perhaps I was not clear either. I didn't think you were attempting > > >to eliminate the HTTP MIME encoding. And believe me, I'm the first > > >one to cheer having a naming convention for this purpose! > > > > > >Are you saying that your intent was only to apply the MIME encoding > > >to how the HTTP server should be serving up the files to the client? > > >Not trying to be difficult, I just want to be sure we're on the same > > >page as the text reads quite differently to me. > > > > > >It reads (to me) that you intend for the hosted file to be MIME > > >encoded rather than binary. Specifically, as [A MIME encoded > > >application/pkcs7-mime "certs-only" file as specified in RFC 2797 > > >[CMC]"]. When I read this it indicated to me that I am supposed to > > >MIME encode the PKCS#7 and name the resultant MIME text file with a > > >.p7c extension. E.g., place the following file content on my web > server: > > > > > >MIME-Version: 1.0 > > >Content-Type: application/pkcs7-mime; > > > smime-type="certs-only"; > > > name="cacerts.p7c" > > >Content-Transfer-Encoding: base64 > > >Content-Disposition: attachment; > > > filename="cacerts.p7c" > > > > > >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg > > >g/ > > >+Q29u > > >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X > > >05 > > >leHRQ > > >... > > >BhcnA=== > > > > > > > > >Matt Cooper > > >Orion Security Solutions > > >1489 Chain Bridge Road, Suite 300 > > >McLean, Virginia 22101 > > >(Mob) 703.981.2269 > > >(Off) 703.917.0060 x. 30 > > >(Fax) 703.917.0260 > > >Visit our website! > > >http://www.orionsec.com > > > > > > > > >________________________________ > > > > > >From: Russ Housley [mailto:housley@vigilsec.com] > > >Sent: Thursday, February 03, 2005 3:39 PM > > >To: Matt Cooper; stefans@microsoft.com > > >Cc: ietf-pkix@imc.org > > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments > > > > > > > > >Matt: > > > > > >We were not clear. We did not intend to eliminate the MIME encoding > > >which is normally present with HTTP. The MIME types are specified in > > >the referenced documents, I believe. Rather, we were also stating a > > >naming convention for the files that are obtained. > > > > > >Russ > > > > > >At 03:15 PM 2/3/2005, Matt Cooper wrote: > > > > > > > > > First, I'd like to say I'm happy to see this come out, this > > >is a needed addition for CRLs. > > > > > > All my comments refer to the following snippet extracted > > >from the draft > > > ( > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt > > > ): > > > > > > ===begin=== > > > When the http scheme is specified, the URI MUST point to a > > > certificate file. The certificate file MUST contain > > >either a single > > > DER encoded certificate (indicated by the .cer file > > >extension) > >or > > > contain a certification path (indicated by the .p7c file > > >extension): > > > > > > .cer A single DER encoded certificate as specified in > > > RFC 2585 [PKIX-CERT]. > > > > > > .p7c A MIME encoded application/pkcs7-mime "certs- > only" > >file > > > as specified in RFC 2797 [CMC]. > > > ===end=== > > > > > > Unless this has been required in another document that I am > > >unaware of, we should use not use "MIME encoded" for this purpose for > > >the following > > >reasons: > > > 1. It creates burden on the client. Why should the client > > >need a MIME decoder to verify a CRL? > > > 2. It creates burden for CA's and CA operators. They may > > >have to learn how to manually encode a PKCS#7 in a MIME structure if > > >their CA does not output this for them. This is error prone and may > > >lead to > >problems. > > > 3. Clients must handle one case as binary and the other case > > > as > >text > > > 4. Web servers already return MIME types for data; another > > >MIME layer is not needed > > > > > > It is not too much to expect that the relying party software > > >can distinguish between a binary cert and a binary p7c file. (For > > >example, MS CAPI already does this for AIA) However, to make life > > >easier for the client, could we throw in appropriate use of MIME > > >types on > >the web server? > > >Perhaps something like this: > > > > > > "HTTP server implementations accessed via the URI SHOULD use > > >the appropriate MIME content-type for the certificate file. > > >Specifically, the HTTP server SHOULD return the content-type > > >application/pkix-cert for a single DER encoded certificate and > > >application/pkcs7-mime for a certs-only PKCS#7. Consuming clients > > >SHOULD use the MIME type as a hint, but should not depend solely on > > >the presence of the correct MIME type in the server response." > > > > > > Calling for the contents of the p7c to be "a certification > > >path" is too restrictive in my mind. It would be better to leave > > >this wide open and say something like "contain one or more > > >certificates that may be helpful to the relying party." This leaves > > >it up to the implementer to put in any certificates that may be > > >useful for path construction regardless of whether we have common > > >trusted roots. (They may also wish to not include the entire path, > > >but instead only the CRL signer cert, which then has another AIA in > > >it.) > > > > > > Suggest rewording the text something like this : > > > > > > When the HTTP scheme is specified, the URI MUST point to a > > >certificate file. The certificate file MUST be either a single binary > > >DER encoded certificate (indicated by the .cer file extension) or a > > >single binary DER encoded certs-only PKCS#7 file (indicated by the > > >.p7c file > > >extension) containing one or more certificates that may be helpful to > > >the relying party. > > > > > > > > > Matt Cooper > > > Orion Security Solutions > > > 1489 Chain Bridge Road, Suite 300 > > > McLean, Virginia 22101 > > > (Mob) 703.981.2269 > > > (Off) 703.917.0060 x. 30 > > > (Fax) 703.917.0260 > > > Visit our website! > > > http://www.orionsec.com > > > > > > From owner-ietf-pkix Wed Feb 9 01:58:47 2005 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 j199wlPZ061644; Wed, 9 Feb 2005 01:58:47 -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 j199wlpE061642; Wed, 9 Feb 2005 01:58:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nb2.stroeder.com (d5-175.dip.isp-service.de [83.121.5.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j199wfIF061487 for ; Wed, 9 Feb 2005 01:58:46 -0800 (PST) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id A48E6E075A; Wed, 9 Feb 2005 10:58:15 +0100 (CET) Received: from nb2.stroeder.com ([127.0.0.1]) by localhost (nb2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08767-04; Wed, 9 Feb 2005 10:58:14 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 1F3F5E059F; Wed, 9 Feb 2005 10:58:14 +0100 (CET) Message-ID: <4209DEB5.6090209@stroeder.com> Date: Wed, 09 Feb 2005 10:58:13 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Russ Housley Cc: Matt Cooper , stefans@microsoft.com, ietf-pkix@imc.org Subject: Re: draft-ietf-pkix-crlaia-00.txt comments References: <6.2.0.14.2.20050204081930.05a73950@mail.binhost.com> <200502071728.j17HSBmY026352@host13.websitesource.com> <6.2.0.14.2.20050208131630.06239290@mail.binhost.com> In-Reply-To: <6.2.0.14.2.20050208131630.06239290@mail.binhost.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at stroeder.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley wrote: > > I expect the server to store a binary .cer and .p7c file. The only > MIME encoding will be applied by the transport protocol. HTTP will > MIME encode. FTP will not. This should be made more clear in the text. I also interpreted it like Matt did. Ciao, Michael. -- Michael Ströder http://www.stroeder.com From owner-ietf-pkix Wed Feb 9 03:29:39 2005 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 j19BTc8M095219; Wed, 9 Feb 2005 03:29:38 -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 j19BTcRG095218; Wed, 9 Feb 2005 03:29:38 -0800 (PST) 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 j19BTbS4095182 for ; Wed, 9 Feb 2005 03:29:37 -0800 (PST) (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 j19BTXn02396; Wed, 9 Feb 2005 12:29:33 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 9 Feb 2005 12:29:33 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j19BTXi23307; Wed, 9 Feb 2005 12:29:33 +0100 (MET) Date: Wed, 9 Feb 2005 12:29:33 +0100 (MET) From: Peter Sylvester Message-Id: <200502091129.j19BTXi23307@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, stefans@microsoft.com Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt 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: Stefan, thanks for the answer, basically I see that there were no conceptual differences, and only some misunderstandings caused by the wordings. > [Stefan] AIA in Certificates and in CRLs share the same ASN.1 syntax > even if we choose to populate the extension with different data. I think > that is perfectly fine and true for many extensions. I.e. when you use > an extension to serve purpose A you may fill that extension with > different parameters and data than if the extension serve purpose B. Yet > the same extension OID is maintained for both cases and the same syntax > is used. It seems that with the clarification concerning the MIME encoding, my remarks does not have no longer a good ground. Nevertheless, I think that it important that when the same accessMethod oid is used, then the retrieval and presentation(encoding) of the data pointed to by the URI should be the same independantly of whether the access method is used in an AIA or a SIA of a certificate or a CRL or whather else beast. > > - The id-ad-caIssuers definition in 3280 defines the usage of ftp, > http, > > ldap (but fails together with operationl protocols to completely > > define the data formats for http and ftp. > > > > [Stefan] This is the initial suggestion but it is debatable. We started > with the minimum set to see whether there was a strong need for anything > else that was not included in version 0. Do you see a strong reason to > expand the proposed set of schemas? If yes, then why? This issue is not orthogonal: - The operational protocols are not complete, only single certs can be retrieved with http and ftp, since there is no other spec., only some undocumented practice. - I am not sure whether FTP is really a necessary goal, in any case, the protocol is difficult to implement or to be profiled, etc. I suggest that either in 3280 or in operational protocols one should clarify the data format with multiple certificates, define the mime types etc. (In the mean time you can put an appendix in the AIA text to remind this, this was done with the SIA in 3161 at some time). In a normative way one should reference operational protocols, and, maybe profile it, i.e. saying the ftp is not recommended, in whatever way you want it. Or, clients SHOULD support ldap AND http, and MUST support one of them at least? .. > > I am not sure that p7c in the current text is really intended to > have > > another mime encapsulation (as mentioned by D.C.), but if so, what > > would this be good for? > > [Stefan] Hopefully this has been sorted out in recent exchange on the > topic. Yes. > > - Shouldn't the data format be met into an updated operational > > protocols? This would also allow to say a little bit more > > about what an http client is supposed to implement as a minimal > > profile for http. > > > > [Stefan] What we ant to do is to describe what is already widely > deployed for AIA. This is what the text tries to capture. If the text > fails to do that, then we are more than happy to receive suggested > improvements to the text. I'd say, not for AIA, but for whatever 'accessMethod' to uris that have certs or lists of certs. You are not exactly responding to the question: There is something in between TCP and the data. One can just name this thingy 'http', but still there are many options to mention, should a 'lightweight' client be able to follow redirections etc. A discussion similar to the SAML/SOAP to http binding seems useful as an update for the operational protocols. example: What returns should be permitted, etc, redirects allowed, chunked encoding?, ... ==> all this should be in the operationl protocols. > > - It doesn't seem extremely useful to me to have several different > > formats to access to certificat list via http, on for certificats > > in general (done by Peter Gutmann's text) and another in this > > text. > > [Stefan] This is the fine balance. We want to limit the set as much as > possible but still support current deployments that have been deployed > in conformity with RFC 3280 in good faith. There is simply too much use > of the .p7c file format to ignore it and declare it non-conformant. I don't want to declar the p7c non conformant, on the contrary, it is simple to implement in the server, and in cas of CMS implementations on the client side, the parsing comes for free, whilst with ... > There is also the aspect of efficiency, where the p7c format may reveal > a complete chain. The certs are a SET, I don't see exactly what you mean, but since we are not in disagreement about the usefulness of the 'type' ... > > > > > - Using a suffix .cer or .p7c to determine the content type behind > > an http uri seems not ok to me, for this AFAIK, http uses mime > types. > > [Stefan] I think/hope this one has been sorted out. Yes. but needs to be corrected in the text. > > > > > - Yes, I know, we might end with a debate whether a list of certs > > can be provided best as: > > > > - SEQUENCE OF Certificate > > - a p7c cert only PKCS7/CMS file > > - a mime multipart containing several individual certificats > > - same result as with ldap... > > > > Well, so be it, ==> 'n' mime types (defined with their file suffix) > > a an http client can set a list of acceptable mime types, and the > server > > must return the data in that way. Using undefined length encoding, > > the first and the second simply mean to encode a fixed prefix and > > suffix, > > the third is a bit more complicated, etc. > > > > [Stefan] We all agree that the information is stored in raw format and > that MIME encoding is an issue for the transport protocol. Is there > anything more to say about this? Since I think that this is an isseu for the operational protocols ... :-) From owner-ietf-pkix Wed Feb 9 07:58:05 2005 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 j19Fw51b041742; Wed, 9 Feb 2005 07:58:05 -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 j19Fw5Tn041741; Wed, 9 Feb 2005 07:58:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sottmxsecs3.entrust.com (sottmxsecs3.entrust.com [216.191.252.14]) by above.proper.com (8.12.11/8.12.9) with SMTP id j19FvxYr041729 for ; Wed, 9 Feb 2005 07:57:59 -0800 (PST) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 3629 invoked from network); 9 Feb 2005 15:57:11 -0000 Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.2.5;09 Feb 2005 15:57:11 -0000 Received: from unknown (HELO sottmxs00.entrust.com) (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 9 Feb 2005 15:57:11 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Feb 2005 10:57:51 -0500 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F03A03168@sottmxs05.entrust.com> From: Sharon Boeyen To: "'Stephen Kent'" , jimsch@exmsft.com Cc: IETF-PKIX Subject: RE: Draft-ietf-pkix-rfc2511bis-07 Date: Wed, 9 Feb 2005 10:57:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50EC0.1877C9EC" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C50EC0.1877C9EC Content-Type: text/plain Jim, sorry for the delay in responding. I have 2 comments: 1) The new document completely changes the meaning of an Object Identifer (changing the name as well as the syntax). In the original RFC (see page 11), the OID was defined as follows: id-regInfo-asciiPairs OBJECT IDENTIFIER ::= {id-regInfo 1} --with syntax OCTET STRING (however in Appendix B they call this id-regInfo-utf8Pairs with a syntax of OCTET STRING, so there was some confusion even back then) In the new RFC it changes to: id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= {id-regInfo 1} --with syntax UTF8String (see section 7.1. OIDs cannot be redefined like this. I suggest you leave the old OID as is and define a new one for UTF8 String. 2) The use of the EncryptedValue structure has been deprecated. This is one of the two choices for conveying an encrypted key in the archive options control that would appear in the controls element of the cert request. The other choice is envelopedData. EncryptedValue is in use in existing products and therefore should not be deprecated. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Friday, January 07, 2005 4:04 PM To: jimsch@exmsft.com Cc: IETF-PKIX Subject: Re: Draft-ietf-pkix-rfc2511bis-07 Folks, Jim sent this message in mid-December and I have seen no response on the list, so far. if nobody responds to Jim, Tim and I will interpret this as implicit authorization for Jim to proceed as he see fit on this topics. Steve >As advertized this draft is now under new editorship. As the new >editor there are a number of issues that I fill still need to be >resolved before this draft can go to last call. If there is no help >forth coming then I will be making arbitrary decions on these issue. > >Additionally, if anyone has kept any of the final reports from the >interop trials for CMP, I would like to see the sections that relate to >CRMF. > >You can easily find the open issues and questions by searching for [[[ >in the document. > >1. Section 4.1 - I have a partial answer for this question dealing >with non DN style names that are authenticated, but are not actually >either subject names (DNs) or subject alt names (General Names). The >only real question at this point is should this rational be documented. > >2. Section 4.2 - I am worried about the possiblity of somebody copying >an encrypted private key being sent to the CA/RA and then copying it >into their own certificate request. They could then later request a >key recovery from the CA/RA and get back somebody elses private key. >This is the reason that I am worried about how a POP proof is done >here. One potential answer is to include the authenticated identity >along with the private key in the encrypted block. > >3. Section 4.2 - We MUST solve the question of what the contents of >the encrypted blob look like. One potential answer is to obsolete >thisMessage and reaplace it with an EnvelopedData then all that needs >to be covered is the format of the encrypted key plus any POP info >required. > >4. Section 4.3 - Does the DH section need to be expanded so that any >key agreement key pair can be used? This can be done by adding a MAC >alg and value pair to the end of the POPOPrivKey choice (and >potentially obsoleting the dhMAC element). > >5. Section 4.4 - Two questions regarding guidence for the number of >iterations and the amount of salt to be used. We need a cryptographer >to give us some guidelines for these details, or atleast need to set >some minimums. > >6. Section 6.1 & 6.2 - The content of these controls is not well >defined and a couple of questions regarding this are asked. This may >have been addressed in the interop by adding some undocumented >restrictions. > >7. Section 6.4 - There are a couple of archive questions here. At >this point my inclination is to kill the entire section unless somebody >wants to make it acutally work. > >8. Section 6.8 - Ditto here. > >9. Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%" The parsing is >difficult (but not impossible) due to the overload of the % token. > >Jim ------_=_NextPart_001_01C50EC0.1877C9EC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Draft-ietf-pkix-rfc2511bis-07

Jim, sorry for the delay in responding. I have 2 = comments:

1) The new document completely changes the meaning of = an Object Identifer (changing the name as well as the syntax). In the = original RFC (see page 11), the OID was defined as follows:

 
id-regInfo-asciiPairs  OBJECT IDENTIFIER  = ::=3D {id-regInfo 1} --with syntax OCTET STRING
(however in Appendix B they call this = id-regInfo-utf8Pairs with a syntax of OCTET STRING, so there was some = confusion even back then)

 
In the new RFC it changes to:
 
id-regInfo-utf8Pairs  OBJECT IDENTIFIER  = ::=3D {id-regInfo 1} --with syntax UTF8String (see section 7.1.
 
OIDs cannot be redefined like this.  I suggest = you leave the old OID as is and define a new one for UTF8 String. =

2) The use of the EncryptedValue structure has been = deprecated. This is one of the two choices for conveying an encrypted = key in the archive options control that would appear in the controls = element of the cert request. The other choice is envelopedData. = EncryptedValue is in use in existing products and therefore should not = be deprecated.

Cheers,
Sharon

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail= .imc.org] On Behalf Of Stephen Kent
Sent: Friday, January 07, 2005 4:04 PM
To: jimsch@exmsft.com
Cc: IETF-PKIX
Subject: Re: Draft-ietf-pkix-rfc2511bis-07



Folks,

Jim sent this message in mid-December and I have seen = no response on
the list, so far.  if nobody responds to Jim, = Tim and I will
interpret this as implicit authorization for Jim to = proceed as he see
fit on this topics.

Steve


>As advertized this draft is now under new = editorship.  As the new
>editor there are a number of issues that I fill = still need to be
>resolved before this draft can go to last = call.  If there is no help
>forth coming then I will be making arbitrary = decions on these issue.
>
>Additionally, if anyone has kept any of the = final reports from the
>interop trials for CMP, I would like to see the = sections that relate to
>CRMF.
>
>You can easily find the open issues and = questions by searching for [[[
>in the document.
>
>1.  Section 4.1 - I have a partial answer = for this question dealing
>with non DN style names that are authenticated, = but are not actually
>either subject names (DNs) or subject alt names = (General Names).  The
>only real question at this point is should this = rational be documented.
>
>2.  Section 4.2 - I am worried about the = possiblity of somebody copying
>an encrypted private key being sent to the CA/RA = and then copying it
>into their own certificate request.  They = could then later request a
>key recovery from the CA/RA and get back = somebody elses private key. 
>This is the reason that I am worried about how a = POP proof is done
>here.  One potential answer is to include = the authenticated identity
>along with the private key in the encrypted = block.
>
>3.  Section 4.2 - We MUST solve the = question of what the contents of
>the encrypted blob look like.  One = potential answer is to obsolete
>thisMessage and reaplace it with an = EnvelopedData then all that needs
>to be covered is the format of the encrypted key = plus any POP info
>required.
>
>4.  Section 4.3 - Does the DH section need = to be expanded so that any
>key agreement key pair can be used?  This = can be done by adding a MAC
>alg and value pair to the end of the POPOPrivKey = choice (and
>potentially obsoleting the dhMAC = element).
>
>5.  Section 4.4 - Two questions regarding = guidence for the number of
>iterations and the amount of salt to be = used.  We need a cryptographer
>to give us some guidelines for these details, or = atleast need to set
>some minimums.
>
>6.  Section 6.1 & 6.2 - The content of = these controls is not well
>defined and a couple of questions regarding this = are asked.  This may
>have been addressed in the interop by adding = some undocumented
>restrictions.
>
>7.  Section 6.4 - There are a couple of = archive questions here.  At
>this point my inclination is to kill the entire = section unless somebody
>wants to make it acutally work.
>
>8.  Section 6.8 - Ditto here.
>
>9.  Section 7.1 - Consider the string = "Tokens?%30%FA%F3?9%"   The parsing is
>difficult (but not impossible) due to the = overload of the % token.
>
>Jim

------_=_NextPart_001_01C50EC0.1877C9EC-- From owner-ietf-pkix Thu Feb 10 05:30:25 2005 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 j1ADUP8p050972; Thu, 10 Feb 2005 05:30:25 -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 j1ADUPHj050971; Thu, 10 Feb 2005 05:30:25 -0800 (PST) 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 j1ADUL4S050949 for ; Thu, 10 Feb 2005 05:30:23 -0800 (PST) (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 OAA09966; Thu, 10 Feb 2005 14:43:34 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021014300006:1260 ; Thu, 10 Feb 2005 14:30:00 +0100 Message-ID: <420B61F7.1060509@bull.net> Date: Thu, 10 Feb 2005 14:30:31 +0100 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt References: <0C3042E92D8A714783E2C44AB9936E1D019BCB43@EUR-MSG-03.europe.corp.microsoft.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 14:30:00, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 14:30:03, Serialize complete at 10/02/2005 14:30:03 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: Stefan, There is a major security issue here. > Denis, > > It is obvious that you base your objections on the assumption that a CRL > issuer cert MUST be issued by the CA issuing the validated subject cert. > > But you also admit that this is what you think the stand should say but > do not say (at least not explicitly). > > Quote from your text: "This is not explicitly stated in RFC 3280 for CRL > issuers, but it is for OCSP responders" > > I guess it will be useless to get into details before we have sorted out > this major cause of disagreement. But since even you admit that there is > no such requirement in RFC 3280 (nor X.509), I'm not sure what there is > to discuss. The security considerations section needs to be discussed. The current text is: Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. As means of reducing problems and security issues related to issuer name collisions, CA names SHOULD be formed in a way that reduce the likelihood of name collisions. The SHOULD in the previous sentence does not solve the problem, since this cannot be prevented. The text should explain how to have a secure system even in the case of a name collision, i.e. two CAs pick the same name to designate a CRL issuer but that name now relates to two different entities. Implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate, terminate at the same trust anchor. This sentence does not solve the problem. The only way to solve the problem is, for relying parties, to be able to know unambiguously which CA is allowed to certify the CRL issuer name. It cannot be "any CA" in a certification tree. Since the syntax of the cRLIssuer contained in DistributionPoint does not permit to place any other information than a name, it cannot designate the CA allowed to certify the CRL issuer name, hence there needs to be a fixed rule to be known by all relying parties. The fixed rule I proposed mimics the conditions of the OCSP responder, i.e. "The CRL Issuer must have a specially marked certificate issued directly by the CA, indicating that the CRL issuer may issue CRLs". Can there be another rule which guarantes that there is no ambiguity about the right CRL issuer bearing the name contained in cRLIssuer ? The answer is no, ... unless you demonstrate the contrary. Note: remember that the CA cannot know in advanced which trust anchor(s) will be placed in the validation policies used by relying parties. Denis > Stefan Santesson > Microsoft Security Center of Excellence (SCOE) > > > >>-----Original Message----- >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>Sent: den 7 februari 2005 06:19 >>To: Stefan Santesson; Russ Housley >>Cc: pkix >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt >> >>Comments on >> >>1. The title and the scope of the document are not in accordance with > > the > >>content of the document. The document is not simply defining a new >>extension >>that may help to find out a CRL, but is defining a new way to verify > > that > >>a >>CRL is correct. >> >> >>2. The new way to verify that a CRL is correct is not aligned with the >>current documents. >> >>According to RFC 3280, page 7, a CRL issuer is an "optional system to >>which >>a CA delegates the publication of certificate revocation lists". >> >>This means that the CA is responsible of the CRL issuance but may > > delegate > >>the publication to another entity, while being still legally > > responsible > >>of >>the issuance of the CRLs. >> >>The CRL distribution points extension, defined in section 4.2.1.14 of > > RFC > >>3280, is the means for the CA to designate the appropriate CRL Issuer. >>When >>the CA is not the CRL issuer, then the cRLIssuer field MUST be present > > and > >>contain the Name of the CRL issuer. This field has the syntax >>GeneralNames. >> >>GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName >> >>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 } >> >>Since a name is only unambiguous when certified by a CA (two CAs can >>certify >>two different entities but might use the same name for each of them), > > the > >>straightforward rule to make sure that the name is unambiguous is to > > use a > >>certificate for that name that has been issued by the CA which has >>designated the CRL Issuer. >> >>This is not explicitly stated in RFC 3280 for CRL issuers, but it is > > for > >>OCSP responderx which play a similar function. In page 3 of RFC 2560 > > we > >>have: >> >>All definitive response messages SHALL be digitally signed. The key >> used to sign the response MUST belong to one of the following: >> >> -- (...) >> -- (...) >> -- a CA Designated Responder (Authorized Responder) who holds a >> *specially marked certificate issued directly by the CA*, >>indicating >> that the responder may issue OCSP responses for that CA. >> >>This means that the CRL Issuer must have a *specially marked > > certificate > >>issued directly by the CA*, indicating that the CRL isssuer may issue > > CRLs > >>for that CA. >> >>Having said this, many portions of the text are not acceptable. Only a > > few > >>examples will be given hereafter. >> >> >>3. The abstract is misleading. The text states: >>"The CRL extension provides a means of discovering and retrieving CRL >>issuer >>certificates." It should say :"The CRL extension provides an > > additional > >>means of discovering and retrieving CRL issuer certificates." >> >> >>4. The introduction is misleading. The text states: >> >>" CRL validation is also specified in RFC 3280, which involves the >>constructions of a valid certification path for the CRL issuer". >> >>There is no concept of "construction of valid certification path for > > the > >>CRL >>issuer". There is however the concept of a certification path which is > > a > >>chain of certificates from a "certificate-to-be-tested" up to one of > > the > >>root keys trusted under the validation policy. For each certificate of > > the > >>certification path, it must be tested that it is not revoked. As said >>above, >>the CRL issuer is designated by the CA and thus there is the need to >>locate, >>get and verify the CRL issuer certificate that has been issued by the > > CA. > >>For each certificate of the certification path, there may be the need > > to > >>capture just ONE CRL issuer certificate and no more. >> >>The next sentences are inappropriate as well and should be deleted. >> >> >>5. The introduction states: >> >> "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. These methods are however not >> generally applicable, and they do not provide a generic solution > > to > >> the problem." >> >>This text is biased and is incorrect. SIA is equally applicable and > > also > >>provides a generic solution to the problem. It has simply to do with > > using > >>an extension which points downwards or upwards. >> >>The key point is that the certification path (as described in RFC > > 3280) > >>needs first to be build. Once it is built, and only once this is done, > > the > >>question is whether or not all certificates of the path are not > > revoked. > >>This means that it is possible to look up in every certificate of the >>certification path and find out the extensions which are present. > > There is > >>no superiority to the new proposed extension, if SIA is populated. >> >> >>6. The introduction states: >> >> This document provides a straightforward and generic solution to > > the > >> CRL issuer certification path building problem by permitting 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, if necessary, >> complete the CRL issuer certification path building to an > > appropriate > >> trust anchor. >> >>Based on the previous arguments, this text is incorrect as well since >>there >>is no "CRL issuer certification path building problem". >> >>Major changes to this document are required to go any further. Until > > an > >>agreement can be reached on the previous issues, it does not make > > sense to > >>discuss the remaining of the document. >> >>Denis >> >> >> >>>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 Authority >> >>> Information Access CRL Extension >>> Author(s) : S. Santesson, R. Housley >>> Filename : draft-ietf-pkix-crlaia-00.txt >>> Pages : 7 >>> Date : 2005-1-26 >>> >>>This document updates RFC 3280 by defining the Authority Information >>> Access Certificate Revocation Lists (CRL) extension. RFC 3280 >>> defines the Authority Information Access certificate extension >> > using > >>> the same syntax. The CRL extension provides a means of >> > discovering > >>> and retrieving CRL issuer certificates. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt >> > > From owner-ietf-pkix Thu Feb 10 05:12:10 2005 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 j1ADCAZv049911; Thu, 10 Feb 2005 05:12:10 -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 j1ADCAtH049910; Thu, 10 Feb 2005 05:12:10 -0800 (PST) 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 j1ADC4sD049893 for ; Thu, 10 Feb 2005 05:12:04 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 10 Feb 2005 13:11:58 +0000 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: draft-ietf-pkix-crlaia-00.txt comments Date: Thu, 10 Feb 2005 13:11:51 -0000 Message-ID: <0C3042E92D8A714783E2C44AB9936E1D019F9B03@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pkix-crlaia-00.txt comments thread-index: AcUODdTzr6d8YJ+YShK0qLy6m4+QfQAACXaQAAEnVSAABGswMABSqK6Q From: "Stefan Santesson" To: "Matt Cooper" , "Russ Housley" Cc: X-OriginalArrivalTime: 10 Feb 2005 13:11:58.0481 (UTC) FILETIME=[19E14810:01C50F72] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1ADC5sD049903 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: So, how about this: When the HTTP scheme is specified, the URI MUST specify the location of a certificate containing file. The file MUST contain either a single binary DER encoded certificate (indicated by the .cer file extension) or one or more certificates encapsulated in a CMS certs-only (PKCS#7) message [ref] (indicated by the .p7c file extension). HTTP server implementations accessed via the URI SHOULD use the appropriate MIME [ref] content-type for the certificate containing file. Specifically, the HTTP server SHOULD use the content-type application/pkix-cert [ref] for a single DER encoded certificate and application/pkcs7-mime [ref] for CMS certs-only (PKCS#7). Consuming clients may use the MIME type and file extension as a hint to the file content, but should not depend solely on the presence of the correct MIME type or file extension in the server response. --------- Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Matt Cooper > Sent: den 9 februari 2005 02:32 > To: Stefan Santesson; 'Russ Housley' > Cc: ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > > Hi Stefan, > > One nit with regard to the wording - The way you have used "certificate > file" makes it seem like a new term when I read it. Is this used in other > docs to collectively describe multiple file types containing certificates? > If no, I think you may want to find a different way to say this so it > doesn't sound like new terminology, or, if not, should it be defined > explicitly? Fairly minor point in any event. > > You can decide what to do with the above comment; I stuck with that > terminology below. I was thinking something along these lines: > > ------- > When the HTTP scheme is specified, the URI MUST specify the location of a > certificate file. The certificate file MUST be either a single binary DER > encoded certificate (indicated by the .cer file extension) file or a > single > binary DER encoded certs-only PKCS#7 [ref] file (indicated by the .p7c > file > extension) containing one or more certificates. > > HTTP server implementations accessed via the URI SHOULD use the > appropriate > MIME [ref] content-type for the certificate file. Specifically, the HTTP > server SHOULD use the content-type application/pkix-cert [ref] for a > single > DER encoded certificate and application/pkcs7-mime [ref] for a certs-only > PKCS#7. Consuming clients may use the MIME type and file extension as a > hint to the file content, but should not depend solely on the presence of > the correct MIME type or file extension in the server response. > ------- > > Best Regards, > > Matt Cooper > Orion Security Solutions > 1489 Chain Bridge Road, Suite 300 > McLean, Virginia 22101 > (Mob) 703.981.2269 > (Off) 703.917.0060 x. 30 > (Fax) 703.917.0260 > Visit our website! > http://www.orionsec.com > > > > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Stefan Santesson > Sent: Tuesday, February 08, 2005 2:17 PM > To: Matt Cooper; Russ Housley > Cc: ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > > Matt, > > Do you have any proposed wording? > Feel free to make a suggestion. > > Stefan Santesson > Microsoft Security Center of Excellence (SCOE) > > > > -----Original Message----- > > From: Matt Cooper [mailto:mcooper@orionsec.com] > > Sent: den 8 februari 2005 19:50 > > To: 'Russ Housley'; Stefan Santesson > > Cc: ietf-pkix@imc.org > > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > > > I knew we would get to the same page eventually. :) > > > > I'm glad to hear the answer is negative. I, and several others I have > > spoken to, took the text in the draft to indicate this extra MIME > > encoding > was > > the > > proposed requirement. So, I think we simply need to reword that > section to > > be very clear on this point. > > > > Best Regards, > > > > Matt Cooper > > Orion Security Solutions > > 1489 Chain Bridge Road, Suite 300 > > McLean, Virginia 22101 > > (Mob) 703.981.2269 > > (Off) 703.917.0060 x. 30 > > (Fax) 703.917.0260 > > Visit our website! > > http://www.orionsec.com > > > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Tuesday, February 08, 2005 1:41 PM > > To: Matt Cooper; stefans@microsoft.com > > Cc: ietf-pkix@imc.org > > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > > > Matt: > > > > Now I understand the issue. Sorry it took so long for me to > understand > > the > > comment. > > > > FALSE. > > > > I expect the server to store a binary .cer and .p7c file. The only > MIME > > encoding will be applied by the transport protocol. HTTP will MIME > > encode. > > FTP will not. > > > > Russ > > > > At 12:27 PM 2/7/2005, Matt Cooper wrote: > > >Russ, > > > > > >TRUE|FALSE: On the server, you intend for the certificate file > (stored > > >TRUE|on > > >the server's hard disk) to be MIME encoded. > > > > > >The question has nothing to do with HTTP. It could be FTP or NFS for > > >all it matters. What the draft says (to me at least) is that you are > > >supposed to MIME encode the data *BEFORE* the protocol encoding ever > > enters > > the picture. > > >This results in the client receiving a MIME encoded file regardless > of > > >transport protocol. > > > > > >Best Regards, > > > > > >Matt Cooper > > >Orion Security Solutions > > >1489 Chain Bridge Road, Suite 300 > > >McLean, Virginia 22101 > > >(Mob) 703.981.2269 > > >(Off) 703.917.0060 x. 30 > > >(Fax) 703.917.0260 > > >Visit our website! > > >http://www.orionsec.com > > > > > > > > >-----Original Message----- > > >From: Russ Housley [mailto:housley@vigilsec.com] > > >Sent: Friday, February 04, 2005 8:21 AM > > >To: Matt Cooper; stefans@microsoft.com > > >Cc: ietf-pkix@imc.org > > >Subject: RE: draft-ietf-pkix-crlaia-00.txt comments > > > > > >Matt: > > > > > >MIME supports many encoding types, including binary and base64. I > > >think that binary will be used in this case, but base64 and other > > >encodings are not prohibited. > > > > > >We should probably say that binary encoding MUST be supported. > > > > > >Russ > > > > > >At 06:29 PM 2/3/2005, Matt Cooper wrote: > > > > > > >Perhaps I was not clear either. I didn't think you were attempting > > > >to eliminate the HTTP MIME encoding. And believe me, I'm the first > > > >one to cheer having a naming convention for this purpose! > > > > > > > >Are you saying that your intent was only to apply the MIME encoding > > > >to how the HTTP server should be serving up the files to the > client? > > > >Not trying to be difficult, I just want to be sure we're on the > same > > > >page as the text reads quite differently to me. > > > > > > > >It reads (to me) that you intend for the hosted file to be MIME > > > >encoded rather than binary. Specifically, as [A MIME encoded > > > >application/pkcs7-mime "certs-only" file as specified in RFC 2797 > > > >[CMC]"]. When I read this it indicated to me that I am supposed to > > > >MIME encode the PKCS#7 and name the resultant MIME text file with a > > > >.p7c extension. E.g., place the following file content on my web > > server: > > > > > > > >MIME-Version: 1.0 > > > >Content-Type: application/pkcs7-mime; > > > > smime-type="certs-only"; > > > > name="cacerts.p7c" > > > >Content-Transfer-Encoding: base64 > > > >Content-Disposition: attachment; > > > > filename="cacerts.p7c" > > > > > > > > >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg > > > >g/ > > > >+Q29u > > > > >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X > > > >05 > > > >leHRQ > > > >... > > > >BhcnA=== > > > > > > > > > > > >Matt Cooper > > > >Orion Security Solutions > > > >1489 Chain Bridge Road, Suite 300 > > > >McLean, Virginia 22101 > > > >(Mob) 703.981.2269 > > > >(Off) 703.917.0060 x. 30 > > > >(Fax) 703.917.0260 > > > >Visit our website! > > > >http://www.orionsec.com > > > > > > > > > > > >________________________________ > > > > > > > >From: Russ Housley [mailto:housley@vigilsec.com] > > > >Sent: Thursday, February 03, 2005 3:39 PM > > > >To: Matt Cooper; stefans@microsoft.com > > > >Cc: ietf-pkix@imc.org > > > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments > > > > > > > > > > > >Matt: > > > > > > > >We were not clear. We did not intend to eliminate the MIME > encoding > > > >which is normally present with HTTP. The MIME types are specified > in > > > >the referenced documents, I believe. Rather, we were also stating > a > > > >naming convention for the files that are obtained. > > > > > > > >Russ > > > > > > > >At 03:15 PM 2/3/2005, Matt Cooper wrote: > > > > > > > > > > > > First, I'd like to say I'm happy to see this come out, > this > > > >is a needed addition for CRLs. > > > > > > > > All my comments refer to the following snippet extracted > > > >from the draft > > > > ( > > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt > > > > > ): > > > > > > > > ===begin=== > > > > When the http scheme is specified, the URI MUST point > to a > > > > certificate file. The certificate file MUST contain > > > >either a single > > > > DER encoded certificate (indicated by the .cer file > > > >extension) > > >or > > > > contain a certification path (indicated by the .p7c > file > > > >extension): > > > > > > > > .cer A single DER encoded certificate as specified > in > > > > RFC 2585 [PKIX-CERT]. > > > > > > > > .p7c A MIME encoded application/pkcs7-mime "certs- > > only" > > >file > > > > as specified in RFC 2797 [CMC]. > > > > ===end=== > > > > > > > > Unless this has been required in another document that I > am > > > >unaware of, we should use not use "MIME encoded" for this purpose > for > > > >the following > > > >reasons: > > > > 1. It creates burden on the client. Why should the client > > > >need a MIME decoder to verify a CRL? > > > > 2. It creates burden for CA's and CA operators. They may > > > >have to learn how to manually encode a PKCS#7 in a MIME structure > if > > > >their CA does not output this for them. This is error prone and may > > > >lead to > > >problems. > > > > 3. Clients must handle one case as binary and the other > case > > > > as > > >text > > > > 4. Web servers already return MIME types for data; another > > > >MIME layer is not needed > > > > > > > > It is not too much to expect that the relying party > software > > > >can distinguish between a binary cert and a binary p7c file. (For > > > >example, MS CAPI already does this for AIA) However, to make life > > > >easier for the client, could we throw in appropriate use of MIME > > > >types on > > >the web server? > > > >Perhaps something like this: > > > > > > > > "HTTP server implementations accessed via the URI SHOULD > use > > > >the appropriate MIME content-type for the certificate file. > > > >Specifically, the HTTP server SHOULD return the content-type > > > >application/pkix-cert for a single DER encoded certificate and > > > >application/pkcs7-mime for a certs-only PKCS#7. Consuming clients > > > >SHOULD use the MIME type as a hint, but should not depend solely on > > > >the presence of the correct MIME type in the server response." > > > > > > > > Calling for the contents of the p7c to be "a certification > > > >path" is too restrictive in my mind. It would be better to leave > > > >this wide open and say something like "contain one or more > > > >certificates that may be helpful to the relying party." This > leaves > > > >it up to the implementer to put in any certificates that may be > > > >useful for path construction regardless of whether we have common > > > >trusted roots. (They may also wish to not include the entire path, > > > >but instead only the CRL signer cert, which then has another AIA in > > > >it.) > > > > > > > > Suggest rewording the text something like this : > > > > > > > > When the HTTP scheme is specified, the URI MUST point to a > > > >certificate file. The certificate file MUST be either a single > binary > > > >DER encoded certificate (indicated by the .cer file extension) or a > > > >single binary DER encoded certs-only PKCS#7 file (indicated by the > > > >.p7c file > > > >extension) containing one or more certificates that may be helpful > to > > > >the relying party. > > > > > > > > > > > > Matt Cooper > > > > Orion Security Solutions > > > > 1489 Chain Bridge Road, Suite 300 > > > > McLean, Virginia 22101 > > > > (Mob) 703.981.2269 > > > > (Off) 703.917.0060 x. 30 > > > > (Fax) 703.917.0260 > > > > Visit our website! > > > > http://www.orionsec.com > > > > > > > > > From owner-ietf-pkix Thu Feb 10 07:17:59 2005 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 j1AFHx6w056896; Thu, 10 Feb 2005 07:17:59 -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 j1AFHxPV056895; Thu, 10 Feb 2005 07:17:59 -0800 (PST) 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 j1AFHwAs056889 for ; Thu, 10 Feb 2005 07:17:58 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 10 Feb 2005 15:17:52 +0000 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt Date: Thu, 10 Feb 2005 15:17:37 -0000 Message-ID: <0C3042E92D8A714783E2C44AB9936E1D019F9BD1@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt thread-index: AcUPdLAVBMQ3Y0WJSQCZVxRoCXh2FgABad/Q From: "Stefan Santesson" To: "Denis Pinkas" Cc: "Russ Housley" , "pkix" X-OriginalArrivalTime: 10 Feb 2005 15:17:52.0664 (UTC) FILETIME=[B0862180:01C50F83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1AFHxAs056890 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think this question is the key issue: > Can there be another rule which guarantes that there is no ambiguity about > the right CRL issuer bearing the name contained in cRLIssuer ? The answer > is > no, ... unless you demonstrate the contrary. > > Note: remember that the CA cannot know in advanced which trust anchor(s) > will be placed in the validation policies used by relying parties. > > Denis > If a relying party trust a rouge CA, then all bets are off. This is part of the PKI fundamentals we have to accept. So the issue is to prevent matching of unrelated certs and CRLs from trusted issuers. This is only a theoretically realistic threat if the CDP in the cert doesn't include any pointer/address to the CRL storage location (which should be considered really BAD practice). Storage location addresses (which have to match between CDP and IDP if present) do have sufficient uniqueness characteristics to effectively mitigate accidental CA name collisions. In fact, there are ways to form CDP and IDP to completely eliminate this threat without imposing your requirement. Yes - an extra level of security would be guaranteed if the rule you suggest would be imposed, but I think it is too late and too restrictive. The threat is not material and realistic enough to justify a restriction that would declare perfectly secure current implementations non-conformant. You are free to seek support for your position, but until you have obtained rough consensus on your suggested limitation, the crl-aia drafting process must assume that the limitation you suggest does NOT exist. Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 10 februari 2005 14:31 > To: Stefan Santesson > Cc: Russ Housley; pkix > Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > > Stefan, > > There is a major security issue here. > > > Denis, > > > > It is obvious that you base your objections on the assumption that a CRL > > issuer cert MUST be issued by the CA issuing the validated subject cert. > > > > But you also admit that this is what you think the stand should say but > > do not say (at least not explicitly). > > > > Quote from your text: "This is not explicitly stated in RFC 3280 for CRL > > issuers, but it is for OCSP responders" > > > > I guess it will be useless to get into details before we have sorted out > > this major cause of disagreement. But since even you admit that there is > > no such requirement in RFC 3280 (nor X.509), I'm not sure what there is > > to discuss. > > The security considerations section needs to be discussed. > > The current text is: > > Implementers should take into account the possible existence of > multiple unrelated CAs and CRL issuers with the same name. As > means of reducing problems and security issues related to issuer > name collisions, CA names SHOULD be formed in a way that reduce the > likelihood of name collisions. > > The SHOULD in the previous sentence does not solve the problem, since this > cannot be prevented. The text should explain how to have a secure system > even in the case of a name collision, i.e. two CAs pick the same name to > designate a CRL issuer but that name now relates to two different > entities. > > Implementations validating CRLs > MUST ensure that the certification path of the target certificate > and the CRL issuer certification path used to validate the target > certificate, terminate at the same trust anchor. > > This sentence does not solve the problem. The only way to solve the > problem > is, for relying parties, to be able to know unambiguously which CA is > allowed to certify the CRL issuer name. It cannot be "any CA" in a > certification tree. > > Since the syntax of the cRLIssuer contained in DistributionPoint does not > permit to place any other information than a name, it cannot designate the > CA allowed to certify the CRL issuer name, hence there needs to be a fixed > rule to be known by all relying parties. > > The fixed rule I proposed mimics the conditions of the OCSP responder, > i.e. > > "The CRL Issuer must have a specially marked certificate issued > directly by the CA, indicating that the CRL issuer may issue CRLs". > > Can there be another rule which guarantes that there is no ambiguity about > the right CRL issuer bearing the name contained in cRLIssuer ? The answer > is > no, ... unless you demonstrate the contrary. > > Note: remember that the CA cannot know in advanced which trust anchor(s) > will be placed in the validation policies used by relying parties. > > Denis > > > From owner-ietf-pkix Thu Feb 10 08:33:31 2005 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 j1AGXVaX061548; Thu, 10 Feb 2005 08:33:31 -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 j1AGXVO7061547; Thu, 10 Feb 2005 08:33:31 -0800 (PST) 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 j1AGXTli061536 for ; Thu, 10 Feb 2005 08:33:29 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 16:33:05 +0000 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt Date: Thu, 10 Feb 2005 16:33:08 -0000 Message-ID: <0C3042E92D8A714783E2C44AB9936E1D019F9C0A@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt thread-index: AcUPjLMPSzx4weWMRlyCmIrOqmON1gAAHmfA From: "Stefan Santesson" To: "Denis Pinkas" Cc: "Russ Housley" , "pkix" X-OriginalArrivalTime: 10 Feb 2005 16:33:05.0134 (UTC) FILETIME=[322A68E0:01C50F8E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1AGXUli061541 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis it looks like there are some misconceptions here: Your scenario only applies to indirect CRLs. For indirect CRLs both CDP AND IDP MUST be present and at least 1 DP location/URL in CDP MUST match at least one DP location/URL in IDP. This is already a requirement of both RFC 3280 and X.509. > This leads to the following conclusion: > > a) if the IDP is not present, then my scenario applies. > b) if the IDP is present, then your scenario applies. Conclusion: a) never apply to this problem space. Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 10 februari 2005 17:21 > To: Stefan Santesson > Cc: Russ Housley; pkix > Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > > Stefan, > > > I think this question is the key issue: > > > > > >> Can there be another rule which guarantes that there is no ambiguity > >> about he right CRL issuer bearing the name contained in cRLIssuer ? > >> The answer is no, ... unless you demonstrate the contrary. > > >> Note: remember that the CA cannot know in advanced which trust > >> anchor(s) will be placed in the validation policies used by relying > >> parties. > > >>Denis > > > If a relying party trust a rouge CA, then all bets are off. This is > part > > of the PKI fundamentals we have to accept. So the issue is to prevent > > matching of unrelated certs and CRLs from trusted issuers. > > > This is only a theoretically realistic threat if the CDP in the cert > > doesn't include any pointer/address to the CRL storage location (which > > should be considered really BAD practice). > > At this stage of explanations, the CRL pointer whether present or absent > does not help. We all know that it is possible to replace a CRL by > another > one since it is never required to secure the protocol to query CRLs. So an > attacker having noticed that two CRL issuer names are the same, might > perform an active attack and exchange CRLs at will. > > > Storage location addresses > > (which have to match between CDP and IDP if present) do have sufficient > > uniqueness characteristics to effectively mitigate accidental CA name > > collisions. In fact, there are ways to form CDP and IDP to completely > > eliminate this threat without imposing your requirement. > > Interresting. Your proposal would lead to the following: > > 1) both the CDP and the IDP MUST must be present, > 2) then they must match. > > ... but the proposal would mandate the presence of the IDP. > > This leads to the following conclusion: > > a) if the IDP is not present, then my scenario applies. > b) if the IDP is present, then your scenario applies. > > Both scenarios would then co-exist. > > If you can revise the main body of the draft along these lines, then we > may > be close to an agreement. > > Then the second implication is : if the CRL issuer is under the same > trust anchor, it will be trusted, otherwise it might not unless the other > trust anchor is also present in the validation policy. So the > recommandation > to use the same trust anchor would be better explained this way in the > security considerations section. > > Denis > > > Yes - an extra level of security would be guaranteed if the rule you > > suggest would be imposed, but I think it is too late and too > > restrictive. The threat is not material and realistic enough to justify > > a restriction that would declare perfectly secure current > > implementations non-conformant. > > > > You are free to seek support for your position, but until you have > > obtained rough consensus on your suggested limitation, the crl-aia > > drafting process must assume that the limitation you suggest does NOT > > exist. > > > > > > > > Stefan Santesson > > Microsoft Security Center of Excellence (SCOE) > > > > > > > >>-----Original Message----- > >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > >>Sent: den 10 februari 2005 14:31 > >>To: Stefan Santesson > >>Cc: Russ Housley; pkix > >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > >> > >>Stefan, > >> > >>There is a major security issue here. > >> > >> > >>>Denis, > >>> > >>>It is obvious that you base your objections on the assumption that a > >> > > CRL > > > >>>issuer cert MUST be issued by the CA issuing the validated subject > >> > > cert. > > > >>>But you also admit that this is what you think the stand should say > >> > > but > > > >>>do not say (at least not explicitly). > >>> > >>>Quote from your text: "This is not explicitly stated in RFC 3280 for > >> > > CRL > > > >>>issuers, but it is for OCSP responders" > >>> > >>>I guess it will be useless to get into details before we have sorted > >> > > out > > > >>>this major cause of disagreement. But since even you admit that > >> > > there is > > > >>>no such requirement in RFC 3280 (nor X.509), I'm not sure what there > >> > > is > > > >>>to discuss. > >> > >>The security considerations section needs to be discussed. > >> > >>The current text is: > >> > >> Implementers should take into account the possible existence of > >> multiple unrelated CAs and CRL issuers with the same name. As > >> means of reducing problems and security issues related to issuer > >> name collisions, CA names SHOULD be formed in a way that reduce > > > > the > > > >> likelihood of name collisions. > >> > >>The SHOULD in the previous sentence does not solve the problem, since > > > > this > > > >>cannot be prevented. The text should explain how to have a secure > > > > system > > > >>even in the case of a name collision, i.e. two CAs pick the same name > > > > to > > > >>designate a CRL issuer but that name now relates to two different > >>entities. > >> > >> Implementations validating CRLs > >> MUST ensure that the certification path of the target > > > > certificate > > > >> and the CRL issuer certification path used to validate the > > > > target > > > >> certificate, terminate at the same trust anchor. > >> > >>This sentence does not solve the problem. The only way to solve the > >>problem > >>is, for relying parties, to be able to know unambiguously which CA is > >>allowed to certify the CRL issuer name. It cannot be "any CA" in a > >>certification tree. > >> > >>Since the syntax of the cRLIssuer contained in DistributionPoint does > > > > not > > > >>permit to place any other information than a name, it cannot designate > > > > the > > > >>CA allowed to certify the CRL issuer name, hence there needs to be a > > > > fixed > > > >>rule to be known by all relying parties. > >> > >>The fixed rule I proposed mimics the conditions of the OCSP responder, > >>i.e. > >> > >> "The CRL Issuer must have a specially marked certificate issued > >> directly by the CA, indicating that the CRL issuer may issue CRLs". > >> > >>Can there be another rule which guarantes that there is no ambiguity > > > > about > > > >>the right CRL issuer bearing the name contained in cRLIssuer ? The > > > > answer > > > >>is > >>no, ... unless you demonstrate the contrary. > >> > >>Note: remember that the CA cannot know in advanced which trust > > > > anchor(s) > > > >>will be placed in the validation policies used by relying parties. > >> > >>Denis > >> > >> > >> > > > > > > From owner-ietf-pkix Thu Feb 10 08:22:06 2005 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 j1AGM6V4060801; Thu, 10 Feb 2005 08:22:06 -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 j1AGM6vi060800; Thu, 10 Feb 2005 08:22:06 -0800 (PST) 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 j1AGM4Zu060790 for ; Thu, 10 Feb 2005 08:22:05 -0800 (PST) (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 RAA28968; Thu, 10 Feb 2005 17:35:26 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021017215234:1387 ; Thu, 10 Feb 2005 17:21:52 +0100 Message-ID: <420B89DC.90806@bull.net> Date: Thu, 10 Feb 2005 17:20:44 +0100 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt References: <0C3042E92D8A714783E2C44AB9936E1D019F9BD1@EUR-MSG-03.europe.corp.microsoft.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 17:21:52, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 17:21:53, Serialize complete at 10/02/2005 17:21:53 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: Stefan, > I think this question is the key issue: > >> Can there be another rule which guarantes that there is no ambiguity >> about he right CRL issuer bearing the name contained in cRLIssuer ? >> The answer is no, ... unless you demonstrate the contrary. >> Note: remember that the CA cannot know in advanced which trust >> anchor(s) will be placed in the validation policies used by relying >> parties. >>Denis > If a relying party trust a rouge CA, then all bets are off. This is part > of the PKI fundamentals we have to accept. So the issue is to prevent > matching of unrelated certs and CRLs from trusted issuers. > This is only a theoretically realistic threat if the CDP in the cert > doesn't include any pointer/address to the CRL storage location (which > should be considered really BAD practice). At this stage of explanations, the CRL pointer whether present or absent does not help. We all know that it is possible to replace a CRL by another one since it is never required to secure the protocol to query CRLs. So an attacker having noticed that two CRL issuer names are the same, might perform an active attack and exchange CRLs at will. > Storage location addresses > (which have to match between CDP and IDP if present) do have sufficient > uniqueness characteristics to effectively mitigate accidental CA name > collisions. In fact, there are ways to form CDP and IDP to completely > eliminate this threat without imposing your requirement. Interresting. Your proposal would lead to the following: 1) both the CDP and the IDP MUST must be present, 2) then they must match. ... but the proposal would mandate the presence of the IDP. This leads to the following conclusion: a) if the IDP is not present, then my scenario applies. b) if the IDP is present, then your scenario applies. Both scenarios would then co-exist. If you can revise the main body of the draft along these lines, then we may be close to an agreement. Then the second implication is : if the CRL issuer is under the same trust anchor, it will be trusted, otherwise it might not unless the other trust anchor is also present in the validation policy. So the recommandation to use the same trust anchor would be better explained this way in the security considerations section. Denis > Yes - an extra level of security would be guaranteed if the rule you > suggest would be imposed, but I think it is too late and too > restrictive. The threat is not material and realistic enough to justify > a restriction that would declare perfectly secure current > implementations non-conformant. > > You are free to seek support for your position, but until you have > obtained rough consensus on your suggested limitation, the crl-aia > drafting process must assume that the limitation you suggest does NOT > exist. > > > > Stefan Santesson > Microsoft Security Center of Excellence (SCOE) > > > >>-----Original Message----- >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>Sent: den 10 februari 2005 14:31 >>To: Stefan Santesson >>Cc: Russ Housley; pkix >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt >> >>Stefan, >> >>There is a major security issue here. >> >> >>>Denis, >>> >>>It is obvious that you base your objections on the assumption that a >> > CRL > >>>issuer cert MUST be issued by the CA issuing the validated subject >> > cert. > >>>But you also admit that this is what you think the stand should say >> > but > >>>do not say (at least not explicitly). >>> >>>Quote from your text: "This is not explicitly stated in RFC 3280 for >> > CRL > >>>issuers, but it is for OCSP responders" >>> >>>I guess it will be useless to get into details before we have sorted >> > out > >>>this major cause of disagreement. But since even you admit that >> > there is > >>>no such requirement in RFC 3280 (nor X.509), I'm not sure what there >> > is > >>>to discuss. >> >>The security considerations section needs to be discussed. >> >>The current text is: >> >> Implementers should take into account the possible existence of >> multiple unrelated CAs and CRL issuers with the same name. As >> means of reducing problems and security issues related to issuer >> name collisions, CA names SHOULD be formed in a way that reduce > > the > >> likelihood of name collisions. >> >>The SHOULD in the previous sentence does not solve the problem, since > > this > >>cannot be prevented. The text should explain how to have a secure > > system > >>even in the case of a name collision, i.e. two CAs pick the same name > > to > >>designate a CRL issuer but that name now relates to two different >>entities. >> >> Implementations validating CRLs >> MUST ensure that the certification path of the target > > certificate > >> and the CRL issuer certification path used to validate the > > target > >> certificate, terminate at the same trust anchor. >> >>This sentence does not solve the problem. The only way to solve the >>problem >>is, for relying parties, to be able to know unambiguously which CA is >>allowed to certify the CRL issuer name. It cannot be "any CA" in a >>certification tree. >> >>Since the syntax of the cRLIssuer contained in DistributionPoint does > > not > >>permit to place any other information than a name, it cannot designate > > the > >>CA allowed to certify the CRL issuer name, hence there needs to be a > > fixed > >>rule to be known by all relying parties. >> >>The fixed rule I proposed mimics the conditions of the OCSP responder, >>i.e. >> >> "The CRL Issuer must have a specially marked certificate issued >> directly by the CA, indicating that the CRL issuer may issue CRLs". >> >>Can there be another rule which guarantes that there is no ambiguity > > about > >>the right CRL issuer bearing the name contained in cRLIssuer ? The > > answer > >>is >>no, ... unless you demonstrate the contrary. >> >>Note: remember that the CA cannot know in advanced which trust > > anchor(s) > >>will be placed in the validation policies used by relying parties. >> >>Denis >> >> >> > > From owner-ietf-pkix Thu Feb 10 08:44:56 2005 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 j1AGiu4h062714; Thu, 10 Feb 2005 08:44:56 -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 j1AGiuVQ062713; Thu, 10 Feb 2005 08:44:56 -0800 (PST) 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 j1AGitLa062695 for ; Thu, 10 Feb 2005 08:44:55 -0800 (PST) (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 RAA28762; Thu, 10 Feb 2005 17:58:16 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021017444175:1405 ; Thu, 10 Feb 2005 17:44:41 +0100 Message-ID: <420B8F34.30807@bull.net> Date: Thu, 10 Feb 2005 17:43:32 +0100 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt References: <0C3042E92D8A714783E2C44AB9936E1D019F9C0A@EUR-MSG-03.europe.corp.microsoft.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 17:44:41, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 17:44:43, Serialize complete at 10/02/2005 17:44:43 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: Stefan, > Denis it looks like there are some misconceptions here: > Your scenario only applies to indirect CRLs. In X.509/ 3.3.32 indirect CRL (iCRL): A revocation list that at least contains revocation information about certificates issued by authorities other than that which issued this CRL. I already mentioned that this sentence is not crystal clear while RFC 3280 states: Whenever the CRL issuer is not the CA that issued the certificates, the CRL is referred to as an indirect CRL. ... which is worse and would need to be corrected. However, this is not the main issue for this thread. Don't you mean the reverse ? i.e. you scenario applies to indirect CRLs while mine does not apply to indirect CRL, but only when the CRL only contains revocation information for certificates coming from one single CA ? Denis > For indirect CRLs both CDP > AND IDP MUST be present and at least 1 DP location/URL in CDP MUST match > at least one DP location/URL in IDP. > > This is already a requirement of both RFC 3280 and X.509. > > > >>This leads to the following conclusion: >> >> a) if the IDP is not present, then my scenario applies. >> b) if the IDP is present, then your scenario applies. > > > Conclusion: a) never apply to this problem space. > > > Stefan Santesson > Microsoft Security Center of Excellence (SCOE) > > > >>-----Original Message----- >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>Sent: den 10 februari 2005 17:21 >>To: Stefan Santesson >>Cc: Russ Housley; pkix >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt >> >>Stefan, >> >> > I think this question is the key issue: >> >> > >> >> >> Can there be another rule which guarantes that there is no > > ambiguity > >> >> about he right CRL issuer bearing the name contained in cRLIssuer > > ? > >> >> The answer is no, ... unless you demonstrate the contrary. >> >> >> Note: remember that the CA cannot know in advanced which trust >> >> anchor(s) will be placed in the validation policies used by > > relying > >> >> parties. >> >> >>Denis >> >> > If a relying party trust a rouge CA, then all bets are off. This is >>part >> > of the PKI fundamentals we have to accept. So the issue is to > > prevent > >> > matching of unrelated certs and CRLs from trusted issuers. >> >> > This is only a theoretically realistic threat if the CDP in the > > cert > >> > doesn't include any pointer/address to the CRL storage location > > (which > >> > should be considered really BAD practice). >> >>At this stage of explanations, the CRL pointer whether present or > > absent > >>does not help. We all know that it is possible to replace a CRL by >>another >>one since it is never required to secure the protocol to query CRLs. > > So an > >>attacker having noticed that two CRL issuer names are the same, might >>perform an active attack and exchange CRLs at will. >> >> > Storage location addresses >> > (which have to match between CDP and IDP if present) do have > > sufficient > >> > uniqueness characteristics to effectively mitigate accidental CA > > name > >> > collisions. In fact, there are ways to form CDP and IDP to > > completely > >> > eliminate this threat without imposing your requirement. >> >>Interresting. Your proposal would lead to the following: >> >> 1) both the CDP and the IDP MUST must be present, >> 2) then they must match. >> >> ... but the proposal would mandate the presence of the IDP. >> >>This leads to the following conclusion: >> >> a) if the IDP is not present, then my scenario applies. >> b) if the IDP is present, then your scenario applies. >> >>Both scenarios would then co-exist. >> >>If you can revise the main body of the draft along these lines, then > > we > >>may >>be close to an agreement. >> >>Then the second implication is : if the CRL issuer is under the same >>trust anchor, it will be trusted, otherwise it might not unless the > > other > >>trust anchor is also present in the validation policy. So the >>recommandation >>to use the same trust anchor would be better explained this way in the >>security considerations section. >> >>Denis >> >> > Yes - an extra level of security would be guaranteed if the rule > > you > >> > suggest would be imposed, but I think it is too late and too >> > restrictive. The threat is not material and realistic enough to > > justify > >> > a restriction that would declare perfectly secure current >> > implementations non-conformant. >> > >> > You are free to seek support for your position, but until you have >> > obtained rough consensus on your suggested limitation, the crl-aia >> > drafting process must assume that the limitation you suggest does > > NOT > >> > exist. >> > >> > >> > >> > Stefan Santesson >> > Microsoft Security Center of Excellence (SCOE) >> > >> > >> > >> >>-----Original Message----- >> >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >> >>Sent: den 10 februari 2005 14:31 >> >>To: Stefan Santesson >> >>Cc: Russ Housley; pkix >> >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt >> >> >> >>Stefan, >> >> >> >>There is a major security issue here. >> >> >> >> >> >>>Denis, >> >>> >> >>>It is obvious that you base your objections on the assumption that > > a > >> >> >> > CRL >> > >> >>>issuer cert MUST be issued by the CA issuing the validated subject >> >> >> > cert. >> > >> >>>But you also admit that this is what you think the stand should > > say > >> >> >> > but >> > >> >>>do not say (at least not explicitly). >> >>> >> >>>Quote from your text: "This is not explicitly stated in RFC 3280 > > for > >> >> >> > CRL >> > >> >>>issuers, but it is for OCSP responders" >> >>> >> >>>I guess it will be useless to get into details before we have > > sorted > >> >> >> > out >> > >> >>>this major cause of disagreement. But since even you admit that >> >> >> > there is >> > >> >>>no such requirement in RFC 3280 (nor X.509), I'm not sure what > > there > >> >> >> > is >> > >> >>>to discuss. >> >> >> >>The security considerations section needs to be discussed. >> >> >> >>The current text is: >> >> >> >> Implementers should take into account the possible existence > > of > >> >> multiple unrelated CAs and CRL issuers with the same name. > > As > >> >> means of reducing problems and security issues related to > > issuer > >> >> name collisions, CA names SHOULD be formed in a way that > > reduce > >> > >> > the >> > >> >> likelihood of name collisions. >> >> >> >>The SHOULD in the previous sentence does not solve the problem, > > since > >> > >> > this >> > >> >>cannot be prevented. The text should explain how to have a secure >> > >> > system >> > >> >>even in the case of a name collision, i.e. two CAs pick the same > > name > >> > >> > to >> > >> >>designate a CRL issuer but that name now relates to two different >> >>entities. >> >> >> >> Implementations validating CRLs >> >> MUST ensure that the certification path of the target >> > >> > certificate >> > >> >> and the CRL issuer certification path used to validate the >> > >> > target >> > >> >> certificate, terminate at the same trust anchor. >> >> >> >>This sentence does not solve the problem. The only way to solve the >> >>problem >> >>is, for relying parties, to be able to know unambiguously which CA > > is > >> >>allowed to certify the CRL issuer name. It cannot be "any CA" in a >> >>certification tree. >> >> >> >>Since the syntax of the cRLIssuer contained in DistributionPoint > > does > >> > >> > not >> > >> >>permit to place any other information than a name, it cannot > > designate > >> > >> > the >> > >> >>CA allowed to certify the CRL issuer name, hence there needs to be > > a > >> > >> > fixed >> > >> >>rule to be known by all relying parties. >> >> >> >>The fixed rule I proposed mimics the conditions of the OCSP > > responder, > >> >>i.e. >> >> >> >> "The CRL Issuer must have a specially marked certificate issued >> >> directly by the CA, indicating that the CRL issuer may issue > > CRLs". > >> >> >> >>Can there be another rule which guarantes that there is no > > ambiguity > >> > >> > about >> > >> >>the right CRL issuer bearing the name contained in cRLIssuer ? The >> > >> > answer >> > >> >>is >> >>no, ... unless you demonstrate the contrary. >> >> >> >>Note: remember that the CA cannot know in advanced which trust >> > >> > anchor(s) >> > >> >>will be placed in the validation policies used by relying parties. >> >> >> >>Denis >> >> >> >> >> >> >> > >> > >> >> > > From owner-ietf-pkix Thu Feb 10 09:06:40 2005 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 j1AH6edG064063; Thu, 10 Feb 2005 09:06:40 -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 j1AH6e3J064062; Thu, 10 Feb 2005 09:06:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.noc.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AH6dWj064053 for ; Thu, 10 Feb 2005 09:06:39 -0800 (PST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id E7AC562DB8; Thu, 10 Feb 2005 18:06:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id A43C444102; Thu, 10 Feb 2005 18:07:54 +0100 (CET) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30447-09; Thu, 10 Feb 2005 18:07:50 +0100 (CET) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id A4D2E440E6; Thu, 10 Feb 2005 18:07:50 +0100 (CET) Received: by callisto.cry.pto (sSMTP sendmail emulation); Thu, 10 Feb 2005 18:06:27 +0100 From: "Julien Stern" Date: Thu, 10 Feb 2005 18:06:27 +0100 To: Stefan Santesson Cc: Denis Pinkas , Russ Housley , pkix Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt Message-ID: <20050210170623.GA30257@cryptolog.com> Mail-Followup-To: Julien Stern , Stefan Santesson , Denis Pinkas , Russ Housley , pkix References: <0C3042E92D8A714783E2C44AB9936E1D019F9BD1@EUR-MSG-03.europe.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C3042E92D8A714783E2C44AB9936E1D019F9BD1@EUR-MSG-03.europe.corp.microsoft.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Feb 10, 2005 at 03:17:37PM -0000, Stefan Santesson wrote: > > I think this question is the key issue: > > > > Can there be another rule which guarantes that there is no ambiguity > about > > the right CRL issuer bearing the name contained in cRLIssuer ? The > answer > > is > > no, ... unless you demonstrate the contrary. > > > > Note: remember that the CA cannot know in advanced which trust > anchor(s) > > will be placed in the validation policies used by relying parties. > > > > Denis > > > > If a relying party trust a rouge CA, then all bets are off. This is part > of the PKI fundamentals we have to accept. So the issue is to prevent > matching of unrelated certs and CRLs from trusted issuers. I do not want to (re)start some heated discussions about this topic, but I'm still curious about the above assumption. Is there a consensus on it from all the list members ? Usually, when a security assumption is broken, there are consequences, but the often used "all bets are off" sentence is a fairly vague consequence. So what does this "all bets are off" mean ? - That the rogue CA can do anything it wants under its hierarchy ? - That the rogue CA can do anything it wants above its hierarchy ? - That the rogue CA can do anything it wants in any other hierarchy ? - That the earth will suddently spin the other way round ? :) - Something else ? (Quite arguably, my consequences still remain quite vague, but hopefully clarify my point). I mean, let's take Microsoft certificate store. And let's assume that some low-level CA far down in the hierarchy of some trust anchor gets corrupted. Do we really want it to be able to impact the security of the system as a whole, and in particular of all the other trust anchor hierarchies ? If this is the case, no system will be usable with two trust anchors with different security clearances. An other way to state the problem would be: is there a solution that would allow to limit the scope of a CA compromise to something much lower than "all bets are off" and if so, how practical would it be, and do we want to implement it somehow ? My (humble) position on the general topic would be directly inferred by an answer on the previous assumption. Regards, -- Julien Stern R&D director Cryptolog International SAS 16-18, rue Vulpian 75013 Paris Tel +33 1 44 08 73 04 From owner-ietf-pkix Thu Feb 10 10:43:02 2005 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 j1AIh2Wp069561; Thu, 10 Feb 2005 10:43:02 -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 j1AIh2Xd069560; Thu, 10 Feb 2005 10:43:02 -0800 (PST) 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 j1AIh1xZ069504 for ; Thu, 10 Feb 2005 10:43:01 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 10 Feb 2005 18:42:55 +0000 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt Date: Thu, 10 Feb 2005 18:42:48 -0000 Message-ID: <0C3042E92D8A714783E2C44AB9936E1D019F9C2D@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt thread-index: AcUPmKAwrnmlti8ETFecoy8pvA8e7gABWVMA From: "Stefan Santesson" To: "Denis Pinkas" Cc: "Russ Housley" , "pkix" X-OriginalArrivalTime: 10 Feb 2005 18:42:55.0663 (UTC) FILETIME=[55AECBF0:01C50FA0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1AIh2xZ069554 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, Sorry for being unclear, and maybe for not seeing what you try to say. What I meant was that the problem should not exist at all for non-indirect CRLs. Here I totally agree that the CRL and the CA can't have unrelated chaining. I'm not sure what the standard says about this but if this is unclear, then it should be made clear. What I further mean is that the existence of diversified cert and CRL paths is therefore only an issue for indirect CRLs, AND for indirect CRLs CDP and IDP matching IS a requirement. The conclusion I make is: The current text in the crl-aia draft is correct since diversified CRL and cert paths may exist where the CRL issuer cert is issued by someone else that the CA that issued the validated cert. Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 10 februari 2005 17:44 > To: Stefan Santesson > Cc: Russ Housley; pkix > Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > > > Stefan, > > > Denis it looks like there are some misconceptions here: > > > Your scenario only applies to indirect CRLs. > > In X.509/ 3.3.32 indirect CRL (iCRL): A revocation list that at least > contains revocation information about certificates issued by authorities > other than that which issued this CRL. > > I already mentioned that this sentence is not crystal clear while RFC 3280 > states: > > Whenever the CRL issuer is not the CA that issued the certificates, > the CRL is referred to as an indirect CRL. > > ... which is worse and would need to be corrected. However, this is not > the main issue for this thread. > > Don't you mean the reverse ? i.e. you scenario applies to indirect CRLs > while mine does not apply to indirect CRL, but only when the CRL only > contains revocation information for certificates coming from one single CA > ? > > Denis > > > For indirect CRLs both CDP > > AND IDP MUST be present and at least 1 DP location/URL in CDP MUST match > > at least one DP location/URL in IDP. > > > > This is already a requirement of both RFC 3280 and X.509. > > > > > > > >>This leads to the following conclusion: > >> > >> a) if the IDP is not present, then my scenario applies. > >> b) if the IDP is present, then your scenario applies. > > > > > > Conclusion: a) never apply to this problem space. > > > > > > Stefan Santesson > > Microsoft Security Center of Excellence (SCOE) > > > > > > > >>-----Original Message----- > >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > >>Sent: den 10 februari 2005 17:21 > >>To: Stefan Santesson > >>Cc: Russ Housley; pkix > >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > >> > >>Stefan, > >> > >> > I think this question is the key issue: > >> > >> > > >> > >> >> Can there be another rule which guarantes that there is no > > > > ambiguity > > > >> >> about he right CRL issuer bearing the name contained in cRLIssuer > > > > ? > > > >> >> The answer is no, ... unless you demonstrate the contrary. > >> > >> >> Note: remember that the CA cannot know in advanced which trust > >> >> anchor(s) will be placed in the validation policies used by > > > > relying > > > >> >> parties. > >> > >> >>Denis > >> > >> > If a relying party trust a rouge CA, then all bets are off. This is > >>part > >> > of the PKI fundamentals we have to accept. So the issue is to > > > > prevent > > > >> > matching of unrelated certs and CRLs from trusted issuers. > >> > >> > This is only a theoretically realistic threat if the CDP in the > > > > cert > > > >> > doesn't include any pointer/address to the CRL storage location > > > > (which > > > >> > should be considered really BAD practice). > >> > >>At this stage of explanations, the CRL pointer whether present or > > > > absent > > > >>does not help. We all know that it is possible to replace a CRL by > >>another > >>one since it is never required to secure the protocol to query CRLs. > > > > So an > > > >>attacker having noticed that two CRL issuer names are the same, might > >>perform an active attack and exchange CRLs at will. > >> > >> > Storage location addresses > >> > (which have to match between CDP and IDP if present) do have > > > > sufficient > > > >> > uniqueness characteristics to effectively mitigate accidental CA > > > > name > > > >> > collisions. In fact, there are ways to form CDP and IDP to > > > > completely > > > >> > eliminate this threat without imposing your requirement. > >> > >>Interresting. Your proposal would lead to the following: > >> > >> 1) both the CDP and the IDP MUST must be present, > >> 2) then they must match. > >> > >> ... but the proposal would mandate the presence of the IDP. > >> > >>This leads to the following conclusion: > >> > >> a) if the IDP is not present, then my scenario applies. > >> b) if the IDP is present, then your scenario applies. > >> > >>Both scenarios would then co-exist. > >> > >>If you can revise the main body of the draft along these lines, then > > > > we > > > >>may > >>be close to an agreement. > >> > >>Then the second implication is : if the CRL issuer is under the same > >>trust anchor, it will be trusted, otherwise it might not unless the > > > > other > > > >>trust anchor is also present in the validation policy. So the > >>recommandation > >>to use the same trust anchor would be better explained this way in the > >>security considerations section. > >> > >>Denis > >> > >> > Yes - an extra level of security would be guaranteed if the rule > > > > you > > > >> > suggest would be imposed, but I think it is too late and too > >> > restrictive. The threat is not material and realistic enough to > > > > justify > > > >> > a restriction that would declare perfectly secure current > >> > implementations non-conformant. > >> > > >> > You are free to seek support for your position, but until you have > >> > obtained rough consensus on your suggested limitation, the crl-aia > >> > drafting process must assume that the limitation you suggest does > > > > NOT > > > >> > exist. > >> > > >> > > >> > > >> > Stefan Santesson > >> > Microsoft Security Center of Excellence (SCOE) > >> > > >> > > >> > > >> >>-----Original Message----- > >> >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > >> >>Sent: den 10 februari 2005 14:31 > >> >>To: Stefan Santesson > >> >>Cc: Russ Housley; pkix > >> >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > >> >> > >> >>Stefan, > >> >> > >> >>There is a major security issue here. > >> >> > >> >> > >> >>>Denis, > >> >>> > >> >>>It is obvious that you base your objections on the assumption that > > > > a > > > >> >> > >> > CRL > >> > > >> >>>issuer cert MUST be issued by the CA issuing the validated subject > >> >> > >> > cert. > >> > > >> >>>But you also admit that this is what you think the stand should > > > > say > > > >> >> > >> > but > >> > > >> >>>do not say (at least not explicitly). > >> >>> > >> >>>Quote from your text: "This is not explicitly stated in RFC 3280 > > > > for > > > >> >> > >> > CRL > >> > > >> >>>issuers, but it is for OCSP responders" > >> >>> > >> >>>I guess it will be useless to get into details before we have > > > > sorted > > > >> >> > >> > out > >> > > >> >>>this major cause of disagreement. But since even you admit that > >> >> > >> > there is > >> > > >> >>>no such requirement in RFC 3280 (nor X.509), I'm not sure what > > > > there > > > >> >> > >> > is > >> > > >> >>>to discuss. > >> >> > >> >>The security considerations section needs to be discussed. > >> >> > >> >>The current text is: > >> >> > >> >> Implementers should take into account the possible existence > > > > of > > > >> >> multiple unrelated CAs and CRL issuers with the same name. > > > > As > > > >> >> means of reducing problems and security issues related to > > > > issuer > > > >> >> name collisions, CA names SHOULD be formed in a way that > > > > reduce > > > >> > > >> > the > >> > > >> >> likelihood of name collisions. > >> >> > >> >>The SHOULD in the previous sentence does not solve the problem, > > > > since > > > >> > > >> > this > >> > > >> >>cannot be prevented. The text should explain how to have a secure > >> > > >> > system > >> > > >> >>even in the case of a name collision, i.e. two CAs pick the same > > > > name > > > >> > > >> > to > >> > > >> >>designate a CRL issuer but that name now relates to two different > >> >>entities. > >> >> > >> >> Implementations validating CRLs > >> >> MUST ensure that the certification path of the target > >> > > >> > certificate > >> > > >> >> and the CRL issuer certification path used to validate the > >> > > >> > target > >> > > >> >> certificate, terminate at the same trust anchor. > >> >> > >> >>This sentence does not solve the problem. The only way to solve the > >> >>problem > >> >>is, for relying parties, to be able to know unambiguously which CA > > > > is > > > >> >>allowed to certify the CRL issuer name. It cannot be "any CA" in a > >> >>certification tree. > >> >> > >> >>Since the syntax of the cRLIssuer contained in DistributionPoint > > > > does > > > >> > > >> > not > >> > > >> >>permit to place any other information than a name, it cannot > > > > designate > > > >> > > >> > the > >> > > >> >>CA allowed to certify the CRL issuer name, hence there needs to be > > > > a > > > >> > > >> > fixed > >> > > >> >>rule to be known by all relying parties. > >> >> > >> >>The fixed rule I proposed mimics the conditions of the OCSP > > > > responder, > > > >> >>i.e. > >> >> > >> >> "The CRL Issuer must have a specially marked certificate issued > >> >> directly by the CA, indicating that the CRL issuer may issue > > > > CRLs". > > > >> >> > >> >>Can there be another rule which guarantes that there is no > > > > ambiguity > > > >> > > >> > about > >> > > >> >>the right CRL issuer bearing the name contained in cRLIssuer ? The > >> > > >> > answer > >> > > >> >>is > >> >>no, ... unless you demonstrate the contrary. > >> >> > >> >>Note: remember that the CA cannot know in advanced which trust > >> > > >> > anchor(s) > >> > > >> >>will be placed in the validation policies used by relying parties. > >> >> > >> >>Denis > >> >> > >> >> > >> >> > >> > > >> > > >> > >> > > > > > From owner-ietf-pkix Thu Feb 10 12:52:26 2005 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 j1AKqQuQ077350; Thu, 10 Feb 2005 12:52:26 -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 j1AKqQLe077349; Thu, 10 Feb 2005 12:52:26 -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 j1AKqOLB077322 for ; Thu, 10 Feb 2005 12:52:24 -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 PAA06315; Thu, 10 Feb 2005 15:52:21 -0500 (EST) Message-Id: <200502102052.PAA06315@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-pkixrep-03.txt Date: Thu, 10 Feb 2005 15:52:21 -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 : Internet X.509 Public Key Infrastructure Repository Locator Service Author(s) : S. Boeyen, P. Hallam-Baker Filename : draft-ietf-pkix-pkixrep-03.txt Pages : 4 Date : 2005-2-10 This document defines a PKI repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate using systems to locate PKI repositories based on a domain name, identify the protocols that can be used to access the repository, and obtain addresses for the servers that host the repository service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-03.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-pkixrep-03.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-pkixrep-03.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-2-10155948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-pkixrep-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-pkixrep-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-10155948.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Fri Feb 11 01:26:13 2005 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 j1B9QDsH086112; Fri, 11 Feb 2005 01:26:13 -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 j1B9QDtR086111; Fri, 11 Feb 2005 01:26:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1B9Q4WO086055 for ; Fri, 11 Feb 2005 01:26:08 -0800 (PST) (envelope-from ietf@augustcellars.com) Received: from romans (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id 6D1E975B29; Fri, 11 Feb 2005 01:25:58 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Sharon Boeyen'" Cc: "'IETF-PKIX'" Subject: RE: Draft-ietf-pkix-rfc2511bis-07 Date: Fri, 11 Feb 2005 01:36:01 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C50FDA.0CB4F480" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F03A03168@sottmxs05.entrust.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUOxTYq5CsGRJhUTxivhI5PuudQqwBU8v+g Message-Id: <20050211092558.6D1E975B29@smtp2.pacifier.net> 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_004E_01C50FDA.0CB4F480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sharon, My problem on the timing of getting remarks in -- since we haven't started last call and I have some comments that required an update to the document anyway. 1. I will define a new OID for this. My assumption is that the old one should be obsoleted as this change was made by the original authors of the draft, I assume in response to interop changes and replaced with the new UTF8String regInfo item. 2. I would disagree with the statement that since EncryptedValue is used in existing products it should not be deprecated, however I am willing to be convinced that we need to keep it. I deprecated the use of the structure for the following reasons: a) There is no identification in the structure as to what public key was used to encrypt the symmetric key. This means that servers must guess as to which private key is used in the decryption operation (or try multiple keys). b) There is no method of changing the structure to be encrypted, but for the reasons covered at the start of section 4.2.1 I did just that in this document. The document does not allow for the encryption of just the PrivateKeyInfo structure anymore. c) The content within the EncryptedValue structure was context sensitive, but not tagged as to actual content. It might be either a certificate or a private key. d) It is not possible to do encryption with key agreement keys given the lack of location to place the sender public key or to identify where it came from. e) It is currently necessary to implement both EncryptedValue and EnvelopedData to implement the spec. This would tend to violate the edict from the chairs that we should avoid, when possible, having two different ways of accomplishing the same thing. f) The structure valueHint is under defined if it is to be meaningfully used. The only marginal advantage that I see is that EncryptedValue uses bit strings rather than octet strings to wrap the data, but as they are almost always in 8 byte quantities with all of the common algorithms in use this seems to be of dubious benefit. I am not sure what indendedAlg was actually suppose to be used for. This seems to be duplicate information with the algorithm identifier associated with the public key in the certificate request, although I suppose the first could be rsa-oaep and the latter rsa-enc. jim _____ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sharon Boeyen Sent: Wednesday, February 09, 2005 7:58 AM To: 'Stephen Kent'; jimsch@exmsft.com Cc: IETF-PKIX Subject: RE: Draft-ietf-pkix-rfc2511bis-07 Jim, sorry for the delay in responding. I have 2 comments: 1) The new document completely changes the meaning of an Object Identifer (changing the name as well as the syntax). In the original RFC (see page 11), the OID was defined as follows: id-regInfo-asciiPairs OBJECT IDENTIFIER ::= {id-regInfo 1} --with syntax OCTET STRING (however in Appendix B they call this id-regInfo-utf8Pairs with a syntax of OCTET STRING, so there was some confusion even back then) In the new RFC it changes to: id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= {id-regInfo 1} --with syntax UTF8String (see section 7.1. OIDs cannot be redefined like this. I suggest you leave the old OID as is and define a new one for UTF8 String. 2) The use of the EncryptedValue structure has been deprecated. This is one of the two choices for conveying an encrypted key in the archive options control that would appear in the controls element of the cert request. The other choice is envelopedData. EncryptedValue is in use in existing products and therefore should not be deprecated. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Friday, January 07, 2005 4:04 PM To: jimsch@exmsft.com Cc: IETF-PKIX Subject: Re: Draft-ietf-pkix-rfc2511bis-07 Folks, Jim sent this message in mid-December and I have seen no response on the list, so far. if nobody responds to Jim, Tim and I will interpret this as implicit authorization for Jim to proceed as he see fit on this topics. Steve >As advertized this draft is now under new editorship. As the new >editor there are a number of issues that I fill still need to be >resolved before this draft can go to last call. If there is no help >forth coming then I will be making arbitrary decions on these issue. > >Additionally, if anyone has kept any of the final reports from the >interop trials for CMP, I would like to see the sections that relate to >CRMF. > >You can easily find the open issues and questions by searching for [[[ >in the document. > >1. Section 4.1 - I have a partial answer for this question dealing >with non DN style names that are authenticated, but are not actually >either subject names (DNs) or subject alt names (General Names). The >only real question at this point is should this rational be documented. > >2. Section 4.2 - I am worried about the possiblity of somebody copying >an encrypted private key being sent to the CA/RA and then copying it >into their own certificate request. They could then later request a >key recovery from the CA/RA and get back somebody elses private key. >This is the reason that I am worried about how a POP proof is done >here. One potential answer is to include the authenticated identity >along with the private key in the encrypted block. > >3. Section 4.2 - We MUST solve the question of what the contents of >the encrypted blob look like. One potential answer is to obsolete >thisMessage and reaplace it with an EnvelopedData then all that needs >to be covered is the format of the encrypted key plus any POP info >required. > >4. Section 4.3 - Does the DH section need to be expanded so that any >key agreement key pair can be used? This can be done by adding a MAC >alg and value pair to the end of the POPOPrivKey choice (and >potentially obsoleting the dhMAC element). > >5. Section 4.4 - Two questions regarding guidence for the number of >iterations and the amount of salt to be used. We need a cryptographer >to give us some guidelines for these details, or atleast need to set >some minimums. > >6. Section 6.1 & 6.2 - The content of these controls is not well >defined and a couple of questions regarding this are asked. This may >have been addressed in the interop by adding some undocumented >restrictions. > >7. Section 6.4 - There are a couple of archive questions here. At >this point my inclination is to kill the entire section unless somebody >wants to make it acutally work. > >8. Section 6.8 - Ditto here. > >9. Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%" The parsing is >difficult (but not impossible) due to the overload of the % token. > >Jim ------=_NextPart_000_004E_01C50FDA.0CB4F480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Draft-ietf-pkix-rfc2511bis-07
Sharon,
 
My problem on the timing of getting remarks = in -- since=20 we haven't started last call and I have some comments that required an = update to=20 the document anyway.
 
1.  I will define a new OID for = this.  My=20 assumption is that the old one should be obsoleted as this change was = made by=20 the original authors of the draft, I assume in response to interop = changes and=20 replaced with the new UTF8String regInfo item.
 
2.  I would disagree with the statement = that since=20 EncryptedValue is used in existing products it should not be deprecated, = however=20 I am willing to be convinced that we need to keep it.  I deprecated = the use=20 of the structure for the following reasons:
 
a) There is no identification in the = structure as to=20 what public key was used to encrypt the symmetric key.  This means = that=20 servers must guess as to which private key is used in the decryption = operation=20 (or try multiple keys).
 
b) There is no method of changing the = structure to be=20 encrypted, but for the reasons covered at the start of section 4.2.1 I = did just=20 that in this document.  The document does not allow for the = encryption of=20 just the PrivateKeyInfo structure anymore.
 
c) The content within the EncryptedValue = structure was=20 context sensitive, but not tagged as to actual content.  It might = be either=20 a certificate or a private key.
 
d) It is = not possible=20 to do encryption with key agreement keys given the lack of location to = place the=20 sender public key or to identify where it came=20 from.
 
e) It is currently necessary to implement = both=20 EncryptedValue and EnvelopedData to implement the spec.  This would = tend to=20 violate the edict from the chairs that we should avoid, when possible, = having=20 two different ways of accomplishing the same=20 thing.
 
f) The=20 structure valueHint is under defined if it is to be meaningfully=20 used.
 
The=20 only marginal advantage that I see is that EncryptedValue uses bit = strings=20 rather than octet strings to wrap the data, but as they are almost = always in 8=20 byte quantities with all of the common algorithms in use this seems to = be of=20 dubious benefit.
 
I am=20 not sure what indendedAlg was actually suppose to be used for.  = This seems=20 to be duplicate information with the algorithm identifier associated = with the=20 public key in the certificate request, although I suppose the first = could be=20 rsa-oaep and the latter rsa-enc.
 
jim

From: owner-ietf-pkix@mail.imc.org = [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sharon=20 Boeyen
Sent: Wednesday, February 09, 2005 7:58 = AM
To:=20 'Stephen Kent'; jimsch@exmsft.com
Cc: = IETF-PKIX
Subject:=20 RE: Draft-ietf-pkix-rfc2511bis-07

Jim, sorry for the delay in responding. I have 2=20 comments:

1) The new document completely changes the meaning = of an=20 Object Identifer (changing the name as well as the syntax). In the = original=20 RFC (see page 11), the OID was defined as follows:


id-regInfo-asciiPairs  OBJECT=20 IDENTIFIER  ::=3D {id-regInfo 1} --with syntax OCTET = STRING=20
(however in Appendix B they call this = id-regInfo-utf8Pairs=20 with a syntax of OCTET STRING, so there was some confusion even back=20 then)


In the new RFC it changes = to:=20
 
id-regInfo-utf8Pairs =20 OBJECT IDENTIFIER  ::=3D {id-regInfo 1} --with syntax UTF8String = (see=20 section 7.1.
 
OIDs=20 cannot be redefined like this.  I suggest you leave the old OID = as is and=20 define a new one for UTF8 String.

2) The use of the EncryptedValue structure has been=20 deprecated. This is one of the two choices for conveying an encrypted = key in=20 the archive options control that would appear in the controls element = of the=20 cert request. The other choice is envelopedData. EncryptedValue is in = use in=20 existing products and therefore should not be deprecated.

Cheers,
Sharon

-----Original Message-----
From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.= imc.org]=20 On Behalf Of Stephen Kent
Sent: Friday, = January 07,=20 2005 4:04 PM
To: jimsch@exmsft.com =
Cc: IETF-PKIX
Subject: Re:=20 Draft-ietf-pkix-rfc2511bis-07



Folks,

Jim sent this message in mid-December and I have = seen no=20 response on
the list, so far.  if = nobody responds=20 to Jim, Tim and I will
interpret this as = implicit=20 authorization for Jim to proceed as he see
fit on this=20 topics.

Steve


>As advertized this draft is now under new=20 editorship.  As the new
>editor = there are a=20 number of issues that I fill still need to be
>resolved before this draft can go to last call.  If = there is=20 no help
>forth coming then I will be = making=20 arbitrary decions on these issue.
>=20
>Additionally, if anyone has kept any of the = final reports=20 from the
>interop trials for CMP, I would = like to=20 see the sections that relate to
>CRMF.=20
>
>You can easily = find the open=20 issues and questions by searching for [[[
>in the=20 document.
>
>1. =20 Section 4.1 - I have a partial answer for this question dealing=20
>with non DN style names that are = authenticated,=20 but are not actually
>either subject = names (DNs) or=20 subject alt names (General Names).  The
>only=20 real question at this point is should this rational be = documented.=20
>
>2.  Section = 4.2 - I am=20 worried about the possiblity of somebody copying
>an encrypted private key being sent to the CA/RA and then = copying=20 it
>into their own certificate = request.  They=20 could then later request a
>key recovery = from the=20 CA/RA and get back somebody elses private key. 
>This is the reason that I am worried about how a POP = proof is done=20
>here.  One potential answer is to = include the=20 authenticated identity
>along with the = private key=20 in the encrypted block.
> =
>3.  Section 4.2 - We MUST solve the question of what = the=20 contents of
>the encrypted blob look = like. =20 One potential answer is to obsolete
>thisMessage=20 and reaplace it with an EnvelopedData then all that needs =
>to be covered is the format of the encrypted key plus any = POP info=20
>required.
>=20
>4.  Section 4.3 - Does the DH section need = to be=20 expanded so that any
>key agreement key = pair can be=20 used?  This can be done by adding a MAC
>alg=20 and value pair to the end of the POPOPrivKey choice (and =
>potentially obsoleting the dhMAC element). =
>
>5.  Section 4.4 - Two = questions=20 regarding guidence for the number of
>iterations=20 and the amount of salt to be used.  We need a cryptographer=20
>to give us some guidelines for these = details, or=20 atleast need to set
>some = minimums.=20
>
>6.  Section = 6.1 &=20 6.2 - The content of these controls is not well
>defined and a couple of questions regarding this are = asked. =20 This may
>have been addressed in the = interop by=20 adding some undocumented
>restrictions.=20
>
>7.  Section = 6.4 - There=20 are a couple of archive questions here.  At
>this point my inclination is to kill the entire section = unless=20 somebody
>wants to make it acutally = work.=20
>
>8.  Section = 6.8 - Ditto=20 here.
>
>9. =20 Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%"   = The=20 parsing is
>difficult (but not = impossible) due to=20 the overload of the % token.
> =
>Jim

------=_NextPart_000_004E_01C50FDA.0CB4F480-- From owner-ietf-pkix Fri Feb 11 02:33:40 2005 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 j1BAXe6d010568; Fri, 11 Feb 2005 02:33:40 -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 j1BAXe0o010567; Fri, 11 Feb 2005 02:33:40 -0800 (PST) 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 j1BAXac8010502 for ; Fri, 11 Feb 2005 02:33:37 -0800 (PST) (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 LAA48986; Fri, 11 Feb 2005 11:46:52 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021111331764:1643 ; Fri, 11 Feb 2005 11:33:17 +0100 Message-ID: <420C89EC.2090405@bull.net> Date: Fri, 11 Feb 2005 11:33:16 +0100 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt References: <0C3042E92D8A714783E2C44AB9936E1D019F9C2D@EUR-MSG-03.europe.corp.microsoft.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/02/2005 11:33:17, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/02/2005 11:33:19, Serialize complete at 11/02/2005 11:33:19 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: Stefan, > Denis, > > Sorry for being unclear, and maybe for not seeing what you try to say. > > What I meant was that the problem should not exist at all for > non-indirect CRLs. Here I totally agree that the CRL and the CA can't > have unrelated chaining. I'm not sure what the standard says about this > but if this is unclear, then it should be made clear. > > What I further mean is that the existence of diversified cert and CRL > paths is therefore only an issue for indirect CRLs, AND for indirect > CRLs CDP and IDP matching IS a requirement. > > The conclusion I make is: The current text in the crl-aia draft is > correct since diversified CRL and cert paths may exist where the CRL > issuer cert is issued by someone else that the CA that issued the > validated cert. The problem is that neither the abstract nor the introduction of this draft is limiting the scope to indirect CRLs only. The point is that a relying party cannot know in advance whether indirect CRLs or "direct CRLs" are being used. So the story starts when the relying party gets a "candidate CRL" from the CRL DP and then it can see whether it contains or not an IDP. The draft should thus address the two scenarios (i.e. an IDP is or is not present) and for direct CRLs there is no "superiority" of the new extension. Would you prepare a revison of the draft along these lines ? If you agree, I woud propose that we discuss off-line with your co-editor the details of the new draft and come back to the list when a new draft is ready. Denis > Stefan Santesson > Microsoft Security Center of Excellence (SCOE) > > > >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > >>On Behalf Of Denis Pinkas >>Sent: den 10 februari 2005 17:44 >>To: Stefan Santesson >>Cc: Russ Housley; pkix >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt >> >> >>Stefan, >> >> >>>Denis it looks like there are some misconceptions here: >> >>>Your scenario only applies to indirect CRLs. >> >>In X.509/ 3.3.32 indirect CRL (iCRL): A revocation list that at least >>contains revocation information about certificates issued by > > authorities > >>other than that which issued this CRL. >> >>I already mentioned that this sentence is not crystal clear while RFC > > 3280 > >>states: >> >> Whenever the CRL issuer is not the CA that issued the > > certificates, > >> the CRL is referred to as an indirect CRL. >> >> ... which is worse and would need to be corrected. However, this is > > not > >>the main issue for this thread. >> >>Don't you mean the reverse ? i.e. you scenario applies to indirect > > CRLs > >>while mine does not apply to indirect CRL, but only when the CRL only >>contains revocation information for certificates coming from one > > single CA > >>? >> >>Denis >> >> >>>For indirect CRLs both CDP >>>AND IDP MUST be present and at least 1 DP location/URL in CDP MUST >> > match > >>>at least one DP location/URL in IDP. >>> >>>This is already a requirement of both RFC 3280 and X.509. >>> >>> >>> >>>>This leads to the following conclusion: >>>> >>>> a) if the IDP is not present, then my scenario applies. >>>> b) if the IDP is present, then your scenario applies. >>> >>> >>>Conclusion: a) never apply to this problem space. >>> >>> >>>Stefan Santesson >>>Microsoft Security Center of Excellence (SCOE) >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>>>Sent: den 10 februari 2005 17:21 >>>>To: Stefan Santesson >>>>Cc: Russ Housley; pkix >>>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt >>>> >>>>Stefan, >>>> >>>> >>>>>I think this question is the key issue: >>>> >>>>> >>>> >>>>>>Can there be another rule which guarantes that there is no >>>>> >>>ambiguity >>> >>> >>>>>>about he right CRL issuer bearing the name contained in >>>>> > cRLIssuer > >>>? >>> >>> >>>>>>The answer is no, ... unless you demonstrate the contrary. >>>>> >>>>>>Note: remember that the CA cannot know in advanced which trust >>>>>>anchor(s) will be placed in the validation policies used by >>>>> >>>relying >>> >>> >>>>>>parties. >>>>> >>>>>>Denis >>>>> >>>>>If a relying party trust a rouge CA, then all bets are off. This >>>> > is > >>>>part >>>> >>>>>of the PKI fundamentals we have to accept. So the issue is to >>>> >>>prevent >>> >>> >>>>>matching of unrelated certs and CRLs from trusted issuers. >>>> >>>>>This is only a theoretically realistic threat if the CDP in the >>>> >>>cert >>> >>> >>>>>doesn't include any pointer/address to the CRL storage location >>>> >>>(which >>> >>> >>>>>should be considered really BAD practice). >>>> >>>>At this stage of explanations, the CRL pointer whether present or >>> >>>absent >>> >>> >>>>does not help. We all know that it is possible to replace a CRL by >>>>another >>>>one since it is never required to secure the protocol to query CRLs. >>> >>>So an >>> >>> >>>>attacker having noticed that two CRL issuer names are the same, >>> > might > >>>>perform an active attack and exchange CRLs at will. >>>> >>>> > Storage location addresses >>>> >>>>>(which have to match between CDP and IDP if present) do have >>>> >>>sufficient >>> >>> >>>>>uniqueness characteristics to effectively mitigate accidental CA >>>> >>>name >>> >>> >>>>>collisions. In fact, there are ways to form CDP and IDP to >>>> >>>completely >>> >>> >>>>>eliminate this threat without imposing your requirement. >>>> >>>>Interresting. Your proposal would lead to the following: >>>> >>>> 1) both the CDP and the IDP MUST must be present, >>>> 2) then they must match. >>>> >>>> ... but the proposal would mandate the presence of the IDP. >>>> >>>>This leads to the following conclusion: >>>> >>>> a) if the IDP is not present, then my scenario applies. >>>> b) if the IDP is present, then your scenario applies. >>>> >>>>Both scenarios would then co-exist. >>>> >>>>If you can revise the main body of the draft along these lines, then >>> >>>we >>> >>> >>>>may >>>>be close to an agreement. >>>> >>>>Then the second implication is : if the CRL issuer is under the same >>>>trust anchor, it will be trusted, otherwise it might not unless the >>> >>>other >>> >>> >>>>trust anchor is also present in the validation policy. So the >>>>recommandation >>>>to use the same trust anchor would be better explained this way in >>> > the > >>>>security considerations section. >>>> >>>>Denis >>>> >>>> >>>>>Yes - an extra level of security would be guaranteed if the rule >>>> >>>you >>> >>> >>>>>suggest would be imposed, but I think it is too late and too >>>>>restrictive. The threat is not material and realistic enough to >>>> >>>justify >>> >>> >>>>>a restriction that would declare perfectly secure current >>>>>implementations non-conformant. >>>>> >>>>>You are free to seek support for your position, but until you >>>> > have > >>>>>obtained rough consensus on your suggested limitation, the >>>> > crl-aia > >>>>>drafting process must assume that the limitation you suggest does >>>> >>>NOT >>> >>> >>>>>exist. >>>>> >>>>> >>>>> >>>>>Stefan Santesson >>>>>Microsoft Security Center of Excellence (SCOE) >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>>>>>Sent: den 10 februari 2005 14:31 >>>>>>To: Stefan Santesson >>>>>>Cc: Russ Housley; pkix >>>>>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt >>>>>> >>>>>>Stefan, >>>>>> >>>>>>There is a major security issue here. >>>>>> >>>>>> >>>>>> >>>>>>>Denis, >>>>>>> >>>>>>>It is obvious that you base your objections on the assumption >>>>>> > that > >>>a >>> >>> >>>>>CRL >>>>> >>>>> >>>>>>>issuer cert MUST be issued by the CA issuing the validated >>>>>> > subject > >>>>>cert. >>>>> >>>>> >>>>>>>But you also admit that this is what you think the stand should >>>>>> >>>say >>> >>> >>>>>but >>>>> >>>>> >>>>>>>do not say (at least not explicitly). >>>>>>> >>>>>>>Quote from your text: "This is not explicitly stated in RFC 3280 >>>>>> >>>for >>> >>> >>>>>CRL >>>>> >>>>> >>>>>>>issuers, but it is for OCSP responders" >>>>>>> >>>>>>>I guess it will be useless to get into details before we have >>>>>> >>>sorted >>> >>> >>>>>out >>>>> >>>>> >>>>>>>this major cause of disagreement. But since even you admit that >>>>>> >>>>>there is >>>>> >>>>> >>>>>>>no such requirement in RFC 3280 (nor X.509), I'm not sure what >>>>>> >>>there >>> >>> >>>>>is >>>>> >>>>> >>>>>>>to discuss. >>>>>> >>>>>>The security considerations section needs to be discussed. >>>>>> >>>>>>The current text is: >>>>>> >>>>>> Implementers should take into account the possible >>>>> > existence > >>>of >>> >>> >>>>>> multiple unrelated CAs and CRL issuers with the same name. >>>>> >>>As >>> >>> >>>>>> means of reducing problems and security issues related to >>>>> >>>issuer >>> >>> >>>>>> name collisions, CA names SHOULD be formed in a way that >>>>> >>>reduce >>> >>> >>>>>the >>>>> >>>>> >>>>>> likelihood of name collisions. >>>>>> >>>>>>The SHOULD in the previous sentence does not solve the problem, >>>>> >>>since >>> >>> >>>>>this >>>>> >>>>> >>>>>>cannot be prevented. The text should explain how to have a secure >>>>> >>>>>system >>>>> >>>>> >>>>>>even in the case of a name collision, i.e. two CAs pick the same >>>>> >>>name >>> >>> >>>>>to >>>>> >>>>> >>>>>>designate a CRL issuer but that name now relates to two different >>>>>>entities. >>>>>> >>>>>> Implementations validating CRLs >>>>>> MUST ensure that the certification path of the target >>>>> >>>>>certificate >>>>> >>>>> >>>>>> and the CRL issuer certification path used to validate the >>>>> >>>>>target >>>>> >>>>> >>>>>> certificate, terminate at the same trust anchor. >>>>>> >>>>>>This sentence does not solve the problem. The only way to solve >>>>> > the > >>>>>>problem >>>>>>is, for relying parties, to be able to know unambiguously which >>>>> > CA > >>>is >>> >>> >>>>>>allowed to certify the CRL issuer name. It cannot be "any CA" in >>>>> > a > >>>>>>certification tree. >>>>>> >>>>>>Since the syntax of the cRLIssuer contained in DistributionPoint >>>>> >>>does >>> >>> >>>>>not >>>>> >>>>> >>>>>>permit to place any other information than a name, it cannot >>>>> >>>designate >>> >>> >>>>>the >>>>> >>>>> >>>>>>CA allowed to certify the CRL issuer name, hence there needs to >>>>> > be > >>>a >>> >>> >>>>>fixed >>>>> >>>>> >>>>>>rule to be known by all relying parties. >>>>>> >>>>>>The fixed rule I proposed mimics the conditions of the OCSP >>>>> >>>responder, >>> >>> >>>>>>i.e. >>>>>> >>>>>> "The CRL Issuer must have a specially marked certificate issued >>>>>> directly by the CA, indicating that the CRL issuer may issue >>>>> >>>CRLs". >>> >>> >>>>>>Can there be another rule which guarantes that there is no >>>>> >>>ambiguity >>> >>> >>>>>about >>>>> >>>>> >>>>>>the right CRL issuer bearing the name contained in cRLIssuer ? >>>>> > The > >>>>>answer >>>>> >>>>> >>>>>>is >>>>>>no, ... unless you demonstrate the contrary. >>>>>> >>>>>>Note: remember that the CA cannot know in advanced which trust >>>>> >>>>>anchor(s) >>>>> >>>>> >>>>>>will be placed in the validation policies used by relying >>>>> > parties. > >>>>>>Denis >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> > > From owner-ietf-pkix Fri Feb 11 04:28:06 2005 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 j1BCS6Ae050090; Fri, 11 Feb 2005 04:28:06 -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 j1BCS6fA050088; Fri, 11 Feb 2005 04:28:06 -0800 (PST) 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 j1BCS243050028 for ; Fri, 11 Feb 2005 04:28:05 -0800 (PST) (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 j1BCRun15533; Fri, 11 Feb 2005 13:27:56 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 11 Feb 2005 13:27:57 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1BCRuP01660; Fri, 11 Feb 2005 13:27:56 +0100 (MET) Date: Fri, 11 Feb 2005 13:27:56 +0100 (MET) From: Peter Sylvester Message-Id: <200502111227.j1BCRuP01660@chandon.edelweb.fr> To: stefans@microsoft.com, Denis.Pinkas@bull.net Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt Cc: housley@vigilsec.com, ietf-pkix@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, It seems not only to me that you are trying to discuss a topic which is out of scope for this document. This document describes how to put a pointer to a repository at some particular place, not more. Assuming that you would have made some top down search through a CA that issued 1000 sub cas etc, you may end with something that has the required structure to validate the CRL. It just takes you some more time. Or, the AIA gives you a hint about what might be best to test first, not more, not less? It is not really better or worse than a SIA, or an implicit directory name, or whatever. Whether this list of certs that you obtain validates according to the same trust anchor is a problem that exists independantly of how you obtained the cert (path) that signed a crl, you are describing this as "it is never required to secure the protocol to query CRLs" Do you want this in the security section: The "pointer" obtained from the AIA extension and the resulting certificates do not indicate anything about the validity of the CRL. Thus, the same techniques to validate the CRL must be applied independantly how the information (i.e. a list of potentially validating certs) is obtained. You MAY say that this URI is not sufficient so a valid CRL cannot be determined at all by starting at that point and limiting the search in an inappropriate way. I may have overlooked something, in this case TIA for teaching :-) Peter From owner-ietf-pkix Fri Feb 11 04:04:24 2005 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 j1BC4OCl042524; Fri, 11 Feb 2005 04:04:24 -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 j1BC4OFT042523; Fri, 11 Feb 2005 04:04:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BC4MRP042446 for ; Fri, 11 Feb 2005 04:04:23 -0800 (PST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with ESMTP id E4F2514C041 for ; Fri, 11 Feb 2005 12:04:04 +0000 (GMT) Received: from smtp3.tcd.ie by localhost.localdomain (VaMailArmor-2.0.1.16) id 09767-5A409AA9; Fri, 11 Feb 2005 12:04:04 +0000 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id C1ACC14C041 for ; Fri, 11 Feb 2005 12:04:04 +0000 (GMT) Message-ID: <420C9F7B.1090001@cs.tcd.ie> Date: Fri, 11 Feb 2005 12:05:15 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-pkixrep-03.txt References: <200502102052.PAA06315@ietf.org> In-Reply-To: <200502102052.PAA06315@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.101; host: smtp3.tcd.ie) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, First time I've read this one (mea culpa). How'd you like to add "_XKMS" as another variant to this? Otherwise the "_HTTP" option is somewhat ambiguous. Cheers, Stephen. Internet-Drafts@ietf.org wrote: > 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 Repository Locator Service > Author(s) : S. Boeyen, P. Hallam-Baker > Filename : draft-ietf-pkix-pkixrep-03.txt > Pages : 4 > Date : 2005-2-10 > > This document defines a PKI repository locator service. The service > makes use of DNS SRV records defined in accordance with RFC 2782. The > service enables certificate using systems to locate PKI repositories > based on a domain name, identify the protocols that can be used to > access the repository, and obtain addresses for the servers that host > the repository service. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-03.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-pkixrep-03.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-pkixrep-03.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. From owner-ietf-pkix Fri Feb 11 22:39:25 2005 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 j1C6dPEB048000; Fri, 11 Feb 2005 22:39:25 -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 j1C6dPEc047999; Fri, 11 Feb 2005 22:39:25 -0800 (PST) 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 j1C6dLOm047901 for ; Fri, 11 Feb 2005 22:39:24 -0800 (PST) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 12 Feb 2005 06:40:53 +0000 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt Date: Sat, 12 Feb 2005 06:38:59 -0000 Message-ID: <0C3042E92D8A714783E2C44AB9936E1D019F9F77@EUR-MSG-03.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt thread-index: AcUQMOftF/wc2le/Tmq4kYTJi9jzgwAmorSg From: "Stefan Santesson" To: "Denis Pinkas" Cc: "Russ Housley" , "pkix" X-OriginalArrivalTime: 12 Feb 2005 06:40:53.0360 (UTC) FILETIME=[CC677700:01C510CD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1C6dOOm047991 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, No I don't see that a rewriting of the document is motivated at this point. There is nothing in the document that suggests that the specified approach is superior in any way. It is an optional mechanism to be used by those who whish to use it to find the CRL signer cert. I think the motivation for allowing this extension in CRLs is sufficiently stated in the document. Nothing you suggest is changing the technical outline of the specified solution. More comments below.. Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 11 februari 2005 11:33 > To: Stefan Santesson > Cc: Russ Housley; pkix > Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > > > Stefan, > > > Denis, > > > > Sorry for being unclear, and maybe for not seeing what you try to say. > > > > What I meant was that the problem should not exist at all for > > non-indirect CRLs. Here I totally agree that the CRL and the CA can't > > have unrelated chaining. I'm not sure what the standard says about this > > but if this is unclear, then it should be made clear. > > > > What I further mean is that the existence of diversified cert and CRL > > paths is therefore only an issue for indirect CRLs, AND for indirect > > CRLs CDP and IDP matching IS a requirement. > > > > The conclusion I make is: The current text in the crl-aia draft is > > correct since diversified CRL and cert paths may exist where the CRL > > issuer cert is issued by someone else that the CA that issued the > > validated cert. > > The problem is that neither the abstract nor the introduction of this > draft > is limiting the scope to indirect CRLs only. > [Stefan] That is because the scope of AIA in CRLs is not limited to indirect CRLs. > The point is that a relying party cannot know in advance whether indirect > CRLs or "direct CRLs" are being used. So the story starts when the relying > party gets a "candidate CRL" from the CRL DP and then it can see whether > it > contains or not an IDP. > [Stefan] This is incorrect. The data in each DP of the CDP will tell the RP whether the DP points to an indirect CRL. > The draft should thus address the two scenarios (i.e. an IDP is or is not > present) and for direct CRLs there is no "superiority" of the new > extension. > [Stefan] I don't see the point with that. The use of the AIA extension in CRL is not different for indirect or direct CRLs. > Would you prepare a revison of the draft along these lines ? > [Stefan] No, see above. > If you agree, I woud propose that we discuss off-line with your co-editor > the details of the new draft and come back to the list when a new draft is > ready. > > Denis > > > Stefan Santesson > > Microsoft Security Center of Excellence (SCOE) > > > > > > > >>-----Original Message----- > >>From: owner-ietf-pkix@mail.imc.org > > > > [mailto:owner-ietf-pkix@mail.imc.org] > > > >>On Behalf Of Denis Pinkas > >>Sent: den 10 februari 2005 17:44 > >>To: Stefan Santesson > >>Cc: Russ Housley; pkix > >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > >> > >> > >>Stefan, > >> > >> > >>>Denis it looks like there are some misconceptions here: > >> > >>>Your scenario only applies to indirect CRLs. > >> > >>In X.509/ 3.3.32 indirect CRL (iCRL): A revocation list that at least > >>contains revocation information about certificates issued by > > > > authorities > > > >>other than that which issued this CRL. > >> > >>I already mentioned that this sentence is not crystal clear while RFC > > > > 3280 > > > >>states: > >> > >> Whenever the CRL issuer is not the CA that issued the > > > > certificates, > > > >> the CRL is referred to as an indirect CRL. > >> > >> ... which is worse and would need to be corrected. However, this is > > > > not > > > >>the main issue for this thread. > >> > >>Don't you mean the reverse ? i.e. you scenario applies to indirect > > > > CRLs > > > >>while mine does not apply to indirect CRL, but only when the CRL only > >>contains revocation information for certificates coming from one > > > > single CA > > > >>? > >> > >>Denis > >> > >> > >>>For indirect CRLs both CDP > >>>AND IDP MUST be present and at least 1 DP location/URL in CDP MUST > >> > > match > > > >>>at least one DP location/URL in IDP. > >>> > >>>This is already a requirement of both RFC 3280 and X.509. > >>> > >>> > >>> > >>>>This leads to the following conclusion: > >>>> > >>>> a) if the IDP is not present, then my scenario applies. > >>>> b) if the IDP is present, then your scenario applies. > >>> > >>> > >>>Conclusion: a) never apply to this problem space. > >>> > >>> > >>>Stefan Santesson > >>>Microsoft Security Center of Excellence (SCOE) > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > >>>>Sent: den 10 februari 2005 17:21 > >>>>To: Stefan Santesson > >>>>Cc: Russ Housley; pkix > >>>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > >>>> > >>>>Stefan, > >>>> > >>>> > >>>>>I think this question is the key issue: > >>>> > >>>>> > >>>> > >>>>>>Can there be another rule which guarantes that there is no > >>>>> > >>>ambiguity > >>> > >>> > >>>>>>about he right CRL issuer bearing the name contained in > >>>>> > > cRLIssuer > > > >>>? > >>> > >>> > >>>>>>The answer is no, ... unless you demonstrate the contrary. > >>>>> > >>>>>>Note: remember that the CA cannot know in advanced which trust > >>>>>>anchor(s) will be placed in the validation policies used by > >>>>> > >>>relying > >>> > >>> > >>>>>>parties. > >>>>> > >>>>>>Denis > >>>>> > >>>>>If a relying party trust a rouge CA, then all bets are off. This > >>>> > > is > > > >>>>part > >>>> > >>>>>of the PKI fundamentals we have to accept. So the issue is to > >>>> > >>>prevent > >>> > >>> > >>>>>matching of unrelated certs and CRLs from trusted issuers. > >>>> > >>>>>This is only a theoretically realistic threat if the CDP in the > >>>> > >>>cert > >>> > >>> > >>>>>doesn't include any pointer/address to the CRL storage location > >>>> > >>>(which > >>> > >>> > >>>>>should be considered really BAD practice). > >>>> > >>>>At this stage of explanations, the CRL pointer whether present or > >>> > >>>absent > >>> > >>> > >>>>does not help. We all know that it is possible to replace a CRL by > >>>>another > >>>>one since it is never required to secure the protocol to query CRLs. > >>> > >>>So an > >>> > >>> > >>>>attacker having noticed that two CRL issuer names are the same, > >>> > > might > > > >>>>perform an active attack and exchange CRLs at will. > >>>> > >>>> > Storage location addresses > >>>> > >>>>>(which have to match between CDP and IDP if present) do have > >>>> > >>>sufficient > >>> > >>> > >>>>>uniqueness characteristics to effectively mitigate accidental CA > >>>> > >>>name > >>> > >>> > >>>>>collisions. In fact, there are ways to form CDP and IDP to > >>>> > >>>completely > >>> > >>> > >>>>>eliminate this threat without imposing your requirement. > >>>> > >>>>Interresting. Your proposal would lead to the following: > >>>> > >>>> 1) both the CDP and the IDP MUST must be present, > >>>> 2) then they must match. > >>>> > >>>> ... but the proposal would mandate the presence of the IDP. > >>>> > >>>>This leads to the following conclusion: > >>>> > >>>> a) if the IDP is not present, then my scenario applies. > >>>> b) if the IDP is present, then your scenario applies. > >>>> > >>>>Both scenarios would then co-exist. > >>>> > >>>>If you can revise the main body of the draft along these lines, then > >>> > >>>we > >>> > >>> > >>>>may > >>>>be close to an agreement. > >>>> > >>>>Then the second implication is : if the CRL issuer is under the same > >>>>trust anchor, it will be trusted, otherwise it might not unless the > >>> > >>>other > >>> > >>> > >>>>trust anchor is also present in the validation policy. So the > >>>>recommandation > >>>>to use the same trust anchor would be better explained this way in > >>> > > the > > > >>>>security considerations section. > >>>> > >>>>Denis > >>>> > >>>> > >>>>>Yes - an extra level of security would be guaranteed if the rule > >>>> > >>>you > >>> > >>> > >>>>>suggest would be imposed, but I think it is too late and too > >>>>>restrictive. The threat is not material and realistic enough to > >>>> > >>>justify > >>> > >>> > >>>>>a restriction that would declare perfectly secure current > >>>>>implementations non-conformant. > >>>>> > >>>>>You are free to seek support for your position, but until you > >>>> > > have > > > >>>>>obtained rough consensus on your suggested limitation, the > >>>> > > crl-aia > > > >>>>>drafting process must assume that the limitation you suggest does > >>>> > >>>NOT > >>> > >>> > >>>>>exist. > >>>>> > >>>>> > >>>>> > >>>>>Stefan Santesson > >>>>>Microsoft Security Center of Excellence (SCOE) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > >>>>>>Sent: den 10 februari 2005 14:31 > >>>>>>To: Stefan Santesson > >>>>>>Cc: Russ Housley; pkix > >>>>>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt > >>>>>> > >>>>>>Stefan, > >>>>>> > >>>>>>There is a major security issue here. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Denis, > >>>>>>> > >>>>>>>It is obvious that you base your objections on the assumption > >>>>>> > > that > > > >>>a > >>> > >>> > >>>>>CRL > >>>>> > >>>>> > >>>>>>>issuer cert MUST be issued by the CA issuing the validated > >>>>>> > > subject > > > >>>>>cert. > >>>>> > >>>>> > >>>>>>>But you also admit that this is what you think the stand should > >>>>>> > >>>say > >>> > >>> > >>>>>but > >>>>> > >>>>> > >>>>>>>do not say (at least not explicitly). > >>>>>>> > >>>>>>>Quote from your text: "This is not explicitly stated in RFC 3280 > >>>>>> > >>>for > >>> > >>> > >>>>>CRL > >>>>> > >>>>> > >>>>>>>issuers, but it is for OCSP responders" > >>>>>>> > >>>>>>>I guess it will be useless to get into details before we have > >>>>>> > >>>sorted > >>> > >>> > >>>>>out > >>>>> > >>>>> > >>>>>>>this major cause of disagreement. But since even you admit that > >>>>>> > >>>>>there is > >>>>> > >>>>> > >>>>>>>no such requirement in RFC 3280 (nor X.509), I'm not sure what > >>>>>> > >>>there > >>> > >>> > >>>>>is > >>>>> > >>>>> > >>>>>>>to discuss. > >>>>>> > >>>>>>The security considerations section needs to be discussed. > >>>>>> > >>>>>>The current text is: > >>>>>> > >>>>>> Implementers should take into account the possible > >>>>> > > existence > > > >>>of > >>> > >>> > >>>>>> multiple unrelated CAs and CRL issuers with the same name. > >>>>> > >>>As > >>> > >>> > >>>>>> means of reducing problems and security issues related to > >>>>> > >>>issuer > >>> > >>> > >>>>>> name collisions, CA names SHOULD be formed in a way that > >>>>> > >>>reduce > >>> > >>> > >>>>>the > >>>>> > >>>>> > >>>>>> likelihood of name collisions. > >>>>>> > >>>>>>The SHOULD in the previous sentence does not solve the problem, > >>>>> > >>>since > >>> > >>> > >>>>>this > >>>>> > >>>>> > >>>>>>cannot be prevented. The text should explain how to have a secure > >>>>> > >>>>>system > >>>>> > >>>>> > >>>>>>even in the case of a name collision, i.e. two CAs pick the same > >>>>> > >>>name > >>> > >>> > >>>>>to > >>>>> > >>>>> > >>>>>>designate a CRL issuer but that name now relates to two different > >>>>>>entities. > >>>>>> > >>>>>> Implementations validating CRLs > >>>>>> MUST ensure that the certification path of the target > >>>>> > >>>>>certificate > >>>>> > >>>>> > >>>>>> and the CRL issuer certification path used to validate the > >>>>> > >>>>>target > >>>>> > >>>>> > >>>>>> certificate, terminate at the same trust anchor. > >>>>>> > >>>>>>This sentence does not solve the problem. The only way to solve > >>>>> > > the > > > >>>>>>problem > >>>>>>is, for relying parties, to be able to know unambiguously which > >>>>> > > CA > > > >>>is > >>> > >>> > >>>>>>allowed to certify the CRL issuer name. It cannot be "any CA" in > >>>>> > > a > > > >>>>>>certification tree. > >>>>>> > >>>>>>Since the syntax of the cRLIssuer contained in DistributionPoint > >>>>> > >>>does > >>> > >>> > >>>>>not > >>>>> > >>>>> > >>>>>>permit to place any other information than a name, it cannot > >>>>> > >>>designate > >>> > >>> > >>>>>the > >>>>> > >>>>> > >>>>>>CA allowed to certify the CRL issuer name, hence there needs to > >>>>> > > be > > > >>>a > >>> > >>> > >>>>>fixed > >>>>> > >>>>> > >>>>>>rule to be known by all relying parties. > >>>>>> > >>>>>>The fixed rule I proposed mimics the conditions of the OCSP > >>>>> > >>>responder, > >>> > >>> > >>>>>>i.e. > >>>>>> > >>>>>> "The CRL Issuer must have a specially marked certificate issued > >>>>>> directly by the CA, indicating that the CRL issuer may issue > >>>>> > >>>CRLs". > >>> > >>> > >>>>>>Can there be another rule which guarantes that there is no > >>>>> > >>>ambiguity > >>> > >>> > >>>>>about > >>>>> > >>>>> > >>>>>>the right CRL issuer bearing the name contained in cRLIssuer ? > >>>>> > > The > > > >>>>>answer > >>>>> > >>>>> > >>>>>>is > >>>>>>no, ... unless you demonstrate the contrary. > >>>>>> > >>>>>>Note: remember that the CA cannot know in advanced which trust > >>>>> > >>>>>anchor(s) > >>>>> > >>>>> > >>>>>>will be placed in the validation policies used by relying > >>>>> > > parties. > > > >>>>>>Denis > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > > > > > From owner-ietf-pkix Mon Feb 14 14:58:41 2005 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 j1EMwfja060816; Mon, 14 Feb 2005 14:58:41 -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 j1EMwfhf060815; Mon, 14 Feb 2005 14:58:41 -0800 (PST) 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 j1EMwXAm060808 for ; Mon, 14 Feb 2005 14:58:33 -0800 (PST) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1EMwRj7007339; Mon, 14 Feb 2005 17:58:27 -0500 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 j1EMw7EY011047; Mon, 14 Feb 2005 17:58:07 -0500 (EST) Message-Id: <5.1.0.14.2.20050214175211.03946308@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 Feb 2005 17:59:09 -0500 To: ietf-pkix@imc.org From: Tim Polk Subject: SCVP Draft 17: Summary of changes Cc: trevorf@exchange.microsoft.com, housley@vigilsec.com, david.cooper@nist.gov, ambarish@malpani.biz 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: Folks, A new version of SCVP-17 was posted this afternoon. IMHO, this version fully satisfies RFC 3379, and is responsive to the comments submitted on the WG mailing list. Ever the optimist, I believe this draft is a strong candidate for WG consensus. Please spend some time reviewing the new draft so we can gauge consensus and either tweak the document before the ID submission deadline (next Monday!) or forward it to the ADs. In the interest of an efficient review, here is a summary of the changes: (1) All of the comments submitted to the list before Christmas were reviewed. Comments where Trevor had worked out a resolution on the list are included here and many (but not all) of the remaining comments were addressed. (2) Inconsistencies between the text and any ASN.1 structures have been resolved. (3) Draft 16 used the term "signed" to refer to messages protected by either a digital signature or a (H)MAC. Draft 17 refers to these messages as "protected" and reserves the word "signed" for messages protected by a digital signature. (4) The Diffie-Hellman based authentication method was changed from MUST to SHOULD implement. (5) The text for validation policies, validation algoriothms and name validation algorithms has all been revised for clarity. (6) A field has been added to the validation policy response message so that servers can indicate the type(s) of status information the server is capable of using, as required in RFC 3379. (7) Validation policies are now required to include default values for all parameters. Draft -16 permitted servers to create policies where clients were forced to supply values for some parameters. (8) A requestor name field was added to the cv request message, so that clients can include an asserted identity, as required in RFC 3379. Servers may still return an authenticated identity for the client if available. (9) The key usage and extended key usage specifications have been enhanced to permit a client to state "no requirements". (10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure from the scvp request message to indicate its policy (in the scvp response and policy response messages). (11) The validation error OIDs associated with the basic validation algorithm and name validation algorithm have been scrubbed. (12) The keyPurposeID in the name validation algorithm was renamed nameCompAlgId. While some of the OIDs specified in this document correspond to extended key usages, that is not a requirement of the specification. The important point was that the OID identified the algorithm used to compare names in the end certificate. (13) The isCA option to support partial path validation was removed from the validation policy. To use this feature securely, extensive additions to the protocol were required to return a set of interim state variables from an incomplete run of RFC 3280 Section 6.1 path validation. The complexity was considered an impediment to completion of the document and was not a requirement in RFC 3379. (This feature may be specified in a separate document in the future, using the SCVP extensions mechanism.) (14) Clients signal whether a cached response is acceptable using the responseFlags rather than a wantback as in draft -16. (15) When providing a list of certificates in the replyWantbacks in an scvp response message, servers are now required to order the certificates beginning with the end certificate. (This is a requirement stated in RFC 3379.) (16) When performing Diffie-Hellman where the client has an ephemeral key and the server has a static key, the ephemeral key is conveyed in the authenticated data wrapper rather than the cv request. The draft does not allow ephemeral - ephemeral but does support pre-shared keys. (17) A new failure code was added to reply status to handle the case where all checks were performed successfully, however one or more of the wantBacks could not be satisfied. (18) The replychecks for status checking were extended to cover the case where the server cannot locate a source of status information. (This differentiates the failure from one where a source is known but network or other errors prevented getting the information.) Of the comments which were not incorporated into the document: (A) The editors disagreed with the comment that path validation algorithms other than that in RFC 3280 should be supported. This is a PKIX WG specification, and there is no requirement in RFC 3379 to support non-PKIX path validation. Consequently, this change was not made. (B) The descriptions of validation algorithm and validation policy more clearly delineate the differences, but I am unsure if all of that class of comments are satisfied. (C) Changes to ASN.1 syntax for elegance alone were not implemented; beauty is in the eye of the beholder and that debate would never end. ASN.1 changes were only made to enforce restrictions specified in the text or for consistency with the text (e.g., add a missing item described elsewhere.) Thanks, Tim Polk From owner-ietf-pkix Tue Feb 15 02:39:09 2005 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 j1FAd9P5083003; Tue, 15 Feb 2005 02:39:09 -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 j1FAd9QJ083002; Tue, 15 Feb 2005 02:39:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx07.ms.so-net.ne.jp (mx07.ms.so-net.ne.jp [202.238.82.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FAcqTw082764 for ; Tue, 15 Feb 2005 02:39:01 -0800 (PST) (envelope-from m-shimaoka@secom.co.jp) Received: from [127.0.0.1] (p299e62.tkyoac00.ap.so-net.ne.jp [218.41.158.98]) by mx07.ms.so-net.ne.jp with ESMTP id j1FAcLDK006736 for ; Tue, 15 Feb 2005 19:38:21 +0900 (JST) Date: Tue, 15 Feb 2005 19:38:19 +0900 From: Masaki SHIMAOKA To: IETF-PKIX Subject: Question about updating the CA to change its DN encoding Message-Id: <20050215180705.EBF8.SHIMAOKA@secom.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I have one question about updating the CA to change its DN encoding. If the old CA and new CA have different keypairs, issue the self-issued certificates each other, and have same DN regardless of encoding, should both CA share the revocation information between their CRLs? # I believe that such self-issued certificates are the one called a name rollover certificate in RFC 3280. The reason why I wonder is that revocation information is specified by issuer and serial number. If an application assumes that DNs of such old CA and new CA is the same, the application may use to check the CRL issued by new CA for a certificate issued by old CA. And if the answer is YES in the case using such applications, it means anyone can make the CRL substitution attack easily. So, I hope the answer is NO and all applications should use to check the CRL issued by the signing key of the corresponding certificate issuer. Is it correct? -- shima From owner-ietf-pkix Tue Feb 15 04:33:54 2005 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 j1FCXs7r021829; Tue, 15 Feb 2005 04:33:54 -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 j1FCXsIN021828; Tue, 15 Feb 2005 04:33:54 -0800 (PST) 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 j1FCXgGn021637 for ; Tue, 15 Feb 2005 04:33:46 -0800 (PST) (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 NAA23592; Tue, 15 Feb 2005 13:46:45 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021513330679:204 ; Tue, 15 Feb 2005 13:33:06 +0100 Message-ID: <4211EC22.6050006@bull.net> Date: Tue, 15 Feb 2005 13:33:38 +0100 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: Tim Polk CC: ietf-pkix@imc.org, trevorf@exchange.microsoft.com, housley@vigilsec.com, david.cooper@nist.gov, ambarish@malpani.biz Subject: Re: SCVP Draft 17: Summary of changes References: <5.1.0.14.2.20050214175211.03946308@email.nist.gov> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 13:33:06, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 13:33:13, Serialize complete at 15/02/2005 13:33:13 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: Tim (or to the ever optimist) > Folks, > A new version of SCVP-17 was posted this afternoon. IMHO, this version > fully satisfies RFC 3379, and is responsive to the comments submitted on > the WG mailing list. My comments 46 to 68 have never been responded on the list. I replied to the disposition of comments for 1-45 stating that several comments were not correctly understood and resolved to my satisfaction, but I got no answer. Under these conditions, I am rather pessimistic, since I have not yet seen the draft. Denis > Ever the optimist, I believe this draft is a > strong candidate for WG consensus. > > Please spend some time reviewing the new draft so we can gauge consensus > and either tweak the document before the ID submission deadline (next > Monday!) or forward it to the ADs. > > In the interest of an efficient review, here is a summary of the changes: > > (1) All of the comments submitted to the list before Christmas were > reviewed. Comments where Trevor had worked out a resolution on the list > are included here and many (but not all) of the remaining comments were > addressed. > (2) Inconsistencies between the text and any ASN.1 structures have been > resolved. > (3) Draft 16 used the term "signed" to refer to messages protected by > either a digital signature or a (H)MAC. Draft 17 refers to these > messages as "protected" and reserves the word "signed" for messages > protected by a digital signature. > (4) The Diffie-Hellman based authentication method was changed from MUST > to SHOULD implement. > (5) The text for validation policies, validation algoriothms and name > validation algorithms has all been revised for clarity. > (6) A field has been added to the validation policy response message so > that servers can indicate the type(s) of status information the server > is capable of using, as required in RFC 3379. > (7) Validation policies are now required to include default values for > all parameters. Draft -16 permitted servers to create policies where > clients were forced to supply values for some parameters. > (8) A requestor name field was added to the cv request message, so that > clients can include an asserted identity, as required in RFC 3379. > Servers may still return an authenticated identity for the client if > available. > (9) The key usage and extended key usage specifications have been > enhanced to permit a client to state "no requirements". > (10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure > from the scvp request message to indicate its policy (in the scvp > response and policy response messages). > (11) The validation error OIDs associated with the basic validation > algorithm and name validation algorithm have been scrubbed. > (12) The keyPurposeID in the name validation algorithm was renamed > nameCompAlgId. While some of the OIDs specified in this document > correspond to extended key usages, that is not a requirement of the > specification. The important point was that the OID identified the > algorithm used to compare names in the end certificate. > (13) The isCA option to support partial path validation was removed from > the validation policy. To use this feature securely, extensive > additions to the protocol were required to return a set of interim state > variables from an incomplete run of RFC 3280 Section 6.1 path > validation. The complexity was considered an impediment to completion > of the document and was not a requirement in RFC 3379. (This feature > may be specified in a separate document in the future, using the SCVP > extensions mechanism.) > (14) Clients signal whether a cached response is acceptable using the > responseFlags rather than a wantback as in draft -16. > (15) When providing a list of certificates in the replyWantbacks in an > scvp response message, servers are now required to order the > certificates beginning with the end certificate. (This is a requirement > stated in RFC 3379.) > (16) When performing Diffie-Hellman where the client has an ephemeral > key and the server has a static key, the ephemeral key is conveyed in > the authenticated data wrapper rather than the cv request. The draft > does not allow ephemeral - ephemeral but does support pre-shared keys. > (17) A new failure code was added to reply status to handle the case > where all checks were performed successfully, however one or more of the > wantBacks could not be satisfied. > (18) The replychecks for status checking were extended to cover the case > where the server cannot locate a source of status information. (This > differentiates the failure from one where a source is known but network > or other errors prevented getting the information.) > > Of the comments which were not incorporated into the document: > > (A) The editors disagreed with the comment that path validation > algorithms other than that in RFC 3280 should be supported. This is a > PKIX WG specification, and there is no requirement in RFC 3379 to > support non-PKIX path validation. Consequently, this change was not made. > (B) The descriptions of validation algorithm and validation policy more > clearly delineate the differences, but I am unsure if all of that class > of comments are satisfied. > (C) Changes to ASN.1 syntax for elegance alone were not implemented; > beauty is in the eye of the beholder and that debate would never end. > ASN.1 changes were only made to enforce restrictions specified in the > text or for consistency with the text (e.g., add a missing item > described elsewhere.) > > Thanks, > > Tim Polk > > From owner-ietf-pkix Tue Feb 15 05:12:52 2005 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 j1FDCqqH035255; Tue, 15 Feb 2005 05:12:52 -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 j1FDCqRC035254; Tue, 15 Feb 2005 05:12:52 -0800 (PST) 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 j1FDCjHY035165 for ; Tue, 15 Feb 2005 05:12:48 -0800 (PST) (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 OAA62674; Tue, 15 Feb 2005 14:25:42 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021514120330:230 ; Tue, 15 Feb 2005 14:12:03 +0100 Message-ID: <4211F542.2080204@bull.net> Date: Tue, 15 Feb 2005 14:12:34 +0100 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: I-D ACTION:draft-ietf-pkix-crlaia-00.txt References: <0C3042E92D8A714783E2C44AB9936E1D019F9F77@EUR-MSG-03.europe.corp.microsoft.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 14:12:03, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 14:12:05, Serialize complete at 15/02/2005 14:12:05 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: Stefan, > Denis, > No I don't see that a rewriting of the document is motivated at this > point. It is your opinion, but not mine. > There is nothing in the document that suggests that the specified > approach is superior in any way. What about the following sentences picked from the document: 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. These methods are however not generally applicable, and they do not provide a generic solution to the problem. This is true only if indirect CRLs are being used, but the wording "indirect CRL" is absent from these lines. > It is an optional mechanism to be used > by those who whish to use it to find the CRL signer cert. ... which is really motivated when indirect CRLs are being used, but otherwise is not and the draft does not say it. > I think the motivation for allowing this extension in CRLs is > sufficiently stated in the document. It is not. In addition, adding an extension does not make sense unless you tell how it should be used. > Nothing you suggest is changing the > technical outline of the specified solution. In this case, the processing of this new extension may be explained and this is not the case at this time. > More comments below.. > > Stefan Santesson > Microsoft Security Center of Excellence (SCOE) > > >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > >>On Behalf Of Denis Pinkas >>Sent: den 11 februari 2005 11:33 >>To: Stefan Santesson >>Cc: Russ Housley; pkix >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt >> >> >>Stefan, >> >> >>>Denis, >>> >>> Sorry for being unclear, and maybe for not seeing what you try to >>> say. > >>> What I meant was that the problem should not exist at all for >>> non-indirect CRLs. Here I totally agree that the CRL and the CA >>> can't have unrelated chaining. I'm not sure what the standard says about >>> this but if this is unclear, then it should be made clear. >>> What I further mean is that the existence of diversified cert and >>> CRL paths is therefore only an issue for indirect CRLs, AND for indirect >>> CRLs CDP and IDP matching IS a requirement. >>> The conclusion I make is: The current text in the crl-aia draft is >>> correct since diversified CRL and cert paths may exist where the CRL >>> issuer cert is issued by someone else that the CA that issued the >>> validated cert. >> The problem is that neither the abstract nor the introduction of this >> draft is limiting the scope to indirect CRLs only. > [Stefan] That is because the scope of AIA in CRLs is not limited to > indirect CRLs. .. but this extension does not add anything, if SIA used. >> The point is that a relying party cannot know in advance whether >> indirect CRLs or "direct CRLs" are being used. So the story starts when the >> relying party gets a "candidate CRL" from the CRL DP and then it can see >> whether it contains or not an IDP. > [Stefan] This is incorrect. The data in each DP of the CDP will tell the > RP whether the DP points to an indirect CRL. DistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, reasons [1] ReasonFlags OPTIONAL, cRLIssuer [2] GeneralNames OPTIONAL } DistributionPointName ::= CHOICE { fullName [0] GeneralNames, nameRelativeToCRLIssuer [1] RelativeDistinguishedName } Which field are you talking about ? >> The draft should thus address the two scenarios (i.e. an IDP is or is >> not present) and for direct CRLs there is no "superiority" of the new >> extension. > [Stefan] I don't see the point with that. The use of the AIA extension > in CRL is not different for indirect or direct CRLs. With direct CRLs, there does not need to be any AIA extension, if the SIA extension in CA certificates is present. This is not said and should be said. Then the processing of the extension should be explained for indirect CRLs. Denis >>Would you prepare a revison of the draft along these lines ? > [Stefan] No, see above. >> If you agree, I woud propose that we discuss off-line with your >> co-editor the details of the new draft and come back to the list >> when a new draft is ready. >>Denis >>>Stefan Santesson >>>Microsoft Security Center of Excellence (SCOE) From owner-ietf-pkix Tue Feb 15 07:22:03 2005 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 j1FFM3Yn064169; Tue, 15 Feb 2005 07:22:03 -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 j1FFM38e064168; Tue, 15 Feb 2005 07:22:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFM1xi064123 for ; Tue, 15 Feb 2005 07:22:02 -0800 (PST) (envelope-from jmdesp@free.fr) Received: from [10.0.0.51] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft5.fr.colt.net with ESMTP id j1FFLk516073 for ; Tue, 15 Feb 2005 16:21:51 +0100 Message-ID: <4212138A.9080401@free.fr> Date: Tue, 15 Feb 2005 16:21:46 +0100 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en, fr, ja MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Question about updating the CA to change its DN encoding References: <20050215180705.EBF8.SHIMAOKA@secom.ne.jp> In-Reply-To: <20050215180705.EBF8.SHIMAOKA@secom.ne.jp> 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: Masaki SHIMAOKA wrote: >I have one question about updating the CA to change its DN encoding. > >If the old CA and new CA have different keypairs, issue the self-issued >certificates each other, and have same DN regardless of encoding, should >both CA share the revocation information between their CRLs? ># I believe that such self-issued certificates are the one called a name >rollover certificate in RFC 3280. > >The reason why I wonder is that revocation information is specified by >issuer and serial number. If an application assumes that DNs of such >old CA and new CA is the same, the application may use to check the CRL >issued by new CA for a certificate issued by old CA. >And if the answer is YES in the case using such applications, it means >anyone can make the CRL substitution attack easily. > >So, I hope the answer is NO and all applications should use to check the >CRL issued by the signing key of the corresponding certificate issuer. > > "name rollover" certificates are needed only for client that don't support encoding conversions when comparing DN. Even many clients are in this case, some clients can be correctly implementing the comparison and then they will handle the two certificates as belonging to the same CA. If thoses clients also fully implement the CRL checking rules, then they should consider a CRLs emitted under either the old or the new key as valid for certificates emitted under both keys. The answer is YES, even if it might be in practice difficult to find even one single client that is actually affected. From owner-ietf-pkix Tue Feb 15 06:52:31 2005 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 j1FEqUFK060504; Tue, 15 Feb 2005 06:52:30 -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 j1FEqUfw060503; Tue, 15 Feb 2005 06:52:30 -0800 (PST) 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 j1FEqTBR060493 for ; Tue, 15 Feb 2005 06:52:29 -0800 (PST) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FEmaaP015427; Tue, 15 Feb 2005 09:48:37 -0500 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 j1FElgEY019512; Tue, 15 Feb 2005 09:47:42 -0500 (EST) Message-Id: <5.1.0.14.2.20050215093727.035dcda8@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Feb 2005 09:48:43 -0500 To: Denis Pinkas From: Tim Polk Subject: Re: SCVP Draft 17: Summary of changes Cc: ietf-pkix@imc.org, trevorf@exchange.microsoft.com, housley@vigilsec.com, david.cooper@nist.gov, ambarish@malpani.biz In-Reply-To: <4211EC22.6050006@bull.net> References: <5.1.0.14.2.20050214175211.03946308@email.nist.gov> 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: Denis, The editors have been working feverishly to meet the deadlines. In some cases, the disposition of comments are currently chicken scratch on paper. They will be submitted to the list as soon as we can document things. However, you should understand that some comments may not be resolved to your satisfaction. We are looking for *rough consensus* here. That means the WG as a group needs to be satisfied on each issue, but some individuals will inevitably be unhappy with the resolution of some particular issues. That is just life. IMHO, issues related to consistency with RFC 3379 are show stoppers - SCVP must be responsive to our requirements document! Issuers related to elegance and personal preference are not show stoppers, and should not be allowed to prevent this document from moving forward. Anyway, we will get the disposition of your comments (and others) documented and onto the list today or tomorrow. I'm looking forward to your comments on our disposition of your comments. Thanks, Tim At 01:33 PM 2/15/2005 +0100, Denis Pinkas wrote: >Tim (or to the ever optimist) > >>Folks, > >>A new version of SCVP-17 was posted this afternoon. IMHO, this version >>fully satisfies RFC 3379, and is responsive to the comments submitted on >>the WG mailing list. > >My comments 46 to 68 have never been responded on the list. > >I replied to the disposition of comments for 1-45 stating that several >comments were not correctly understood and resolved to my satisfaction, >but I got no answer. > >Under these conditions, I am rather pessimistic, since I have not yet seen >the draft. > >Denis > > >>Ever the optimist, I believe this draft is a strong candidate for WG >>consensus. >>Please spend some time reviewing the new draft so we can gauge consensus >>and either tweak the document before the ID submission deadline (next >>Monday!) or forward it to the ADs. >>In the interest of an efficient review, here is a summary of the changes: >>(1) All of the comments submitted to the list before Christmas were >>reviewed. Comments where Trevor had worked out a resolution on the list >>are included here and many (but not all) of the remaining comments were >>addressed. >>(2) Inconsistencies between the text and any ASN.1 structures have been >>resolved. >>(3) Draft 16 used the term "signed" to refer to messages protected by >>either a digital signature or a (H)MAC. Draft 17 refers to these >>messages as "protected" and reserves the word "signed" for messages >>protected by a digital signature. >>(4) The Diffie-Hellman based authentication method was changed from MUST >>to SHOULD implement. >>(5) The text for validation policies, validation algoriothms and name >>validation algorithms has all been revised for clarity. >>(6) A field has been added to the validation policy response message so >>that servers can indicate the type(s) of status information the server is >>capable of using, as required in RFC 3379. >>(7) Validation policies are now required to include default values for >>all parameters. Draft -16 permitted servers to create policies where >>clients were forced to supply values for some parameters. >>(8) A requestor name field was added to the cv request message, so that >>clients can include an asserted identity, as required in RFC 3379. >>Servers may still return an authenticated identity for the client if >>available. >>(9) The key usage and extended key usage specifications have been >>enhanced to permit a client to state "no requirements". >>(10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure >>from the scvp request message to indicate its policy (in the scvp >>response and policy response messages). >>(11) The validation error OIDs associated with the basic validation >>algorithm and name validation algorithm have been scrubbed. >>(12) The keyPurposeID in the name validation algorithm was renamed >>nameCompAlgId. While some of the OIDs specified in this document >>correspond to extended key usages, that is not a requirement of the >>specification. The important point was that the OID identified the >>algorithm used to compare names in the end certificate. >>(13) The isCA option to support partial path validation was removed from >>the validation policy. To use this feature securely, extensive additions >>to the protocol were required to return a set of interim state variables >>from an incomplete run of RFC 3280 Section 6.1 path validation. The >>complexity was considered an impediment to completion of the document and >>was not a requirement in RFC 3379. (This feature may be specified in a >>separate document in the future, using the SCVP extensions mechanism.) >>(14) Clients signal whether a cached response is acceptable using the >>responseFlags rather than a wantback as in draft -16. >>(15) When providing a list of certificates in the replyWantbacks in an >>scvp response message, servers are now required to order the certificates >>beginning with the end certificate. (This is a requirement stated in RFC >>3379.) >>(16) When performing Diffie-Hellman where the client has an ephemeral key >>and the server has a static key, the ephemeral key is conveyed in the >>authenticated data wrapper rather than the cv request. The draft does >>not allow ephemeral - ephemeral but does support pre-shared keys. >>(17) A new failure code was added to reply status to handle the case >>where all checks were performed successfully, however one or more of the >>wantBacks could not be satisfied. >>(18) The replychecks for status checking were extended to cover the case >>where the server cannot locate a source of status information. (This >>differentiates the failure from one where a source is known but network >>or other errors prevented getting the information.) >>Of the comments which were not incorporated into the document: >>(A) The editors disagreed with the comment that path validation >>algorithms other than that in RFC 3280 should be supported. This is a >>PKIX WG specification, and there is no requirement in RFC 3379 to support >>non-PKIX path validation. Consequently, this change was not made. >>(B) The descriptions of validation algorithm and validation policy more >>clearly delineate the differences, but I am unsure if all of that class >>of comments are satisfied. >>(C) Changes to ASN.1 syntax for elegance alone were not implemented; >>beauty is in the eye of the beholder and that debate would never end. >>ASN.1 changes were only made to enforce restrictions specified in the >>text or for consistency with the text (e.g., add a missing item described >>elsewhere.) >>Thanks, >>Tim Polk > > > From owner-ietf-pkix Tue Feb 15 07:18:15 2005 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 j1FFIFmC063811; Tue, 15 Feb 2005 07:18:15 -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 j1FFIFvZ063810; Tue, 15 Feb 2005 07:18:15 -0800 (PST) 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 j1FFIEoH063804 for ; Tue, 15 Feb 2005 07:18:14 -0800 (PST) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FFHaaX022466; Tue, 15 Feb 2005 10:17:39 -0500 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 j1FFHPEY001418; Tue, 15 Feb 2005 10:17:25 -0500 (EST) Message-Id: <5.1.0.14.2.20050215101149.030ddab8@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Feb 2005 10:18:27 -0500 To: Denis Pinkas From: Tim Polk Subject: SCVP draft 17 available now! (Was Re: SCVP Draft 17: Summary of changes) Cc: ietf-pkix@imc.org In-Reply-To: <4211EC22.6050006@bull.net> References: <5.1.0.14.2.20050214175211.03946308@email.nist.gov> 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: Denis, I just realized the significance of your comment "since I have not yet seen the draft." The ID announcement does not seem to have been posted, but the new draft is available right now from the PKIX WG charter page. The URL for draft 17 is http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-17.txt If I had recognized this situation, I would have included the URL in my message with the summary of changes yesterday. Thanks, Tim At 01:33 PM 2/15/2005 +0100, Denis Pinkas wrote: >Tim (or to the ever optimist) > >>Folks, > >>A new version of SCVP-17 was posted this afternoon. IMHO, this version >>fully satisfies RFC 3379, and is responsive to the comments submitted on >>the WG mailing list. > >My comments 46 to 68 have never been responded on the list. > >I replied to the disposition of comments for 1-45 stating that several >comments were not correctly understood and resolved to my satisfaction, >but I got no answer. > >Under these conditions, I am rather pessimistic, since I have not yet seen >the draft. > >Denis > > >>Ever the optimist, I believe this draft is a strong candidate for WG >>consensus. >>Please spend some time reviewing the new draft so we can gauge consensus >>and either tweak the document before the ID submission deadline (next >>Monday!) or forward it to the ADs. >>In the interest of an efficient review, here is a summary of the changes: >>(1) All of the comments submitted to the list before Christmas were >>reviewed. Comments where Trevor had worked out a resolution on the list >>are included here and many (but not all) of the remaining comments were >>addressed. >>(2) Inconsistencies between the text and any ASN.1 structures have been >>resolved. >>(3) Draft 16 used the term "signed" to refer to messages protected by >>either a digital signature or a (H)MAC. Draft 17 refers to these >>messages as "protected" and reserves the word "signed" for messages >>protected by a digital signature. >>(4) The Diffie-Hellman based authentication method was changed from MUST >>to SHOULD implement. >>(5) The text for validation policies, validation algoriothms and name >>validation algorithms has all been revised for clarity. >>(6) A field has been added to the validation policy response message so >>that servers can indicate the type(s) of status information the server is >>capable of using, as required in RFC 3379. >>(7) Validation policies are now required to include default values for >>all parameters. Draft -16 permitted servers to create policies where >>clients were forced to supply values for some parameters. >>(8) A requestor name field was added to the cv request message, so that >>clients can include an asserted identity, as required in RFC 3379. >>Servers may still return an authenticated identity for the client if >>available. >>(9) The key usage and extended key usage specifications have been >>enhanced to permit a client to state "no requirements". >>(10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure >>from the scvp request message to indicate its policy (in the scvp >>response and policy response messages). >>(11) The validation error OIDs associated with the basic validation >>algorithm and name validation algorithm have been scrubbed. >>(12) The keyPurposeID in the name validation algorithm was renamed >>nameCompAlgId. While some of the OIDs specified in this document >>correspond to extended key usages, that is not a requirement of the >>specification. The important point was that the OID identified the >>algorithm used to compare names in the end certificate. >>(13) The isCA option to support partial path validation was removed from >>the validation policy. To use this feature securely, extensive additions >>to the protocol were required to return a set of interim state variables >>from an incomplete run of RFC 3280 Section 6.1 path validation. The >>complexity was considered an impediment to completion of the document and >>was not a requirement in RFC 3379. (This feature may be specified in a >>separate document in the future, using the SCVP extensions mechanism.) >>(14) Clients signal whether a cached response is acceptable using the >>responseFlags rather than a wantback as in draft -16. >>(15) When providing a list of certificates in the replyWantbacks in an >>scvp response message, servers are now required to order the certificates >>beginning with the end certificate. (This is a requirement stated in RFC >>3379.) >>(16) When performing Diffie-Hellman where the client has an ephemeral key >>and the server has a static key, the ephemeral key is conveyed in the >>authenticated data wrapper rather than the cv request. The draft does >>not allow ephemeral - ephemeral but does support pre-shared keys. >>(17) A new failure code was added to reply status to handle the case >>where all checks were performed successfully, however one or more of the >>wantBacks could not be satisfied. >>(18) The replychecks for status checking were extended to cover the case >>where the server cannot locate a source of status information. (This >>differentiates the failure from one where a source is known but network >>or other errors prevented getting the information.) >>Of the comments which were not incorporated into the document: >>(A) The editors disagreed with the comment that path validation >>algorithms other than that in RFC 3280 should be supported. This is a >>PKIX WG specification, and there is no requirement in RFC 3379 to support >>non-PKIX path validation. Consequently, this change was not made. >>(B) The descriptions of validation algorithm and validation policy more >>clearly delineate the differences, but I am unsure if all of that class >>of comments are satisfied. >>(C) Changes to ASN.1 syntax for elegance alone were not implemented; >>beauty is in the eye of the beholder and that debate would never end. >>ASN.1 changes were only made to enforce restrictions specified in the >>text or for consistency with the text (e.g., add a missing item described >>elsewhere.) >>Thanks, >>Tim Polk > > > From owner-ietf-pkix Tue Feb 15 07:15:15 2005 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 j1FFFFnu063586; Tue, 15 Feb 2005 07:15:15 -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 j1FFFFts063585; Tue, 15 Feb 2005 07:15:15 -0800 (PST) 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 j1FFFBtG063566 for ; Tue, 15 Feb 2005 07:15:12 -0800 (PST) (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 QAA16274; Tue, 15 Feb 2005 16:28:33 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021516145458:311 ; Tue, 15 Feb 2005 16:14:54 +0100 Message-ID: <4212120E.6010300@bull.net> Date: Tue, 15 Feb 2005 16:15:26 +0100 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: Tim Polk CC: pkix Subject: SCVP 16 comments 1-16 X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:14:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:14:56, Serialize complete at 15/02/2005 16:14:56 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: Tim, You said: "I am looking forward to your comments on our disposition of your comments". You already got this one below which was not responded. Denis ========================================================================== Denis, The editors have been working feverishly to meet the deadlines. In some cases, the disposition of comments are currently chicken scratch on paper. They will be submitted to the list as soon as we can document things. However, you should understand that some comments may not be resolved to your satisfaction. We are looking for *rough consensus* here. That means the WG as a group needs to be satisfied on each issue, but some individuals will inevitably be unhappy with the resolution of some particular issues. That is just life. IMHO, issues related to consistency with RFC 3379 are show stoppers - SCVP must be responsive to our requirements document! Issuers related to elegance and personal preference are not show stoppers, and should not be allowed to prevent this document from moving forward. Anyway, we will get the disposition of your comments (and others) documented and onto the list today or tomorrow. I'm looking forward to your comments on our disposition of your comments. Thanks, Tim -------- Original Message -------- Subject: Re: SCVP 16 comments deadline Date: Wed, 08 Dec 2004 17:00:33 +0100 From: Denis Pinkas Organization: Bull SA. To: Trevor Freeman CC: ietf-pkix@imc.org References: Trevor, > Hi Denis, > Below are responses to 1-16. Others will follow later. I am pleased that you accepted comments 13, 14, 15 and 16. Among this list, I have a further remark on comment 4. > * 4. Page 13. Typo. Section 3.1.2 "checks" > * The two following lines are in fact one line: > * > * Change: > * > * - Build a validated certification path to a trust anchor; and > * > * - Do revocation status checks on the certification path. > * > * into: > * > * - Build a validated certification path to a trust anchor and > * do revocation status checks on the certification path. > * > [TF] Since this paragraph is listing the possible checks and building a > path is a separate check to revocation checking, I think the current > text is more accurate. I agree that "building a path is a separate check to revocation checking", but revocation checking without building a validated path does not make sense. The full text currently is: - Build a certification path to a trust anchor; - Build a validated certification path to a trust anchor; and - Do revocation status checks on the certification path. The full text should be: - Build a certification path to a trust anchor; - Build a validated certification path to a trust anchor; and do revocation status checks on the certification path. Denis From owner-ietf-pkix Tue Feb 15 07:42:29 2005 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 j1FFgTLm066094; Tue, 15 Feb 2005 07:42:29 -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 j1FFgTM8066093; Tue, 15 Feb 2005 07:42:29 -0800 (PST) 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 j1FFgSB2066087 for ; Tue, 15 Feb 2005 07:42:28 -0800 (PST) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FFfbaP028423; Tue, 15 Feb 2005 10:41:37 -0500 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 j1FFepEY012136; Tue, 15 Feb 2005 10:40:51 -0500 (EST) Message-Id: <5.1.0.14.2.20050215102730.03595b98@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Feb 2005 10:41:52 -0500 To: Denis Pinkas From: Tim Polk Subject: Re: SCVP 16 comments 1-16 Cc: pkix In-Reply-To: <4212120E.6010300@bull.net> 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: Denis, Comment 4 was addressed in the new draft. Your comment that "revocation checking without building a validated path does not make sense" was accepted, and the client now asserts a single check to request a validated path with revocation checking, as in your proposal. Our resolution was slightly different from your proposal. You proposed to resolve this issue by reducing the set of checks from three to two. We retained three different checks because we wanted to allow for the case where a path is built and validated without considering status information. This is explicitly permitted in both RFC 2459 and 3280, and should be covered by SCVP as well. Our text follows: Excerpt form draft -17, section 3.2.2 Checks > > For public key certificates, the following checks are defined: > > - id-stc-build-pkc-path: Build a certification path to a trust > anchor; > > - id-stc-build-valid-pkc-path: Build a validated certification path > to a trust anchor (revocation checking not required); > > - id-stc-build-status-checked-pkc-path: Build a validated > certification path to a trust anchor and perform revocation > status checks on the certification path. > > Conforming SCVP server implementations MUST support the id-stc-build- > pkc-path check. Conforming SCVP server implementations that support > delegated path validation (DPV) as defined in [RQMTS] MUST support > the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc- > path checks. > Your thoughts? Tim From owner-ietf-pkix Tue Feb 15 07:35:56 2005 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 j1FFZu89065506; Tue, 15 Feb 2005 07:35:56 -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 j1FFZuBD065505; Tue, 15 Feb 2005 07:35:56 -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 j1FFZt0G065498 for ; Tue, 15 Feb 2005 07:35:55 -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 KAA15028; Tue, 15 Feb 2005 10:35:52 -0500 (EST) Message-Id: <200502151535.KAA15028@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-2797-bis-02.txt Date: Tue, 15 Feb 2005 10:35:52 -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 : Certificate Management Messages over CMS Author(s) : M. Myers, et al. Filename : draft-ietf-pkix-2797-bis-02.txt Pages : 0 Date : 2005-2-14 This document defines the base syntax for CMC, a Certificate Management protocol using CMS (Cryptographic Message Syntax). This protocol addresses two immediate needs within the Internet PKI community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Crytpography Standard), and 2. The need in S/MIME (Secure MIME) for a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-2797-bis-02.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-2797-bis-02.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-2797-bis-02.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-2-15103842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-2797-bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-2797-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-15103842.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Tue Feb 15 07:36:19 2005 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 j1FFaJDb065560; Tue, 15 Feb 2005 07:36:19 -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 j1FFaJ3d065559; Tue, 15 Feb 2005 07:36:19 -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 j1FFaIXw065553 for ; Tue, 15 Feb 2005 07:36:19 -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 KAA15249; Tue, 15 Feb 2005 10:36:16 -0500 (EST) Message-Id: <200502151536.KAA15249@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-scvp-17.txt Date: Tue, 15 Feb 2005 10:36:15 -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 : Simple Certificate Validation Protocol (SCVP) Author(s) : A. Malpani, et al. Filename : draft-ietf-pkix-scvp-17.txt Pages : 76 Date : 2005-2-14 SCVP allows a client to delegate certificate path construction and certificate path validation to a server. The path construction or validation (e.g. making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-17.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-scvp-17.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-scvp-17.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-2-15103847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-scvp-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-scvp-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-15103847.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Tue Feb 15 07:17:22 2005 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 j1FFHMYa063760; Tue, 15 Feb 2005 07:17:22 -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 j1FFHMhj063759; Tue, 15 Feb 2005 07:17:22 -0800 (PST) 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 j1FFHFpa063727 for ; Tue, 15 Feb 2005 07:17:17 -0800 (PST) (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 QAA71394; Tue, 15 Feb 2005 16:30:39 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021516170121:315 ; Tue, 15 Feb 2005 16:17:01 +0100 Message-ID: <4212128C.7010005@bull.net> Date: Tue, 15 Feb 2005 16:17:32 +0100 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: Tim Polk CC: pkix Subject: SCVP 16 comments 17-45 X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:17:01, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:17:02, Serialize complete at 15/02/2005 16:17:02 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 j1FFHMpa063754 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim, You said: "I am looking forward to your comments on our disposition of your comments". You already got these ones below which were not responded. Denis ========================================================================== Denis, The editors have been working feverishly to meet the deadlines. In some cases, the disposition of comments are currently chicken scratch on paper. They will be submitted to the list as soon as we can document things. However, you should understand that some comments may not be resolved to your satisfaction. We are looking for *rough consensus* here. That means the WG as a group needs to be satisfied on each issue, but some individuals will inevitably be unhappy with the resolution of some particular issues. That is just life. IMHO, issues related to consistency with RFC 3379 are show stoppers - SCVP must be responsive to our requirements document! Issuers related to elegance and personal preference are not show stoppers, and should not be allowed to prevent this document from moving forward. Anyway, we will get the disposition of your comments (and others) documented and onto the list today or tomorrow. I'm looking forward to your comments on our disposition of your comments. Thanks, Tim -------- Original Message -------- Subject: Re: SCVP 16 comments deadline Date: Wed, 05 Jan 2005 13:46:18 +0100 From: Denis Pinkas Organization: Bull SA. To: Trevor Freeman CC: ietf-pkix@imc.org References: Trevor, Here are my responses on 17-45. There are still many major points on which we do not agree. The MAJOR one has still to do with the deletion of the validation ALGORITHM so that all validation POLICY dependant parameters can be placed under the validation policy reference. 17. On top of page 7, the relationship between the validation policy and the basic certification path algorithm is not explained. Then in section 1.4 The concept of validation algorithm is introduced but its relationship with the validation policy is not explained. This is confusing. Later on when observing the ASN.1 syntax it may be discovered that two OIDs are being used: - one for the validation policy (ValidationPolRef) and - one for the validation algorithm (ValidationAlg). This is overcomplicated and unnecessary. [TF] Is there a specific issue with the current draft such as a scenario which is not addressed ? [DP] I do not believe that raising this question is a good way to solve my concern. The “S” from SCVP was supposed to mean “Simple”. The current description is the description of CCVP ”Complex Certificate Validation Protocol”. Now, since you asked, CCVP is unable to support the validation algorithm described in section 6.2 of RFC 3280 (with many trust points, each one with its set of parameters). Adding more complexity to solve it would not be the right answer. A major simplification is obtained if there is an OID to define the validation policy while there may be or not be additional parameters. We sould then have: valPolByOID::= SEQUENCE { valPolId OBJECT IDENTIFIER, parameters ANY DEFINED BY ValPolId OPTIONAL } Specifying a path processing compliant with section 6.1 of RFC 3280 would not be possible in the general case, since the current text from RFC 3280 is too vague/ambiguous to support the case where a CRL is *not* signed by the CA. It would be desirable to be able to communicate easily and in a standard way the parameters that may be set in section 6.1 from RFC 3280. In addition, key usage should be added to that list. The document should then define a bundle of all these previous useful parameters and allow for the addition of other parameters. It is thus proposed to define an OID for a validation policy compliant with section 6.1 of RFC 3280 (some differences with section 6 from 3280bis, i.e. adding precision, may be expected). It is thus proposed to modify the text starting from : " The inputs to the basic certification path processing algorithm used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise" up to the end of section 1.3 with the following: "For clients able to specify the parameters of a validation policy, it may be useful to define a standard data structure (using a bundle) able to support the parameters of the basic certification path processing algorithm defined by in section 6.1.1 from [PKIX-1] : - a set of Trust Anchors (by value or by reference), - the initial Certificate Policy set, - initial Certificate Policy mapping setting, - initial any-Policy setting, - initial explicit Certificate Policy setting. as well as : - the usage of the key contained in the certificate (e.g., key encipherment, key agreement, signature) This will be done using a bundle which encapsulates all these parameters. Other application-specific purposes parameters may be added". 18. Section 1.4 is about a "Validation Algorithm". Given what was said before, the header of this section should be changed. If we make a subsection 1.3.1 called "1.3.1. General" for encapsulating the previous text, then we can introduce a new section 1.3.2 called: "1.3.2. Validation policy according to section 6.1 of RFC 3280" [TF] See comment to 17 [DP] See my response above. Some of the text present in the current section 1.4 has been used to build the new text that is proposed below: "1.3.2. Validation policy according to section 6.1 of RFC 3280 SCVP defines a specific validation policy which implements the certification path validation algorithm as defined in section 6.1 of [PKIX-1]. This specific validation policy, called "rfc-3280 basic validation policy" uses the parameters defined in the bundle mentioned above. Note that this algorithm does not support in its full generality the algorithm described in section 6.2 of [PKIX-1] since, when more than one trust anchor is being defined, all the conditions that are specified apply to all trust anchors, whereas section 6.2 allows to have different conditions for every trust anchor. The rfc-3280 basic validation policy may be the default validation policy supported by the server, but does not need to". 19. Section 2 "Protocol Overview" In order to allow for interoperability and testing a common protocol needs to be supported. It should be defined. [TF] There is plenty of precedence for this to be in a separate document. CMS itself just defines the syntax. [DP] Would you be more explicit ? 20. Section 3 "Validation Request" The unsigned request form is not explained and there is a confusion for the signed request which indeed authenticates the client and is thus not anonymous. The current text is : "A signed request is used to authenticate the client to the server or to provide an anonymous client integrity over the request-response pair." It should be rephrased as: "An unsigned request provides an anonymous client integrity over the request since the hash of the request or the full request is incorporated in the response. A signed request is used to authenticate the client to the server". [TF] Since by definition the anonymous client has to sign the request as well this does not make sense. A server can also return a cached response in which case there is no hash of the request in the response. How about : An anonymous client signs the request to provide integrity over the request. A identifiable signs the request to authenticate itself to the server. [DP] This does not make sense. If the response is a live response (not cached) then including the hash of the request in the response is fine and the request does not need to be signed. If the response is a cached response, then the cached response must include “sufficient” information to make sure for the client that it is not a replay from a too old response. The only way is to copy all the parameters of the original request. In either case, signing the request does not help. 21. Page 13. Section 3.1.2 "checks" The following sentence adds nothing and should be removed: "A server may still choose to perform revocation status checks when performing path construction, although this information cannot be returned to the client." [TF] I think it reinforces that with some checks, don't require revocation status checking but a server may still elect to do so. [DP] I disagree. A server SHALL do what the client asks, no more no less. Please, delete the sentence. 22. Page 15. Section 3.1.3 "wantBack" The text states: - Proof of revocation status for each certificate in the AC issuer certification path; It would be important to refer the section of the RFC which explains how to check the "revocation status for each certificate in the AC issuer certification path". [TF] OK, I will add a reference to 3281 section 5. [DP] RFC 3281 is “An Internet Attribute Certificate Profile for Authorization ». I do not believe that it is the correct reference. The basic problem is that there exists no RFC that explains how to check the "revocation status for each certificate in the AC issuer certification path". So leaving details to the validation policy is the only solution. 23. Page 15. Section 3.1.3 "wantBack" The text states: The client can also request a non-cached response to the request by including wantback id-swb-non-cached-resp in the request. The default behavior should be the reverse: fresh information is provided, unless the client accept cached information. The item should be changed into: id-swb-cached-resp [TF] This has been moved to response flags and the default is non-cached. [DP] Fine, finally one point on which we agree. 24. Page 15. Section 3.1.3 "wantBack" The text states: id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13} It should be mentioned that this item is only possible for DPD. [TF] Why is this only possible with DPD? [DP] Because DPV returns only the fist valid path (i.e. a single path) 25. Page 16. Section 3.1.4 validationPolicy The following sentence is talking of an agreement whereas such agreement does not exist. Delete the sentence: "The client and server can optionally agree on a set of parameters which may fully or partially define a validation policy". [TF] OK 26. Page 16. Section 3.1.4 validationPolicy The text states: "If a partial set of parameters has been agreed upon, then the client supplies a reference to the policy plus whatever parameters are necessary to complete the request in this item. This should be replaced with: "If the validation policy does not define all parameters necessary for processing an SCVP request, then the client need to supply these parameters". [TF] Thats is not true. The client can omit whatever parameters match the server default value. [DP] This would mean that the default validation policy always have a full set of parameters. In that case the quoted sentence is still incorrect since it states “ a partial set of parameters”. That sentence still needs to be corrected. What about:” The client supplies a reference to the policy plus whatever parameters which are allowed to change the default parameters". 27. Page 16. Section 3.1.4 validationPolicy The syntax of the validationPolicy item is defined as: ValidationPolicy ::= SEQUENCE { validationPolRef ValidationPolRef, validationAlg [0] ValidationAlg OPTIONAL, userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL, inhibitPolicyMapping [2] BOOLEAN OPTIONAL, requireExplicitPolicy [3] BOOLEAN OPTIONAL, inhibitAnyPolicy [4] BOOLEAN OPTIONAL, isCA [5] BOOLEAN OPTIONAL, trustAnchors [6] TrustAnchors OPTIONAL, keyUsages [7] SEQUENCE SIZE (1..MAX) OF KeyUsage OPTIONAL, extendedKeyUsages [8] ExtKeyUsageSyntax OPTIONAL} This structure is quite odd, because it only allows to pass additional parameters as parameters of the validationAlg. Suppressing the validationAlg item add adding validationParamExtensions would be a simpler and cleaner way. [TF] The only way to include other parameters is because the algorithm needs them. You cannot introduce new parameters without at the same time defining there use. Therefore mandating additional parameters be passed which the corresponding identifier for their is the right thing to do. [DP] I disagree. I could say: the only way to include other parameters is to place them as parameters of the validation policy because the validation policy needs them. Your response is placed too early and does not consider the proposal made just after. See the proposal hereafter and please reconsider your position. This is one of the major issues. Each validation policies uses its own parameters. We should have something like : ValPolByOID ::= SEQUENCE { valPolgId OBJECT IDENTIFIER, parameters ANY DEFINED BY valPolId OPTIONAL } More details follow. 28. It is highly debatable if URIs should be supported or not to reference a validation policy. URIs are not stable over time and thus unless there are dereferenced and a hash value is computed over them, it is insecure to use them. There is a discussion in the security consideration section, but no warning and no pointer here. If we keep them, we should warn the user. [TF] The argument over the stability of URIs is discussed in the security section - which is the appropriate place. The reality is in many organizations are stable enough and much more manageable. The issue over dereferencing and hashing is bogus. Both OID and URI are both opaque stings for this purpose and rely on you trusting the management doing the right thing. [DP] Anyway a reference to the security consideration section is missing. If you believe that a URI is opaque, it should be said, because dereferencing is very often announced by some people as being an advantage. You can place that information in the security considerations section if you wish and then let the IESG decide. If the WG should decides that they should be supported (and if the IESG agrees) on page 17, the ASN.1 description should then be: ValidationPolicy ::= CHOICE { valPolByOID [0] ValPolByOID, valPolByURI [1] ValPolByURI } ValPolByOID ::= SEQUENCE { valPolgId OBJECT IDENTIFIER, parameters ANY DEFINED BY valPolId OPTIONAL } ValPolByURI ::= SEQUENCE { uri IA5String, hashAlgo OBJECT IDENTIFIER, hashValue OCTET STRING} 29. It is proposed to define the following bundle: ValidationParamBundle ::= SEQUENCE { certificatePolicySet [0] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL, inhibitPolicyMapping [1] BOOLEAN OPTIONAL, requireExplicitPolicy [2] BOOLEAN OPTIONAL, inhibitAnyPolicy [3] BOOLEAN OPTIONAL, isCA [4] BOOLEAN OPTIONAL, trustAnchors [5] TrustAnchors OPTIONAL, keyUsages [6] SEQUENCE SIZE (1..MAX) OF KeyUsage OPTIONAL, extendedKeyUsages [7] ExtKeyUsageSyntax OPTIONAL, extensions [8] EXPLICIT Extensions OPTIONAL } Note that userPolicySet" is unclear and has been changed into "certificatePolicySet". [TF] The use of userPolicySet aligns with 3280. I don't think the name to the existing structure is ambiguous or misleading. [DP] Your response arguments about the note but omits to respond to the main argument of this comment. So I consider that a response to this comment is still awaited. BTW, userPolicySet is not a term used in RFC 3280, so you cant’t say it aligns with RFC 3280. The text would need to be aligned with the new structure and, of course the parameters of the rfc-3280 basic validation policy will simply include the bundle above as its parameters. It should also be mentioned somewhere in the document that the support of the rfc-3280 basic validation policy is not mandatory for conformance but, if supported then the bundle needs to be supported. 30. Page 17. Section 3.1.5 validationAlg should be deleted. [TF] Already done [DP] Let us see what the next text will look like to know whether this comment is solved or not. I fear it is not. 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be deleted and replaced by a section later on the "rfc-3280 basic validation policy", which should have its OID defined under the scvp tree for OIDs. [TF] the basic validation algorithm references the 3280 section 6. [DP] What you call the basic validation algorithm is one of the many elements of the rfc-3280 basic validation policy. It is buried within the validation policy and does not need to be identified independently of the validation policy. The default Validation Algorithm still needs to be deleted. This relates to comment 17. 32. Page 17. Section 3.1.5.1. Some text of this section might be re-used to build a new section on the rfc-3280 basic validation policy. Note that the last sentence at the bottom of page 17, should be removed. This sentence is: "The default validation policy MUST use the basic validation algorithm". Any default validation policy can be used. [TF] See answer to 31 [DP] See my response above. 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !) should be as well deleted. [TF] The duplicate has been deleted 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm This goal of this section seems to introduce an additional test to the basic "rfc-3280 basic validation policy". It would come naturally as an extension of ValidationParamBundle, rather than as a parameter of the validationAlgo which has been proposed to be removed. The text should be modified accordingly. [TF] See answer 27. [DP] See my response: your response does not consider the proposal made in comment 27. 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm NameValidationAlgParms ::= SEQUENCE { keyPurposeId KeyPurposeId, validationNames GeneralNames } This construct is artificial since KeyPurposeId is about the Extended Key Usage and has nothing to do with name validation. [TF] Its simple reuses and existing practice. [DP] I do not understand the argument about “existing practice”. It could indeed be interesting to test the Extended Key Usage extension of a certificate, but this should be supported as an extension of ValidationParamBundle. The text should be modified accordingly. 36. Page 22. Section 3.1.5.3 userPolicySet userPolicySet should be changed everywhere into certificatePolicySet. [TF] userPolicySet aligns with 3280 section 6. [DP] userPolicySet is not a term used in RFC 3280, so you cant’t say it aligns with RFC 3280 section 6. You are probably reading a different document. 37. Page 22. Section 3.1.5.3 userPolicySet The text has many sentences like: SCVP clients SHOULD support userPolicySet item in requests, and SCVP servers MUST support userPolicySet item in requests. These requirements only apply for the rfc-3280 basic validation policy, and this should be clearly mentioned. [TF] Since all validation polices contain userPolicySet, it can be in any policy. [DP] I disagree. There may be some validation policies where no parameter at all can be changed by the client. I would expect that most clients will use OIDs for validation policies with no parameter at all. A client is not necessarily allowed to change any parameter of a validation policy. In some cases clients will be allowed to specify only some parameters (but not all). 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping The text states: By default the server allows policy mapping as part of certification path validation. For simplicity, this should be the reverse. Replace with: "By default the server does not perform policy mapping as part of certification path validation. If the client wants the server to support policy mapping, allowPolicyMapping must be set to TRUE in the request". [TF] This conflicts with 3280 section 6. [DP] It does not. Section 6 does not mandate policy mapping. The default is simplicity: no policy mapping. 39. Page 24. Section 3.1.5.8 trustAnchors The text states: "A certificate reference can be used to identify the trust anchor by certificate hash and optionally a distinguished name with serial number". This is not consistent with the ASN.1 definition of PKCReference which is: PKCReference ::= CHOICE { cert [0] Certificate, pkcRef [1] ESSCertID } Please correct. [DP] A response is missing. 40. Page 25. Section 3.1.6 responseRefHash The text states: "By default, the server includes a hash of the request in the response. If the client wants the server to include the full request in the response, responseRefHash is set to FALSE." The server shall always include a hash of the request in the response. [TF] A server cannot include a hash of the request in a cached response. [DP] See my new response to comment 20. If the response is a live response (not cached) then including the hash of the request in the response is fine. If the response is a cached response, then the cached response must include “sufficient” information to make sure for the client that it is not a replay from a too old response. The only way is to copy all the parameters of the original request. This is an easy way to allow to test the integrity of the request. Since the full description of the validation policy may be much longer a flag should be used to say that the full validation policy is not returned unless requested. [TF] There is one, it is responseValidationPolByRef. The response flags now has a FullRequestInResponse in place of the requestRefHash. [DP] Let us see what the full new proposal is. If you agree with my response to comment 20, maybe we are converging. It is thus proposed to have instead the following: "3.1.6.1 fullRequestInResponse The fullRequestInResponse controls if the client wants the server to include the full request in the response. By default, fullRequestInResponse is set to FALSE. If the client wants back the full request then it must set this parameter to TRUE. The main reason a client would request the server to include the full request in the response is to archive the request-response exchange in a single object. That is, the client wants to archive a single object which includes both request and response". 41. Page 26. Section 3.1.6.2 responseValidationPolByRef This item should be renamed: fullValPolInResponse The text should be changed into: "The fullValPolInResponse controls whether the response includes the identifier of the validation policy with all the parameters that have been used by the server, i.e. all the variable parameters independent from the fact that there were specified by the client or defaulted if not specified. By default, fullValPolInResponse is set to FALSE. If the client wants the full validation policy to be included, then fullValPolInResponse is set to TRUE. The main reason a client would request the server to include validation policy to be included by value is to archive the request-response exchange in a single object. That is, the client wants to archive the CVResponse and have it include every aspect of the validation policy." [TF] I have not changed the name, but the section now reads The responseValidationPolByRef controls whether the response includes just a reference to the policy or the reference to the policy plus all the parameters by value of the policy used to process the request. the response MUST contain references to the validation policy. If the client wants the validation policy parameters to be also included by value, then the responseValidationPolByRef is set to FALSE. The main reason a client would request the server to include validation policy to be included by value is to archive the request-response exchange in a single object. That is, the client wants to archive the CVResponse and have it include every aspect of the validation policy. [DP] This new proposed text is still incorrect: “just a reference to the validation policy” does not help, (unless the validation policy has no variable parameter). We need to have a mechanism for replay protection and/or for making sure that the response relates to the right request: “just a reference to the validation policy” does not provide this property. However, my proposal provides that property. Please reconsider my text. The ResponseFlags should be changed as follows: ResponseFlags ::= SEQUENCE { fullRequestInResponse BOOLEAN DEFAULT FALSE, fullValPolInResponse BOOLEAN DEFAULT FALSE, signResponse BOOLEAN DEFAULT TRUE } 42. Page 28. Section 3.1.9 intermediateCerts. Minor. Change: The optional intermediateCerts item helps the SCVP server create valid certification paths. into: The optional intermediateCerts item may help the SCVP server to create valid certification paths. [TF] Fixed 43. Page 29. Section 3.1.11. producedAt Last sentence. Change: SCVP server SHOULD support the producedAt values in the request. into: SCVP server MAY support the producedAt values in the request. Reason: cached responses should not need to be implemented in order to be compliant with the specification. [TF] Fixed 44. Page 32. Section 3.5 dhPublicKey The text states: "For the server to compute the shared secret, it must lean the public values the client generates, therefore the client MUST include this in the request if it uses this mechanism to integrity protect the request- response pair." Replace: "to integrity protect the request-response pair" with : "to authenticate and integrity protect the first response and authenticate and integrity protect subsequent request-response pairs". [TF] draft now read " integrity protect the request and the subsequent response." The use of DH does not necessarily authenticate the request. 45. Page 32. Section 3.6 SCVP Request Authentication The text states: "It is a matter of local policy what validation policy is used by the server when validating requests". This sentence could be misinterpreted because the word "validating" is being used. Change into: It is a matter of local policy what validation policy is used by the server when authentication requests". [TF] Fixed END OF COMMENTS Denis From owner-ietf-pkix Tue Feb 15 07:53:26 2005 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 j1FFrQBM067257; Tue, 15 Feb 2005 07:53:26 -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 j1FFrQev067256; Tue, 15 Feb 2005 07:53:26 -0800 (PST) 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 j1FFrMqE067239 for ; Tue, 15 Feb 2005 07:53:24 -0800 (PST) (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 RAA32866; Tue, 15 Feb 2005 17:06:47 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021516530953:345 ; Tue, 15 Feb 2005 16:53:09 +0100 Message-ID: <42121B05.80300@bull.net> Date: Tue, 15 Feb 2005 16:53:41 +0100 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: Tim Polk CC: pkix Subject: Re: SCVP 16 comments 1-16 References: <5.1.0.14.2.20050215102730.03595b98@email.nist.gov> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:53:09, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:53:10, Serialize complete at 15/02/2005 16:53:10 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: Tim, > Denis, > Comment 4 was addressed in the new draft. Your comment that "revocation > checking without building a validated path does not make sense" was > accepted, and the client now asserts a single check to request a > validated path with revocation checking, as in your proposal. > Our resolution was slightly different from your proposal. You proposed > to resolve this issue by reducing the set of checks from three to two. > We retained three different checks because we wanted to allow for the > case where a path is built and validated without considering status > information. This is explicitly permitted in both RFC 2459 and 3280, > and should be covered by SCVP as well. > Our text follows: > Excerpt form draft -17, section 3.2.2 Checks >> For public key certificates, the following checks are defined: >> >> - id-stc-build-pkc-path: Build a certification path to a trust >> anchor; >> >> - id-stc-build-valid-pkc-path: Build a validated certification path >> to a trust anchor (revocation checking not required); >> >> - id-stc-build-status-checked-pkc-path: Build a validated >> certification path to a trust anchor and perform revocation >> status checks on the certification path. Humm !! humm !! You say above "reducing the set of checks from three to two.". If I count correctly I see three choices above. Would you explain ? Denis >> Conforming SCVP server implementations MUST support the id-stc-build- >> pkc-path check. Conforming SCVP server implementations that support >> delegated path validation (DPV) as defined in [RQMTS] MUST support >> the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc- >> path checks. >> > > Your thoughts? > > Tim From owner-ietf-pkix Tue Feb 15 08:22:05 2005 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 j1FGM4MS069419; Tue, 15 Feb 2005 08:22:04 -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 j1FGM4UE069418; Tue, 15 Feb 2005 08:22:04 -0800 (PST) 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 j1FGM3OQ069408 for ; Tue, 15 Feb 2005 08:22:04 -0800 (PST) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FGLbDT027010; Tue, 15 Feb 2005 11:21:38 -0500 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 j1FGKmEY021969; Tue, 15 Feb 2005 11:20:48 -0500 (EST) Message-Id: <5.1.0.14.2.20050215111449.03932bc0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Feb 2005 11:21:49 -0500 To: Denis Pinkas From: Tim Polk Subject: Re: SCVP 16 comments 1-16 Cc: ietf-pkix@imc.org In-Reply-To: <42121B05.80300@bull.net> References: <5.1.0.14.2.20050215102730.03595b98@email.nist.gov> 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: Please reread my message. I said *you* suggested reducing the set from three to two, but we retained all three. The rationalization is clearly stated in the message. At 04:53 PM 2/15/2005 +0100, you wrote: >Tim, > >>Denis, > >>Comment 4 was addressed in the new draft. Your comment that "revocation >>checking without building a validated path does not make sense" was >>accepted, and the client now asserts a single check to request a >>validated path with revocation checking, as in your proposal. > >>Our resolution was slightly different from your proposal. You proposed >>to resolve this issue by reducing the set of checks from three to two. >>We retained three different checks because we wanted to allow for the >>case where a path is built and validated without considering status >>information. This is explicitly permitted in both RFC 2459 and 3280, and >>should be covered by SCVP as well. > >>Our text follows: > >>Excerpt form draft -17, section 3.2.2 Checks > > >>> For public key certificates, the following checks are defined: >>> >>> - id-stc-build-pkc-path: Build a certification path to a trust >>> anchor; >>> >>> - id-stc-build-valid-pkc-path: Build a validated certification path >>> to a trust anchor (revocation checking not required); >>> >>> - id-stc-build-status-checked-pkc-path: Build a validated >>> certification path to a trust anchor and perform revocation >>> status checks on the certification path. > >Humm !! humm !! > >You say above "reducing the set of