what are the goals of using raw public keys in constrained-voucher?

[mcr]

1. eliminate PKIX processing and path validation code from the pledge?
2. bootstrap certificate-less BRSKI? (no EST, no CMP, no SCEP)?
3. should we just be opening the door to some new security ecosystem? (Kerberos?)

We agree that we should not be describing this new ecosystem in this document.
"future work" statement.

Should the Registrar explain the bootstrapping goals that it has in the voucher-request?
EST, vs CMP, vs Kerberos, vs?
The pledge would otherwise just try the protocols that it knows, and it would then succeed or fail on its own. This could be based upon the pledge looking at different HTTP/CoAP resources on the Registrar.

Should this be a new extension to BRSKI, which is a new document, not constrained-voucher?

Can we assume that there are pledges supporting more than one kind of enrollment protocol?

[EskoDijk]

further possible goal:
4. reduce the size of the Voucher object (useful in constrained networks)

For example don't include the Registrar cert in the Voucher - the Pledge already has this cert due to the DTLS handshake! - but rather only include the subject public key information of that cert. This could save 100s of bytes. In case the MASA was planning to pin the Registrar identity, the MASA could autonomously decide to pin the Registrar public key i.s.o. the full cert because the MASA knows that the Pledge model xyz can deal with this. Registrar signaling isn't even needed to come to such decision.

(Of course looking at #73 if we add a (future) signaling protocol for Registrar to say what it wants pinned and how, then the MASA would have to honor that request preferably and not make the decision all by itself. But I assume #73 is to be a separate spec.)

In case a raw public key is pinned, I think it is okay if we now limit this (by SHOULD, or MUST) to only to the Registrar's public key (just like written currently in constrained-voucher). In case we go for "SHOULD" here then it implies that a MASA MAY still pin an intermediate CA or a root CA if it really wants to, which should be okay as the Pledge knows how to do the chain validation in that case.

[csosto-pk]

2 and 4 are good reasons imo.

But I don't think we need to be too verbose in the doc about it. Just a brief mention maybe.