Erik,
Can you remove schokhani@xxxxxxxxxxxx<mailto:schokhani@xxxxxxxxxxxx> from
Directory List and make sure
Santosh.chokhani@xxxxxxxxx<mailto:Santosh.chokhani@xxxxxxxxx> is on the list.
Thanks for your assistance
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of Erik Andersen
Sent: Sunday, August 30, 2015 10:02 AM
To: Directory list <x500standard@xxxxxxxxxxxxx>; SG17-Q11
<t13sg17q11@xxxxxxxxxxxxx>; PKIX <pkix@xxxxxxxx>
Subject: [x500standard] subject directory attributes extension
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:
8.3.2.3 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 Attribute{{SupportedAttributes}}
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 rejected.
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:
4.2.1.8. 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.
Regards,
Erik
