[Anima-bootstrap] minutes from ANIMA bootstrap 2016-05-24, including query re: use of RFC4108

[Michael Richardson <[e-mail]>]

Up-front-query for Russ about RFC4108:
   1) can we use this piece of RFC4108 directly in this way?
   2) Or should we have a new id-on-XXX? (even if the hardwareModuleName is
      identical)

As additional part of the query:
   The Trusted Computing Group's specification
       "TCG Infrastructure WG TPM Keys for Platform Identity for TPM 1.2
          Specification, Version 1.0 Revision 3"
    indicates that a DevID certificate for a TPM:
      > SHALL contain a hardwareModuleName as specified in RFC 4108 [50] that
      > describes the TPM.

      > Note: The TCG registered OID (2.23.133.1.0) represents the hwType and
      > TPM 1.2. The hwSerialNum is the TPM serial number. The combination of
      > the hwType and hwSerialNum uniquely identifies the hardware module.

      > Meanwhile they are apparently looking at:
      > "the use of HardwareModuleName to represent the TPM when using the
      > hwType 2.23.133.1.2 to represent "TPM2.0.""


Meeting 2016-05-24.

Present: Max Pritikin (max)
         Michael Richardson (mcr)
         Peter van der Stok (peter)
         Toerless Eckert (toerless)

We resumed the work to review the EDNOTEs in the document, but were drawn to
a comment that _mcr_ made the previous week about RFC4108.  We talked for 50
minutes on this topic, aa it has relevance to the document and to attempts
to get running code.

_mcr_ had asked if we could use the the hardwareModuleName subjectAltName that
is defined in RFC4108 (as well as the defined otherName OID).  RFC4108 is
primarily about signing firmware, it provides for the signed firmware object
to be bound to a particular device, and provides the following ASN.1:

      id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
        iso(1) identified-organization(3) dod(6) internet(1) security(5)
        mechanisms(5) pkix(7) on(8) 4 }

   A HardwareModuleName (HMN) is composed of an object identifier and an octet
   string:

      HardwareModuleName ::= SEQUENCE {
        hwType OBJECT IDENTIFIER,
        hwSerialNum OCTET STRING }


We discussed a few aspects of this definition.
1) it has a hwType which is an OID, and therefore manufacturers can define
   an OID from an OID ARC they control, such as a Private Enterprise Number
   (PEN).
2) the hwType means that all of the hwSerialNum is vendor-specific, and the
   vendor can take care of making sure that this number is unique.

We discussed that we might also want to have one or more well-known hwType
OIDs for the case where the hwSerialNum is in fact an EUI-48 or EUI-64;
i.e. for the case where hwSerialNum is already a globally unique identifier.

We also discussed that we feel that for ANIMA, hwSerialNum SHOULD be
restricted to IA5String.  We expect the contents of this field to be human
readable.

We believe that this subjectAltName attribute be a MUST for LDevIDs produced
by the registar.  Behind the scenes this really means that the registrar
must reject certificate requests from clients where this SAN is not included.

We want the LDevID to contain as many attributes from the IDevID as possible,
but we also want the registrar to be in authoritative for the CN.
The CN will be set (i.e. the registrar will insist that the client request)
a CN that is relevant to the domain.

It may be that some vendors will be unable or unwilling to provide a
HardwareModuleName in their IDevID.  We discussed that this may require
custom code in the registrar to extract an equivalent for the
HardwareModuleName from other places in the IDevID.  This is preferably
out of scope.   In discussion, it was realized that because the contents of
the certificate MUST be specified by the client, that this custom code mostly
must live in the new node, which the vendor controls anyway.

{The above is not entirely true though: if the new node wants to claim
HardwareModuleName="FOO", then the registar must be able to verify that "FOO"
occurs in an appropriate place in the IDevID, so the registar may still need
proprietary code if the vendor won't put a HMN in their IDevID)

Document ACTIONs:

1)  The device SHOULD propogate all fields from the IDevID (subjectAltName,
   and subjectName) to the LDevID via the CSR. The Registar is, however,
   authoritative for the CN, and does not copy that literally.

2) Section 5.1 will be updated to indicate that the Registar SHOULD look to
    the rfc4108 hwModuleName for the hwSerialNum and MAY look to vendor
    specific locations for compatibilitiy with non-standard manufacturing
    installed credentials.

3) The Resulting LDevID MUST have a hwSerialNum regardless of where the
   registrar had to look to find it in the IDevID.

4) The HardwareModuleName is the registrar's identifier into the MASA.
   For the purposes of lookup to the MASA, we will consider the entire
   HardwareModuleName as an octet-string, including the ASN.1 SEQUENCE
   overhead.

5) If the hwSerialNum must be generated by the registar from another source
   (such as an EUI-48 in some other field), then we will want to define
   a hwType for this (TBD).

   (This language needs to be cleaned up to reflect the reality of EST vs CMC
   and the use of CSRattrs to the client for generation of the CSR conforming
   to these requirements)

In discussion, the terms:
    SUDI == Secure Unique Device Identifier.

which is Cisco speak for an IDevID.






--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-