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

[David Chadwick <[e-mail]>]

Denis Pinkas wrote:
> David,
> 
> I have three major concerns with this draft:
> 
> 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.

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

I dont have a problem with adding this statement.

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

Fine, I will add this.

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

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

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

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)


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

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.

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

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

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

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: [phone]
Fax [phone]
Mobile: [phone]
Email: [e-mail]
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

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