X.509 is an ITU recommendation for defining digital certificates (www.ietf.org/html.charters/pkix-charter.html). Originally, X.509 certificates were meant to provide nonforgeable evidence of a person's identity. Consequently, X.509 certificates contain information about certificate owners, such as their name and public key, signed by Certificate Authority (CA). However, it quickly became evident that in many situations, information about a person's privileges or attributes can be much more important than that of their identity. Thus, for example, on an e-commerce B2B site, entrance may be restricted to those who are members of a certain commercial organization, or who have paid a certain membership to a professional association. In such contexts, the authorization process is not based on identity, but rather on attributes.
This led to the addition of a new field in the third edition of X.509 (1997)extensions that could hold any data. Many systems have taken advantage of this to introduce additional information (such as privileges) in private extension fields. However, the somewhat haphazard manner in which this occurred has led to a fragmented system, which lacks some interoperability, jurisdiction, and revocation functionality. If revocation of one privilege is needed, the whole certificate must be revoked. Furthermore, it is more appropriate that attributes (privileges) are assigned by organizations that are "direct owners" of this informationuniversities for registered students, medical associations for health professionals, and so onthan that CAs assign it.
Therefore, in the fourth edition of the X.509 Standard (2000), the definition of an attribute certificate (AC) was introduced to distinguish it from public-key certificates (PKC) from previous versions of the X.509 Standard. Attribute Authority (AA) provides AC and signs it using its own private key. AC is bounded to PKC because the field holder in an attribute certificate contains a serial number and the X500 name of the public-key certificate's issuer; see Tables 1 and 2.
Field | Value |
Version | V1 |
Holder: Issuer | CN=Certificate Authority, O=IMP C=SCG |
Holder: SerialNumber | 123456789 |
Issuer | CN=Attribute Authority, O=IMP, C=SCG |
Signature | dsaWithMD5 |
SerialNumber | 987654321 |
ValidityPeriod | January 1, 2005-January 1, 2007 |
Attributes Type | 2.5.4.72 (role) |
Value | Manager |
SignatureValue | A765 E543 ... |
Field | Value |
Version | V3 |
serialNumber | 123456789 |
Signature | dsaWithMD5 |
Issuer | CN=Attribute Authority, O=IMP, C=SCG |
ValidityPeriod | January 1, 2005-January 1, 2007 |
SubjectPublicKeyInfo | DSA Encryption |
A765 E543 ... | |
... |
X.509 supports discretionary, mandatory, and role-based access control (MAC, DAC, and RBAC). X.509 supports RBAC by defining role specification ACs (RSAC) that hold permissions granted to each role, and role assignment ACs (RAAC) that assign various roles to the users. In role specification ACs, the holder is the role and the privilege attributes are permissions granted to the role.
Java 2 SDK supports:
- Public/private key creation and management.
- Digital signature generation and verification.
- Public key certificate generation and management.
- Keystore management.
However, Java doesn't support attribute certificate generation and management. Therefore, we've implemented a provider named IMPCS ("Institute Mihailo Pupin Computer Systems") that works with attribute certificates.