Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Alexey Melnikov <[e-mail]> wrote:
    >> Alexey Melnikov <[e-mail]> wrote:
    >> >> > o In the language of [RFC6125] this provides for a SERIALNUM-ID >
    >> >> category of identifier that can be included in a certificate and >
    >> >> therefore that can also be used for matching purposes.  The >
    >> >> SERIALNUM-ID whitelist is collated according to manufacturer trust >
    >> >> anchor since serial numbers are not globally unique.
    >>
    >> > This is actually not helping. I was looking for something like:
    >>
    >> >   DNS-ID = a subjectAltName entry of type dNSName
    >>
    >> > Basically I was asking for a definition of SERIALNUM-ID somewhere.
    >>
    >> It's a (subject)DN of serial number=123456, not a subjectAltName.
    >> (not the CertificateSerialNumber)

    > In this case, you need to use CN-ID as the base for the definition. The
    > important part there is that the RDN can't be repeated multiple times
    > in a DN. If it does, that would make the whole DN not suitable for use
    > a la RFC 6125.

To recap, we have changed the text to avoid multiple references to 6125.
We use a reference to LDAP (rfc4519), because that's where the fields get
a clear statment as to how to present them.  We don't need to do RFC6125
matching on certificates to URLs, etc. for the TLS Client Certificates, so
rfc6125 does not really help anyone, so the discussion about CN-ID seems
to just distract.



 2.3.1.  Identification of the Pledge

|   In the context of BRSKI, pledges have a 1:1 relationship with a
    "serial-number".  This serial-number is used both in the "serial-
    number" field of voucher or voucher-requests (see Section 3) and in
    local policies on registrar or MASA (see Section 5).

|   The serialNumber fields is defined in [RFC5280], and is a SHOULD
|   field in [IDevID].  IDevID certificates for use with this protocol
|   MUST include the "serialNumber" attribute with the device's unique
|   serial number (from [IDevID] section 7.2.8, and [RFC5280] section
|   4.1.2.4's list of standard attributes).

|   The serialNumber field is used as follows by the pledge to build the
|   "serial-number" that is placed in the voucher-request.  In order to
|   build it, the fields need to be converted into a serial-number of
|   "type string".

|   An example of a printable form of the "serialNumber" field is
|   provided in [RFC4519] section 2.31 ("WI-3005").  That section further
|   provides equality and syntax attributes.

|   Due to the reality of existing device identity provisioning
|   processes, some manufacturers have stored serial-numbers in other
|   fields.  Registrar's SHOULD be configurable, on a per-manufacturer
|   basis, to look for serial-number equivalents in other fields.

    As explained in Section 5.5 the Registrar MUST extract the serial-
    number again itself from the pledge's TLS certificate.  It can
    consult the serial-number in the pledge-request if there are any
|   possible confusion about the source of the serial-number.


... section 5 now jus says:

    The extensions for a registrar (equivalent to EST server) are:

    o  Client authentication is automated using Initial Device Identity
       (IDevID) as per the EST certificate based client authentication.
       The subject field's DN encoding MUST include the "serialNumber"
|      attribute with the device's unique serial number as explained in
|      Section 2.3.1


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