Subject: request for WG to adopt draft-chadwick-webdav-00.txt as a work item

From: George Michaelson <[email-masked]>
Date: Thu, 6 Sep 2007 12:16:35 +0530

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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 6 Sep 2007 11:12:05 +0100

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.

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.

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

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of George Michaelson
> Sent: den 6 september 2007 08:47
> To: [email-masked]
> Subject: request for WG to adopt draft-chadwick-webdav-00.txt as a work
> item
>
>
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Sep 2007 16:07:57 +0530

On Thu, 6 Sep 2007 11:12:05 +0100
Stefan Santesson <[email-masked]> wrote:

> 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

> > 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
> > 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.
> >
> > 1) that part which documents use of WEBDAV as a repository
> > publication protocol and the use of a REST model.
> >
> > '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.
> >

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 6 Sep 2007 11:56:34 +0100

A few answers and comments:

> I don't see
> aggressive use of the various existing CRL/OCSP check methods.

We must have vastly different experience then. I see a very large deployment of PKI based on CRL and OCSP. However large amounts of certs are deployed where they are not very visible, for example to enable VPN or wireless networks. Public PKIs are still not very spread with exception of web-server certificates.

It is my experience that OCSP and CRLs works very well in the vast majority of cases I see.

> I do think that webdav, being more generally deployed and useful, may be

More specifically, what blocking factor for PKI deployment do you think would go away with this solution?

Webdav does not have the greatest security story and here we are depending on that technology to provide reliable trustworthy information. I would like to see someone being expert on this technology vouching for its security properties.

> from its own trust in a repository infrastructure?

I does not have to. It can use a signed CRL as source. When an OCSP server do access the CA database, it usually either sits on the local protected network together with the CA or use other security means to protect the integrity of that information.

This is vastly different from a user accessing the webdav server over the public internet.

Stefan Santesson
Senior Program Manager

> From: George Michaelson [mailto:[email-masked]]
> Sent: den 6 september 2007 12:38
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: request for WG to adopt draft-chadwick-webdav-00.txt as a
> work item
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Sep 2007 16:49:06 +0530

On Thu, 6 Sep 2007 11:56:34 +0100
Stefan Santesson <[email-masked]> wrote:

> We must have vastly different experience then. I see a very large
> deployment of PKI based on CRL and OCSP. However large amounts of
> certs are deployed where they are not very visible, for example to
> enable VPN or wireless networks. Public PKIs are still not very
> spread with exception of web-server certificates.

right. I see webdave (that was a slip, which I will leave in for its
humour value in context) addressing the public space. 

I do not claim OCSP, CRLs are not used. I will believe you that  in
private contexts they get good deployment. I am also sure that very few
people in browserland consciously engage with CRLs or OCSP services, and
routinely click through warning boxes about server certificate name
mismatches, expiry, or lack of TA material behind the cert being
offered.

> It is my experience that OCSP and CRLs works very well in the vast

That's good to know. Because the SIDR WG is about testing assertions
about the totality of the information in the repository, OCSP was not
high on my radar. access to CRLs, and efficient access to repositories
is, and web or webdav, in allowing mechanisms like cache time controls,
virtual hosting and streams of data, looked like a good longterm fit. 

> 
> > I do think that webdav, being more generally deployed and useful,
> > may be enabling technology for certificate use.
> 

public acceptance of the management side costs of maintaining
repositories. I regard the methods embedded in my current open source
systems as wildly ad-hoc. Since webdav is a given for the webserver
which is the public face of the certificate processes, making webdav be
used to publish and maintain the repository would be trivial. YMMV

> Webdav does not have the greatest security story and here we are
> depending on that technology to provide reliable trustworthy
> information. I would like to see someone being expert on this
> technology vouching for its security properties.

That is also fair. It will be abundantly clear to the rest of the list
I am a consumer of certificate expertise, not an originator. I felt
that webdav over HTTP/TLS was adequately secure. If I am wrong, that
would of course change my feelings. But only in respect of the CRL/OCSP
side for relying parties. I am still interested in its use as a
provisioning method, where you own the link to the repository from the
certificate engine.

> 
> > 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?
> 
> I does not have to. It can use a signed CRL as source. When an OCSP
> server do access the CA database, it usually either sits on the local
> protected network together with the CA or use other security means to
> protect the integrity of that information.
> 

As I said, I don't think webdav on HTTP/80 makes much sense for the
OCSP/CRL side of this. I would expect that configuring the specific
Webdav/HTTPS server certificate in was morally equivalent to accepting
the OCSP servers certification over its assertions.

My main interest is repository PROVISIONING. The necessary aspects of
defining a namespace for mapping certificate DNs into the web, for a
web view of SIA/AIA, and the definition of a protocol for using webdav
to get the material ONTO the repository is where I am looking for a win.

You are addressing the revocation side, and I do not disagree there are
issues. I would expect that a rewrite on the draft could separate into
now three parts

1) webdav as a trustable protocol, and REST models for the publishing
   process. Mainly about POST and DEL behaviours to write and remove
   information.

2) webdav as a trustable protocol, and REST models for the relying party
   side including the revokation issues. mainly about GET and the
   expectations in namespace to defined CRLs over sets of certs, beyond
   the one-cert CRL model.

3) namespace mapping from DN into the web URL. mainly about the
   principles, and the specific mapping for full DNs. As I said in
   my original mail, I don't think this is going to be applicable for
   all contexts, wide/flat namespaces may expect other mappings.

I would be able to exploit 1) and 3). I do not see 2) as such a massive
problem it could not be entertained, but I can see as WG chair you are
not drawn there.

If Dave isn't motivated to buy into this and the draft isn't going
anywhere I won't be making a stink. I just wanted to float the idea and
do a +1 on it. 

Its probably not worth more of your time right now Stefan. I won't post
any more for a bit.

 cheers

-george

> > Subject: Re: request for WG to adopt draft-chadwick-webdav-00.txt
> > as a work item
> >
> > > 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.
> >
> > 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.
> >
> > > offer multiple solutions anyway, mostly to enable re-use of
> > > existing infrastructures.
> > >
> > > 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?
> >
> > > 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.
> >
> > > > 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 would also like to ask that the document be slightly
> > > > modified, to present two distinct parts in the proposal
> > > >
> > > > 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.
> > > >
> > > > version to support virtual webhost naming in a secured
> > > > connection
> > to
> > > > Thanks to Dave Chadwick for writing this draft, and presenting
> > > > it
> > at
> > > > IETF69 Chicago.
> > > >
> > > > -George
> > >
> > >
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Sep 2007 08:48:13 -0400

At 4:49 PM +0530 9/6/07, George Michaelson wrote:
>...

It's important to let folks in PKIX know that the SIDR context is not 
typical for PKIs. In the RPKI EVERY RP needs to verify EVERY cert and 
CRL (and other signed objects), in nominal operation. Thus an 
OCSP-style revocation status mechanism is inappropriate as it would 
generate tons of requests/responses.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Sep 2007 08:35:24 -0400

>from its own trust in a repository infrastructure?

in many (most?) cases, the OCSP server gets a copy of a CRL from the 
CA and uses that as the basis for its responses.  For the lightweight 
OSCP model (recently approved as an RFC) the responses are 
pre-generated, typically based on a CRL or a privately-transmitted 
CRL-equivalent. So, OCSP is not a good example, i.e., it generally 
makes use of CRLs or their moral equivalent (transmitted securely 
from a CA).

Steve

---

From: David Chadwick <[email-masked]>
Date: Thu, 06 Sep 2007 20:11:46 +0100

Hi George

thankyou for raising the topic on the list (others have only privately
engaged with me).

The current draft does have multiple parts to it, which could be easily
separated into separate IDs.

i)the REST principles and definition of the AIA for the cert and CRL
states/URL locations

ii)the format of the directory structure in the repository (from the 
DN). As you noted, my proposal is only one of many ways of standardising 
this, and it isnt needed at all if push mode is used.

iii) protocols for picking up the state information. One could use 
various different protocols for this, as well as webdav.

Stefan is only partly correct in saying that revocation trust has moved
from signed objects to the repository.  It is true that an attacker 
could make a revoked cert appear to be not revoked by attacking the 
repository and re-installing a valid cert. But this would soon be 
discovered by the issuer and fixed probably in less time than the period 
between CRL issuances. Further, an attacker could not make a valid cert 
appear to be revoked because it cannot manufacture a genuine CRL that is 
needed at the CRL URL. An attacker could make it appear that the cert 
that you are holding was never actually issued by attacking the 
repository and removing the cert from the cert URL. But this is no 
different to a DOS attack which both CRLs and OCSP are susceptible to 
and is considerably more difficult to engineer. Again, the issuer should 
be able to easily detect this. Signed objects are still
essential to prove you have a certificate, in that if rubbish is posted 
at the cert URL, it would never be accepted, so it has to be a genuine 
signed certificate that is there.  Consequently an attacker could never 
manufacture a false credential without breaking the asymmetric 
encryption algorithm, in which case all of PKI is dead anyway.

I am happy to revise the ID when we have an agreement on what changes
should be made, and split it into several if required.

We now have a fully working system using http (not SSL
yet), implemented by a student, and the performance is impressive. Its 
also much easier to install than LDAP for example.

regards

David

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 7 Sep 2007 10:21:26 +0100

David,

> It is true that an attacker
> discovered by the issuer and fixed probably in less time than the
> period between CRL issuances.

One can argue if this is good enough, but if the attacker has control over the web server, then he can re-install the cert as valid at the time of the attack (i.e. when the relying party is receiving the fake transaction and does the checking), and then remove it again to cover up his tracks. This could be done in a few seconds.

> Further, an attacker could not make a valid cert
> appear to be revoked because it cannot manufacture a genuine CRL that
> is needed at the CRL URL.

Which of your statements is true?
"It is true that an attacker could make a revoked cert appear to be not revoked"; or
"Further, an attacker could not make a valid cert appear to be revoked"

From how I read your document I don't need to create any CRL to make a revoked certificate appear non-revoked because only revoked certificates have a CRL of length 1, right?
So I could simply remove the CRL and re-install the certificate as non-revoked.

Your document states:
"*When* a certificate is revoked, it has a unique web page
(revocation URL) at which the revocation list (of length one) *SHOULD* be
found."

Stefan Santesson
Senior Program Manager

> From: David Chadwick [mailto:[email-masked]]
> Sent: den 6 september 2007 21:12
> To: George Michaelson
> Cc: Stefan Santesson; [email-masked]
> >> This is vastly different from a user accessing the webdav server
> over
> >> the public internet.
> >
> Research Web site:
> http://www.cs.kent.ac.uk/research/groups/iss/index.html

---

From: David Chadwick <[email-masked]>
Date: Fri, 07 Sep 2007 20:58:20 +0100

Stefan Santesson wrote:
> David,
> 
>> It is true that an attacker could make a revoked cert appear to be
>> not revoked by attacking the repository and re-installing a valid
>> cert. But this would soon be discovered by the issuer and fixed
>> probably in less time than the period between CRL issuances.
> 
> One can argue if this is good enough, but if the attacker has control
> over the web server, then he can re-install the cert as valid at the
> time of the attack (i.e. when the relying party is receiving the fake
> transaction and does the checking), and then remove it again to cover
> up his tracks. This could be done in a few seconds.

True if the attacker has full control over the web server.

> 
>> Further, an attacker could not make a valid cert appear to be
>> revoked because it cannot manufacture a genuine CRL that is needed
>> at the CRL URL.
> 
> Which of your statements is true? "It is true that an attacker could
> make a revoked cert appear to be not revoked"; or "Further, an
> attacker could not make a valid cert appear to be revoked"

Both are true. There is no conflict in these statements as far as I can 
see. One statement is saying I can turn black into white, the other is 
saying I cannot turn white into black.

> 
>> From how I read your document I don't need to create any CRL to
>> make a revoked certificate appear non-revoked because only revoked
>> certificates have a CRL of length 1, right?

correct, if you have control over the repository.

> 
> Your document states: "*When* a certificate is revoked, it has a
> unique web page (revocation URL) at which the revocation list (of
> length one) *SHOULD* be found."
> 

The reason this is SHOULD and not MUST is risk vs cost as determined by 
the issuer and its users, to give the community more flexibility. The 
safest but costliest method is to issue CRLs, but the cheapest and less 
secure method is to simply remove the certificate. This might be 
adequate for some applications

regards

David

> 
> Stefan Santesson Senior Program Manager Windows Security, Standards
> 
> 
>> -----Original Message----- From: David Chadwick
>> [mailto:[email-masked]] Sent: den 6 september 2007 21:12 
>> To: George Michaelson Cc: Stefan Santesson; [email-masked] 
>> thankyou for raising the topic on the list (others have only
>> privately engaged with me).
>> 
>> The current draft does have multiple parts to it, which could be
>> easily separated into separate IDs.
>> 
>> i)the REST principles and definition of the AIA for the cert and
>> CRL states/URL locations
>> 
>> ii)the format of the directory structure in the repository (from
>> the DN). As you noted, my proposal is only one of many ways of 
>> standardising this, and it isnt needed at all if push mode is used.
>> 
>> 
>> Stefan is only partly correct in saying that revocation trust has
>> moved from signed objects to the repository.  It is true that an
>> attacker could make a revoked cert appear to be not revoked by
>> attacking the repository and re-installing a valid cert. But this
>> would soon be discovered by the issuer and fixed probably in less
>> time than the period between CRL issuances. Further, an attacker
>> could not make a valid cert appear to be revoked because it cannot
>> manufacture a genuine CRL that is needed at the CRL URL. An
>> attacker could make it appear that the cert that you are holding
>> was never actually issued by attacking the repository and removing
>> the cert from the cert URL. But this is no different to a DOS
>> attack which both CRLs and OCSP are susceptible to and is
>> considerably more difficult to engineer. Again, the issuer should 
>> be able to easily detect this. Signed objects are still essential
>> to prove you have a certificate, in that if rubbish is posted at
>> the cert URL, it would never be accepted, so it has to be a genuine
>>  signed certificate that is there.  Consequently an attacker could
>> never manufacture a false credential without breaking the
>> asymmetric encryption algorithm, in which case all of PKI is dead
>> anyway.
>> 
>> I am happy to revise the ID when we have an agreement on what
>> changes should be made, and split it into several if required.
>> 
>> We now have a fully working system using http (not SSL yet),
>> implemented by a student, and the performance is impressive. Its 
>>> On Thu, 6 Sep 2007 11:56:34 +0100 Stefan Santesson
>>> <[email-masked]> wrote:
>>> 
>>>>> I don't see aggressive use of the various existing CRL/OCSP
>>>>> check methods.
>>>> We must have vastly different experience then. I see a very
>>>> large deployment of PKI based on CRL and OCSP. However large
>>>> amounts of certs are deployed where they are not very visible,
>>>> for example to enable VPN or wireless networks. Public PKIs are
>>>> still not very spread with exception of web-server
>>>> certificates.
>>> right. I see webdave (that was a slip, which I will leave in for
>>> its humour value in context) addressing the public space.
>>> 
>>> I do not claim OCSP, CRLs are not used. I will believe you that
>>> in private contexts they get good deployment. I am also sure that
>>> very
>> few
>>> people in browserland consciously engage with CRLs or OCSP
>>> services,
>> and
>>> routinely click through warning boxes about server certificate
>>> name mismatches, expiry, or lack of TA material behind the cert
>>> being offered.
>>> 
>>> 
>>> That's good to know. Because the SIDR WG is about testing
>>> assertions about the totality of the information in the
>>> repository, OCSP was not high on my radar. access to CRLs, and
>>> efficient access to
>> repositories
>>>>> I do think that webdav, being more generally deployed and
>>>> More specifically, what blocking factor for PKI deployment do
>>>> you think would go away with this solution?
>>> repositories. I regard the methods embedded in my current open
>>> source systems as wildly ad-hoc. Since webdav is a given for the
>>> webserver which is the public face of the certificate processes,
>>> making webdav
>> be
>>>> Webdav does not have the greatest security story and here we
>>>> are depending on that technology to provide reliable
>>>> trustworthy information. I would like to see someone being
>>>> expert on this technology vouching for its security properties.
>>>> 
>>> That is also fair. It will be abundantly clear to the rest of the
>>> 
>> list
>>> I am a consumer of certificate expertise, not an originator. I
>>> felt that webdav over HTTP/TLS was adequately secure. If I am
>>> wrong, that would of course change my feelings. But only in
>>> respect of the
>> CRL/OCSP
>>> provisioning method, where you own the link to the repository
>>> from
>> the
>>> certificate engine.
>>> 
>>>>> 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?
>>>> I does not have to. It can use a signed CRL as source. When an
>>>> OCSP server do access the CA database, it usually either sits
>>>> on the
>> local
>>>> protected network together with the CA or use other security
>>>> means
>> to
>>> As I said, I don't think webdav on HTTP/80 makes much sense for
>>> the OCSP/CRL side of this. I would expect that configuring the
>>> specific Webdav/HTTPS server certificate in was morally
>>> equivalent to
>> accepting
>>> My main interest is repository PROVISIONING. The necessary
>>> aspects of defining a namespace for mapping certificate DNs into
>>> the web, for a web view of SIA/AIA, and the definition of a
>>> protocol for using
>> webdav
>>> to get the material ONTO the repository is where I am looking for
>>> a
>> win.
>>> You are addressing the revocation side, and I do not disagree
>>> there
>> are
>>> issues. I would expect that a rewrite on the draft could separate
>>> 
>> into
>>> now three parts
>>> 
>>> 1) webdav as a trustable protocol, and REST models for the
>>> publishing process. Mainly about POST and DEL behaviours to write
>>> and remove information.
>>> 
>>> 2) webdav as a trustable protocol, and REST models for the
>>> relying
>> party
>>> my original mail, I don't think this is going to be applicable
>>> for all contexts, wide/flat namespaces may expect other mappings.
>>> 
>>> 
>>> problem it could not be entertained, but I can see as WG chair
>>> you
>> are
>>> not drawn there.
>>> 
>>> If Dave isn't motivated to buy into this and the draft isn't
>>> going anywhere I won't be making a stink. I just wanted to float
>>> the idea
>> and
>>> do a +1 on it.
>>> 
>>> Its probably not worth more of your time right now Stefan. I
>>> won't
>> post
>>> any more for a bit.
>>> 
>>> cheers
>>> 
>>> -george
>>> 
>>>> Stefan Santesson Senior Program Manager Windows Security,
>>>> Standards
>>>> 
>>>> 
>>>>> -----Original Message----- From: George Michaelson
>>>>> [mailto:[email-masked]] Sent: den 6 september 2007 12:38 To:
>>>>> Stefan Santesson Cc: [email-masked] Subject: Re: request
>>>>> for WG to adopt draft-chadwick-webdav-00.txt as a work item
>>>>> 
>>>>> On Thu, 6 Sep 2007 11:12:05 +0100 Stefan Santesson
>>>>> <[email-masked]> wrote:
>>>>> 
>>>>>> 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.
>>>>> 
>>>>>>  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.
>>>>> 
>>>>>> 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.
>>>>> 
>>>>>> Stefan Santesson Senior Program Manager Windows Security,
>>>>>> Standards
>>>>>> 
>>>>>> 
>>>>>>> -----Original Message----- From:
>>>>>>> [email-masked] [mailto:owner-ietf- 
>>>>>>> [email-masked]] On Behalf Of George Michaelson Sent:
>>>>>>> den 6 september 2007 08:47 To: [email-masked] Subject:
>>>>>>> request for WG to adopt draft-chadwick-webdav-00.txt as a
>>>>>>> work item
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> 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
>>> 
>> --
>> 
>> David W. Chadwick, BSc PhD Professor of Information Systems
>> Security The Computing Laboratory, University of Kent, Canterbury,
>> CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44
>> 1227 762 811 Mobile: +44 77 96 44 7184 Email:
>> [email-masked] Home Page:
>> http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web
>> site: http://www.cs.kent.ac.uk/research/groups/iss/index.html 
>> Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is
>> 0xBC238DE5
>> 

--

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Sep 2007 13:55:11 +0100

> saying I cannot turn white into black.

You are absolutely right about this David. Sorry for my sloppy reading.
But it does not change my principle stand on this I'm afraid.

Stefan Santesson
Senior Program Manager