Hi Erik
subject directory attributes are personal identifying information (PII).
All PII can be used for authorisation, even the address attribute e.g.
all people who live on street X are allowed to park their car there free
of charge. So there is no contradiction in the standard.
More comments below
On 30/08/2015 15:01, Erik Andersen wrote:
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.
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
