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

From: Qin Wu <[email-masked]>
Date: Sat, 18 Sep 2021 09:40:50 +0000

I agree with this analysis, it looks the naming of this leaf ' idevid-issuer ' is the root cause for introducing such confusion, i.e., easily link KeyIdentifier to 'issuer' defined in section 4.1.2.4 of RFC5280.
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.

-Qin
-----邮件原件-----
发件人: Anima [mailto:[email-masked]] 代表 Michael Richardson
发送时间: 2021年9月9日 1:12
收件人: [email-masked]
抄送: [email-masked]; Esko Dijk <[email-masked]>; [email-masked]
主题: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

RFC8366 specifies a idevid-issuer to identify the CA that issued the IDevID.
It says:
  https://www.rfc-editor.org/rfc/rfc8366.html#section-5.3

leaf idevid-issuer {
        type binary;
        description
          "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.";
      }

We have some discussion about what exactly this means.
https://github.com/anima-wg/constrained-voucher/issues/161 captures this as three possibilities:

1) only the KeyIdentifier OCTET STRING
2) the complete AuthorityKeyIdentifier ASN.1 SEQUENCE structure
3) the complete Authority Key Identifier extension OCTET STRING value 'extnValue' per Section 4.1 of RFC 5280

Esko suggests that (3) is the correct thing, detailed as:

OCTET STRING (26 byte) 30168014D5039FC78A4DC0468760191FD71B1534C2D88428
  SEQUENCE (1 elem)
    [0] (20 byte) D5039FC78A4DC0468760191FD71B1534C2D88428

> I meant here 26 bytes, sorry!
> So 2 bytes 04 18 are used to encode ‘OCTET STRING’, 2 bytes 30 16 for 
> ‘SEQUENCE’, 2 bytes 80 14 for the ‘[0]’ and the rest is the actual 
> KeyIdentifier (20 bytes).

We think this consistent with other users of Authority Key Identifier.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Esko Dijk <[email-masked]>
Date: Mon, 20 Sep 2021 12:47:50 +0000

Hello Qin,

> naming of this leaf ' idevid-issuer ' is the root cause for introducing such confusion,

For me the cause of the confusion was the sentence " The Authority Key Identifier OCTET STRING (as defined in Section 4.2.1.1 of RFC 5280)".
There is only one OCTET STRING defined in Section 4.2.1.1, which is the keyIdentifier field, also named "Key Identifier" in the draft which is not the "Authority Key Identifier".
The actual Authority Key Identifier OCTET STRING is defined in Section 4.1 as the field " extnValue" which is present in the Authority Key Identifier extension, so one needs to look in another section (4.1) for the meant OCTET STRING.  The interpretation is still ambiguous between options 2 and 3 even if you analyse closely.

> whether the voucher artifacts signed by manufacture, needs to closely tie with MASA

For nonceful Vouchers, the MASA would need to sign it or delegate the generation and/or signing to a manufacturer's server. (In the latter case there is a trust relation and operational interaction, but no close tie necessarily.) As long as the signer can be trusted by the Pledge's built-in Trust Anchor, it works.

regards
Esko

-----Original Message-----
From: Qin Wu <[email-masked]> 
Sent: Saturday, September 18, 2021 11:41
To: Michael Richardson <[email-masked]>; [email-masked]
Cc: [email-masked]; Esko Dijk <[email-masked]>; [email-masked]
Subject: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

-Qin
-----邮件原件-----
发件人: Anima [mailto:[email-masked]] 代表 Michael Richardson
发送时间: 2021年9月9日 1:12
收件人: [email-masked]
抄送: [email-masked]; Esko Dijk <[email-masked]>; [email-masked]
主题: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

leaf idevid-issuer {
        type binary;
        description

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Sep 2021 17:27:58 -0400

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