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
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
