Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
"Anders Rundgren" <anders.rundgren@telia.com> Wed, 30 July 2008 21:36 UTC
Return-Path: <owner-ietf-pkix@mail.imc.org>
X-Original-To: ietfarch-pkix-archive@core3.amsl.com
Delivered-To: ietfarch-pkix-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E373A69DB for <ietfarch-pkix-archive@core3.amsl.com>; Wed, 30 Jul 2008 14:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.931
X-Spam-Level:
X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVGVdD629isz for <ietfarch-pkix-archive@core3.amsl.com>; Wed, 30 Jul 2008 14:36:14 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6ABA73A69CF for <pkix-archive@ietf.org>; Wed, 30 Jul 2008 14:36:14 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UKuA3Q026835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 13:56:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m6UKuALB026834; Wed, 30 Jul 2008 13:56:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6UKu8Ck026828 for <ietf-pkix@imc.org>; Wed, 30 Jul 2008 13:56:09 -0700 (MST) (envelope-from anders.rundgren@telia.com)
Received: from arport2v (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) (authenticated as u18116613) id 4873CA950041C7F5; Wed, 30 Jul 2008 22:53:19 +0200
Message-ID: <00b301c8f29f$b757b700$82c5a8c0@arport2v>
From: Anders Rundgren <anders.rundgren@telia.com>
To: Massimiliano Pala <pala@cs.dartmouth.edu>, Tom Gindin <tgindin@us.ibm.com>
Cc: ietf-pkix@imc.org
References: <OF3858F0CB.DB5A7654-ON85257495.00544FAB-85257495.0081B3DB@us.ibm.com> <48902FEC.9010104@cs.dartmouth.edu>
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
Date: Thu, 31 Jul 2008 01:55:13 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
I'm less concerned about details regarding this protocol than how to use the information it provides. Security GUI have shown to be very difficult to design since they either [try to] hide the gory stuff or assumes a level of education that isn't generally available. I wouldn't be surprised if Microsoft with their CardSpace scheme will [eventually] make two-factor authentication as easy to use as credit cards; it even looks like credit cards! Anders Rundgren ----- Original Message ----- From: "Massimiliano Pala" <pala@cs.dartmouth.edu> To: "Tom Gindin" <tgindin@us.ibm.com> Cc: <ietf-pkix@imc.org> Sent: Wednesday, July 30, 2008 11:10 Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt Hi Tom, In section 2.1.1. only a brief descriptions we list only some of the reasons for adopting a PRQP and it is not intended to be exhaustive. The argument in 2.1.2. still holds, in the sense that currently there is no mapping in the certificates between DNS domains and certificates - as you pointed out there is no field that could carry such information. I will probably need to add some more deep considerations in this section thus listing the benefits coming from the usage of a dynamic protocol. The intent of defining a protocol for PKI resource query that is transport independent allows for more flexibility than using a specific service like DNS. I would not say that the DNS is not secure enough - it could be possible to distribute signed records via DNS; it can be difficult from a management point of view: it is my opinion that integrating that type of support in current DNS is harder and takes longer than defining a new protocol which is easy and can be implemented really fast. Last, but not least, at the last IETF my presentation on extending PRQP to a Peer-to-peer environment that would allow the implementation of a real service discovery system for PKIs strongly suggest that the overhead introduced by the definition of a specific protocol is rewarded with a wide range of possibilities for PKI management and would allow for better usability of PKIs. See section A.2 of the I-D for more information. These are just some of the reasons I can come up with. The current status of the draft is, AFAIK, on experimental track just because of this: we need to know if this protocol would allow for an efficient and interoperable method for PKI resource discovery or not. So far the DNS has not provided such a service, IMHO. Anyhow, I would encourage the usage of the DNS SRV record to locate a local RQA (if available), though. As I am going to explain in my presentation later today, we are moving forward from this point of view as an RQA will be setup for all of the CAs within the TACAR repository (http://www.tacar.org). When we will have a deployed environment and, eventually, support for client applications we will be able to evaluate more what the results are and if it will be worth to move the I-D to standard track or not. I will a concise version of these considerations to the 2.1.2 section of the I-D in order to make it more clear why we propose the usage of PRQP instead of DNS SRV records - although I do not want this section to become too long. Thanks for the comments and, if you have more, please let me know :D Later, Max Tom Gindin wrote: > Max: > > The DNS Name has to go into a specific extension to be used. I > don't think that putting a DNS Name into IssuerAltName means "look here > for SRV records associated with PKI management", and its most common > meaning in SubjectAltName is "expect to see this certificate when you > connect to this DNS Name", but an AccessDescription could easily be > assigned to mean that it's a pointer to SRV records. There are General > Names associated with AKI, CRL Distribution Point, and Name Constraint as > well, but they clearly are not appropriate for such purposes. > An argument that "DNS is not the right mechanism for this, and > it's worth a new protocol to avoid using DNS" is different than the one > you made in the first version of your draft. It looks to me like the > argument against DNS usage would rely heavily on the perception that DNS > isn't secure enough, especially for revocation information. Is that > really a strong enough reason to expect typical relying parties to > implement a new client protocol? > > Tom Gindin -- Best Regards, Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] pala@cs.dartmouth.edu project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883 PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179 --o------------------------------------------------------------------------
- I-D ACTION:draft-ietf-pkix-prqp-00.txt Internet-Drafts
- Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt Tom Gindin
- Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt Massimiliano Pala
- Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt Tom Gindin
- Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt Massimiliano Pala
- Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt Anders Rundgren