- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 23 Oct 2005 14:22:44 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Lisa Dusseault <lisa@osafoundation.org>, WebDav WG <w3c-dist-auth@w3.org>
- Message-ID: <435B8094.1040903@gmx.de>
OK,
below a proposal to resolve issues 20
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20>, "Lock
Token Examples"), 91
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=91>, "chapter
name for lock token uri schemes"), 102
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=102>, "lock
tokens in examples") and 99
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=99>, "Risks
Connected with Lock Tokens").
It does this by
- fixing examples (URI scheme, syntax, whitespace), always using
syntactically legal urn:uuid URIs
- rewriting section 6.4, getting rid of 6.5 consequently
- fixing the security consideratios, basically re-using the text from
RFC2518 and just fix what was broken or out-of-date
- move "opaquelocktoken" definition into appendix with minimally
required spec text
The changes are:
Section 6., para. 16:
OLD:
This specification provides a lock token URI scheme called
opaquelocktoken that meets the uniqueness requirements. However
resources are free to return any URI scheme so long as it meets the
uniqueness requirements. According to current IETF best practices,
implementations SHOULD use registered URI schemes to ensure
uniqueness.
NEW:
A robust method for generating a lock token fulfilling the uniqueness
requirements is to leverage the "Universally Unique IDentifier"
(UUID) mechanism. URI schemes that can use UUIDs are the "UUID" URN
Namespace defined in [9] and the "opaquelocktoken" URI scheme defined
in Appendix C.
However resources are free to return any URI scheme so long as it
meets the uniqueness requirements. According to current IETF best
practices, implementations SHOULD use registered URI schemes to
ensure uniqueness.
Section 6., para. 19:
OLD:
6.4 Lock Token URI Schemes
In order to guarantee uniqueness across all resources for all time a
server MAY use the Universal Unique Identifier (UUID) [9] mechanism
to generate a lock token:
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly
while still guaranteeing the lock token to be unique across all
resources for all time. With the 'opaquelocktoken' scheme, the
server MAY reuse a UUID with extension characters added. If the
server does this then the algorithm generating the extensions MUST
guarantee that the same extension will never be used twice with the
associated UUID.
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID
production is the string representation of a UUID. Note that white
space (LWS) is not allowed between elements of this production.
Extension = path ; path is defined in section 3.3 of RFC2396 [5]
6.5 Lock Capability Discovery
NEW:
6.4 Lock Capability Discovery
Section 7., para. 77:
OLD:
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
If: <http://www.ics.uci.edu/users/f/fielding/index.html>
(<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
NEW:
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
If: <http://www.ics.uci.edu/users/f/fielding/index.html>
(<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
Section 8., para. 219:
OLD:
MOVE /container/ HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/othercontainer/
Overwrite: F
If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
NEW:
MOVE /container/ HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/othercontainer/
Overwrite: F
If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
Section 8., para. 260:
OLD:
HTTP/1.1 200 OK
Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
NEW:
HTTP/1.1 200 OK
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Section 8., para. 261:
OLD:
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-
00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://example.com/workspace/webdav
/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
NEW:
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
Section 8., para. 263:
OLD:
Note that the locktoken and lockroot href elements would not contain
any whitespace. The line return appearing in this document is only
for formatting.
8.11.7 Example - Refreshing a Write Lock
NEW:
8.11.7 Example - Refreshing a Write Lock
Section 8., para. 265:
OLD:
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
NEW:
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
Section 8., para. 268:
OLD:
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-
00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://example.com/workspace/webdav
/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
NEW:
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>infinity</D:depth>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
<D:href
>http://example.com/workspace/webdav /proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
Section 8., para. 292:
OLD:
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: example.com
Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
NEW:
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: example.com
Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
Section 8., para. 295:
OLD:
In this example, the lock identified by the lock token
"opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
successfully removed from the resource
http://example.com/workspace/webdav/info.doc. If this lock included
more than just one resource, the lock is removed from all resources
included in the lock. The 204 (No Content) status code is used
instead of 200 (OK) because there is no response entity body.
NEW:
In this example, the lock identified by the lock token
"urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully
removed from the resource
http://example.com/workspace/webdav/info.doc. If this lock included
more than just one resource, the lock is removed from all resources
included in the lock. The 204 (No Content) status code is used
instead of 200 (OK) because there is no response entity body.
Section 9., para. 38:
OLD:
If: (<opaquelocktoken:a-write-lock-token> ["I am an ETag"]), (["I
am another ETag"])
NEW:
If: (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>
["I am an ETag"]),
(["I am another ETag"])
Section 9., para. 39:
OLD:
The previous header would require that the resource identified in the
Request-URI be locked with the specified lock token and in the state
identified by the "I am an ETag" ETag or in the state identified by
the second ETag "I am another ETag". To put the matter more plainly
one can think of the previous If header as being in the form (or (and
<opaquelocktoken:a-write-lock-token> ["I am an ETag"]) (and ["I am
another ETag"])).
NEW:
The previous header would require that the resource identified in the
Request-URI be locked with the specified lock token and in the state
identified by the "I am an ETag" ETag or in the state identified by
the second ETag "I am another ETag". To put the matter more plainly
one can think of the previous If header as being in the form (or (and
<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC> ["I am an ETag"])
(and ["I am another ETag"])).
Section 9., para. 44:
OLD:
COPY /resource1 HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/resource2
If: <http://www.example.com/resource1>
(<opaquelocktoken:a-write-lock-token> [W/"A weak ETag"]),
(["strong ETag"]),
<http://www.bar.bar/random>
(["another strong ETag"])
NEW:
COPY /resource1 HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/resource2
If: <http://www.example.com/resource1>
(<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>
[W/"A weak ETag"]),
(["strong ETag"]),
<http://www.bar.bar/random>
(["another strong ETag"])
Section 9., para. 45:
OLD:
In this example http://www.example.com/resource1 is being copied to
http://www.example.com/resource2. When the method is first applied
to http://www.example.com/resource1, resource1 must be in the state
specified by "(<opaquelocktoken:a-write-lock-token> [W/"A weak
ETag"]) (["strong ETag"])", that is, it either must be locked with a
lock token of "opaquelocktoken:a-write-lock-token" and have a weak
entity tag W/"A weak ETag" or it must have a strong entity tag
"strong ETag".
NEW:
In this example http://www.example.com/resource1 is being copied to
http://www.example.com/resource2. When the method is first applied
to http://www.example.com/resource1, resource1 must be in the state
specified by "(<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC> [W/"A
weak ETag"]) (["strong ETag"])", that is, it either must be locked
with a lock token of "urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC"
and have a weak entity tag W/"A weak ETag" or it must have a strong
entity tag "strong ETag".
Section 9., para. 49:
OLD:
If: (Not <opaquelocktoken:write1> <opaquelocktoken:write2>)
NEW:
If: (Not <urn:uuid:E90CB889-97CA-49b9-AC33-111111111111>
<urn:uuid:E90CB889-97CA-49b9-AC33-222222222222>)
Section 9., para. 50:
OLD:
When submitted with a request, this If header requires that all
operand resources must not be locked with opaquelocktoken:write1 and
must be locked with opaquelocktoken:write2.
NEW:
When submitted with a request, this If header requires that all
operand resources must not be locked with
urn:uuid:E90CB889-97CA-49b9-AC33-111111111111 and must be locked with
urn:uuid:E90CB889-97CA-49b9-AC33-222222222222.
Section 9., para. 58:
OLD:
DELETE /specs/rfc2518.txt HTTP/1.1
Host: www.example.com
If: <http://www.example.com/specs/>
(<opaquelocktoken:a-write-lock-token>)
NEW:
DELETE /specs/rfc2518.txt HTTP/1.1
Host: www.example.com
If: <http://www.example.com/specs/>
(<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>)
Section 13., para. 19:
OLD:
Description: The href contains a single lock token URI which refers
to the lock (i.e., the OpaqueLockToken-URI production in section
6.4).
NEW:
Description: The href contains a single lock token URI which refers
to the lock.
Section 14., para. 85:
OLD:
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href>opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-
00a0c91a9d76</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://www.example.com/container/</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
NEW:
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:href>http://www.example.com/container/</D:href>
<D:propstat>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href
>urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://www.example.com/container/</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Section 19., para. 24:
OLD:
This specification requires the use of Universal Unique Identifiers
(UUIDs) [9] for lock tokens, in order to guarantee their uniqueness
across space and time. The security considerations for UUIDs do not
apply because WebDAV does not assume that lock tokens are supposed to
be hard to guess or require integrity. In addition, UUIDs MAY
contain a IEEE 802 node ID, usually the host address. Since a WebDAV
server will issue many locks over its lifetime, the use of node IDs
might cause the WebDAV server to reveal its IEEE 802 address.
Several risks are related to this:
NEW:
This specification recommends the use of Universal Unique Identifiers
(UUIDs) for lock tokens, in order to guarantee their uniqueness
across space and time. UUIDs, as defined in [9], contain a "node"
field which "consists of the IEEE address, usually the host address.
For systems with multiple IEEE 802 nodes, any available node address
can be used." Since a WebDAV server will issue many locks over its
lifetime, the implication is that it will also be publicly exposing
its IEEE 802 address.
There are several risks associated with exposure of IEEE 802
addresses. Using the IEEE 802 address:
Section 19., para. 28:
OLD:
19.8 Hosting malicious scripts executed on client machines
NEW:
Section 4.5 of [9] details an alternate mechanism for generating the
"node" field of a UUID without using an IEEE 802 address, which
alleviates the risks associated with exposure of IEEE 802 addresses
by using an alternate source of uniqueness.
19.8 Hosting malicious scripts executed on client machines
Section 20., para. 4:
OLD:
This specification also defines a URI scheme for the encoding of lock
tokens, the opaquelocktoken URI scheme described in section 6.4.
NEW:
This specification also defines the "opaquelocktoken" URI scheme for
the encoding of lock tokens (see Appendix C).
NEW:
Appendix C. 'opaquelocktoken' URI Scheme
The 'opaquelocktoken' URI scheme defined below uses the Universal
Unique Identifier (UUID) mechanism ([9], Section 4) to easily
generate lock tokens fulfilling the uniqueness requirements stated in
Section 6.3.
OpaqueLockToken-URI = "opaquelocktoken:" UUID [path]
; UUID: see [RFC4122], Section 3.
; path: see [RFC3986], Section 3.3.
Note that the optional "path" postfix allows to generate many lock
tokens from a single URI, by appending an varying string such as a
sequence number.
Example:
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017
--- draft-ietf-webdav-rfc2518bis-latest.xml 2005-10-21 16:12:09.000000000 +0100
+++ draft-ietf-webdav-rfc2518bis-latest.20.xml 2005-10-23 13:02:21.000000000 +0100
@@ -601,7 +601,7 @@
</t>
</section>
- <section title="Lock Tokens">
+ <section title="Lock Tokens" anchor="lock.tokens">
<t>
A lock token is a type of state token, represented as a URI, which
identifies a particular lock. A lock token is returned in the Lock-
@@ -619,11 +619,16 @@
resources and servers without fear of confusion.
</t>
<t>
- This specification provides a lock token URI scheme called
- opaquelocktoken that meets the uniqueness requirements. However
- resources are free to return any URI scheme so long as it meets the
- uniqueness requirements. According to current IETF best practices, implementations
- SHOULD use registered URI schemes to ensure uniqueness.
+ A robust method for generating a lock token fulfilling the
+ uniqueness requirements is to leverage the "Universally Unique IDentifier"
+ (UUID) mechanism. URI schemes that can use UUIDs are the "UUID" URN
+ Namespace defined in <xref target="RFC4122"/> and the "opaquelocktoken"
+ URI scheme defined in <xref target="opaquelocktoken.uri.scheme"/>.
+ </t>
+ <t>
+ However resources are free to return any URI scheme so long as it meets the
+ uniqueness requirements. According to current IETF best practices, implementations
+ SHOULD use registered URI schemes to ensure uniqueness.
</t>
<t>
Submitting a lock token does not confer full privilege to use
@@ -640,31 +645,6 @@
</t>
</section>
- <section title="Lock Token URI Schemes">
- <t>
- In order to guarantee uniqueness across all resources for all time
- a server MAY use the <xref target="RFC4122">Universal Unique
- Identifier (UUID)</xref> mechanism to generate a lock token:
- </t>
- <t>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</t>
- <t>The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly
- while still guaranteeing the lock token to be unique across all
- resources for all time. With the 'opaquelocktoken' scheme, the server MAY
- reuse a UUID with extension characters added. If the server does this then
- the algorithm generating the extensions MUST guarantee that the same
- extension will never be used twice with the associated UUID.
- </t>
- <t>
- OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The
- UUID production is the string representation of a UUID. Note
- that white space (LWS) is not allowed between
- elements of this production.
- </t>
- <t>
- Extension = path ; path is defined in section 3.3 of <xref target="RFC2396">RFC2396</xref>
- </t>
- </section>
-
<section title="Lock Capability Discovery">
<t>
Since server lock support is optional, a client trying to lock a
@@ -1039,7 +1019,7 @@
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
If: <http://www.ics.uci.edu/users/f/fielding/index.html>
- (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
+ (<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
>>Response
@@ -2441,8 +2421,8 @@
Host: www.example.com
Destination: http://www.example.com/othercontainer/
Overwrite: F
- If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
- (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
+ If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
+ (<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
>>Response
@@ -2688,7 +2668,7 @@
>>Response
HTTP/1.1 200 OK
- Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
+ Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
@@ -2706,12 +2686,12 @@
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
- <D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-
- 00a0c91e6be4</D:href>
+ <D:href
+ >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
- <D:href>http://example.com/workspace/webdav
- /proposal.doc</D:href>
+ <D:href
+ >http://example.com/workspace/webdav/proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
@@ -2729,11 +2709,6 @@
seconds). Note that the nonce, response, and opaque fields have not
been calculated in the Authorization request header.
</t>
- <t>
- Note that the locktoken and lockroot href elements would not contain
- any whitespace. The line return appearing in this document is only
- for formatting.
- </t>
</section>
<section title="Example - Refreshing a Write Lock">
@@ -2744,7 +2719,7 @@
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: example.com
Timeout: Infinite, Second-4100000000
- Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
+ Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
@@ -2770,12 +2745,12 @@
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
- <D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-
- 00a0c91e6be4</D:href>
+ <D:href
+ >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
<D:lockroot>
- <D:href>http://example.com/workspace/webdav
- /proposal.doc</D:href>
+ <D:href
+ >http://example.com/workspace/webdav /proposal.doc</D:href>
</D:lockroot>
</D:activelock>
</D:lockdiscovery>
@@ -2919,7 +2894,7 @@
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: example.com
- Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
+ Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
Authorization: Digest username="ejw",
realm="ejw@example.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
@@ -2933,7 +2908,7 @@
<t>
In this example, the lock identified by the lock token
- "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
+ "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
successfully removed from the resource
http://example.com/workspace/webdav/info.doc. If this lock included
more than just one resource, the lock is removed from all resources
@@ -3118,7 +3093,7 @@
<section title="If Header" anchor="if-header">
<figure>
- <artwork>
+ <artwork type="abnf2616">
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List
Tagged-list = Resource 1*List
@@ -3179,8 +3154,9 @@
<figure>
<preamble>Example - no-tag-list production</preamble>
<artwork><![CDATA[
- If: (<opaquelocktoken:a-write-lock-token> ["I am an ETag"]), (["I
- am another ETag"])
+ If: (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>
+ ["I am an ETag"]),
+ (["I am another ETag"])
]]></artwork>
</figure>
<t>
@@ -3189,7 +3165,7 @@
state identified by the "I am an ETag" ETag or in the state
identified by the second ETag "I am another ETag". To put the
matter more plainly one can think of the previous If header as being
- in the form (or (and <opaquelocktoken:a-write-lock-token> ["I am an
+ in the form (or (and <urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC> ["I am an
ETag"]) (and ["I am another ETag"])).
</t>
</section>
@@ -3220,7 +3196,9 @@
Host: www.example.com
Destination: http://www.example.com/resource2
If: <http://www.example.com/resource1>
- (<opaquelocktoken:a-write-lock-token> [W/"A weak ETag"]), (["strong ETag"]),
+ (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>
+ [W/"A weak ETag"]),
+ (["strong ETag"]),
<http://www.bar.bar/random>
(["another strong ETag"])
]]></artwork>
@@ -3229,9 +3207,9 @@
In this example http://www.example.com/resource1 is being copied to
http://www.example.com/resource2. When the method is first applied
to http://www.example.com/resource1, resource1 must be in the state
- specified by "(<opaquelocktoken:a-write-lock-token> [W/"A weak ETag"])
+ specified by "(<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC> [W/"A weak ETag"])
(["strong ETag"])", that is, it either must be locked with a lock
- token of "opaquelocktoken:a-write-lock-token" and have a weak entity tag
+ token of "urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC" and have a weak entity tag
W/"A weak ETag" or it must have a strong entity tag "strong ETag".
</t>
<t>
@@ -3254,13 +3232,14 @@
</t>
<figure>
<artwork><![CDATA[
- If: (Not <opaquelocktoken:write1> <opaquelocktoken:write2>)
+ If: (Not <urn:uuid:E90CB889-97CA-49b9-AC33-111111111111>
+ <urn:uuid:E90CB889-97CA-49b9-AC33-222222222222>)
]]></artwork>
</figure>
<t>
When submitted with a request, this If header requires that all
- operand resources must not be locked with opaquelocktoken:write1 and must
- be locked with opaquelocktoken:write2.
+ operand resources must not be locked with urn:uuid:E90CB889-97CA-49b9-AC33-111111111111 and must
+ be locked with urn:uuid:E90CB889-97CA-49b9-AC33-222222222222.
</t>
<t>
The Not production is particularly useful with the "<DAV:no-lock>"
@@ -3294,9 +3273,10 @@
<figure>
<preamble>Example - Matching lock tokens with collection locks</preamble>
<artwork><![CDATA[
- DELETE /specs/rfc2518.txt HTTP/1.1
- Host: www.example.com
- If: <http://www.example.com/specs/> (<opaquelocktoken:a-write-lock-token>)
+ DELETE /specs/rfc2518.txt HTTP/1.1
+ Host: www.example.com
+ If: <http://www.example.com/specs/>
+ (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>)
]]></artwork>
<postamble>For this example, the lock token must be compared to the
identified resource, which is the 'specs' collection identified by
@@ -3571,9 +3551,7 @@
be returned unless some other error is returned. On the other hand,
if the client did not include a conditional header in the request,
then the server MUST NOT use this error.
-
</t>
-
</section>
<section title="414 Request-URI Too Long">
@@ -3740,8 +3718,7 @@
<t hangText="Namespace: ">DAV:</t>
<t hangText="Purpose: ">The lock token associated with a lock. </t>
<t hangText="Description: ">The href contains a single lock token URI which refers
- to the lock (i.e., the OpaqueLockToken-URI production in
- section 6.4). </t>
+ to the lock.</t>
<t hangText="Extensibility: ">MAY be extended with additional child elements or
attributes which SHOULD be ignored if not recognized. </t>
</list>
@@ -4500,8 +4477,8 @@
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
- <D:href>opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-
- 00a0c91a9d76</D:href>
+ <D:href
+ >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
</D:locktoken>
<D:lockroot>
<D:href>http://www.example.com/container/</D:href>
@@ -5120,27 +5097,34 @@
<section title="Risks Connected with Lock Tokens">
<t>
- This specification requires the use of <xref target="RFC4122">Universal
- Unique Identifiers (UUIDs)</xref> for lock tokens, in order to guarantee
- their uniqueness across space and time. The security considerations
- for UUIDs do not apply because WebDAV does not assume that lock tokens
- are supposed to be hard to guess or require integrity. In addition,
- UUIDs MAY contain a IEEE 802 node ID, usually the host address. Since a
- WebDAV server will
- issue many locks over its lifetime, the use of node IDs might cause the
- WebDAV server to reveal its IEEE 802 address. Several risks are related
- to this:
- </t>
- <t><list style="symbols">
- <t>It is possible to track the movement of hardware from subnet to
- subnet.</t>
-
- <t>It may be possible to identify the manufacturer of the hardware
- running a WebDAV server.
+ This specification recommends the use of Universal
+ Unique Identifiers (UUIDs) for lock tokens, in order to guarantee
+ their uniqueness across space and time. UUIDs, as defined in <xref target="RFC4122" />,
+ contain a "node" field which "consists of the IEEE address,
+ usually the host address. For systems with multiple IEEE 802 nodes,
+ any available node address can be used." Since a WebDAV server will
+ issue many locks over its lifetime, the implication is that it will
+ also be publicly exposing its IEEE 802 address.
+ </t>
+ <t>
+ There are several risks associated with exposure of IEEE 802
+ addresses. Using the IEEE 802 address:
+ </t>
+ <t>
+ <list style="symbols">
+ <t>It is possible to track the movement of hardware from subnet to
+ subnet.</t>
+ <t>It may be possible to identify the manufacturer of the hardware
+ running a WebDAV server.</t>
+ <t>It may be possible to determine the number of each type of computer
+ running WebDAV.</t>
+ </list></t>
+ <t>
+ Section 4.5 of <xref target="RFC4122"/> details an alternate mechanism
+ for generating the "node" field of a UUID without using an IEEE 802
+ address, which alleviates the risks associated with exposure of IEEE
+ 802 addresses by using an alternate source of uniqueness.
</t>
- <t>It may be possible to determine the number of each type of
- computer running WebDAV. </t>
- </list></t>
</section>
<section title="Hosting malicious scripts executed on client machines">
@@ -5191,9 +5175,8 @@
referred to as "DAV:creationdate" for brevity.
</t>
<t>
- This specification also defines a URI scheme for the encoding of
- lock tokens, the opaquelocktoken URI scheme described in section
- 6.4.
+ This specification also defines the "opaquelocktoken" URI scheme for the
+ encoding of lock tokens (see <xref target="opaquelocktoken.uri.scheme"/>).
</t>
<t>
To ensure correct interoperation based on this specification, IANA
@@ -5643,6 +5626,29 @@
</section>
</section>
+<section title="'opaquelocktoken' URI Scheme" anchor="opaquelocktoken.uri.scheme">
+ <t>
+ The 'opaquelocktoken' URI scheme defined below uses the Universal Unique
+ Identifier (UUID) mechanism (<xref target="RFC4122"/>, Section 4) to
+ easily generate lock tokens fulfilling the uniqueness requirements
+ stated in <xref target="lock.tokens"/>.
+ </t>
+<figure><artwork type="abnf">
+ OpaqueLockToken-URI = "opaquelocktoken:" UUID [path]
+ ; UUID: see [RFC4122], Section 3.
+ ; path: see [RFC3986], Section 3.3.
+</artwork></figure>
+ <t>
+ Note that the optional "path" postfix allows to generate many lock tokens
+ from a single URI, by appending an varying string such as a sequence
+ number.
+ </t>
+<figure><preamble>Example:</preamble><artwork type="abnf">
+ opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017
+</artwork></figure>
+</section>
+
+
</back>
</rfc>
Received on Sunday, 23 October 2005 12:23:17 UTC