Subject: [Anima] “idevid-issuer” value from voucher (request) payload

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Aug 2021 13:29:38 -0400

RFC8366 details the idevid-issuer field in the voucher.

          "The Authority Key Identifier OCTET STRING (as defined in
           Section 4.2.1.1 of RFC 5280) from the pledge's IDevID
           certificate.  Optional since some serial-numbers are
           already unique within the scope of a MASA.
           Inclusion of the statistically unique key identifier
           ensures statistically unique identification of the hardware.
           When processing a voucher, a pledge MUST ensure that its
           IDevID Authority Key Identifier matches this value.  If no
           match occurs, then the pledge MUST NOT process this voucher.

           When issuing a voucher, the MASA MUST ensure that this field
           is populated for serial-numbers that are not otherwise unique
           within the scope of the MASA.";

RFC8995 doesn't speak about idevid-issuer at all.

The situation where this matters is where a vendor, when assigning
_serialNumber_ (X520SerialNumber) in it's IDevID can not make them unique
across MASA/voucher signing keys.
Scenarios where this can occur would be:
  a) different parts of (a big dis-) organization start doing IDevID provisioning
     at different times, and each decides to start with serialNumber 1.

  b) there is a merger of two entities.  Of course, each started with 1.
  c) some other screwup where a counter was reset, or was unknown.
     For instance, the IDevID provisioning box at factory A dies, and
     did not synchronize it's database correctly with the backup.
     A new IDevID signing key (perhaps a subordinate CA key) is generated,
     and it's possible that some numbers are repeated.

In addition to one of the above scenarios, the situations must also be that
all the devices (pledges) use the *same* MASA voucher signing trust anchor.
So in (a) above, this means that the different parts were not doing BRSKI at
all, and then all joined into the same MASA.  If they had been doing BRSKI
(or SZTP) before the merger, then they'd have distinct MASA signing keys, and
there would be no conflict.

On the pledge side, how does the pledge know that it must verify the idevid-issuer?
Well, if it's present.   A pledge that could be retroactively programmed to
start doing it, could also be retroactively adjusted to use a new MASA trust
anchor.   So, if we are going to depend upon it, then it had better be
present in at least some of the tests.

We had discussions on whether or not the idevid-issuer might be needed in the
voucher-request.   it's clearly allowed, since it hasn't been forbidden in
RFC8995.

On the Registar side, the Registrar needs to know how to index the pledge.
What's the primary key that it can use to put into it's database?
In my code, I started using the (hash) of public key in the certificate.
I don't care about the serialNumber or the idevid-issuer, which maybe is a
mistake.  I'd be in trouble of by chance, two vendors (or the same vendor)
managed to generate the same private key, and therefore had the same public
key.

Whey would the pledge need to include the idevid-issuer in the voucher-request?
I think that it would never, as the IDevID already includes the Issuer in the
certificate, and so that's all redundant.

I think that we will say this (voucher-requests do not need idevid-issuer) in
the constrained-voucher document.   Since we extend the YANG, we can refine
the constrained-voucher part.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Esko Dijk <[email-masked]>
Date: Fri, 27 Aug 2021 18:35:05 +0000

> RFC8995 doesn't speak about idevid-issuer at all.

It defines usage of idevid-issuer in the Registrar Voucher Request (RVR). But yes it doesn't speak about it for use in the Voucher.
In certain cases the MASA needs to receive this information from the Registrar; e.g. in the scenarios a) b) c)  that you sketched, 
to select the right signing authority out of multiple.

> Well, if it's present.   

Agree, if not present -> it is not verified. If present: Pledge must verify it.

> the constrained-voucher part.

Ideally we update the YANG of voucher-request-constrained to document the usage of idevid-issuer in the RVR. (RFC 8995 should have done that, but alas.)
"do not need idevid-issuer" is mostly true for the Voucher.  I do see a particular corner case where idevid-issuer is needed in the Voucher to avoid identity confusion, 
I can write that down some other time.

Esko

---

From: Michael Richardson <[email-masked]>
Date: Sat, 28 Aug 2021 15:28:54 -0400

Esko Dijk <[email-masked]> wrote:
    > It defines usage of idevid-issuer in the Registrar Voucher Request
    > (RVR). But yes it doesn't speak about it for use in the Voucher.
    > In certain cases the MASA needs to receive this information from the
    > Registrar; e.g. in the scenarios a) b) c)  that you sketched,

Right, it is there.
I was looking at the document when I wrote my email, and I thought that I
searched for it, and didn't find it.  But there it is in section 5.5.

The Pledge doesn't really know if it has to include it, because it doesn't
know if a merger (or other action) has occured since it was shipped.   I
think that the pledge can omit it whenever it has included it's IDevID certificate.

The Registrar has no idea if it needs to include it.
I conclude that it has to always include it since it has no way of knowing.

My MASA uses the certificate as the key to find the pledge's database entry
so I haven't noticed it's absense.
The examples do not include it :-(

    > Ideally we update the YANG of voucher-request-constrained to document
    > the usage of idevid-issuer in the RVR. (RFC 8995 should have done that,
    > but alas.)
    > "do not need idevid-issuer" is mostly true for the Voucher.  I do see a
    > particular corner case where idevid-issuer is needed in the Voucher to
    > avoid identity confusion,

Thank you.
My other idea is to obsolete it, on the assumption that private keys are
never repeated.