Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name
draft-ietf-pkix-srvsan-05

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    pkix mailing list <ietf-pkix@imc.org>, 
    pkix chair <pkix-chairs@tools.ietf.org>
Subject: Protocol Action: 'Internet X.509 Public Key 
         Infrastructure Subject Alternative Name for expression of 
         service name' to Proposed Standard 

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Subject Alternative Name for 
   expression of service name '
   <draft-ietf-pkix-srvsan-06.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) 
Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-06.txt

Ballot Text

Technical Summary

  This document specifies how to use the existing X.509 certificate
  Subject Alternative Name extension (with the otherName syntax) to
  carry a reference to a DNS SRV record.  The intent is to link a
  certificate to the service named in the DNS record.

  The document notes that the problem being solved here is not the
  typical server authentication problem.  Instead, an authorization
  problem is being solved.  The question being answered here is whether
  the server that holds the private key is authorized to provide a
  particular service.  This mechanism fills a gap that otherwise would
  exist if the server is provisioned with typical server certificate
  that attests just to the name of the server.  A server holding a
  certificate with this extension has been certified by the issuer of
  the certificate to offer the service expressed in the corresponding
  SRV RR record.  The cited example in the document is that of a
  Kerberos server (e.g., a KDC).

  When DNSSEC is fully deployed, this extension may not be needed, as
  signed DNS records (SRV RR and others) should be able to provide the
  same form of authentic authorization information.  (This extension
  does not represent competition with DNSSEC as the only binding
  provided is to SRV RR records, a subset of overall DNSSEC
  functionality.)

Working Group Summary

  The PKIX WG expressed consensus to advance the draft to Proposed
  Standard.

Protocol Quality

  This document was reviewed by Russ Housley for the IESG.

RFC Editor Note