Re: request for WG to adopt draft-chadwick-webdav-00.txt as a work item
George Michaelson <ggm@apnic.net> Thu, 06 September 2007 12:04 UTC
Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITG5k-0002mO-D7 for pkix-archive@lists.ietf.org; Thu, 06 Sep 2007 08:04:12 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITG5i-0004rg-UT for pkix-archive@lists.ietf.org; Thu, 06 Sep 2007 08:04:12 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l86AcBYN023869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 03:38:11 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l86AcB6Z023868; Thu, 6 Sep 2007 03:38:11 -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 mint.apnic.net (mint.apnic.net [202.12.29.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l86Ac7nt023854 for <ietf-pkix@imc.org>; Thu, 6 Sep 2007 03:38:10 -0700 (MST) (envelope-from ggm@apnic.net)
Received: from asmtp.apnic.net (unknown [169.223.7.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id D0C12D5F34; Thu, 6 Sep 2007 20:38:04 +1000 (EST)
Date: Thu, 06 Sep 2007 16:07:57 +0530
From: George Michaelson <ggm@apnic.net>
To: Stefan Santesson <stefans@microsoft.com>
Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: Re: request for WG to adopt draft-chadwick-webdav-00.txt as a work item
Message-ID: <20070906160757.4ccdf148@garlique.algebras.org>
In-Reply-To: <A15AC0FBACD3464E95961F7C0BCD1FF006A25BDE5E@EA-EXMSG-C307.europe.corp.microsoft.com>
References: <20070906121635.134112cf@garlique.algebras.org> <A15AC0FBACD3464E95961F7C0BCD1FF006A25BDE5E@EA-EXMSG-C307.europe.corp.microsoft.com>
X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386--netbsdelf)
X-Fruit-Of-The-Month-Club: persimmon
X-Face: (G*pY('2ZlP:=]{&J8["6Ibt`-M4xkya9HI%Ij0Q|PTT[qLP~"GJ:bxz>brS}WggoHS$gbYM81`^GU@icr}P?d>R\RNgjc)w:c_].{ylf,&Q,6J:esKfk!|/kr{uvQ3wDlnYxBVj; ; t7v=rA"3r>Z'w&ptd}\?5
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
On Thu, 6 Sep 2007 11:12:05 +0100 Stefan Santesson <stefans@microsoft.com> wrote: > > Thanks for bringing this up George. > > As for all solutions to problems where there already exist other > solutions to the same problems, it is important to determine why we > need another solution to the same problem. > Yes. I certainly agree that 'just because we can' is not a good basis for deciding to do things. However, there is something about REST which I observe is being used by a wide community of people as infrastructure technology, to build systems. Equally, webdav has become something which is trivially available. And, it is remarkably easy to deploy on the web server-side. So I see a useful convergence of desire (wide uptake of certificate backed processes, which require access to repositories) and reality (technologies which are easy to deploy, and can be used to bootstrap and maintain certificate repositories). But it reflects my world view. I haven't found widespread uptake of the more traditional mechanisms that have been available to date. Like many others, I don't see aggressive use of the various existing CRL/OCSP check methods. I do think that webdav, being more generally deployed and useful, may be enabling technology for certificate use. > There is a value to have a limited standardized set of ways to do > things as it makes interoperability easier. Sometimes we choose to > offer multiple solutions anyway, mostly to enable re-use of existing > infrastructures. > > I would like to hear more about why it is important to add this to > the menu of repository solutions and revocation mechanisms. I'm going to have to think about that. I fear I am mainly looking at parochial contexts, where I have web, and webdav, and REST coding models, so being able to exploit that technology makes it far easier for me to deploy a repository in the system-as-a-whole compared to using one of the other mechanisms. > My personal concern about the presented approach is that it changes > the trust mechanism for certificate revocation from signed objects > (CRLs and OCSP responses) to trust in a repository infrastructure. um. I'm not sure I understand the difference. In practice, where does an OCSP server get its information about certificate revokation, if not from its own trust in a repository infrastructure? and, the WEBDAV exchange is using a signed transport. ok. I see Dave did make that optional. that looks like a weakness to me. I would expect that to be addressed, if the work was adopted. > That is, if I get a certificate in return from an expected location > it is supposed to be valid. Yet, when revoked a 1 post CRL is > examined making revocation CRL based. I don't think this fits with > the model of CRL processing described in section 6.3 of RFC 3280. Yes. a side effect of REST is the applicability of an item of data is very contextually bound to its name-path in the REST url. I would have thought that we could be discussing alternative approaches to make more traditional CRLs over collections of objects explicit namepoints in REST. But, that kinda goes back to your base question: why another method? -George > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- > > pkix@mail.imc.org] On Behalf Of George Michaelson > > Sent: den 6 september 2007 08:47 > > To: ietf-pkix@imc.org > > Subject: request for WG to adopt draft-chadwick-webdav-00.txt as a > > work item > > > > > > > > I am very interested in the construction of a systematic framework > > for webdav based publication protocols to be used to publish into > > repositories. Other WG areas of work are considering adoption of > > certificate based models which require large, distributed > > repositories to be maintained, and will imply a repository > > provisioning protocol. > > > > I therefore wish to propose the WG adopt > > draft-chadwick-webdav-00.txt as a work item. > > > > I would also like to ask that the document be slightly modified, to > > present two distinct parts in the proposal > > > > 1) that part which documents use of WEBDAV as a repository > > publication protocol and the use of a REST model. > > > > 2) that part which discusses naming of the repository objects in the > > repository, eg for use in the SIA and AIA fields, and the related > > REST model name mapping. > > > > The reason I ask that it be re-worked in this way is that there are > > other models of repository naming architecture which do not have > > 'deep' RDN name structure in the certificate Subject name, and are > > less ameanable to a deterministic mapping as Dave has proposed. If > > the document is re-worked slightly to make it plain that this is > > only one of many repository naming models, it will be easier for > > related work to cite this document in reference to part 1) use of > > WEBDAV and to draw up a distinct repository name mapping function > > reflecting part 2) in spirit. > > > > I have some very minor concerns with stipulating the correct TLS > > version to support virtual webhost naming in a secured connection to > > the server during WEBDAV binding. I am sure these can be very easily > > addressed. > > > > Thanks to Dave Chadwick for writing this draft, and presenting it at > > IETF69 Chicago. > > > > -George > >
- request for WG to adopt draft-chadwick-webdav-00.… George Michaelson
- RE: request for WG to adopt draft-chadwick-webdav… Stefan Santesson
- Re: request for WG to adopt draft-chadwick-webdav… George Michaelson
- RE: request for WG to adopt draft-chadwick-webdav… Stefan Santesson
- Re: request for WG to adopt draft-chadwick-webdav… George Michaelson
- Re: request for WG to adopt draft-chadwick-webdav… Stephen Kent
- Re: request for WG to adopt draft-chadwick-webdav… Stephen Kent
- Re: request for WG to adopt draft-chadwick-webdav… David Chadwick
- Re: request for WG to adopt draft-chadwick-webdav… Denis Pinkas
- Re: request for WG to adopt draft-chadwick-webdav… David Chadwick
- RE: request for WG to adopt draft-chadwick-webdav… Stefan Santesson
- Re: request for WG to adopt draft-chadwick-webdav… David Chadwick
- Re: request for WG to adopt draft-chadwick-webdav… David Chadwick
- Re: request for WG to adopt draft-chadwick-webdav… Denis Pinkas
- Re: request for WG to adopt draft-chadwick-webdav… Stephen Kent
- RE: request for WG to adopt draft-chadwick-webdav… Stefan Santesson
- RE: request for WG to adopt draft-chadwick-webdav… Stefan Santesson
- Re: request for WG to adopt draft-chadwick-webdav… Stephen Kent
- Re: request for WG to adopt draft-chadwick-webdav… David Chadwick
- RE: request for WG to adopt draft-chadwick-webdav… Kemp, David P.
- Re: request for WG to adopt draft-chadwick-webdav… David Chadwick