Document Action: 'Traceable Anonymous Certificate' to Experimental RFC

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Traceable Anonymous Certificate '
   <draft-ietf-pkix-tac-04.txt> as an Experimental RFC

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-tac-04.txt

Technical Summary

   This document describes a model for issuing X.509 certificates in
which the certificates do not contain the "true" name of the user, and
thus provide some level of anonymity. Traceable Anonymous Certificates
(TACs) are issued by a CA that is divided into two parts. One part
verifies and records the identity of the user to whom the certificate is
issued, and the other issues the certificate to the user but does not know
the user's identity.  The certificates issued under the TAC model are
intended primary for use in web access (and not in applications such as
e-mail). The model allows an aggrieved party to request that a TAC CA
divulge the identity of a user who has abused the anonymity offered by the
certificate. (Details of what constitutes abuse by a user are outside the
scope of the document and are established by TAC CA via a Certification
Policy.) To void the anonymity offered by the two-arty issuance procedure,
both parts of the CA collaborate using a protocol defined in the document.



  The current version of the model supports only RSA-based security
protocols between the two parts of the TAC CA, although the user's
certificate may contain a public key for any algorithm.


Working Group Summary


This document has reached rough WG consensus after considerable debate
over the last 18 months. It is targeted at Experimental status. This work
did not attract much interest from most WG members initially. It addresses
a PKI niche, which some WG members didn't think would ever be of
commercial interest. The document authors were Korean and they had
considerable trouble expressing their ideas in writing, and in a suitable
style for an IETF standard. Steve Kent, my co-chair, agreed to become a
co-author and he re-wrote the document and has coordinated subsequent
revisions. Two WG members provided extensive reviews of the I-D, which
resulted in a number of changes to address technical details. The version
that entered WGLC triggered comments from a few WG members. Changes were
made to address several of these comments, but a suggestion to make a
substantial design change was rejected. Two WG members raised concerns
whether the split-signature technology employed here adds enough security
to merit the increased complexity. However, the principle authors work for
KISA, the Korean Information Security Agency that accredits CAs in that
country. Their judgment that this is a reasonable tradeoff is enough to
merit progression as experimental document. The real proof of the
document's value will be decided based on adoption by CAs, something the
KISA authors say will happen (at least in their country).

Document Quality

There are no know implementations at this time, which is not surprising
for a document targeted at Experimental status. However, the KISA staff
who are the principle authors have indicated that they anticipate at least
one commercial TAC CA (in South Korea) will be forthcoming after an RFC is
published. An organization that chooses to implement the model described
here will be a CA service provider, not a product vendor per se.

RFC Editor Note

This document is being forwarded for publication assuming that the
proposed update to the TLP will be completed by the IETF Trust prior
to completion of the RFC publication process.  If that process does not
terminate successfully, please make the following substitution in 
Appendix A, replacing RFC XXXX with the number assigned to this RFC:

OLD

   DEFINITIONS IMPLICIT TAGS ::=

NEW

   DEFINITIONS IMPLICIT TAGS ::=

--
--   Copyright (c) 2009 IETF Trust and the persons identified as
--   authors of the code.  All rights reserved.
--
--   Redistribution and use in source and binary forms, with or without
--   modification, are permitted provided that the following conditions
--   are met:
--
--   - Redistributions of source code must retain the above copyright
--     notice, this list of conditions and the following disclaimer.
--
--   - Redistributions in binary form must reproduce the above copyright
--     notice, this list of conditions and the following disclaimer in
--     the documentation and/or other materials provided with the
--     distribution.
--
--   - Neither the name of Internet Society, IETF or IETF Trust, nor the
--     names of specific contributors, may be used to endorse or promote
--     products derived from this software without specific prior
--     written permission.
--
--
--
--   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
--   'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
--   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
--   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
--   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
--   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
--   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
--   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
--   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
--   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
--   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--
--   This version of the ASN.1 module is part of RFC XXXX;
--   see the RFC itself for full legal notices.
--