![]() |
![]()
| ![]() |
![]()
NAME
SYNOPSIS
X509_ATTRIBUTE *
X509_ATTRIBUTE *
X509_ATTRIBUTE *
void
DESCRIPTIONIn the X.501 standard, an Attribute is the fundamental ASN.1 data type used to represent any kind of property of any kind of directory entry. In OpenSSL, very few objects use it directly, most notably the X509_REQ_INFO object used for PKCS#10 certification requests described in X509_REQ_new(3), the PKCS8_PRIV_KEY_INFO object used for PKCS#8 private key information described in PKCS8_PRIV_KEY_INFO_new(3), and the PKCS12_SAFEBAG container object described in PKCS12_SAFEBAG_new(3).
Be careful to not confuse the type of the attribute and the type of the value.
RETURN VALUES
In particular, these functions fail if memory allocation fails.
SEE ALSOd2i_X509_ATTRIBUTE(3), OBJ_nid2obj(3), PKCS12_SAFEBAG_new(3), PKCS7_add_attribute(3), PKCS8_pkey_get0_attrs(3), PKCS8_PRIV_KEY_INFO_new(3), X509_ATTRIBUTE_get0_object(3), X509_ATTRIBUTE_set1_object(3), X509_EXTENSION_new(3), X509_new(3), X509_REQ_add1_attr(3), X509_REQ_new(3) STANDARDS
HISTORY
BUGSA data type designed to hold arbitrary data is an oxymoron. While it may occasionally be useful for abstract syntax specification or for generic container objects, using it for the representation of specific data in a specific data structure feels like dubious design. Having two distinct data types to hold arbitrary data – in this case, X509_ATTRIBUTE on the X.501 language level and X509_EXTENSION as described in X509_EXTENSION_new(3) on the X.509 language level – feels even more questionable, in particular considering that Attributes in certification requests can be used to ask for Extensions in certificates. At the very least, the direct use of the low-level generic X509_ATTRIBUTE type in specific data types like certification requests or private key information looks like a layering violation and appears to put type safety into jeopardy.
|