Device Owner Attribute
draft-turner-deviceowner-attribute-03

[Ballot comment]
I understand how the OID works though this moves it so operators that own devices need oids instead of just vendors that build devices needing one. If lots of enterprises want to use this, I doubt the current EN approach is the best.  I don't understand when a country code is used or what it means in terms of authorization decisions. It seems problematic to have multiple ways of specifying the same country given the matching rules would not cause them to match.

[Ballot comment]
I think this document is clearly confusing and I hope it will be reworked in significant fashion to clearly state what it specifies and what it is useful and how.

[Ballot comment]
1. I support two of the points raised by Pasi's DISCUSS: the concept of 'ownership' needs clarification and especially what meas for a device to be 'owned' by a country, and having multiple ways of identifying country codes may lead to interoperability problems

2. Normative reference [X.680] is to the 2002 edition of the ITU-T recommendation which is seperseded by the 2008 edition. We should discuss whether such reference (which is the equivalent to a downref to an obsolete RFC) is OK. I did not enter a DISCUSS as I have already entered one for a different document, but we probably need a common approach.

[Ballot discuss]
This is the one of the issues on Pasi's list:

    DeviceOwner  ::= CHOICE {
      alpha2Country  [0] PrintableString ( SIZE (2) ),
        -- ISO 3166-1 2 Letter Codes (aka diagram).
      alpha3Country  [1] PrintableString ( SIZE (3) ),
        -- ISO 3166-1 3 Letter Codes (aka trigram).
      alpha4Country  [2] PrintableString ( SIZE (4) ),
        -- ISO 3166-2 4 Letter Codes (ISO 3166-1 diagram and a hyphen
        -- followed by one alpha or numeric code).
      alpha5Country  [3] PrintableString ( SIZE (5) ),
        -- ISO 3166-2 5 Letter Codes (ISO 3166-1 diagram and a hyphen
        -- followed by two alpha or numeric codes).
      alpha6Country  [4] PrintableString ( SIZE (6) ),
        -- ISO 3166-2 6 Letter Codes (ISO 3166-1 diagram and a hyphen
        -- followed by three alpha or numeric codes).
      numericCountry    INTEGER (0..999),
        -- ISO 3166-1 3 Digit Codes.
      group              OBJECT IDENTIFIER
    }

Having both 2 letter country codes, 3 letter country codes
(some of which correspond to 2 letter country codes) and numeric country
codes doesn't help interoperability. If you look at LTRU WG document,
you can see that there is a single registry that avoids multiple representations of the same thing.

My recommendation is to either remove everything but 1 choice for country codes (using 3 letter country codes seems to be the best), or add more text clarifying which choice is going to be used in which case and how interoperability is to be achieved.

[Ballot comment]
I dislike that this attribute is not defined on anything in particular, and thus unlikely to lead to interoperability unless referenced from elsewhere.  However, this was already covered by other DISCUSS positions so I won't add mine.

It would also be good to better understand the requirements for identifying owners.  In particular, having different options for country codes plus different options for non-countries makes it really hard for me to figure out what the owner is.  I wonder if it will be too likely for the same owner to be represented in multiple different ways, which might make the comparison fail if not all those options are known to the comparison-making party.

[Ballot discuss]
This is the one of the issues on Pasi's list:

    DeviceOwner  ::= CHOICE {
      alpha2Country  [0] PrintableString ( SIZE (2) ),
        -- ISO 3166-1 2 Letter Codes (aka diagram).
      alpha3Country  [1] PrintableString ( SIZE (3) ),
        -- ISO 3166-1 3 Letter Codes (aka trigram).
      alpha4Country  [2] PrintableString ( SIZE (4) ),
        -- ISO 3166-2 4 Letter Codes (ISO 3166-1 diagram and a hyphen
        -- followed by one alpha or numeric code).
      alpha5Country  [3] PrintableString ( SIZE (5) ),
        -- ISO 3166-2 5 Letter Codes (ISO 3166-1 diagram and a hyphen
        -- followed by two alpha or numeric codes).
      alpha6Country  [4] PrintableString ( SIZE (6) ),
        -- ISO 3166-2 6 Letter Codes (ISO 3166-1 diagram and a hyphen
        -- followed by three alpha or numeric codes).
      numericCountry    INTEGER (0..999),
        -- ISO 3166-1 3 Digit Codes.
      group              OBJECT IDENTIFIER
    }

Having both 2 letter country codes, 3 letter country codes
(some of which correspond to 2 letter country codes) and numeric country
codes doesn't help interoperability. If you look at LTRU WG document,
you can see that there is a single registry that avoids multiple representations of the same thing.

[Ballot comment]
I'm wondering why you did not just use a domain name for the owner? So the owner could be cisco.com or something like that.

[Ballot comment]
I would suggest that the authors re-consider this draft and try to
see if it can be written to be about cert extensions, about organizations
and about specific rules on what implementations need to do in order to
support policy decisions regarding these attributes.

Some specific comments:

I agree with the issues that Pasi raised in his review.

Also, the document says:

  The Device Owner attribute indicates the country or organization that
  owns the Device with which this attribute is associated.

But I do not know what it means for a device to be owned by a country.
I would argue that in most cases there is no such thing. Devices belong
to organizations, e.g., ministry of such and such, city blaah
administration, or acme corporation.

And:

  This attribute may be used in authorization decisions. For example, a
  router deciding whether to connect to another router could check that
  the device owner present in the device's certificate is on an
  "approved" list.

This is a pretty weak definition. First of all, it brings up interesting
applications for routers that you probably did not mean? (E.g., if these
certs were somehow used in BGP, we would not expect interdomain BGP to
demand that it only talks to the same domain :-) Secondly, I don't know
what to implement based on the above description.

And:

  NOTE: This document does not provide LDAP equivalent schema
  specification as this attribute is targeted at public key
  certificates [RFC5280] and attribute certificates [RFC3281bis].  This
  is left to a future specification.

I do not understand what "this" refers to in the last sentence. The
application to certs? Or LDAP schema? Please be more specific.

[Ballot comment]
I agree with the issues that Pasi raised in his review.

Also, the document says:

  The Device Owner attribute indicates the country or organization that
  owns the Device with which this attribute is associated.

But I do not know what it means for a device to be owned by a country.
I would argue that in most cases there is no such thing. Devices belong
to organizations, e.g., ministry of such and such, city blaah
administration, or acme corporation.

And:

  This attribute may be used in authorization decisions. For example, a
  router deciding whether to connect to another router could check that
  the device owner present in the device's certificate is on an
  "approved" list.

This is a pretty weak definition. First of all, it brings up interesting
applications for routers that you probably did not mean? (E.g., if these
certs were somehow used in BGP, we would not expect interdomain BGP to
demand that it only talks to the same domain :-) Secondly, I don't know
what to implement based on the above description.

And:

  NOTE: This document does not provide LDAP equivalent schema
  specification as this attribute is targeted at public key
  certificates [RFC5280] and attribute certificates [RFC3281bis].  This
  is left to a future specification.

I do not understand what "this" refers to in the last sentence. The
application to certs? Or LDAP schema? Please be more specific.

[Ballot comment]
I agree with the issues that Pasi raised in his review.

Also, the document says:

  This attribute may be used in authorization decisions. For example, a
  router deciding whether to connect to another router could check that
  the device owner present in the device's certificate is on an
  "approved" list.

This is a pretty weak definition. First of all, it brings up interesting
applications for routers that you probably did not mean? (E.g., if these
certs were somehow used in BGP, we would not expect interdomain BGP to
demand that it only talks to the same domain :-) Secondly, I don't know
what to implement based on the above description.

And:

  NOTE: This document does not provide LDAP equivalent schema
  specification as this attribute is targeted at public key
  certificates [RFC5280] and attribute certificates [RFC3281bis].  This
  is left to a future specification.

I do not understand what "this" refers to in the last sentence. The
application to certs? Or LDAP schema? Please be more specific.

[Ballot discuss]
I have reviewed draft-turner-deviceowner-attribute-02, and have a
couple of questions/concerns that I'd like to discuss before
recommending approval of the document:

- Abstract/Section 1: talking about "protocols that support ASN.1
attributes" is really vague, and unlikely to lead to any kind of
interoperability (e.g. Kerberos uses ASN.1 and has some concept of
attributes, but it doesn't look like this spec as-is would allow using
this attribute in Kerberos -- and probably that was not the intent,
either).

If the intent is PKCs and ACs, I'd suggest something like "This
attribute may be included in attribute certificates [RFC3281bis] and
in the Subject Directory Attributes extension in public key
certificates [RFC5280]" (or is it intended to be used in DNs, too?)
The document title should be slightly more specific, too.

- I was surprised to find "IMPORTS NOTHING" in the ASN.1 module -- it
seems most of the ASN.1 is generic attribute stuff which should be
imported (instead of copy-pasted) from somewhere?

- Why have three different ways (2-latter, 3-letter, numeric) of
representing exactly the same information? This seems unlikely to
promote interoperability (e.g. if the information is an integer, we
don't usually allow both little-endian, big-endian, and
"middle-endian" encodings, but just pick one of them...)

- Why three separate entries for 3166-2 codes, instead of SIZE(4..6)?

- The concept of "ownership" may vary from one legal system to
another, but IMHO it's more typical to say that a device is owned by
by a legal person (e.g. "Ministry of Justice, Finland" or "IETF Trust,
Virginia, USA") than by a country (which would usually have
thousands/millions of different organizations).

When you use the 3166 codes in the device owner attribute, is it
intended to specify just the nationality of the organization (e.g.
"US" for IETF Trust, "FI" for "Ministry of Justice, Finland"), or is
it intended to imply that the organization is somehow part of "the
government"? (which is obviously a very fuzzy definition if you have
federal, state, municipal levels, different branches, government-owned
companies, etc.)

1.a - Carl Wallace is the Shepherd.  I have personally reviewed the
document and assert that it is ready for IESG publication.

1.b - The document has been reviewed by Russ Housley, Jim Schaad, and Kurt Zelienga, who were considered to be experts with ASN.1 and/or directories.  There are no concerns about depth or breadth of the reviews.

1.c - I see no need for wider review.

1.d - There are no specific concerns of which the AD and/or IESG should
be aware.

1.e - This is not a product of a WG.

1.f - This is not a product of a WG.

1.g - I have personally verified that the document satisfies all ID nits (although it does generate several spurious warnings).

1.h - The document splits it references into normative and informative
as required.

1.i - The document has an IANA consideration section and it is consistent with the main body (there are no IANA considerations).

1.j - Sean Turner verified the ASN.1.

1.k - Write-up is as follows:

Technical Summary

This document defines the deviceOwner attribute.  This attribute may be carried in a public key certificate in the Subject Directory Attributes extension, in an attribute certificate in the attribute field, in a directory as an attribute, or in protocols that support attributes.

Discussion Summary

The -00 version was reviewed by Kurt Zeilenga.  A match rule was added to the definition to ensure a proper match can be performed between a presented attribute and a stored attribute.

Document Quality

This document is a short document that defines an attribute a matching rule.

Personnel

Carl Wallace is the shepherd.  Tim Polk is the sponsoring AD.