Subject: Re: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

From: Qin Wu <[email-masked]>
Date: Fri, 24 Sep 2021 09:52:55 +0000

Thank Michale for clarification, so if my understanding is correct, idevid-issuer is now only referred to authority key identifier and serial number is not part of idevid-issuer.

-Qin
-----邮件原件-----
发件人: Michael Richardson [mailto:[email-masked]] 
发送时间: 2021年9月23日 5:28
收件人: Qin Wu <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

Qin Wu <[email-masked]> wrote:
    > Also I am wondering whether the voucher artifacts signed by
    > manufacture, needs to closely tie with MASA. Maybe this relation can be
    > decoupled as well.

The critical thing that RFC8366 worried about is a *manufacturer* that had poor serial number control.  This could be caused by the manufacturer being big and different parts of the organization not being aware of what other parts were doing.  This also can occur due to merges and acquisitions.

None of this matters if the MASA are distinct, but clearly one of the savings from the mergers would be that the MASA service would be centralized.

What we have figured out:

1) the pledge never needs to put idevid-issuer in.  It's certificate (and
   thus the issuer of said certificate) is in the DTLS Client certificate in
   protocol.  So the pledge never needs to know if an M&A has occured :-)

2) the Registrar needs to extract the serial-number and idevid-issue, and
   it SHOULD always include the idevid-issuer in the Registrar Voucher
   Request (RVR).  Since that part occurs on a non-constrained Internet, the
   extra 6 bytes of wrapper don't matter much, so just always include it.

3) the MASA knows if it must include idevid-issuer or not, and it should do
   an appropriate thing.

The remaining problem is just that we need to create voucher examples with idevid-issue included, where the idevid-issuer is *wrong*, in order to test pledge verification code.  But, that should be doable as unit tests.

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