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

[Esko Dijk <[e-mail]>]

Hi,

> [Qin]: Yes, I confuse with the option2 and 3, 
> 1. first, I didn't see 2 bytes 04 18 appeared in the below 26 bytes example encoded data
> 2. Second I think ox18 standard for length of encoded data which is 24 bytes.
> 3. Since the 'SEQUENCE' is included in the encoded data, why not choose option 2?

1. Indeed for Option 3, the idevid-issuer field bstr would contain 26 bytes: 041830168014D5039FC78A4DC0468760191FD71B1534C2D88428
Option 2 is 24 bytes: 30168014D5039FC78A4DC0468760191FD71B1534C2D88428
Option 1 is 20 bytes: D5039FC78A4DC0468760191FD71B1534C2D88428

2. Sorry, not quite sure what you meant here! In this case the data inside the octet string ('payload') is 24 bytes but it could be another value depending on how the CA encodes its Authority Key Identifier ext, e.g. how it is hashed / how long the hash is, and what other of the optional fields are included in the AKI.

3. Option 2 and 3 are quite similar I think. In the Constrained-BRSKI draft + interop work we have just selected Option 3, though.  This was based on the feeling that Option 3 was closest to the present RFC 8366 definition. The size was not really an argument here because the field is used always in the non-constrained network leg Registrar -> MASA (in Voucher Request) and hardly ever used in the constrained network leg (Registrar -> Pledge, in Voucher).

Best regards
Esko

-----Original Message-----
From: Qin Wu <[e-mail]> 
Sent: Tuesday, September 21, 2021 12:44
To: Esko Dijk <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

Hi, Esko:

-----邮件原件-----
发件人: Anima [mailto:[e-mail]] 代表 Esko Dijk
发送时间: 2021年9月20日 20:48
收件人: Qin Wu <[e-mail]>; [e-mail]
抄送: [e-mail]
主题: Re: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in the idevid-issuer field?

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.
[Qin]: Yes, I confuse with the option2 and 3, 
1. first, I didn't see 2 bytes 04 18 appeared in the below 26 bytes example encoded data
2. Second I think ox18 standard for length of encoded data which is 24 bytes.
3. Since the 'SEQUENCE' is included in the encoded data, why not choose option 2?

> 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.
[Qin]:Thank for clarification, if my understanding is correct, the MASA in the former case is the third party entity while manufacturer's server in the latter case should be deployed together with the device by the same manufacturer.
regards
Esko

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

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:[e-mail]] 代表 Michael Richardson
发送时间: 2021年9月9日 1:12
收件人: [e-mail]
抄送: [e-mail]; Esko Dijk <[e-mail]>; [e-mail]
主题: [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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [

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