idnits 2.17.1 draft-chadwick-webdav-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 473. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 485 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2007) is 6153 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 3280' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC 3978' is defined on line 423, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group D.W.Chadwick (University of Kent) 2 INTERNET-DRAFT 3 Expires: Dec 2007 June 2007 4 Target category: Standard Track 6 Internet X.509 Public Key Infrastructure 8 Use of WebDAV for Certificate Publishing and Revocation 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware have 16 been or will be disclosed, and any of which he or she becomes aware 17 will be disclosed, in accordance with Section 6 of BCP 79 [RFC 3978]. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes the use of the WebDAV protocol for publishing 38 and 39 revoking X.509 public key certificates and specifies two new access 40 methods for the Authority Information Access extension to support this. 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in [RFC 2119]. 46 Please send comments on this document to the ietf-pkix@imc.org mailing 47 list or to the author. 49 1. Introduction 51 There are a number of well known problems with using LDAP to store 52 certificates and certificate revocation lists, for example, most 53 corporate firewalls deny access to the LDAP protocol. 55 This document specifies the use of the WebDAV [RFC 2518] protocol 56 extensions to HTTP [RFC 2616] to store and revoke certificates. The 57 protocol supports the transfer of any type of certificate, public key 58 or attribute, as well as any type of revocation list. WebDAV is widely 59 supported, several open source implementations are available including 60 one for Apache, and there is an active community working with it (see 61 http://www.webdav.org/). 63 The protocol specified in this document is based on the 64 Representational State Transfer {REST} principles [REST], in which the 65 web itself is the state transition machine for a certificate. When a 66 certificate does not exist it has no web page. When a certificate 67 exists, it has a unique web page (the certificate URL) at which it MUST 68 be found. When a certificate is revoked, it has a unique web page 69 (revocation URL) at which the revocation list (of length one) SHOULD be 70 found. Obviously both URL pages MUST NOT exist simultaneously, since a 71 certificate cannot be in both states simultaneously. Whilst a 72 certificate might exist i.e. from its time of first issuing until it 73 validity period finishes, one of the pages SHOULD exist, although some 74 implementations MAY choose to treat a revoked certificate the same as a 75 certificate that has never existed. Optionally the revocation page MAY 76 exist after the validity period of a certificate has expired. 78 This document specifies two certificate extensions, the certificate URL 79 and the revocation URL, which may be stored in certificates in order to 80 determine its state using the WebDAV protocol. Section 2 defines these 81 certificate extensions. Section 3 specifies how the WebDAV protocol can 82 be used to retrieve the current state of a certificate, using these two 83 certificate extensions. 85 2. Certificate extensions to support the use of WebDAV 87 This document specifies two new access methods for the 88 AuthorityInformationAccess (AIA) extension defined in RFC 3280 [RFC 89 3280]. The AIA extension is designed to point to services of the 90 issuer of the certificate in question. One of the standard uses of this 91 extension is to point to the OCSP service provided by the issuer. Since 92 the WebDAV service can be used as an alternative to the OCSP service, 93 it seems appropriate to use the AIA extension to point to the WebDAV 94 service. We copy below the ASN.1 of the AIA extension, taken from [RFC 95 3280] for the convenience of the reader: 97 AuthorityInfoAccessSyntax ::= 98 SEQUENCE SIZE (1..MAX) OF AccessDescription 100 AccessDescription ::= SEQUENCE { 101 accessMethod OBJECT IDENTIFIER, 102 accessLocation GeneralName } 104 The two new accessMethods, webdavCert and webdavRev, are defined as 105 follows: 107 webdavCert OBJECT IDENTIFIER ::= { 1.2.826.0.1.3344810.10.2 } 109 webdavRev OBJECT IDENTIFIER ::= { 1.2.826.0.1.3344810.10.3 } 111 When the AIA accessMethod is webdavCert or webdavRev, then the 112 accessLocation must be a URL pointing to the WebDAV server where the 113 certificate or CRL can be found. The URL must point to the exact 114 location of the certificate or CRL in the server so that relying 115 parties can download the certificate or the CRL. 117 webdavRev MUST NOT be present in a certificate if webdavCert is not 118 present. 120 When a certificate has been issued containing the webdavCert extension, 121 and has not been revoked, it MUST be present at the webdavCert location 122 specified in this extension. When a certificate has been issued and 123 revoked, the certificate MUST NOT be available at the webdavCert 124 location. 126 If the webdavRev extension was present in the certificate prior to its 127 revocation, then a CRL of length 1 containing the serial number of the 128 revoked certificate, MUST be present at the webdavRev location 129 immediately the certificate is revoked. 131 3. Using the WebDAV protocol 133 WebDAV specifies extensions to the HTTP/1.1 protocol so that web 134 content can be managed remotely. WebDAV provides users with the ability 135 to create, remove and query information about web pages, including 136 their contents and properties, such as their creation dates, expiry 137 dates, authors etc. In the context of X.509, a web page will be a 138 single X.509 certificate (either public key or attribute) or a CRL 139 containing a single entry, and their properties can be any fields of 140 the certificate or CRL. WebDAV also provides the ability to create 141 sets of related web pages, called collections, and to retrieve 142 hierarchical membership listings of them. In the context of X.509, a 143 certificate subject can represent a collection, and his/her 144 certificates can be the collection membership listing. 145 The set of CRLs issued by an issuer can also be a collection membership 146 listing. 148 3.1 Naming WebDAV resources 150 WebDAV resources are named by URLs, where the hierarchical names are 151 delimited with the "/" character. The name of a collection ends with /. 152 If we model our X.509 certificate store in the same way as an 153 X.500/LDAP directory tree, and name it using the subject DNs to 154 represent collections, this provides us with the ability to retrieve a 155 listing of all the certificates that are owned by a single subject. We 156 use the rules of RFC 4514 [RFC 4514] to convert the DNs into strings, 157 with the exceptions that we replace the comma "," separator between 158 RDNs with the "/" character which is the WebDAV separator, and replace 159 spaces with %20. For example, a collection belonging to the subject 160 whose Distinguished Name is, in RFC 4514 syntax, "c=gb, o=University of 161 Kent, cn=David Chadwick", will be named in a WebDAV repository with the 162 URL: 164 https://server.dns.name/c=gb/o=University%20of%20Kent/cn=David%20Chadwi 165 ck/ 167 A GET request to retrieve all the certificates of David Chadwick would 168 use the URL of the collection, viz: 170 GET /c=GB/o=University%20of%20Kent/cn=David%20Chadwick/ HTTP/1.1 171 Host: server.dns.name 173 A GET request to retrieve a specific certificate of a subject will use 174 the URL specified in the webdavCert access location. 176 We can similarly model a CRL store as a collection of CRLs under its 177 issuer, using the collection name cn=CRLs/, where each CRL contains a 178 single CRL entry and is named with the serial number of the certificate 179 that it revokes. This provides us with the ability to retrieve a 180 listing of all the CRLs that have been issued by a single issuer, and 181 consequently a listing of all certificates that have been revoked. 183 For example, if David Chadwick is an attribute authority who delegates 184 attribute certificates to people, and subsequently revokes some of 185 them, then a GET request to retrieve all the CRLs issued by David 186 Chadwick would use the URL of the collection, viz: 188 GET /c=GB/o=University%20of%20Kent/cn=David%20Chadwick/cn=CRLs/ 189 HTTP/1.1 190 Host: server.dns.name 192 A GET request to retrieve a specific CRL of a certificate will use the 193 URL specified in the webdavRev access location of the certificate. 195 3.2. Using the WebDAV protocol to manage X.509 repositories 197 In order to create a new collection, WebDAV specifies the MKCOL method. 198 The difference between this method and HTTP PUT or POST, is that the 199 latter are allowed to overwrite existing content at the specified URL, 200 whereas MKCOL will fail if there is any existing content at the 201 specified URL. In the context of X.509, this ensures that a certificate 202 issuer cannot unwittingly overwrite existing certificates when creating 203 a new collection for a subject. This is an important concern when there 204 are several certificate issuers for the same subject (either attribute 205 certificate issuers and/or public key certificate issuers). It is 206 important to ensure that no issuer deletes the certificates issued by 207 another issuer. 209 In order to create a certificate or CRL or update an existing 210 certificate in an existing collection, the PUT method is used. It is 211 essential that every certificate and CRL has a unique name within a 212 collection, so that updates can overwrite the same certificate and new 213 certificates and CRLs cannot overwrite existing ones. The onus for 214 creating the unique names is with the issuer. This document defines one 215 algorithm in Section 3.3 for ensuring this uniqueness is maintained. 217 In order to revoke a certificate, the HTTP DELETE command is used by 218 the issuer. This removes the certificate and its properties from the 219 WebDAV server. Simultaneously with this, if the revoked certificate 220 contains the webdavRev access location, the issuer MUST use the HTTP 221 PUT method to create a new CRL containing the serial number of the 222 certificate that has just been revoked. The revocationDate and 223 thisUpdate fields of the CRL MUST be set to the current time, and the 224 nextUpdate field SHOULD be set to sometime after the certificate was 225 due to expire and the date after which the CRL will be removed from the 226 WebDAV store. This ensures that: 227 i) the CRL never needs to be reissued or updated, and 228 ii) relying parties know the minimum duration that the CRL will 229 exist for on the web (should they wish to prove sometime after 230 the certificate has expired that it was revoked prior to 231 expiring). 233 3.3 Searching for particular certificates or CRLs 235 Document properties are specified in XML as name/value pairs. The 236 WebDAV protocol supports the PROPFIND method, in which the properties 237 of a resource can be retrieved, but it not possible to specify which 238 property value you require. Only the property types can be specified. 239 Consequently, if we perform a PROPFIND for the "Role" property, then 240 the web server will return an XML encoded message containing all the 241 ACs that contained a property named Role along with their values. 242 Clearly this is not a viable solution for searching for particular 243 certificates or CRLs. Work on the WebDAV searching and locating 244 capability (DASL) started in 1998, but the work was never completed and 245 the IETF closed the DASL working group some years later. The latest 246 version of the WebDAV Searching and Locating protocol is very recent 247 [Search] and several implementations are said to exist, but we were 248 unable to find a usable one. Consequently we have left the search 249 feature for future work. 251 3.4 Deriving Unique Names for Certificates and CRLs 253 Because PKCs and ACs may be updated or re-issued by their issuers, it 254 is important to have unique names (certificate URLs) for each of them. 255 Furthermore, each certificate MUST have its unique certificate URL and 256 optional revocation URL embedded in it so that relying parties can 257 retrieve the contents of either URL to check the current state of the 258 certificate. 260 Whilst the primary contents of a PKC are fixed (i.e. public key and 261 subject names) the contents of an AC are very varied, and can be any 262 attribute, including authorisation policies. We therefore propose a 263 fixed naming scheme for PKCs and CRLs, but two different naming schemes 264 for ACs, depending upon whether the attribute contains a 265 role/privilege, or a policy. 267 The following algorithm MAY be used to create the unique names for 268 certificates and CRLs: 270 - each AC has the file suffix .ace, each PKC has the file suffix 271 .p7c and 272 each CRL has the file suffix .crl 273 - we use the rules described in RFC 4514 [RFC 4514] to create 274 strings from 275 distinguished names, in particular, using the comma "," to 276 separate the 277 RDNs in a DN, a plus sign "+" to separate the attribute value 278 assertions 279 in an RDN, and an equals sign "=" to separate attribute types and 280 values. 281 - the name of a PKC file is created from the issuer DN and 282 certificate 283 serial number concatenated with a plus sign e.g. "c=gb, 284 o=university of kent, cn=CSCA+SN=123445.p7c" 285 - the name of a role AC file is created from the contents of its 286 attribute values plus the serial number of the certificate, 287 concatenated with a plus sign E.g. a role AC with the embedded 288 attribute type PermisRole with attribute value Project Manager, 289 and certificate serial number of 12345 would create the filename 290 "PermisRole=Project Manager+SN=123456.ace". The serial number 291 provides the uniqueness, whilst the attribute type and value 292 provides user friendliness when the issuer wants to browse a 293 WebDAV repository and retrieve an AC for editing. 294 - the name of a policy AC file is created from the unique name of 295 the policy embedded in the policy attribute value, E.g. a policy 296 with the name 297 "AstroGridUsers" would produce the filename 298 "Policy=AstroGridUsers.ace". Note that it is a policy language 299 issue how the policy name is encoded in the policy attribute 300 value. 301 - the name of a CRL file is created from the serial number of the 302 certificate that it revokes. E.g. a CRL that revokes a 303 certificate with 304 serial number 1234 would produce the filename 305 "serialNumber=1234.crl". 307 4. Security Considerations 309 The frequency and method by which a relying party contacts the issuers 310 WebDAV repository is determined by its risk mitigation strategy and the 311 optional presence of the revocation URL in a certificate. The frequency 312 can vary per application or per user request, and is set by the relying 313 party as appropriate, and not by the issuer, which is putting the 314 responsibility and risk where it belongs, with the relying party. In 315 order to minimise risk, a relying party SHOULD contact the repository 316 when a certificate is first validated, and then periodically during the 317 life of the users session according to its own risk assessment. 319 A security weakness in the WebDAV scheme is that it is vulnerable to 320 denial of service attacks, in that if the WebDAV server is not 321 available, relying parties will not be able to tell if a certificate 322 has been revoked or not. However, other schemes, such as OCSP servers 323 and publishing CRLs, are also equally vulnerable to DOS attacks, and so 324 WebDAV is no different in this respect. CRLs do have one advantage in 325 that an old CRL is better than no CRL, since it does contain some 326 revoked certificates. The equivalent WebDAV procedure is where the 327 relying party periodically downloads collections of all single entry 328 CRLs issued by any issuer. Consequently we do not believe that DOS 329 attacks are any more of a significant security threat to WebDAV than to 330 existing revocation mechanisms. The following procedure is one possible 331 one that relying parties may wish to implement in order to periodically 332 validate a certificate. 334 The relying party issues a HTTP or HTTPS GET command to the certificate 335 URL. The choice between HTTP and HTTPS is discussed later. If the HTTP 336 status code 404 Not Found is returned, the relying party SHOULD assume 337 that the certificate has been revoked, and permanently record this in 338 its internal cache along with the time of the request. If the 339 certificate is returned, a simple bitwise comparison of the initial 340 validated certificate with the subsequently retrieved copy of the 341 certificate is all that is needed by the relying party to ensure that 342 the certificate is still identical to the one originally validated. 343 Certificate signature verification is therefore not needed for 344 revocation status checking. The relying party may optionally cache the 345 certificate and its time of last retrieval. If the certificate has been 346 updated in the repository during the users session, which is likely to 347 be a rare occurrence, then the retrieved certificate will fail the 348 bitwise comparison and will need to be validated again. 350 If the client is unable to contact the certificate URL and receive 351 either a certificate or Not Found response, it SHOULD contact the 352 revocation URL, providing there is one is in the certificate. If the 353 HTTP status code 404 Not Found is returned from the revocation URL, the 354 relying party MAY, according to its risk assessment procedure, assume 355 that the certificate is still valid, and record this in its cache. 356 (Note. In high risk cases, an attacker could be blocking the 357 certificate URL and spoofing the revocation URL). If the CRL is 358 returned instead of Not Found, the signature is validated and the 359 relying party caches the result permanently to ensure the certificate 360 cannot be used again and no further retrieves need be made. 361 Intermediate caching of the CRL is supported and encouraged, so that if 362 a certificate has been revoked and the CRL successfully retrieved, 363 intermediate web servers can cache the CRL to speed up subsequent 364 queries. 366 If the relying party is unable to make a connection to the revocation 367 URL, then the relying party can check its cache to see if a previous 368 request to either URL has succeeded or not. If neither URLs are 369 available, the relying party SHOULD use its local risk assessment 370 procedure to decide what to do when there are network problems. For 371 example, if the transaction is low risk, it may decide to treat the 372 certificate as valid. Alternatively it may decide to try contacting the 373 URLs again, or alternatively to treat the certificate as revoked. 375 Clients may use either HTTPS or HTTP depending upon their and the 376 issuers security requirements. HTTP presents a number of security 377 weaknesses compared to HTTPS. Firstly HTTP provides public access to 378 the certificate, which may violate the privacy of the certificate 379 subject. (There is no equivalent privacy leakage for a CRL.) 380 Furthermore intermediate Web servers may cache copies of frequently 381 accessed web pages to improve performance, but this would negate the 382 proposed revocation service. To counteract this, the issuers Web server 383 MUST use the no-cache cache-response-directive [RFC 2616] in the HTTP 384 response of successful certificate requests and Not Found CRL requests, 385 to prevent intermediate servers from caching these responses. This will 386 ensure that all subsequent queries are directed to the authoritative 387 source of the information and that stale cached responses are not 388 received. Finally HTTP is susceptible to redirection, substitution and 389 man in the middle attacks. Consequently, if the certificates are not 390 meant to be publicly available or stronger security is required, then 391 secure access should be provided using HTTP with TLS [RFC 4346]. This 392 will stop network redirection, substitution attacks and intermediate 393 caching. TLS can also provide confidentiality of the retrieved 394 certificates during transfer, in cases where privacy protection of 395 sensitive certificates is required by the issuer. TLS can also provide 396 strong client side authentication, which will allow access controls to 397 be placed on the WebDAV repository, further protecting the privacy of 398 the subjects certificates. The privacy of CRLs is less important, and 399 it enhances security if more copies of these are publicly available. 401 5. References 403 5.1 Normative References 405 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 406 Requirement Levels", March 1997. 408 [RFC 4346] T. Dierks, E. Rescorla. "The Transport Layer Security (TLS) 409 Protocol Version 1.1". RFC 4346. April 2006. 411 [RFC 2518] Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. 412 "HTTP Extensions for Distributed Authoring WEBDAV". RFC 2518, February 413 1999 415 [RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, 416 P. Leach, T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1." 417 June 1999. 419 [RFC 3280] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet 420 X.509 Public Key Infrastructure Certificate and Certificate Revocation 421 List (CRL) Profile," RFC 3280, April 2002 423 [RFC 3978] Bradner, S., "IETF Rights in Contributions" BCP 78, 424 RFC 3978, March 2005. 426 [RFC 4514] K. Zeilenga. "Lightweight Directory Access Protocol (LDAP): 427 String Representation of Distinguished Names". RFC 4514, June 2006. 429 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - 430 Open Systems Interconnection - The Directory: Authentication Framework, 431 June 1997. 433 5.2 Informative References 435 [REST] see http://en.wikipedia.org/wiki/Representational_State_Transfer 437 [Search] J. Reschke et al. "Web Distributed Authoring and Versioning 438 (WebDAV) SEARCH". , 9 Feb 2007. 440 6. Author's Address 442 David Chadwick 443 Computing Laboratory 444 University of Kent 445 Canterbury 446 CT2 7NF 447 England 449 d.w.chadwick@kent.ac.uk 451 7. Acknowledgements 453 The author would like to thank Sassa Otenko for first proposing this 454 mechanism, Sean Anthony for implementing it and providing a workable 455 proof of concept, and members of the Europki 2007 program committee and 456 Denis Pinkas for providing feedback on earlier versions of this 457 document. 459 9 Intellectual Property Rights 461 Copyright (C) The IETF Trust (2007) 463 This document is subject to the rights, licenses and restrictions 464 contained in BCP 78, and except as set forth therein, the authors 465 retain all their rights. 467 This document and the information contained herein are provided on an 468 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 469 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 470 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 471 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 472 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 473 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.