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

["Denis Pinkas" <[e-mail]>]

David,

Thank you for your quick reply.

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

If you only use HTTP, it is as if CRLs or certificates were placed in a directory without being signed.
In this context, I cannot "buy" your argument of "There is no such thing as absolute security". 

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

The problem is not adding this requirement, but to say HOW a relying party 
will know - without using out of bands means - that it is indeed connected to the right web server.
 
>> 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.

I was incorrect when writing the three lines above. I should have said:

“The proposed scheme is only able to provide real-time revocation status of certificates 
and thus in unable to support a non-repudiation service". 

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

I tried to imagine the options of the proposal. 
I return the question:  What are the real benefits of option c) versus options b) ?
 
>> 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)

The key question is which options are desirable .

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

The idea is different, the information MUST be captured, when available. 
Anyway, this method is only usable for real-time authentication and keeping it 
would simply be useless.
 
>> 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.

I know understand, but the sentence should be rephrased.

Considering the question to adopt or not this proposal as a PKIX work item, 
for the time being, I am not in favor for the following reasons:

- when using the webdavCert accessMethod, the proposal is insecure 
   since HTTPs is still not mandated,

- when using the webdavCert accessMethod the proposal is insecure 
  since the trust anchor to be used to verify the information provided by the web server is undefined, 

- the proposal is limited to support real-time revocation status of certificates, 
   i.e. it cannot support a non-repudiation service,

- CRLs may be fetched using HTTP, so the argument against LDAP becomes moot.

The idea of having a CRL of length one is original, but CRL splitting is another way to avoid long CRLs.

Denis 

=============================================================

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

Regards,

Denis Pinkas