idnits 2.17.1 draft-ietf-kitten-gssapi-naming-exts-02.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.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 732. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 26, 2006) is 6507 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) == Outdated reference: A later version (-05) exists of draft-ietf-kitten-gss-naming-01 ** Downref: Normative reference to an Informational draft: draft-ietf-kitten-gss-naming (ref. 'I-D.GSS-NAMING') ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETWORK WORKING GROUP N. Williams 2 Internet-Draft Sun 3 Expires: December 28, 2006 June 26, 2006 5 GSS-API Naming Extensions 6 draft-ietf-kitten-gssapi-naming-exts-02.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 28, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 The Generic Security Services API (GSS-API) provides a simple naming 40 architecture that supports name-based authorization. This document 41 introduces new APIs that extend the GSS-API naming and authorization 42 model. 44 Table of Contents 46 1. Conventions used in this document . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Name Attribute Sources and Criticality . . . . . . . . . . 3 49 4. Name Attributes/Values as ACL Subjects . . . . . . . . . . 4 50 5. Mapping Mechanism Facilities to Name Attributes . . . . . 4 51 5.1. Kerberos V and SPKM Authorization-Data . . . . . . . . . . 4 52 5.2. Kerberos V Cross-Realm Transit Paths . . . . . . . . . . . 5 53 5.3. PKIX Certificate Extensions . . . . . . . . . . . . . . . 5 54 5.3.1. PKIX EKUs . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5.3.2. PKIX Certificate Alternative Names . . . . . . . . . . . . 6 56 5.3.3. Other PKIX Certificate Extensions and Attributes . . . . . 6 57 5.4. PKIX Certificate CA Paths and Trust Anchors . . . . . . . 6 58 6. GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . 6 59 6.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . 7 61 7.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8 62 8. GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 8 63 8.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 64 9. GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 10 65 9.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 66 10. GSS_Delete_name_attribute() . . . . . . . . . . . . . . . 11 67 10.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11 68 11. GSS_Export_name_composite() . . . . . . . . . . . . . . . 12 69 11.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12 70 12. GSS_Map_name_to_any() . . . . . . . . . . . . . . . . . . 13 71 12.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13 72 13. GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 14 73 13.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14 74 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 75 15. Security Considerations . . . . . . . . . . . . . . . . . 15 76 16. Normative References . . . . . . . . . . . . . . . . . . . 15 77 Author's Address . . . . . . . . . . . . . . . . . . . . . 17 78 Intellectual Property and Copyright Statements . . . . . . 18 80 1. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Introduction 88 As described in [I-D.GSS-NAMING] the GSS-API's naming architecture 89 suffers from certain limitations. This document proposes concrete 90 GSS-API extensions as outlined in [I-D.GSS-NAMING]. 92 A number of extensions to the GSS-API [RFC2743] and its C Bindings 93 [RFC2744] are described herein with the goal of making authorization 94 information, and other information that can be modelled as "name 95 attributes" available as such to applications. For example, Kerberos 96 V authorization data elements, both, in their raw forms as well as 97 mapped to more useful value types, can be made available to GSS-API 98 applications through these interfaces. 100 The model is that GSS names have attributes. The attributes of a 101 name may be authenticated by the credential whence the name comes, or 102 may have been set locally on a GSS name for the purpose of 103 "asserting" the attribute during credential acquisition or security 104 context exchange. Name attributes' values are network 105 representations thereof (e.g., the actual value octets of the 106 contents of an X.509 certificate extension, for example) and are 107 intended to be useful for constructing portable access control 108 facilities. Applications may often require language- or platform- 109 specific data types, rather than network representations of name 110 attributes, so a function is provided to obtain objects of such types 111 associated with names and name attributes. 113 3. Name Attribute Sources and Criticality 115 A given GSS name object's name attributes may be authenticated or 116 asserted by an associated credential, or it may be mapped or derived 117 from another attribute of the same name. 119 That a given name's given attribute is 'mapped' means that it was 120 obtained through some mapping mechanism applied to another attribute 121 of the name that was not, itself, mapped. For example, such 122 attributes as platform-specific internal identifiers may sometimes be 123 mapped from other name attributes. 125 Name attributes may be "critical," meaning that applications that do 126 not understand them MUST reject security contexts where the peer has 127 such unknown, critical attributes. 129 4. Name Attributes/Values as ACL Subjects 131 Some name attributes (e.g., numeric user or group identifiers) may be 132 useful as subjects of access control list (ACL) entries, some may not 133 (e.g., time of day login restrictions). The 134 GSS_Inquire_name_attribute() function indicates this. 136 To facilitate the development of portable applications that make use 137 of name attributes to construct and evaluate portable ACLs the GSS- 138 API makes name attribute values available in canonical network 139 encodings thereof. 141 To facilitate the development of platform- or language-specific 142 applications that need access to native types of representations of 143 name attributes an optional facility is provided, 144 GSS_Map_name_to_any(). 146 5. Mapping Mechanism Facilities to Name Attributes 148 [NOTE: This entire section should probably be split into one or more 149 separate Internet-Drafts. It is here in the -00 of this I-D to help 150 readers understand how to mechanism-specific name attributes would be 151 accessed through these GSS-API extensions.] 153 Kerberos V [I-D.ietf-krb-wg-kerberos-clarifications] and the Simple 154 Public-Key GSS-API Mechanism, SPKM [RFC2025], both support the 155 concept and encoding of containers of "authorization-data" as 156 described in [I-D.ietf-krb-wg-kerberos-clarifications]. 158 PKIX [RFC3280] supports a number of authorization-data-like features, 159 like Extended Key Usage values (EKUs) and certificate extensions. 161 The authorization data can be accessed through the GSS-API name 162 attributes facility defined herein. 164 5.1. Kerberos V and SPKM Authorization-Data 166 Authorization-data non-container elements asserted in Kerberos V AP- 167 REQ Authenticators MUST be mapped into *asserted* GSS-API name 168 attributes; if not contained in AD-IF-RELEVANT then they MUST be 169 mapped into *critical* GSS-API name attributes. AD-AND-OR 170 authorization-data elements MUST be mapped into a single *critical* 171 attribute, (TBD). 173 Authorization-data included in Kerberos V Tickets that is not 174 contained in AD-KDCIssued (with valid signature) MUST be mapped into 175 *asserted* GSS-API name attributes. Conversely, authorization-data 176 elements in Kerberos V Tickets contained by AD-KDCIssued MUST be 177 mapped into *authenticated* GSS-API name attributes 179 As with authorization-data elements in Authenticators, authorization- 180 data elements in Tickets not contained in AD-IF-RELEVANT are to be 181 mapped to *critical* name attributes, and similarly with AD-AND-OR 182 (see above). 184 The OIDs for authorization-data elements are to be the authorization- 185 data element's 'ad-type' integer ID, relative to the base OID 186 [NOTE: what about negative ad-type's? OID arcs are positive 187 integers... ad-type is an Int32, so clearly something can be done.] 189 5.2. Kerberos V Cross-Realm Transit Paths 191 [Add text on how to represent/encode/interpret krb5 realm transit 192 paths as name attribute values. And text on PKINIT too... Basically 193 Ticket's 'transited' field should be exposed as an authenticated name 194 attribute, with some uncompressed encoding, possibly encompassing 195 certificate validation paths of client certs used for PKINIT, with 196 criticality determined by the presence of the transit-policy-checked 197 flag.] 199 5.3. PKIX Certificate Extensions 201 [NOTE: In the Kerberos V authorization-data case we can tell when AD 202 elements are "authenticated" and when the are asserted, but what 203 about x.509 certificate extensions? Clearly KU, EKUs and 204 subjectAltNames are authenticated in that no CA should sign a cert 205 with, say, arbitrary subjectAltNames not understood by the CA, but, 206 does that also apply to all other x.509 certificate extensions? The 207 answer may depend on actual CA operator practices... At worst a new 208 extension may be needed, like Kerberos V's AD-KDCIssued AD container 209 element; at best this text can just say "all cert extensions MUST be 210 mapped to authenticated..." below.] 212 PKI certificate extensions MAY/SHOULD/MUST (see comment above) be 213 mapped to *authenticated* GSS-API name attributes with the _same_ 214 OIDs, and if they be marked critical in the certificate then they 215 MUST be mapped as *critical* GSS-API name attributes. 216 SubjectAltNames and EKUs, specifically, MUST be mapped to 217 *authenticated* GSS-API name attributes; see below. Certificate 218 extensions MUST be mapped to GSS-API name attributes whose OIDs are 219 the same as the extensions' 221 5.3.1. PKIX EKUs 223 Extended Key Usage extensions, specifically, MUST be mapped as 224 described above, except that GSS-API name attributes for EKUs MUST 225 have NULL values (i.e., zero-length OCTET STRINGs). 227 PKI certificate key usages (KUs, but not EKUs), MUST NOT be mapped to 228 GSS-API name attributes. 230 5.3.2. PKIX Certificate Alternative Names 232 PKI certificate subjectAltNames MUST be mapped as *authenticated*, 233 *non-critical* GSS-API name attributes. 235 PKI certificate extensions MUST be mapped to *authenticated* GSS-API 236 name attributes with the _same_ OIDs, and if they be marked critical 237 in the certificate then they MUST be mapped as *critical* GSS-API 238 name attributes. 240 Extended Key Usage extensions, specifically, MUST be mapped as 241 described above, except that GSS-API name attributes for EKUs MUST 242 have NULL values (i.e., zero-length OCTET STRINGs). 244 5.3.3. Other PKIX Certificate Extensions and Attributes 246 [Add text...] 248 5.4. PKIX Certificate CA Paths and Trust Anchors 250 [Add text on how to represent/encode/interpret PKI certificate 251 validation CA paths as name attribute values, much as with Kerberos V 252 transited paths.] 254 6. GSS_Display_name_ext() 256 Inputs: 258 o name NAME, 260 o display_as_name_type OBJECT IDENTIFIER 262 Outputs: 264 o major_status INTEGER, 265 o minor_status INTEGER, 267 o display_name STRING 269 Return major_status codes: 271 o GSS_S_COMPLETE indicates no error. 273 o GSS_S_UNAVAILABLE indicates that the given name could not be 274 displayed using the syntax of the given name type. 276 o GSS_S_FAILURE indicates a general error. 278 This function displays a given name using the given name syntax, if 279 possible. This operation may require mapping MNs to generic name 280 syntaxes or generic name syntaxes to mechanism-specific name 281 syntaxes; such mappings may not always be feasible and MAY be inexact 282 or lossy, therefore this function may fail. 284 6.1. C-Bindings 286 OM_uint32 GSS_Display_name_ext( 287 OM_uint32 *minor_status, 288 gss_name_t name, 289 gss_OID display_as_name_type, 290 gss_buffer_t display_name 291 ); 293 7. GSS_Inquire_name() 295 Inputs: 297 o name NAME 299 Outputs: 301 o major_status INTEGER, 303 o minor_status INTEGER, 305 o name_is_MN BOOLEAN, 307 o mn_mech OBJECT IDENTIFIER, 309 o asserted_attrs SET OF OBJECT IDENTIFIER, 310 o authenticated_attrs SET OF OBJECT IDENTIFIER, 312 o critical_attrs SET OF OBJECT IDENTIFIER, 314 o all_attrs SET OF OBJECT IDENTIFIER, 316 o [NOTE: Perhaps this function should also output an indicator as to 317 the provenance of the name, of which, in the GSS-API, there are 318 three: imported, inquired from a credential, and a peer's name 319 inquired from a security context.] 321 Return major_status codes: 323 o GSS_S_COMPLETE indicates no error. 325 o GSS_S_FAILURE indicates a general error. 327 This function outputs the sets of attributes of a name, that are 328 authenticated, asserted or critical. It also indicates if a given 329 NAME is an MN or not and, if it is, what mechanism it's an MN of. 331 7.1. C-Bindings 333 OM_uint32 gss_inquire_name( 334 OM_uint32 *minor_status, 335 gss_name_t name, 336 int name_is_MN, 337 gss_OID *MN_mech, 338 gss_OID_set *authenticated, 339 gss_OID_set *asserted, 340 gss_OID_set *critical, 341 gss_OID_set *all_attrs 342 ); 344 8. GSS_Get_name_attribute() 346 Inputs: 348 o name NAME, 350 o attr OBJECT IDENTIFIER 352 Outputs: 354 o major_status INTEGER, 355 o minor_status INTEGER, 357 o authenticated BOOLEAN, -- FALSE if asserted but not authenticated 358 by a trusted entity 360 o negative BOOLEAN, 362 o mapped BOOLEAN, 364 o critical BOOLEAN, 366 o values SET OF OCTET STRING, 368 o display_values SET OF STRING 370 Return major_status codes: 372 o GSS_S_COMPLETE indicates no error. 374 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 375 known or set. 377 o GSS_S_FAILURE indicates a general error. 379 This function outputs the value(s) associated with a given GSS name 380 object for a given name attribute. 382 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 383 for order preservation; this has been discussed on the KITTEN WG 384 mailing list and the consensus seems to be that, indeed, that was 385 always the intention. 387 8.1. C-Bindings 389 The C-bindings of GSS_Get_name_attribute() requires one function call 390 per-attribute value, for multi-valued name attributes. This is done 391 by using a single gss_buffer_t for each value and an input/output 392 integer parameter to distinguish initial and subsequent calls and to 393 indicate when all values have been obtained. 395 The 'more' input/output parameter should point to an integer variable 396 whose value, on first call to gss_name_attribute_get() MUST be -1, 397 and whose value upon function call return will be non-zero to 398 indicate that additional values remain, or zero to indicate that no 399 values remain. The caller should not modify this parameter after the 400 initial call. 402 OM_uint32 gss_get_name_attribute( 403 OM_uint32 *minor_status, 404 gss_name_t name, 405 gss_OID attr, 406 int *authenticated, 407 int *negative, 408 int *mapped, 409 int *critical, 410 gss_buffer_t value, 411 gss_buffer_t display_value, 412 int *more 413 ); 415 9. GSS_Set_name_attribute() 417 Inputs: 419 o name NAME, 421 o critical BOOLEAN, 423 o negative BOOLEAN, 425 o attr OBJECT IDENTIFIER, 427 o values SET OF OCTET STRING 429 Outputs: 431 o major_status INTEGER, 433 o minor_status INTEGER 435 Return major_status codes: 437 o GSS_S_COMPLETE indicates no error. 439 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 440 known or could not be set. 442 o GSS_S_FAILURE indicates a general error. 444 NOTE: This function relies on the GSS-API notion of "SET OF" allowing 445 for order preservation; this has been discussed on the KITTEN WG 446 mailing list and the consensus seems to be that, indeed, that was 447 always the intention. 449 9.1. C-Bindings 451 The C-bindings of GSS_Set_name_attribute() requires one function call 452 per-attribute value, for multi-valued name attributes -- each call 453 adds one value. To replace an attribute's every value delete the 454 attribute's values first with GSS_Delete_name_attribute(). 456 OM_uint32 gss_set_name_attribute( 457 OM_uint32 *minor_status, 458 gss_name_t name, 459 int critical, 460 int negative, 461 gss_OID attr, 462 gss_buffer_t value 463 ); 465 10. GSS_Delete_name_attribute() 467 Inputs: 469 o name NAME, 471 o attr OBJECT IDENTIFIER, 473 Outputs: 475 o major_status INTEGER, 477 o minor_status INTEGER 479 Return major_status codes: 481 o GSS_S_COMPLETE indicates no error. 483 o GSS_S_UNAVAILABLE indicates that the given attribute OID is not 484 known. 486 o GSS_S_FAILURE indicates a general error. 488 Deletion of negative authenticated attributes from NAME objects MUST 489 NOT be allowed. [Do we need a new major status code for "permission 490 denied"?] 492 10.1. C-Bindings 493 OM_uint32 gss_delete_name_attribute( 494 OM_uint32 *minor_status, 495 gss_name_t name, 496 gss_OID attr 497 ); 499 11. GSS_Export_name_composite() 501 Inputs: 503 o name NAME 505 Outputs: 507 o major_status INTEGER, 509 o minor_status INTEGER, 511 o exp_composite_name OCTET STRING 513 Return major_status codes: 515 o GSS_S_COMPLETE indicates no error. 517 o GSS_S_FAILURE indicates a general error. 519 This function outputs a token which can be imported with 520 GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type 521 and which preserves any name attribute information associated with 522 the input name (which GSS_Export_name() may well not). The token 523 format is no specified here as this facility is intended for inter- 524 process communication only; however, all such tokens MUST start with 525 a two-octet token ID, hex 04 02, in network byte order. 527 The OID for GSS_C_NT_COMPOSITE_EXPORT is . 529 11.1. C-Bindings 531 OM_uint32 gss_export_name_composite( 532 OM_uint32 *minor_status, 533 gss_name_t name, 534 gss_buffer_t exp_composite_name 535 ); 537 12. GSS_Map_name_to_any() 539 Inputs: 541 o name NAME, 543 o authenticated BOOLEAN, -- if TRUE no data will be output unless it 544 is authenticated 546 o type_id OBJECT IDENTIFIER 548 Outputs: 550 o major_status INTEGER, 552 o minor_status INTEGER, 554 o output ANY DEFINED BY type_id 556 Return major_status codes: 558 o GSS_S_COMPLETE indicates no error. 560 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 561 not be done. The minor status code may provide additional 562 information. 564 o GSS_S_FAILURE indicates a general error. The minor status code 565 may provide additional information. 567 Whereas name attribute's values are encoded in some network 568 representation applications often require native, language- and/or 569 platform-specific data types. This function provides access to such 570 types. 572 12.1. C-Bindings 574 typedef struct gss_any *gss_any_t; 575 OM_uint32 gss_map_name_to_any( 576 OM_uint32 *minor_status, 577 gss_name_t name, 578 int authenticated, 579 gss_OID type_id, 580 gss_any_t output 581 ); 582 Note the new C bindings type, gss_any_t. We define it as a pointer 583 to an incompletely declared struct. 585 13. GSS_Release_any_name_mapping() 587 Inputs: 589 o name NAME, 591 o type_id OBJECT IDENTIFIER, 593 o input ANY DEFINED BY type_id 595 Outputs: 597 o major_status INTEGER, 599 o minor_status INTEGER, 601 Return major_status codes: 603 o GSS_S_COMPLETE indicates no error. 605 o GSS_S_UNAVAILABLE indicates that the mapping or conversion could 606 not be done. The minor status code may provide additional 607 information. 609 o GSS_S_FAILURE indicates a general error. The minor status code 610 may provide additional information. 612 This function releases, if possible, the objects of language- and/or 613 platform-specific types output by GSS_Map_name_to_any(). If such 614 types have native release functions applications MAY use either those 615 or this function to release the given object. 617 13.1. C-Bindings 619 typedef struct gss_any *gss_any_t; 620 OM_uint32 gss_release_any_name_mapping( 621 OM_uint32 *minor_status, 622 gss_name_t name, 623 gss_OID type_id, 624 gss_any_t *input 625 ); 627 14. IANA Considerations 629 This document creates a namespace of GSS-API name attributes. 630 Attributes are named by OID, so no single authority might be needed 631 for allocation, however, in the interest of providing the community 632 with an authority for name attribute OID allocation and a way to find 633 the existing set of name attributes, the IANA should establish both, 634 a single OID off of which name attributes could be allocated, and a 635 registry of known GSS name attributes. 637 GSS-API name attribute registry entries should contain all the 638 information that GSS_Inquire_name_attribute() may return about the 639 given name attributes and their OIDs: 641 o a name attribute OID (this is a unique key) 643 o a name attribute symbolic name, starting with "GSS_C_NA_" (this is 644 a unique key) 646 o a brief description, in English 648 o whether the attribute is useful as the subject of access control 649 list entries 651 o whether the attribute is useful as an indicator of trust 653 o an optional normative reference to documentation for the given 654 name attribute 656 The allocation and registration policy should be first come, first 657 served. Registry entries' OIDs need not be based on the base OID 658 given above. 660 15. Security Considerations 662 664 [In particular, the status of a name attribute as "authenticated" vs. 665 "asserted" requires close review, particularly with respect to PKIX 666 certificate extensions.] 668 [Also, we need to work out the security considerations of (and 669 possibly remove) negative attributes.] 671 16. Normative References 673 [I-D.GSS-NAMING] 674 Hartman, S., "Desired Enhancements to GSSAPI Naming", 675 draft-ietf-kitten-gss-naming-01.txt (work in progress), 676 February 2005. 678 [I-D.ietf-krb-wg-kerberos-clarifications] 679 Neuman, C., "The Kerberos Network Authentication Service 680 (V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work 681 in progress), September 2004. 683 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 684 (SPKM)", RFC 2025, October 1996. 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997. 689 [RFC2743] Linn, J., "Generic Security Service Application Program 690 Interface Version 2, Update 1", RFC 2743, January 2000. 692 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 693 C-bindings", RFC 2744, January 2000. 695 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 696 X.509 Public Key Infrastructure Certificate and 697 Certificate Revocation List (CRL) Profile", RFC 3280, 698 April 2002. 700 Author's Address 702 Nicolas Williams 703 Sun Microsystems 704 5300 Riata Trace Ct 705 Austin, TX 78727 706 US 708 Email: Nicolas.Williams@sun.com 710 Intellectual Property Statement 712 The IETF takes no position regarding the validity or scope of any 713 Intellectual Property Rights or other rights that might be claimed to 714 pertain to the implementation or use of the technology described in 715 this document or the extent to which any license under such rights 716 might or might not be available; nor does it represent that it has 717 made any independent effort to identify any such rights. Information 718 on the procedures with respect to rights in RFC documents can be 719 found in BCP 78 and BCP 79. 721 Copies of IPR disclosures made to the IETF Secretariat and any 722 assurances of licenses to be made available, or the result of an 723 attempt made to obtain a general license or permission for the use of 724 such proprietary rights by implementers or users of this 725 specification can be obtained from the IETF on-line IPR repository at 726 http://www.ietf.org/ipr. 728 The IETF invites any interested party to bring to its attention any 729 copyrights, patents or patent applications, or other proprietary 730 rights that may cover technology that may be required to implement 731 this standard. Please address the information to the IETF at 732 ietf-ipr@ietf.org. 734 Disclaimer of Validity 736 This document and the information contained herein are provided on an 737 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 738 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 739 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 740 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 741 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 742 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 744 Copyright Statement 746 Copyright (C) The Internet Society (2006). This document is subject 747 to the rights, licenses and restrictions contained in BCP 78, and 748 except as set forth therein, the authors retain all their rights. 750 Acknowledgment 752 Funding for the RFC Editor function is currently provided by the 753 Internet Society.