Device Owner Attribute
A certificate attribute to name a device's owner
Turner, S., "Device Owner Attribute", RFC 5916, DOI 10.17487/RFC5916, June 2010, <https://www.rfc-editor.org/info/rfc5916>.
@misc{rfc5916,
series = {Request for Comments},
number = 5916,
howpublished = {RFC 5916},
publisher = {RFC Editor},
doi = {10.17487/RFC5916},
url = {https://www.rfc-editor.org/info/rfc5916},
author = {S. Turner},
title = {{Device Owner Attribute}},
pagetotal = 6,
year = 2010,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5916 IECA
Category: Informational June 2010
ISSN: 2070-1721
Device Owner Attribute
Abstract
This document defines the Device Owner attribute. It indicates the
entity (e.g., company, organization, department, agency) that owns
the device. This attribute may be included in public key
certificates and attribute certificates.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5916.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
This document specifies the Device Owner attribute. It indicates the
entity (e.g., company, organization, department, agency) that owns
the device. This attribute is intended to be used in public key
certificates [RFC5280] and attribute certificates [RFC5755].
This attribute may be used in automated authorization decisions. For
example, when two peers are deciding whether to communicate, each
could check that the device owner present in the other device's
certificate is on an "approved" list. This check is performed in
addition to certification path validation [RFC5280]. The mechanism
for managing the "approved" list is beyond the scope of this
document.
NOTE: This document does not provide an equivalent Lightweight
Directory Access Protocol (LDAP) schema specification as this
attribute is targeted at public key certificates [RFC5280] and
attribute certificates [RFC5755]. Definition of an equivalent LDAP
schema is left to a future specification.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. ASN.1 Syntax Notation
The attribute is defined using ASN.1 [X.680], [X.681], [X.682], and
[X.683].
2. Device Owner
The Device Owner attribute indicates the entity (e.g., company,
organization, department, agency) that owns the device with which
this attribute is associated. Device Owner is an object identifier.
The following object identifier identifies the Device Owner
attribute:
id-deviceOwner OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 69
}
The ASN.1 syntax for the Device Owner attribute is as follows:
at-deviceOwner ATTRIBUTE ::= {
TYPE OBJECT IDENTIFIER
EQUALITY MATCHING RULE objectIdentifierMatch
IDENTIFIED BY id-deviceOwner
}
There MUST only be one value of Device Owner associated with a
device. Distinct owners MUST be represented in separate
certificates.
3. Security Considerations
If this attribute is used as part of an authorization process, the
procedures employed by the entity that assigns each value must ensure
that the correct value is applied. Including this attribute in a
public key certificate or attribute certificate ensures the value for
the device owner is integrity protected.
4. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization", RFC
5755, January 2010.
[RFC5912] Schaad, J. and P. Hoffman, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
June 2010.
[X.501] ITU-T Recommendation X.520 (2002) | ISO/IEC 9594-2:2002,
Information technology - The Directory: Models.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002,
Information Technology - Abstract Syntax Notation One:
Information Object Specification.
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002,
Information Technology - Abstract Syntax Notation One:
Constraint Specification.
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002,
Information Technology - Abstract Syntax Notation One:
Parameterization of ASN.1 Specifications.
Appendix A. ASN.1 Module
This appendix provides the normative ASN.1 [X.680] definitions for
the structures described in this specification using ASN.1 as defined
in [X.680], [X.681], [X.682], and [X.683].
DeviceOwnerAttribute-2008
{ joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) module(0) id-deviceOwnerAttribute-2008(34) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
-- IMPORTS from New PKIX ASN.1 [RFC5912]
ATTRIBUTE
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
-- Imports from ITU-T X.501 [X.501]
objectIdentifierMatch
FROM InformationFramework
{ joint-iso-itu-t ds(5) module(1) informationFramework(1) 4 }
;
-- device owner attribute OID and syntax
id-deviceOwner OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 69
}
at-deviceOwner ATTRIBUTE ::= {
TYPE OBJECT IDENTIFIER
EQUALITY MATCHING RULE objectIdentifierMatch
IDENTIFIED BY id-deviceOwner
}
END
Author's Address
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
EMail: turners@ieca.com
AI ELI5
On this page
§1Device Ownership in Certificates
X.509 certificates bind a public key to an entity (a person, device, or organization). They contain identity information and can include extension fields for application-specific data. Two devices that want to communicate can verify each other's certificates and check that they recognize and trust the other's identity.
This RFC defines the Device Owner attribute, which names the entity (company, organization, department, or agency) that owns a device. The attribute is an object identifier (OID), a hierarchical label from a managed registry. Including this attribute in a certificate is optional, but when present, it allows one device to verify not just that another device's certificate is valid, but that it is owned by an organization on an approved list.
For example, a company laptop might include the company's OID as the Device Owner. When connecting to a corporate VPN, the VPN server checks both the certificate's validity and whether the Device Owner matches a trusted list. If a device is stolen and its certificate used from outside the company, the Device Owner attribute correctly identifies the legitimate owner, helping detect unauthorized use.
A certificate is your digital ID. This adds one line to it: 'owned by Company X.' When someone looks at your certificate, they can check if they trust Company X, in addition to checking if your certificate is real.
§2Use Cases for Device Ownership
The primary use case is automated authorization decisions between peers. When two devices want to establish a secure connection, each can examine the other's certificate and verify that the Device Owner is trusted before proceeding. For example, a medical device might only communicate with devices owned by its hospital system; a manufacturing controller might only accept commands from devices owned by the manufacturer or an authorized service provider.
This is particularly useful in environments with many devices where manual approval is impractical. The Device Owner attribute provides a way to express organizational boundaries in certificates, allowing fine-grained trust decisions based on organizational membership rather than individual device identity alone.
Your work device could refuse to talk to devices that aren't owned by your company, even if their certificates look okay. It's like checking both that someone's ID is real and that they work at a place you trust.
§3How It Works
The Device Owner attribute is defined using ASN.1 syntax, the standard notation for certificate structures. Its object identifier is a specific path in the government and defense namespace: joint-iso-ccitt country us organization dod infosec attributes 69. The attribute's value is itself an object identifier—a dotted number like 2.16.840.1.101.2.1.5.69.1.1—chosen to identify the owning entity.
A device MUST have at most one Device Owner attribute per certificate. If an entity owns multiple devices or has multiple departments that should be distinguishable, those distinctions are represented in separate certificates, each with its own Device Owner value. The attribute's value is protected by the certificate's digital signature, ensuring that an attacker cannot modify it without invalidating the entire certificate.
The RFC does not define how to manage the approved list of Device Owners or how organizations obtain and assign OIDs. It also does not specify an equivalent schema for directory services like LDAP, leaving that for future work. The attribute is intended only for use in X.509 certificates and attribute certificates, not in directory entries.
The Device Owner attribute stores a code number that identifies the owner. Each device certificate can list one owner. The certificate is digitally locked, so nobody can change who owns it without breaking the lock.
§4Security Implications
If the Device Owner attribute is used in authorization decisions, the process of assigning ownership values must be carefully controlled. Only the entity with the power to issue certificates (the certificate authority) should be able to set the Device Owner attribute, and they must ensure the correct value is assigned to each device.
Because the attribute is included in the signed certificate, its value is integrity-protected: an attacker cannot change it without breaking the certificate's signature and making the entire certificate invalid. However, if a certificate authority is compromised or mismanages its process, it might issue certificates with incorrect Device Owner values. Authorization decisions based on this attribute are only as secure as the process used to assign it.
The RFC emphasizes that certification path validation (checking that the certificate chain is valid and signed by trusted authorities) must still be performed in addition to any Device Owner check. The Device Owner attribute is one piece of information that feeds into an authorization decision but should never be the sole criterion.
The Device Owner information is locked into the certificate and can't be changed without breaking it. But if whoever creates certificates makes a mistake or gets hacked, they might put the wrong owner down. Always double-check the certificate's validity before trusting it.