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

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 7 Sep 2007 10:38:17 +0200

David,

I have three major concerns with this draft:

1 - The current proposal is insecure, unless HTTPS is mandated.

2 - Even, if HTTPS is mandated, the proposal is still insecure 
     unless the relying parties may securely know which trust anchor 
    shall be used to verify the certification path of the webdav server.  
    That information MUST be provided by the CA that has issued the certificate, 
    and NOT by "other means".

3 - The text states:

“Whilst a certificate might exist, i.e. from its time of first issuing until it validity period finishes,
 one of the pages SHOULD exist, although some implementations MAY choose to treat 
 a revoked certificate the same as a certificate that has never existed”.

I would be worthwhile to phrase this differently and move the sentence 
once the webdavCert accessMethod has been introduced and state:

“If only the webdavCert accessMethod is supported, then the scheme is only able 
to provide real-time revocation status of certificates.  In order to support a non-repudiation service, 
the webdavRev accessMethod must be supported”.

This means that Certificates issuers may choose to support:

a)	only the webdavRev accessMethod, or
b)	only the webdavCert accessMethod, or
c)	both the webdavRev accessMethod and the webdavCert accessMethod.

This is not clearly stated in the draft.

In addition, I have the following concerns:

4 - The text states:

“When a certificate exists, it has a unique web page (the certificate URL) at which it MUST be found”.

I would be worthwhile to phrase this differently and move the sentence 
once the webdavCert accessMethod has been introduced and state:

“If the webdavCert accessMethod is supported, then when a certificate exists, 
it has a unique web page (the certificate URL) at which the revocation list (of length one) 
MUST be found”.

This means that the following sentence is not appropriate:

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

5 - The text states:

“Optionally the revocation page MAY exist after the validity period of a certificate has expired”.

Using RFC 3280, there is no way to know for a relying party (unless out of bands mechanisms 
are being used), if the CA has chosen to do so or not, so such a feature would be unusable.  
In addition, there is no need to maintain such information once a certificate has expired.

6 – In the security considerations section, the text states:

“Consequently, if the certificates are not meant to be publicly available or stronger security 
is required, then secure access should be provided using HTTP with TLS".

The use of HTTPS has nothing to do with “publicly available” certificates.

Denis

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

Regards,

Denis Pinkas

---

From: David Chadwick <[email-masked]>
Date: Fri, 07 Sep 2007 21:12:39 +0100

> 1 - The current proposal is insecure, unless HTTPS is mandated.

There is no such thing as absolute security as you are aware and HTTPS 
does not give absolute security. It does provide more security than HTTP 
but at a greater cost. So the option to use HTTP is there for those RPs 
that are happy with this risk vs cost tradeoff.

>     and NOT by "other means".

I dont have a problem with adding this statement.

> the webdavRev accessMethod must be supported”.

Fine, I will add this.

> This is not clearly stated in the draft.

I do not think that issuers will want to support a), do you?

> “When a certificate exists, it has a unique web page (the certificate URL) at which it MUST be found”.

This is because I never considered your proposed option a) above.  I 
would prefer not to go down this route unless a good argument can be 
made for your option a)

> In addition, there is no need to maintain such information once a certificate has expired.

I seem to remember that it was you who wanted this feature so that an RP 
could determine after the fact whether a cert had been revoked or not. 
Out of bound mechanisms are OK anyway, since you have already suggested 
one ie. that the CA tells the RP which trust anchor to use for the SSL 
service.

> The use of HTTPS has nothing to do with “publicly available” certificates.

It is related in this way. If HTTPS with client side (mutual) authn is 
used, then the server can use the DN of the client to provide an authz 
service. With http only public access can be provided.

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: Stephen Kent <[email-masked]>
Date: Mon, 10 Sep 2007 13:11:31 -0400

David,

I have to agree with those who have expressed some concerns about 
security aspects of cert revocation status under the WebDAV model.  I 
think it is a precept of current PKI models that we don't rely 
completely on the integrity of repositories.  That's why we post 
signed CRLs and why the v2 CRL has both this update and next update 
fields. We are always cognizant of the possibility that even with 
signed data, the data might not be fresh, and so we try to minimize 
the vulnerabilities associated with our reliance on on repositories.

Steve

---

From: David Chadwick <[email-masked]>
Date: Tue, 11 Sep 2007 11:01:46 +0100

Hi Steve

As you know nearly everything in security is a tradeoff in one way or 
another. What the webdav scheme gives you is instant revocation status, 
which CRLs do not give you, but the tradeoff is having to trust the 
repository. So the schemes are fundamentally different, but I submit 
that there are many user requirements where the tradeoff of instant 
revocation is preferable to the more cryptographically protected though 
stale CRL scheme.

regards

David

Stephen Kent wrote:
> completely on the integrity of repositories.  That's why we post signed 
> CRLs and why the v2 CRL has both this update and next update fields. We 
> are always cognizant of the possibility that even with signed data, the 
> data might not be fresh, and so we try to minimize the vulnerabilities 
> associated with our reliance on on repositories.
> 
> Steve
> 
> 

--

---

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

David,

Everything in security is a tradeoff, but that is not an excuse to introduce new classes of threats that defeats basic security principles when there exists valid alternatives that don't.
PKI has some basic important security principles in that it leverage trust in signed objects and not in the information infrastructure. Also, when CRLs are used for revocation checking, there is an underlying principle that one or more CRL's are available with scopes that cover all issued certificate with a current validity period.

With the WebDav proposal you violate both these principles. I don't see a strong enough motivation for doing so, and I object to putting an IETF/PKIX rubberstamp on such solution
Therefore I can't support this solution to be developed within the PKIX workgroup.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of David Chadwick
> Sent: den 11 september 2007 12:02
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: request for WG to adopt draft-chadwick-webdav-00.txt as a
> work item
>
>
> Hi Steve
>
> signed
> Research Web site:
> http://www.cs.kent.ac.uk/research/groups/iss/index.html

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Sep 2007 11:10:01 -0400

At 11:01 AM +0100 9/11/07, David Chadwick wrote:
>Hi Steve
>
>As you know nearly everything in security is a tradeoff in one way 
>or another. What the webdav scheme gives you is instant revocation 
>status, which CRLs do not give you, but the tradeoff is having to 
>trust the repository. So the schemes are fundamentally different, 
>but I submit that there are many user requirements where the 
>tradeoff of instant revocation is preferable to the more 
>cryptographically protected though stale CRL scheme.
>
>regards
>
>David

The phrase "instant revocation status" is, I fear, a misnomer. In 
OCSP an RP can make a query about a single cert and get a response 
that applies to just that cert, but that says nothing about the 
relative freshness of the revocation  status data vs. what a CRL 
tells us.  The same is potentially true here.

Also, if one argues that a CA will manage a repository under the 
WebDAV approach to offer fresher revocation status data than a CRL, 
the same argument could be made for the CA managing an OCSP server, 
right? In the case of OCSP, one need not trust a repository, but 
rather trust an OCSP server.  Is there a difference? Maybe, maybe 
not. It will depend on what forms of authentication one requires for 
WebDAV access, e.g., if you mandated use of TLS and required that the 
TLS server cert be issued under the CA in question, then maybe the 
security would be equivalent to what we have with an OCSP server (not 
lightweight) with a server cert issued under the CA.

In general I think that instant revocation is over emphasized. In 
many (most?) contexts the decision to revoke a cert is a serious one, 
and thus people generally do not act very quickly. In fact, this is a 
big part of why the financial community insisted on cert hold status 
as a half-way revocation mechanism.  Thus the speed with which a 
revocation decision is reflected in a database (OCSP, CRL, or WebDAV) 
is probably the fastest link in the process chain.

Steve

---

From: David Chadwick <[email-masked]>
Date: Fri, 14 Sep 2007 17:14:48 +0100

Stefan Santesson wrote:
> David,
> 
> Everything in security is a tradeoff, but that is not an excuse to
> introduce new classes of threats that defeats basic security
> principles when there exists valid alternatives that don't. PKI has
> some basic important security principles in that it leverage trust in
> signed objects and not in the information infrastructure.

I think you will find this is not always entirely true. The DNS is 
usually needed as a trusted entity, and if it mal-performs PKIs can 
break disasterously.

  Also, when
> CRLs are used for revocation checking, there is an underlying
> principle that one or more CRL's are available with scopes that cover
> all issued certificate with a current validity period.

I agree that this is one of the key strengths of CRLs.

> 
> With the WebDav proposal you violate both these principles. I don't
> see a strong enough motivation for doing so,

Lets wait and see on this one. WebDav is becoming more ubiquitous all 
the time. SVN and other systems use it as their transport medium. It is 
rumoured that it will take over from FTP soon.

But as I said in my earlier email, my proposal is really three topics in 
one: the REST conceptual model, the protocol(s) that might use the REST 
principles for certificate status (only WebDav proposed so far but 
others could be used as well), and the information model for naming the 
certs and CRL files.

I think fundamentally it is the REST model that you do not like for 
determining the status of a certificate. Am I correct on that?

regards

David

  and I object to putting
> an IETF/PKIX rubberstamp on such solution Therefore I can't support
> this solution to be developed within the PKIX workgroup.
> 
> 
> Stefan Santesson Senior Program Manager Windows Security, Standards
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:owner-ietf- [email-masked]] On Behalf Of David Chadwick 
>> Sent: den 11 september 2007 12:02 To: Stephen Kent Cc:
>> [email-masked] Subject: Re: request for WG to adopt
>> draft-chadwick-webdav-00.txt as a work item
>> 
>> 
>> Hi Steve
>> 
>>>  security aspects of cert revocation status under the WebDAV
>>> model.  I think it is a precept of current PKI models that we
>>> don't rely completely on the integrity of repositories.  That's
>>> why we post
>> signed
>>> CRLs and why the v2 CRL has both this update and next update
>>> fields.
>> We
>>> are always cognizant of the possibility that even with signed
>>> data,
>> the
>> 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: "Kemp, David P." <[email-masked]>
Date: Mon, 17 Sep 2007 10:28:37 -0400

David,

I have to agree with Stefan and Steve on this.

1) DNS may be mis-trusted (falsely treated as a trusted entity)
with disastrous results, but properly designed applications would
permit PKI to fix that, not fail because of it.  A signed object
containing a DNS name permits detection of DNS failures.

Any purely DNS-based identity registration process is, of course,
as weak as DNS itself, so PKI at a minimum would have to use
something like credit card identity proofing through multiple
channels (physical mail of a registration secret + home
telephone activation) if it wishes to claim better assurance
for real (vs. pseudonymous) identities than that provided by DNS.

2) It is not the REST model that is of concern - short CRLs,
OCSP responses, or their signed SAML equivalents could be
retrieved just as easily using RESTful requests (SOAP/resource)
as with LDAP, CMC, or SOAP/RPC.  As Stefan says, it is the
signed object generated by a trusted PKI component that counts,
not the method by which it is obtained.  Of course, a CA
with any particular level of assurance could operate a WebDAV
interface that yields the same results as its CRLs, but you
intend WebDAV revocation responders to not be limited
to CAs, thus greatly expanding the attack surface of the system.

Is there a way to leverage all three portions of the proposal
(REST conceptual model, REST protocols, and naming models)
while preserving the end-to-end (PKI to consumer application)
properties of signed objects?

>> What the webdav scheme gives you is instant revocation
>> status, which CRLs do not give you, but the tradeoff is 
>> having to trust the repository.

If "instant" is the goal, I believe it would be better
achieved by morphing the repository into a basic assurance
PKI component with its own keys.  A CA's CPS can document
any deliberative process it wants (including none) before
revoking certs, thus permitting delegated responders
(WebDAV or other) to achieve any desired tradeoff between
response time and accuracy.

V/R,
Dave

---

From: David Chadwick <[email-masked]>
Date: Wed, 26 Sep 2007 21:55:36 +0100

Hi David

I have been thinking about the question you posed below, and my response 
is just below it

> properties of signed objects?

One solution would be for the cert URL to point to the certificate and 
the revocation URL to point to the CRL for this certificate, in which 
the following states hold:

Certificate exists and is valid: certificate at certificate URL and 
empty CRL at rev URL
Certificate exists and is revoked: nothing at certificate URL and CRL 
with single entry at rev URL.
Certificate not issued: nothing at either URL (URLs probably not defined)

In this way you have cryptographic proof of the state of the 
certificate, and each certificate has its own stateful resource URLs.

What do you think?

regards

David

--