This came up trying to respond to Ben Kaduks ACP review
i am just working through and me stumbling across the BRSKI reference:
BRSKI section 2.3.1:
| The serialNumber field is defined in [RFC5280]. That specification
| allows for the field to be omitted if there is a good technical
| reason. IDevID certificates for use with this protocol are REQUIRED
| to include the "serialNumber" attribute with the device's unique
| serial number (from [IDevID] section 7.2.8, and [RFC5280] section
| 4.1.2.2's list of standard attributes).
The serialNumber field defined in [RFC5280] 4.1.2.2 is not the subject
DN serialNumber (a string) that we want to talk about, but the certificate
serial
number (a number). That serialNumber string is actually defined in [X.520],
for which BRSKI does unfortunately not have a reference. See for example
[RFC4519] used in BRSKI as an example for a serialNumber, it point correctly
to [X.520].
[rant]
Instead of the real serialNumber, [RFC5280] has "explicitly tagged" attributes
called X520<name> in A.1, including X520SerialNumber. But without explanation.
So i am not sure what those are and if in the IETF certificate language one
would need to refer to any such attributes as X520<name>. I have certainly
never seen any router CLI using any such X520<name>...
Grep'ing through all RFCs i could not find any mentioning of X520<name>
other than in the few RFC that define their ASN.1, such as [RFC5280].
So i wouldn't dare to mention any such name before finding an explanation
for them.
[/rant]
Aka: I am not sure exactly what the minimum editorial fix is:
"The serialNumber field is defined in [RFC5280]"
This is AFAIK not correct unless A.1 definition of X520SerialNumber can
be represented as definition of serialNumber. More easily, serialNumber is
defined in [X.520]
"and [RFC5280] section 4.1.2.2's list of standard attributes"
this is wrong.
"and [RFC5280] section A.1's list of standard attributes"
i have no idea if this would be right given that A.1 only has X520SerialNumber.
Cheers
Toerless
In-Reply-To:
<am0pr10mb19562762c90381915ec47095e7...@am0pr10mb1956.eurprd10.prod.outlook.com>
On Tue, Sep 01, 2020 at 07:58:52AM +0000, Werner, Thomas wrote:
> Thanks, just one small change, the refinement of "voucher/pinned-domain-cert"
> should read:
>
> refine "voucher/pinned-domain-cert" {
> mandatory false;
> description "A pinned-domain-cert field
> is not valid in a voucher request, and
> any occurrence MUST be ignored";
> }
>
> Best regards
> Thomas
>
> -----Ursprüngliche Nachricht-----
> Von: Michael Richardson <[email protected]>
> Gesendet: Montag, 31. August 2020 22:01
> An: [email protected]
> Cc: Werner, Thomas (CT RDA CST SEA-DE) <[email protected]>
> Betreff: Re: BRSKI#43, Figure 5 YANG Tree diagram for Voucher-Request
>
>
> Thomas has pointed out that the "pinned-domain-cert" and "last-renewal-date"
> fields which are defined in RFC8366 are not clearly specified for the
> voucher-request.
>
> Neither are needed or appropriate in a voucher-request.
> I have edited the YANG to include:
>
> refine "voucher/pinned-domain-cert" {
> mandatory false;
> description "A voucher-request field
> is not valid in a voucher request, and
> any occurrence MUST be ignored";
> }
>
> refine "voucher/last-renewal-date" {
> description "A last-renewal-date field
> is not valid in a voucher request, and
> any occurrence MUST be ignored";
> }
>
> This is, I think, an editorial change.
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6
> IoT consulting =-
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
