Subject: Re: [Netconf] draft-ietf-netconf-call-home-17

From: Kent Watsen <[email-masked]>
Date: Mon, 11 Apr 2016 14:20:36 +0000

[CC-ing NETCONF WG and Max, editor of the IEEE 802.1AR-2009 spec]

Hi Marta,

Thanks for writing.  I'm traveling this week, but will respond to your mail as quickly as I can.

To ensure I understand, is it correct to say that the DPU is the "NC/RC server" (that initiates the call-home connection) and the PMA is the NC/RC client (that listens for and accepts the TCP connection)?  [NC/RC = NETCONF/RESTCONF]

You mentioned TLS mutual authentication, is this netconf-ch-tls or restconf-ch-tls, or netconf-ch-ssh with RFC 6187?  (see the IANA Considerations section in the draft for those registrations)

Answering your questions:

a) True, the second bullet point is "Identifiers other than fully qualified DNS domain names".  Note that the first bullet point regards client identity, but we're discussing server identity here.   I don't see a question here, so I'll move on to 'b' now.

b) We very much expect that the certificate presented can be the device's IDevID (or LDevID) certificate; the quoted text below even calls out IDevID specifically.   I think your question is if its possible/allowed given the statement in Section 1.7.2 in RFC 6125, as well as the definition of "identifier type" in Section 1.8.  It seems to me that this must be possible, perhaps defined in a spec related to IEEE 802.1AR-2009.  If not, then we might need to consider extending RFC 6125 to allow it.

c) Again, this was/is not the intent.  We very much expect IDevID certificates to encode a DUID (e.g. serial-number) in its CommonName field.

BTW, you mentioned DHCP and DUID-EN initially.  Please note that the call-home draft only regards the NC/RC protocol; any interaction with a DHCP server is out of scope.   If interested in how a DHCP server might be used in conjunction with call-home, for zero touch provisioning workflows, please see https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-08#section-4.3.

Cheers,
Kent

From: Marta Seda <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 7, 2016 at 9:31 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: draft-ietf-netconf-call-home-17

I am a participating member of Broadband Forum WT-301 FTTdP architecture.  This particular standard uses IETF-call home.  We have been discussing the reference identifier to use for establishing a TLS session between a G.fast DPU (Distribution Point Unit) and PMA (Persistent Manager) when the DPU does a “call-home” to the PMA (and you are using TLS mutual authentication).  The DPU is a telcom quality device (that can be installed in a cabinet).  We have been discussing use of DUID-EN for DHCP to uniquely identify DPU devices (DUID-EN by definition are globally unique).

Currently call-home-17 section 3.1 describes the client steps towards establishing a connection.  It  contains the below statement with respect to reference identifiers.

   C6  If certificate path validation is used, the NETCONF/RESTCONF

       client MUST ensure that the presented certificate has a valid

       chain of trust to a preconfigured issuer certificate, and that

       the presented certificate encodes an "identifier" [RFC6125<https://trac.tools.ietf.org/html/rfc6125>] that

       the client had awareness of prior to the connection attempt.  How

       identifiers are encoded in certificates MAY be determined by a

       policy associated with the certificate's issuer.  For instance, a

       given issuer may be known to only sign IDevID certificates

       [Std-802.1AR-2009<https://trac.tools.ietf.org/html/draft-ietf-netconf-call-home-17#ref-Std-802.1AR-2009>] having a unique identifier (e.g., serial

       number) in the X.509 certificate's "CommonName" field.

Question:

a)      Call-home-17 currently describes support of RFC 6125 identifiers.  RFC 6125 is centered around service identities associated with a fully qualified DNS domain name.  RFC 6125 Section 1.7.2 excludes device identity as part of this RFC.

b)     If the desired policy does not include IDevIDs, what other options are available for encoding the “identifier” in the presented certificate (from the call-home perspective)?

c)      Does such statement in step c6 preclude simpler identifiers (e.g., DUID (it is in binary format whereas common name is a string)).

Sincerely,

Marta Seda
Calix Networks

---

From: Marta Seda <[email-masked]>
Date: Thu, 14 Apr 2016 00:38:07 +0000

Hi, Ken,

Thanks for getting back to me.  Next week BBF is meeting again to discuss path validation in the context of call-home.  To give you some background on what BBF is attempting to solves in the fttdP working group, we are looking into supporting mutual authentication (netconf-ch-tls) between the management entity (PMAA/PMA) and the telcom device (DPU).  The DPU is owned by the operator.  PMAA is an aggregator of PMAs (there is a 1:1 relationship between PMA and DPU).  In your previous email, yes you got the relationships correct:
PMA=NC client
DPU=NC server

There are some differences between BBF and IETF with respect to call home (e.g., BBF has gone in the direction of preferring to learn the call home server addresses via DHCP (instead of via a bootstrap server as per https://tools.ietf.org/html/draft-ietf-netconf-server-model-09).

The question that we are struggling to handle is the reference identifier definition.  RFC 6125 Section 6.2.1 provides guidance for building your reference identifiers.  However it recommends to build your reference identifiers on the DNS-ID.    If I go to https://tools.ietf.org/html/draft-ietf-netconf-call-home-17 Security section, the reference identifier is defined as the serial number (I am assuming that it is the device serial identifier (not the certificate serial number)).  Your previous email suggest this is the correct interpretation (common name is the device serial number).  (that in itself presents some problems with 3rd party PMA/PMAAs – it isn’t unique enough).

To mitigate these risks, this RFC requires that the

   NETCONF/RESTCONF client validate the server's SSH host key or

   certificate, by certificate path validation to a preconfigured issuer

   certificate, or by comparing the host key or certificate to a

   previously trusted or "pinned" value.  Furthermore, when a

   certificate is used, this RFC requires that the client be able to

   match an identifier encoded in the presented certificate with an

   identifier the client was preconfigured to expect (e.g., serial

   number).

We (BBF) are discussing how to encode in the certificate the DPU serial number (4-bytes) and the vendor ID.  Below is a copy-paste out of 802.1AR on the subject and subjectAltname (SAN).  You can see that 802.1AR states that subject field should have a DN but doesn’t state anything about its format (instead it punts the description to RFC 5280 and RFC 4108).   RFC 5280 does not provide a format for the subject serial number (serial number of the certificate is described instead).  RFC 4108 provides a means to include Part Identifier and Serial Identifier in the SAN field (thus resulting in some redundancy between the subject and SAN field (subject field has a serial number)).

7.2.8 subject
      The DevID subject field shall uniquely identify the device associated
      with the particular DevID credential within the issuer’s domain of
      significance. The formatting of this field shall contain a unique X.500
      Distinguished Name (DN). This may include the unique device serial
      number assigned by the manufacturer or any other suitable unique DN
      value that the issuer prefers. In the case of a third-party CA or a
      standards certification agency, this can contain the manufacturer’s
      identity information. The subject field’s DN encoding should include
      the “serialNumber” attribute with the device’s unique serial number.

7.2.9 subjectAltName
      The non-critical DevID subjectAltName extension may supplement the
      subject field identity information as specified in RFC 5280 by
      containing a hardwareModuleName as specified in RFC 4108 [B22].

As you can see there are some incongruities in the standards.  The DPU serial number is defined in WT-301 is a 4-byte field and the vendor ID to be 4 bytes.  I am trying to understand how I can fit these fields into the certificate.

This is a copy-paste example from the anima-bootstrap mailing group (I’ve  stripped the example to only x.509 fields of interest)

Certificate

  Serial Number (hex): 138BA1550000002D9F7A

  Issuer:

    cn=Cisco Manufacturing CA

    o=Cisco Systems

  Subject:

    Name: C819HWD-A-K9

    Serial Number: PID:C819HWD-A-K9 SN:FTX1XXXXZ (Is this example formatted correctly (would it meet 802.1AR?)

    cn=C819HWD-A-K9

    serialNumber=PID:C819HWD-A-K9 SN:FXXXXFZ

Can you clarify where the device serial number and part number is supposed to live in the certificate (which fields define it consistently)?  I have to admit that I have problems with this example (the DPU serial number is only 4 bytes long and I need a field to uniquely identify it by the vendor ID (to make it globally unique).  The Issuer field shows the name of the issuer of the certificate (not of the device necessarily).

Could you provide an example of the format that both standards have in mind (or at least provide reference to RFC that explain the proper format for the serial number attribute and the Subjectaltname that you need to use with DevIDs)?  It is unclear when Subjectaltname is used (if the above example is correct, there is no need for it).

Also, if the format of Serial Number is up to the manufacturing vendor (whether the above example is correct only due to lack of standards), are there plans to remedy the situation?  I am asking because BBF is an interop forum.  If this is an area open to vendor interpretation, it would be good to understand/confirm that.

Regards,

Marta Seda

From: Kent Watsen [mailto:[email-masked]]
Sent: Monday, April 11, 2016 7:21 AM
To: Marta Seda <[email-masked]>; [email-masked]
Cc: [email-masked]; max pritikin <[email-masked]>
Subject: Re: draft-ietf-netconf-call-home-17

Hi Marta,

Cheers,
Kent

Question:

Sincerely,

Marta Seda
Calix Networks

---

From: Marta Seda <[email-masked]>
Date: Fri, 15 Apr 2016 20:49:42 +0000

Perhaps this email is too long, let me summarize the questions needing clarification (they are all related to the certificate format which I am not finding in 802.1ar nor call home draft).

a)      What is the expected 802.1AR and call-home common name format? The device serial number is not a unique (different vendor can use the same serial number)

a.      Could it be acceptable to put an ASCII DUID-EN formatted string (DUID-EN is binary in nature).  For example,

                                                    i.     CN= 5771-AFGB (5771 is Cisco Enterprise ID and AFGB is the serial number of the DPU)

                                                   ii.     Could the common name include the model number?  For example, CN=5771-E348CR1-AFGB)  where the format is <enterprise ID>-<model>-<SN> (all in asci format)?

b)     I am having a difficult time visualizing how the SAN includes RFC 4108 hardwareModuleName , how would this be expressed?  Is this the correct syntax to use:

                                                    i.     subjectAltName=otherName:1.3.6.1.5.5.7.8;UTF8:AF68

Clarification/examples would be helpful if you have any.

Regards,

Marta Seda

From: Marta Seda
Sent: Wednesday, April 13, 2016 5:38 PM
To: 'Kent Watsen' <[email-masked]>; [email-masked]
Cc: [email-masked]; max pritikin <[email-masked]>
Subject: RE: draft-ietf-netconf-call-home-17

Hi, Ken,

   number).

7.2.8 subject

7.2.9 subjectAltName

Certificate

  Issuer:

    o=Cisco Systems

  Subject:

    Name: C819HWD-A-K9

    cn=C819HWD-A-K9

Regards,

Marta Seda

From: Kent Watsen [mailto:[email-masked]]
Sent: Monday, April 11, 2016 7:21 AM
To: Marta Seda <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; max pritikin <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-netconf-call-home-17

Hi Marta,

Cheers,
Kent

Question:

Sincerely,

Marta Seda
Calix Networks

---

From: Kent Watsen <[email-masked]>
Date: Mon, 18 Apr 2016 14:18:47 +0000

Hi Marta,

My understanding is that the CommonName field is prefixed by other Subject fields.  For instance, /C=US/ST=CA/L=Sunnyvale/O=Example Company/CN=<unique-id>, where unique-id might be a serial-number.  So even though the serial number may not be globally unique, it is unique when qualified this way.

IEEE 802.1AR-2009 says this in Section 7.2 (DevID credential fields):

7.2.2 serialNumber
Certificate serial number, a positive integer of up to 20 octets. The serialNumber identifies the certificate, and shall be created by the CA that signs the DevID certificate. The serialNumber shall be unique in the scope of DevID certificates signed by the CA. This will typically be different from any manufacturer serial numbers or other unique identifiers associated with the equipment in which the DevID is installed.

7.2.8 subject
The DevID subject field shall uniquely identify the device associated with the particular DevID credential within the issuer’s domain of significance. The formatting of this field shall contain a unique X.500 Distinguished Name (DN). This may include the unique device serial number assigned by the manufacturer or any other suitable unique DN value that the issuer prefers. In the case of a third-party CA or a standards certification agency, this can contain the manufacturer’s identity information.
The subject field’s DN encoding should include the “serialNumber” attribute with the device’s unique serial number.

7.2.9 subjectAltName
The non-critical DevID subjectAltName extension may supplement the subject field identity information as specified in RFC 5280 by containing a hardwareModuleName as specified in RFC 4108 [B22].

Note how 7.2.8 talks about a "serialNumber" attribute.   The text in the call-home draft should be updated:

OLD:

       For instance, a
       given issuer may be known to only sign IDevID certificates
       [Std-802.1AR-2009] having a unique identifier (e.g., serial
       number) in the X.509 certificate's "CommonName" field.

NEW

       For instance, a
       given issuer may be known to only sign IDevID certificates
       [Std-802.1AR-2009] having a unique identifier (e.g., serial
       number) in the X.509 certificate's "serialNumber" field.

Kent

From: Marta Seda <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 15, 2016 at 4:49 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, max pritikin <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-ietf-netconf-call-home-17

Regards,

Marta Seda

From: Marta Seda
Sent: Wednesday, April 13, 2016 5:38 PM
To: 'Kent Watsen' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; max pritikin <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-ietf-netconf-call-home-17

Hi, Ken,

   number).

7.2.8 subject

7.2.9 subjectAltName

Certificate

  Issuer:

    o=Cisco Systems

  Subject:

    Name: C819HWD-A-K9

    cn=C819HWD-A-K9

Regards,

Marta Seda

Hi Marta,

Cheers,
Kent

Question:

Sincerely,

Marta Seda
Calix Networks

---

From: Marta Seda <[email-masked]>
Date: Tue, 19 Apr 2016 10:33:34 +0000

Hi, Kent,
Thanks for clarifying the “new” text of call-home.  That clarifies that we don’t need to support a new attribute in the subject field called “Serialnumber”.  However that still leave open the common name serial number.  It should be a DN format.  Just incorporating the serial number in binary, hex, or asci format doesn’t represent a DN.  Are you implying in this response that it is up to the vendor to put any format? (perhaps integer list is suitable (matching the label)? Just want to clarify it (have internal discussions within bbf if this is acceptable or not since there are informal discussions going on about 3rd party PMAs).

CN=11111 (if I understood your email correctly, is an acceptable format).

Marta

Sent: Monday, April 18, 2016 4:19 PM

Hi Marta,

7.2.2 serialNumber

7.2.8 subject

7.2.9 subjectAltName

OLD:

       For instance, a

NEW

       For instance, a

Kent

Regards,

Marta Seda

From: Marta Seda

Hi, Ken,

   number).

7.2.8 subject

7.2.9 subjectAltName

Certificate

  Issuer:

    o=Cisco Systems

  Subject:

    Name: C819HWD-A-K9

    cn=C819HWD-A-K9

Regards,

Marta Seda

Hi Marta,

Cheers,
Kent

Question:

Sincerely,

Marta Seda
Calix Networks

---

From: Kent Watsen <[email-masked]>
Date: Tue, 19 Apr 2016 15:35:20 +0000

Hi Marta,

> That clarifies that we don’t need to support a new attribute in the subject field called “Serialnumber”.

Wait, the "new" text was implying just the opposite, that there would be a Subject field called "serialNumber".  That said, note that this text is not normative, being just an example ("For instance, ..."), so don't read too much into it...

> Are you implying in this response that it is up to the vendor to put any format?

So long as the certificate is an IDevID, I would expect the vendors to use a format compatible with IEEE 802.1AR-2009.  Specifically, I would expect a Subject to be a DN like "/C=US/ST=CA/L=Sunnyvale/O=Example Company/serialNumber=<unique-id>" (where <unique-id> is ascii text) and maybe (on a per-vendor discretionary basis) have a subjectAltName field containing a hardwareModuleName, as specified in RFC 4108.

Are we converging?

Kent

Date: Tuesday, April 19, 2016 at 6:33 AM

Hi, Kent,

Marta

Hi Marta,

7.2.2 serialNumber

7.2.8 subject

7.2.9 subjectAltName

OLD:

       For instance, a

NEW

       For instance, a

Kent

Regards,

Marta Seda

From: Marta Seda

Hi, Ken,

   number).

7.2.8 subject

7.2.9 subjectAltName

Certificate

  Issuer:

    o=Cisco Systems

  Subject:

    Name: C819HWD-A-K9

    cn=C819HWD-A-K9

Regards,

Marta Seda

Hi Marta,

Cheers,
Kent

Question:

Sincerely,

Marta Seda
Calix Networks

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 19 Apr 2016 23:54:07 +0000

On Apr 19, 2016, at 9:35 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Marta,

> That clarifies that we don’t need to support a new attribute in the subject field called “Serialnumber”.

Wait, the "new" text was implying just the opposite, that there would be a Subject field called "serialNumber".  That said, note that this text is not normative, being just an example ("For instance, ..."), so don't read too much into it…

I think there is some confusion here. I think due to the overloading of the “serialNumber” field name. There are two serialNumber fields in these certificate (sigh). The one that matters is the serialNumber field of the X.500 DN. From  https://tools.ietf.org/html/rfc5280#section-4.1.2.4 :

   "Implementations of this specification MUST
   be prepared to receive the following standard attribute types in
   issuer and subject (Section 4.1.2.6<https://tools.ietf.org/html/rfc5280#section-4.1.2.6>) names:
      * country,
      * organization,
      * organizational unit,
      * distinguished name qualifier,
      * state or province name,
      * common name (e.g., "Susan Housley"), and
      * serial number. <——— this is the serial number attribute in the subject name."

Which is what, this?
https://tools.ietf.org/html/rfc4519#section-2.31
At any rate it comes down to a free form string anyway. It probably always will since I can’t imagine convincing all vendors to use a common serial number format.

The hardwareModuleName is slightly better with an hwType OID but the hwSerialNum is still:

   hwSerialNum is the serial number of the hardware module.  No
      particular structure is imposed on the serial number; it need not
      be an integer.  However, the combination of the hwType and
      hwSerialNum uniquely identifies the hardware module.

Questions from way down below:
Question:
a)      Call-home-17 currently describes support of RFC 6125 identifiers.  RFC 6125 is centered around service identities associated with a fully qualified DNS domain name.  RFC 6125 Section 1.7.2 excludes device identity as part of this RFC.

True. Both by excluding identifiers other than fully qualified DNS domain names and also client identities.

The combination of the issuer authorityKeyIdentifier and a free form serialNumber field which can be string compared is probably the best we have unless we provide a much more guidance.

I wonder if step c6 is referring to “server” and “client” as per the labels in section2 solution overview figure or the Note directly under the diagram (as in per protocol).  Kent?

- max

Are we converging?

Kent

Hi, Kent,

Marta

Hi Marta,

7.2.2 serialNumber

7.2.8 subject

7.2.9 subjectAltName

OLD:

       For instance, a

NEW

       For instance, a

Kent

Regards,

Marta Seda

From: Marta Seda

Hi, Ken,

   number).

7.2.8 subject

7.2.9 subjectAltName

Certificate

  Issuer:

    o=Cisco Systems

  Subject:

    Name: C819HWD-A-K9

    cn=C819HWD-A-K9

Regards,

Marta Seda

Hi Marta,

Cheers,
Kent

Question:

Sincerely,

Marta Seda
Calix Networks

---

From: Kent Watsen <[email-masked]>
Date: Wed, 20 Apr 2016 16:41:39 +0000

Hi Max,

3 comments below, each prefixed by [KENT]     (sorry, my email client isn't formatting this nicer)

Thanks,
Kent

From: "Max Pritikin (pritikin)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 19, 2016 at 7:54 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: Marta Seda <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-netconf-call-home-17
On Apr 19, 2016, at 9:35 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Marta,

Which is what, this?

[KENT] it is a free-form string, true, but it asserts that the serial numbers must be case-insensitive...I wonder if that constraint would concern any vendors?

[KENT] is this fix for this to amend the call-home draft to use a less restrictive reference for "identity", or to update RFC 6125 to allow for device identities?

[KENT]  step c6 says "the NETCONF/RESTCONF client", which is depicted by the right-hand life-line in the diagram presented in Section 2 (Solution Overview).  So in step c6, the relevant bit is that it is the SSH/TLS *client*, and hence authenticating the remote-peer's TLS server certificate or SSH host-key.

- max

Kent

---

From: t.petch <[email-masked]>
Date: Thu, 21 Apr 2016 16:23:19 +0100

Marta

In your first e-mail, you said you were struggling to reconcile RFC6125
and call-home.

"RFC 6125 Section 6.2.1 provides guidance for building your reference
identifiers.  However it recommends to build your reference identifiers
on the DNS-ID.    If I go to
https://tools.ietf.org/html/draft-ietf-netconf-call-home-17 Security
section, the reference identifier is defined as the serial number."

I do not read call-home as defining the reference identifier as the
serial number.  It says
"... may be known to only sign IDevID certificates  [Std-802.1AR-2009]
having a unique identifier (e.g., serial  number) "

It is 'may be known' and 'e.g.' which I think is far removed from
defining the reference identifier as the serial number.  I see it as
allowing any reference identifier you like to suit your environment.

When I read this, I think how keen Kent is on serial numbers and so we
have to mention them - I am not keen and would have omitted all
reference to them from the call-home I-D:-)

Likewise RFC6125, for all its appendices, is applicable to Web access
over the public Internet with a powerful server accessed from a
underpowered client, with a human on tap to provide intelligence when
needed with no client authentication (IMO:-).  Of course it uses DNS-ID,
who uses anything else on the Web? but this is unlike any network
management I have done, where underpowered servers are accessed by
powerful clients (NMS 'servers') in the middle of the night with not a
human in sight, over a private network with client authentication
paramount.  So I tend to take RFC6125 with a pinch of salt - it excludes
the use case which I think covers network manaagement.

I think that the underlying philosophy of RFC6125, of knowing in advance
what to expect and checking that you get it in the X.509 Certificate, is
right, but the details wrong, for most use cases (I disagree too on its
wild-carding).  I did make comments on this in course of its
preparation - I lost. In a private network, the organisation might well
issue all its own certificates with whatever it likes by way of unique
identification, only requiring uniqueness within the organisation.
.
Reading your e-mails, my sense is of you reading too much into the
words, of the RFC and I-D.

Note, too, that the call-home I-D has been through all the stages of
IETF review and is only awaiting a final polish from the RFC Editor, so
the only changes at this stage would be to improve the grammar, or
clarity.

Tom Petch

----- Original Message -----
From: "Marta Seda" <[email-masked]>
To: "Kent Watsen" <[email-masked]>;
<[email-masked]>
Cc: "max pritikin" <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 19, 2016 11:33 AM
Subject: Re: [Netconf] draft-ietf-netconf-call-home-17

> Hi, Kent,
> Thanks for clarifying the new text of call-home.  That clarifies that
we dont need to support a new attribute in the subject field called
Serialnumber.  However that still leave open the common name serial
number.  It should be a DN format.  Just incorporating the serial number
in binary, hex, or asci format doesnt represent a DN.  Are you implying
in this response that it is up to the vendor to put any format? (perhaps
integer list is suitable (matching the label)? Just want to clarify it
(have internal discussions within bbf if this is acceptable or not since
there are informal discussions going on about 3rd party PMAs).
> My understanding is that the CommonName field is prefixed by other
Subject fields.  For instance, /C=US/ST=CA/L=Sunnyvale/O=Example
Company/CN=<unique-id>, where unique-id might be a serial-number.  So
even though the serial number may not be globally unique, it is unique
when qualified this way.