Skip to main content

Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
RFC 4683

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 Identification Method (SIM)' to Proposed 
         Standard 

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Subject Identification Method 
   (SIM) '
   <draft-ietf-pkix-sim-09.txt> as a Proposed Standard

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

The IESG contact persons are Russ Housley and Tim Polk.

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

Ballot Text

Technical Summary

  To distinguish among multiple individuals with the same name, it may
  be necessary to include in a certificate some personal data that may
  be considered sensitive.  Examples of such personal ID data are U.S.
  social security numbers and similar national ID numbers in other
  countries.  A certificate subject may be willing to disclose this data
  to some relying parties (RPs), but not to everyone who may have access
  to his/her certificate.  Recall that certificates are often passed
  over the Internet without encryption, stored in repositories that may
  allow public access, and so on.  Thus a wide range of possible
  adversaries will have an opportunity to conduct offline attacks that
  seek to reveal sensitive ID data if it is part of a certificate.

  SIM is a technique for managing this problem of selective disclosure
  of such sensitive (though not secret) ID data in the context of X.509
  certificates.  The SIM data is carried as a subject alternative name
  (SAN) using the Privacy-Enhanced Personal Identifier (PEPSI) format,
  also defined in this document.  Because this data is carried in the
  SAN, the subject name must itself be unique without the further
  qualification provided by this other data, consistent with X.509 and
  PKIX certificate requirements.

  The PEPSI value is the result of applying a two-pass hash function to
  the SIM data, employing a user-supplied password and a Registration
  Authority supplied random number.  An attacker trying to confirm a
  guessed SIM value cannot employ a pre-computed dictionary attack, due
  to the use of the random number.  Nonetheless, selection of a poor
  password by a user does allow an attacker to mount a focused, offline
  guessing attack on a PEPSI value.

  Three scenarios for use of SIM are described:
  
    -  If a relying party knows the user's SIM value, and uses
       it to uniquely identify the user, the RP can confirm the
       user's identify through processing of the certificate and
       user disclosure of the password to the RP via a secure
       channel.

    -  If the RP does not know the SIM value, it can be disclosed
       to the RP via secure transfer of the password, and processing
       of the certificate by the RP, e.g., so that the RP can
       acquire the SIM value for future use.

    -  Finally, knowledge of the password by the user can be
       employed as a secondary authentication mechanism, in
       addition to the user's knowledge of his private key,
       without exposing the SIM data to an RP.
 
Working Group Summary
 
  The PKIX working group expressed consensus to advance the document to
  Proposed Standard.
 
Protocol Quality
 
  This document has been reviewed by PKIX working group and by the PKIX
  working group chairs.

  This document was reviewed by Russ Housley for the IESG.

Note to RFC Editor

  Please expand the first use of "RA".

  OLD:

       R          The random number value generated by an RA.

  NEW:

       R          The random number value generated by a Registration
                  Authority (RA).

RFC Editor Note