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 <bill...@huawei.com>
Sent: Tuesday, September 21, 2021 12:44
To: Esko Dijk <esko.d...@iotconsultancy.nl>; la...@ietf.org
Cc: anima@ietf.org
Subject: RE: [Anima] RFC 8366 / BRSKI / constrained-voucher: what is encoded in
the idevid-issuer field?
Hi, Esko:
-----邮件原件-----
发件人: Anima [mailto:anima-boun...@ietf.org] 代表 Esko Dijk
发送时间: 2021年9月20日 20:48
收件人: Qin Wu <bill...@huawei.com>; la...@ietf.org
抄送: anima@ietf.org
主题: 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 <bill...@huawei.com>
Sent: Saturday, September 18, 2021 11:41
To: Michael Richardson <m...@sandelman.ca>; la...@ietf.org
Cc: stokc...@bbhmail.nl; Esko Dijk <esko.d...@iotconsultancy.nl>; anima@ietf.org
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:anima-boun...@ietf.org] 代表 Michael Richardson
发送时间: 2021年9月9日 1:12
收件人: la...@ietf.org
抄送: stokc...@bbhmail.nl; Esko Dijk <esko.d...@iotconsultancy.nl>; anima@ietf.org
主题: [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 [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
