[x500standard] SV: Re: subject directory attributes extension

  • From: "Erik Andersen" <era@xxxxxxx>
  • To: <x500standard@xxxxxxxxxxxxx>, "SG17-Q11" <t13sg17q11@xxxxxxxxxxxxx>
  • Date: Mon, 31 Aug 2015 11:06:28 +0200

Hi David,

I still believe it is a hack when the same thing is used for two things (PII
and privilege) without signalling in anyway when it is used for what.

Clause 15 of the seventh edition says:

With the exception of the SOA identifier extension, any of the extensions
that may be included in a public-key certificate shall only be included if
that public-key certificate is one that assigns privilege to its subject
(i.e., the subjectDirectoryAttributes extension shall be present). If any of
these extensions is present in a public-key certificate, that extension
applies to ALL privileges present in the subjectDirectoryAttributes
extension.

If I put a picture of myself and nothing else into the
subjectDirectoryAttributes extension, can that be considered a privilege
specification?
If I add such a picture in the extension, can I then add all the extensions
defined in SECTION 3?

Regards,

Erik

-----Oprindelig meddelelse-----
Fra: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] På vegne af David Chadwick
Sendt: 30 August 2015 19:15
Til: x500standard@xxxxxxxxxxxxx
Emne: [x500standard] Re: subject directory attributes extension

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.


all identity attributes can be used for privilege management so this is not
contradictory.



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.

and why would you want to know that?
Ans. So that you can give them access to resources

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


It is implied



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.


No. If you are a privilege verifier you check that the holder has the
required privilege. If he does have them but you cannot understand them,
then he is refused access. So there is no security issue her. The holder
should ensure that he gets privileges that the verifier can understand.



One could imagine that this extension is used for a lot of other
things than holding privileges.

Please give me an example of PII that cannot be used for granting a
privilege.

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?


? sorry dont understand



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

identity attributes are used to assign privileges e.g.
UK citizens only
Females only
Over 18s only
etc.


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.

I dont think we have any problem at all

regards

David




Regards,



Erik













-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.

-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.

Other related posts: