when MASA signs with raw public key, where does it put it?

[mcr]

In some version of my code, I had been putting the RPK into unprotected bucket with key 60299. Why? I have no idea where that number came from, but it's been around in my code for awhile. Probably a private use value, but even that seems wrong.

Where can the MASA put it's raw public key for signing vouchers? If the Registrar does not have it, then it can't verify the Voucher, but maybe it has dubious value anyway. Maybe in the RPK case, this does not matter. (Pledge already has it). Maybe there should be a kid value?

[EskoDijk]

Related question is when signing with MASA's PKIX cert identity: where to put MASA's signing certificate, as in the COSE format this isn't included. My answer to both would be like below:

MASA can definitely include a "kid" field in the Voucher, which is useful ...

• if the MASA knows that the Pledge stores multiple manufacturer trust anchors (CA public keys) inside.
• then "kid" is used to indicate which of those trust anchors to use for verification.
• it avoids the Pledge having to try them all which may cost time/energy.
• note that KID can have any form as determined in a vendor-specific way between MASA and Pledge. E.g. it could be simply an int (0,1,2,3 etc). Although standard forms like short hash may be better for cases where e.g. MASA is outsourced and standard software is used that the vendor can't influence.

In case the Pledge is known to store only 1 trust anchor, then it's not so useful. I noticed we don't have text yet describing this "MASA MAY include kid" situation. (It was in the Thread spec ;-) ) This works in a similar/same way for RPK/cert trust anchors.

So for a Pledge the raw public key itself isn't needed, only a KID to indicate it in very specific cases.

Now the Registrar could also use the same "kid" field to validate the Voucher's signature. However in this case the "kid" generation method needs to be standardized as the Registrar otherwise doesn't know how it was created. And the Registrar would need to receive the MASA's raw public key in an out-of-band manner just like it receives the MASA's (PKIX) signing certificate in an out-of-band way. However 8995 says also:

Registrar evaluation of the voucher itself is purely for transparency and audit purposes to further inform log verification (see Section 5.8.3); therefore, a registrar could accept future voucher formats that are opaque to the registrar.

which implies Registrar needn't always verify the Voucher?

[EskoDijk]

Just a note that Section 9.3 needs text to consider the case of Voucher signing and whether/if/when an x5bag would be needed in the Voucher. My take:

• x5bag SHOULD NOT be included (keep size small) - exception is if the MASA knows the Pledge doesn't pre-store the signing public key/cert , and thus needs to provide a cert or cert chain that links the signing identity/key to the pre-stored Trust Anchor that is inside the Pledge.
• kid : see above comments, mostly not useful - exception case is if Pledge stores multiple MASA/vendor trust anchors and needs to choose between them ; to avoid trial-and-error.

[mcr]

Discussion about how to get MASA signing key in some OOB way that the administrator of a Registrar would ask for. So an administrator could type in, "add manufacturer foo.example", and there would be an https://masa.foo.example/info.json...

This might also be used like: https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-sets https://www.rfc-editor.org/rfc/rfc7517

[EskoDijk]

Note for the record: my previous comment of 2022-06-27 on 'x5bag' and 'kid' is already integrated into the present draft.

@mcr How the Registrar's administrator gets the information on approved MASAs (either certificates or raw pubkeys) and which protocol is used for that, is I believe out of scope of current BRSKI. If so , we don't need to write much on this.

So to answer the original question of this issue, I don't think MASA has to put the (raw) signing pubkey anywhere in the constrained Voucher. Just like it does not include the signing certificate in the constrained Voucher.

[mcr]

@mcr How the Registrar's administrator gets the information on approved MASAs (either certificates or raw pubkeys) and which protocol is used for that, is I believe out of scope of current BRSKI. If so , we don't need to write much on this.

Yes, I agree. That's not to say that some kind of standard way to communicate this info via sales channel/email wouldn't be welcome.

So to answer the original question of this issue, I don't think MASA has to put the (raw) signing pubkey anywhere in the constrained Voucher. Just like it does not include the signing certificate in the constrained Voucher.

It sure makes it hard to write a promiscuous registrar without a key to verify things. What about if we specified a way to find the key in DNS?

[EskoDijk]

It sure makes it hard to write a promiscuous registrar without a key to verify things.

I don't see a problem here because

• the Pledge always identifies itself using a IDevID certificate in the handshake (even a Pledge that only supports RPK)
• so the Registrar can identify the Manufacturer's CA that signed this cert in the usual way (e.g. because that CA is part of PKIX or because it obtained the CA cert via an out of band method a list of Manufacturer CAs to trust - the authorityKeyIdentifier is going to match one of the certs of the list)
• the Registrar connects to the MASA using the MASA URI so it knows it's securely talking to the right server / manufacturer.
• the Pledge would anyway reject the Voucher if it came from the wrong server / manufacturer
• RFC 8995 doesn't require the Registrar to do any checking - it even says the Voucher format may be opaque to the Registrar e.g. a future format that the Registrar doesn't know about.
  • Section 5.6 of 8995 doesn't say that the Registrar should verify the Voucher's signature.

[mcr]

It sure makes it hard to write a promiscuous registrar without a key to verify things.

I don't see a problem here because

• the Pledge always identifies itself using a IDevID certificate in the handshake (even a Pledge that only supports RPK)

That certificate, and the chain that leads up from it might have no relationship to the EE identity that the MASA uses to sign the voucher. It could be anchored to the same CA (in a different branch) or it might be a totally different CA. It could also be a raw signature too.

• the Registrar connects to the MASA using the MASA URI so it knows it's securely talking to the right server / manufacturer.

Yes, but the MASA might be identified by arbitrary WebPKI anchor that has nothing to do with signatures on vouchers.

• the Pledge would anyway reject the Voucher if it came from the wrong server / manufacturer

yes, that's true.

• RFC 8995 doesn't require the Registrar to do any checking - it even says the Voucher format may be opaque to the Registrar e.g. a future format that the Registrar doesn't know about.

  • Section 5.6 of 8995 doesn't say that the Registrar should verify the Voucher's signature.

Agreed, it's not required, but it sure is NICE for an audit trail.

[EskoDijk]

Yes, for auditing purposes (including checking of the signature) there is a clear problem with the "potentially missing signer identity" i.e. knowing at minimum the public key of the signer, and ideally a bit more (e.g. a certificate chain associated with the signer if it has one.)

This issue is not specific to RPK, same problem when MASA signs with a certificate-based identity but this identity differs from whatever the Registrar learns via other paths. This issue is specific to constrained-voucher which omits the cert chain from the Voucher.

There are various solutions for this issue if we want to solve it;

A) require the MASA to supply the signing key/cert in an out of band manner to the customer IF it signs with a key that the customer cannot know otherwise. In this case a vendor that doesn't provide any sales integration with its end customer, just needs to make sure that its MASA will sign with the same CA identity that the Pledge identities itself with.

B) use unsecured 'x5bag' attribute in the Voucher to store entire MASA signer's chain. This is then stripped off by a Registrar who wants to reduce traffic. A protected 'x5bag' attribute in the Voucher is of course left untouched - this is one the Pledge may use in rare cases as we define in our draft.

C) define a new HTTPS / REST resource at the MASA that Registrar can use to request the signing cert chain or RPK that the MASA will use for this particular Pledge. So Registrar can get the info without burdening the Voucher with it.

Note that C) could be left entirely as future work, while A) and B) will require some wording already in the present draft to ensure forward compatibility if we define such solution in the future in more detail.

[mcr]

D) define a multipart/ reply that has voucher and cert chain in a different part. (C) would work for me, I'm squeamish about modifying the voucher to remove x5bag, but it could work.

[EskoDijk]

(C) is also optional for the Registrar to perform and doesn't mess with the Voucher, so overall a good solution.

For products that have the 'sales integration' with the end customer it is still an option that the vendor sends its MASA CA certificate, and Pledge identities (IDevID/serial), the MASA's signing cert if any and the public (RPK) signing key that the MASA will use, all to the customer. Then the Registrar can verify Voucher signature already without doing the option C) REST call.

Do we want to leave (C) as future work - or define a solution in the present draft? It would fit in this draft because the issues comes from using the COSE_Sign1 structure which doesn't include the signing cert/key inside. We could label this issue 'future' if we decide to postpone it since the "typical" deployments are not affected. E.g. normally I would expect the MASA CA (i.e. the private key thereof) to be the signer of Vouchers which is a supposedly known entity for the Registrar.

[mcr]

Esko Dijk @.***> wrote:

(C) is also optional for the Registrar to perform and doesn't mess with the Voucher, so overall a good solution.

Do we want to leave (C) as future work - or define a solution in the present draft? It would fit in this draft because the issues comes from using the COSE_Sign1 structure which doesn't include the signing cert/key inside.

Let's hack up some text this late afternoon during the hackathon, if you are here, or in the pub during the week.

[EskoDijk]

@mcr I did some reconsideration of all options; and the below option seems attractive:

(E) include the full RPK in the "rpk" COSE header parameter in the unprotected bucket.

Using "kid" is not quite right because it's intended for another purpose and might be already in use for some use cases as described in our draft. If the registrar gets the full RPK in a standard format in the "rpk" parameter, then it can easily verify it (signature) or look up the RPK in a list of RPKs if it has that.

Because "rpk" is in the unprotected bucket, the Registrar can easily strip it out to save space and the voucher signature is unaffected, before sending it on to the Pledge. The Pledge doesn't ever need "rpk" because it either uses its builtin trusted key to verify, or in rare cases if multiple keys are present it looks up the right key using the "kid" field.

It should be easy to get an assigment here: https://www.iana.org/assignments/cose/cose.xhtml#header-parameters

there's plenty of free namespace for COSE parameters. Value type is 'bstr'. Format can be exactly like 'pinned-domain-pubk' and 'proximity-registrar-pubk' fields i.e. the key and associated algorithm information.

[mcr]

@mcr to provide pull request.