Re: [pkix] subject directory attributes extension

"Miller, Timothy J." <> Mon, 31 August 2015 12:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 829C21B392B for <>; Mon, 31 Aug 2015 05:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F3kur_fetZtw for <>; Mon, 31 Aug 2015 05:20:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86C9D1B38CD for <>; Mon, 31 Aug 2015 05:20:25 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 31 Aug 2015 12:20:23 +0000
Received: from ([]) by ([]) with mapi id 15.01.0256.013; Mon, 31 Aug 2015 12:20:23 +0000
From: "Miller, Timothy J." <>
To: Erik Andersen <>, Directory list <>, SG17-Q11 <>, PKIX <>
Thread-Topic: [pkix] subject directory attributes extension
Thread-Index: AdDjJ/P1+gOSVDO4Q3+nQ21EupucDgAvXUpA
Date: Mon, 31 Aug 2015 12:20:22 +0000
Message-ID: <>
References: <000001d0e32c$620a9030$261fb090$>
In-Reply-To: <000001d0e32c$620a9030$261fb090$>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BY2PR09MB109; 5:N50j7xX2i2m0nsy0LEFj812qfWzDa4CYc+7O5BjdwZs9dhf5SzHTp72BMp2uD6cc0cry+qOB2EU2nH/BSwJfFtnEwWJUitOeVF2LRZfRE6h9dzvlXi6yh/nwbF/bQ6xyaEQQz3DQqfEPowAPshSLnA==; 24:dSMoPFVa7RHrWDjcAGCqu5EyDrUhC7ep9fKX4nrC7EnoXOYwfcCm+1XL8png48TEt12wZvntuNoV4nZFC87/El1D9mqLU4WRJmtLqrtELWk=; 20:E6/sRhL2jwUHQwfDfKuDD26zH4DptPOF61JaMIO1PVvJDyMT3Astdgxt4e1Raq64Bv6aCQv1rKu2xabTl98mSQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB109;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BY2PR09MB109; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB109;
x-forefront-prvs: 0685122203
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(107886002)(40100003)(68736005)(105586002)(2950100001)(10400500002)(86362001)(5003600100002)(77096005)(62966003)(97736004)(5001770100001)(76576001)(4001540100001)(5007970100001)(189998001)(106356001)(74316001)(5001960100002)(81156007)(77156002)(5002640100001)(102836002)(5004730100002)(5001830100001)(50986999)(54356999)(5001860100001)(2656002)(2900100001)(33656002)(101416001)(46102003)(66066001)(87936001)(92566002)(122556002)(64706001)(76176999)(99286002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB109;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2015 12:20:22.5503 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB109
Archived-At: <>
Subject: Re: [pkix] subject directory attributes extension
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Aug 2015 12:20:27 -0000

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

Subject directory attributes is just a place to ram in random things that aren't names, policies, key usages, or otherwise fit under other extensions.  I.e., it's for things that in an X.500 directory would be represented as class attributes.  That's all.  You could put a picture of your dog in there if you like [1].  E.g., DoD PKI uses it to carry country of citizenship though I can't for the life of my name a system that processes it.

You can use it to carry attributes that you might use for access control, but that's entirely up to you and it's up to *your code* to enforce.  It's a transport convenience, not something really intended for cert validation code to muck with.  You can mark it critical, but that means you'll have a hell of a time with compatibility.  

> 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.

Neither.  From an RFC perspective the current extension serves both purposes without problems.

-- T
[1] Use of this extension for as a holding pen for random data in a signature collision attack is left as an exercise for Arjen Lenstra, Marc Stevens, and Benne de Weger.  :)