Review HB: clarify consequences of pinning wrong thing

[mcr]

> (12) Pinning of Raw Public Keys

> "However, if the Pledge is known to also support RPK pinning and the MASA
> intends to pin the Registrar's identity (not a CA), then MASA SHOULD pin the
> RPK (RPK3 in Figure 2) of the Registrar instead of the Registrar's End-Entity
> certificate to save space in the voucher.": why is that not a MUST? What are
> the consequences, if that is not done as highlighted?

[EskoDijk]

I understand changing this to MUST is the easiest way out of the review comments :)
However, it needn't be a MUST in this case because if the MASA is not pinning the RPK but rather the full certificate then the Pledge will still work - because it supports both cert pinning and RPK pinning (that's the word "also" in the text).

To consider: do we want to distinguish in more detail the following 3 cases:

1. Pledge only supports full cert pinning (MASA knows this and will pin full cert always)
2. Pledge only supports RPK pinning (MASA knows this and will pin RPK of Registrar only, always - and ignores the policy requirement that it should rather pin the Domain CA cert if available)
3. Pledge supports both RPK and cert pinning (MASA knows this and will pin the RPK of Registrar only if it really wants to pin the Registrar identity only ; due to policies for this specific customer ; this saves space then. In case the customer's policy tells MASA to pin the Domain CA cert, then it uses cert pinning and not RPK pinning to conform to the policy best.)

The current text only considers cases 1 and 3 Pledges, not case 2.

[EskoDijk]

So in the original text, the only "consequences" the reviewer asks about is a larger voucher size. And if the vendor has a specific reason to inflate voucher size (even though we don't know the reasons yet) and it doesn't hurt the protocol that should be possible, right?

[petervanderstok]

Case 2 is not really wanted.

Peter Esko Dijk schreef op 2021-08-17 18:09:

I understand changing this to MUST is the easiest way out of the review comments :) However, it needn't be a MUST in this case because if the MASA is not pinning the RPK but rather the full certificate then the Pledge will still work - because it supports both cert pinning and RPK pinning (that's the word "also" in the text).

To consider: do we want to distinguish in more detail the following 3 cases:

• Pledge only supports full cert pinning (MASA knows this and will pin full cert always)
• Pledge only supports RPK pinning (MASA knows this and will pin RPK of Registrar only, always - and ignores the policy requirement that it should rather pin the Domain CA cert if available)
• Pledge supports both RPK and cert pinning (MASA knows this and will pin the RPK of Registrar only if it really wants to pin the Registrar identity only ; due to policies for this specific customer ; this saves space then. In case the customer's policy tells MASA to pin the Domain CA cert, then it uses cert pinning and not RPK pinning to conform to the policy best.)

The current text only considers cases 1 and 3 Pledges, not case 2.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. Triage notifications on the go with GitHub Mobile for iOS [3] or Android [4].

Links:

[1] https://github.com/anima-wg/constrained-voucher/issues/141#issuecomment-900431398 [2] https://github.com/notifications/unsubscribe-auth/ADCZGQMKKQUGATKWWIXTRODT5KCTLANCNFSM5AZDKM7Q [3] https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 [4] https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email