[pkix] subject directory attributes extension

"Erik Andersen" <era@x500.eu> Sun, 30 August 2015 14:01 UTC

Return-Path: <era@x500.eu>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 942E81B3395 for <pkix@ietfa.amsl.com>; Sun, 30 Aug 2015 07:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.455
X-Spam-Level: ****
X-Spam-Status: No, score=4.455 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MlyXIfuU3W8C for <pkix@ietfa.amsl.com>; Sun, 30 Aug 2015 07:01:40 -0700 (PDT)
Received: from mail02.dandomain.dk (mail02.dandomain.dk []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875F91B337A for <pkix@ietf.org>; Sun, 30 Aug 2015 07:01:39 -0700 (PDT)
Received: from Morten ([]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id 2201508301601352195; Sun, 30 Aug 2015 16:01:35 +0200
From: "Erik Andersen" <era@x500.eu>
To: "Directory list" <x500standard@freelists.org>, "SG17-Q11" <t13sg17q11@lists.itu.int>, "PKIX" <pkix@ietf.org>
Date: Sun, 30 Aug 2015 16:01:35 +0200
Message-ID: <000001d0e32c$620a9030$261fb090$@x500.eu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D0E33D.259471A0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdDjJ/P1+gOSVDO4Q3+nQ21EupucDg==
Content-Language: en-gb
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/YAuy-M4-MFijfX92Ps-zItAr-GY>
Subject: [pkix] subject directory attributes extension
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Aug 2015 14:01:43 -0000

There seems to be some confusion about the use of the subject directory
attributes extension.


When one read SECTION 3 of X.509 - Attribute Certificate Framework, there is
a lot of talk about this extension for carrying privilege in public-key
certificates (which make the section title a little misleading).  Section 3
seems to assume that the subject directory attributes extension is only used
for carrying privilege.


This is not clear in SECTION 2 of X.509 - Public-Key Certificate Framework
and it not clear in RFC 5280.


In 8.3.1, item b) of the seventh edition of X.509 says:


b)    A relying party may need securely to know certain identifying
information about a subject in order to have confidence that the subject is
indeed the person or thing intended. For example, information such as postal
address, position in a corporation, or a picture image may be required. Such
information may be conveniently represented as directory attributes, but
these attributes are not necessarily part of the distinguished name. A
certificate field is therefore needed for conveying additional directory
attributes beyond those in the distinguished name.


This paragraph does not mention privilege at all.


The definition of the extension is:     Subject directory attributes extension

This field conveys any desired Directory attributes associated with the
subject of the certificate. This field is defined as follows:


subjectDirectoryAttributes EXTENSION ::= {

  SYNTAX         AttributesSyntax

  IDENTIFIED BY  id-ce-subjectDirectoryAttributes }


AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF


This extension may, at the option of the certificate issuer, be either
critical or non-critical. A certificate-using system processing this
extension is not required to understand all attribute types included in the
extension. If the extension is flagged critical, at least one of the
attribute types contained in the extension shall be understood for the
certificate to be accepted. If the extension is flagged critical and none of
the contained attribute types is understood, the certificate shall be


If this extension is present in a public-key certificate, some of the
extensions defined in clause 15 may also be present.


Only the last paragraph gives a very small hint that the extension could (or
shall?) be used for carrying privilege. If the attributes carry privilege,
it seems quite important that the relying party (privilege verifier)
understand all the attributes.


One could imagine that this extension is used for a lot of other things than
holding privileges. Can I include the extensions defined in clause 15 if I
just put into this extension a single, arbitrary attribute that has nothing
to do we privilege?


SECTION 3 is clear on the issue, but a lot of people may not read SECTION 3.


RFC 5280 has no notion of privilege: Subject Directory Attributes


The subject directory attributes extension is used to convey identification
attributes (e.g., nationality) of the subject. The

extension is defined as a sequence of one or more attributes. Conforming CAs
MUST mark this extension as non-critical.


id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }


SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute


What is the solution: Two extensions, one for privilege attribute types and
one for non-privilege attribute types? Seems like we have backward
compatibility problems whatever we do.