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