> 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.
> On the pledge side, how does the pledge know that it must verify the > idevid-issuer? > Well, if it's present. Agree, if not present -> it is not verified. If present: Pledge must verify it. > 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. 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 -----Original Message----- From: Anima <[email protected]> On Behalf Of Michael Richardson Sent: Thursday, August 26, 2021 19:30 To: [email protected] Subject: [Anima] “idevid-issuer” value from voucher (request) payload 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 protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
