<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml">
<!ENTITY RFC3852 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3852.xml">
<!ENTITY RFC4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-farrell-pkix-other-certs-00" ipr="full3978">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Abbreviated Title">Other Certificates Extension</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Stephen Farrell" initials="S." surname="Farrell">
      <organization>Trinity College Dublin</organization>

      <address>
        <postal>
          <street>Department of Computer Science</street>
          <street>Trinity College</street>

          <!-- Reorder these if your country does things differently -->

          <city>Dublin</city>

          <region></region>

          <code>2</code>

          <country>Ireand</country>
        </postal>

        <phone>+353-1-896-1761</phone>

        <email>stephen.farrell@cs.tcd.ie</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="December" year="2007" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Security</area>

    <workgroup>IETF</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
	  <t>Some applications using public key certificates can benefit from a way
to link together a set of certificates belonging to the same end entity. This
memo defines a certificate extension that supports such linkage.  </t>
</abstract> </front>

  <middle>
    <section title="Introduction">
		<t><xref target="RFC3280">RFC 3280</xref> defines a profile for the use
of public key certificates for Internet applications. Some applications may
require a way to link together a set of certificates belonging to the same end
entity so this memo defines a new public key
certificate extension that supports such linkage.</t>

	<t>Other than asserting that the set of certificates belong to the same end entity, the
semantics of the actual linkage of certifcates is not defined here, that is a
matter for application developers and the operators of certification
authorities (CAs). In particular we do not define how a CA can validate
that the same end entity is the holder of the various private keys, nor how
any application should make use of this information.
This memo simply defines the relevant syntax.</t>

        <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
      
    </section>

	<section anchor="usecases" title="A Use Case">

			<t>Public key certificates expire, typically about a year after
they are created. Some applications might need to know that the same entity is
the subject of this certificate and a previously used certificate. </t>

<t>For example, if a web server certificate expires, it could be useful for a
web browser to know that the server currently presenting a certificate in a
<xref target="RFC4346">TLS</xref> handshake represents the same web server that
previously presented a certificate. This could be used for example to allow the
browser to automatically fill in form fields for the server in question, even
if the server certificate has been replaced. While the same effect can be
achieved based on the use of the same issuer and subject fields in a certificate
there could be security issues involved in such comparisons, e.g. if the
subject name includes a DNS name and the ownership of that DNS domain has
changed.</t>

<t>The use of the new extension provides a way for the CA to signal
to the application that the same end entity is involved, regardless of name
changes. The new extension could also allow the web site operator to
more easily change CA when renewing its certificate.</t>

	</section>

	<section anchor="extension" title="Other Certificates Extension">

	<t>This section defines the syntax for the other certificates extension.</t>

	<t>The new extension is simply a list of other issuer/serial number pairs
from the linked certificates. The IssuerAndSerialNumber construct is 
taken from <xref target="RFC3852">CMS</xref>.</t>

	<t>When this extension is present the CA is asserting that the 
same end entity is the subject of the relevant certificates. Mechanisms for
how this assertion is validated by the CA or used by consumers of
the certificate are out of scope of this memo.</t>

	<t>This extension MUST NOT be marked critical.</t>

	<t>id-ce-otherCerts OBJECT IDENTIFIER ::== { id-ce XXX }</t>

	<t>OtherCertificates ::= SEQUENCE OF IssuerAndSerialNumber</t>

	</section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The use case motivating this was contributed to the W3C web 
security context (WSC) working group by Tyler Close. 
See http://www.w3.org/2006/WSC/wiki/SafeWebFormEditor for details.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD. Some warnings for CAs and applications needed.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references title="Normative References">
      &RFC2119; 
		&RFC3280;
		&RFC3852;
    </references>


    <references title="Informative References">
		&RFC4346;

    </references>

    <section anchor="asn1" title="ASN.1 Module">
      <t>TBD</t>
    </section>


  </back>

</rfc>
