Alex Deacon INTERNET-DRAFT VeriSign, Inc Expires February 2004 August 2003 AIA Access Method for XKMS Services Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Authority Information Access extension that is used to indicate how to access CA information and services for the issuer of the certificate in which this extension appears. This document defines an access method identifier that indicates the location of XKMS [XKMS] services. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 1. XKMS Access Method In order to convey to relying parties the location of an XKMS service, CA's SHOULD use the following AuthorityInfoAccess accessMethod OID: id-ad-xkms OBJECT IDENTIFIER ::= { id-ad 8 } When using the id-ad-xkms accessMethod, the associated accessLocation value MUST be a URI. This specification does not mandate which XKMS services should be made available by the XKMS service provider. 2. Example ASN.1 The following example shows an AuthorityKeyIdentifier extension that contains the id-ad-xkms accessMethod OID and a URI pointing to an XKMS service running at http://xkms.example.com/ SEQUENCE { OBJECT IDENTIFIER authorityInfoAccess (1 3 6 1 5 5 7 1 1) OCTET STRING, encapsulates { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER 1 3 6 1 5 5 7 48 8) [6] 'http://xkms.example.com/' } } } } 3. Security Considerations 3.1 Trusing the XKMS Responder The signature on the response from the XKMS service may not have any trust relationship to the signature on the certificate that contains the AIA extension. As such, relying parties MUST establish the trustworthiness of the XKMS service before acting upon any of the information contained in the response. 4. IANA Considerations Certificate extensions and attribute certificate extensions are identified by object identifiers (OIDs). The OID for the extension defined in this document was assigned from an arc delegated by the IANA to the PKIX Working Group. No further action by the IANA is necessary for this document or any anticipated updates 5. References 5.1 Normative References [RFC3280] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 5.2 Informative References [XKMS] XML Key Management Specification (XKMS) v2.0. W3C Working Draft. P. Halam-Baker, Editor. http://www.w3.org/TR/xkms2/. April 2003. Author's Addresses Alex Deacon VeriSign, Inc. 487 East Middlefield Road Mountain View, CA USA Email: alex@verisign.com