Re: [SCITT] SCRAPI: Registration with Proof of Possession

[Orie Steele <[e-mail]>]

I opened a draft PR to SCRAPI to capture some of this, and I have a PoC
implementation of it for SD-JWT that can be adopted for SCITT Signed
Statements.

https://github.com/ietf-scitt/draft-birkholz-scitt-scrapi/pull/9

OS

On Wed, Dec 6, 2023 at 10:50 AM Orie Steele <[e-mail]>
wrote:

> After a chat with Richard Barnes, I think there are a few things happening
> with `cnf` and key binding, that we should probably consider
> independently for scitt:
>
> 1. Registration Policies that require fresh signatures from issuers.
> 2. Registration Policies that require issuer's to commit to a recent tree
> head.
> 3. Registration Policies that require additional context binding and a
> fresh signature from the issuer bound to special context.
>
> 1 and 2 are basically both about "time".
>
> If the Transparency Service does not trust the issuer to be honest about
> time, the transparency service can force the issuer to include a time
> commitment from the transparency service in their registration with binding
> to their confirmation public key.
>
> In the case the "nonce" is a timestamp, the TS rejects key binding tokens
> that are outside some window.
>
> In the case the "nonce" is a recent tree head, the TS rejects key binding
> tokens that are not to a tree head inside some window.
>
> In the case the "nonce" is a "challenge token", the nonce is some special
> context, the TS rejects key binding tokens that lack this special context.
>
> There is an opportunity to make the registration none interactive and one
> shot, assuming the following is acceptable:
>
> 1. The key binding token nonce is a "recent timestamp / tree head"
> 2. The transparency service rejects key binding tokens with nonces that
> are not "recent"
>
> There is an opportunity to make the registration interactive and context
> binding, assuming the following is acceptable:
>
> 1. The transparency service includes specific context the issuer must
> commit to in their "challenge token".
> 2. The issuer uses the challenge token as the nonce in their key binding
> token.
> 3. The transparency service rejects key binding tokens with nonces that
> omit required context
>
> In this second case, imagine a "dynamic registration policy"
>
> Holder (Issuer) asks Verifier (Transparency Service) for a challenge token
> for a Customs Entry for 16056100.
>
> The transparency service knows that animal products require certificates
> to be imported, and issues a challenge token that looks like this:
>
> iss: "https://transparency.example"
> aud: "https://transparency.example"
> iat: ${now}
> exp: ${now + 7 day}
>
> current_tree_head: ... (not all TS are trees)
> current_policy_hash: ... (not all policies are stored in trees)
>
> entry_number: 42
> hts_codes: [ 16056100 ]
>
> The holder starts registering signed statements, each is bound to the same
> "challenge token".
>
> The first signed statement covers a phytosanitary certificate for the sea
> cucumber processing facility.
>
> The regulatory requirements change.
>
> The second signed statement covers the (now required) export certificate
> for sea cucumbers.
>
> The transparency service would normally have rejected the second signed
> statement, but because of the context in the challenge token, the
> transparency service knows that the second signed statement is now actually
> required.
>
> The holder did not need to request a "new challenge token" when the
> regulatory changes happened, and the holder still had to prove
> possession of the public key bound to both certificates ( and these public
> keys are different ).
>
> I chose to make this context scenario about sea cucumbers, but it could
> easily have been about network capable hardware devices that need to comply
> with regulations specific to Radio Antennas and GPUs... In those cases
> there would be firmware certifications required, and compliance
> requirements might change inside the transaction window.
>
> This also solves the problem of forcing the issuer to commit to the
> registration policies as they exist at the time the "challenge token" is
> issued.
>
> The TS can reject registrations that are committing to stale policies, or
> accept registrations that are commiting to stale policies, because the TS
> will know which policies the issuer is committing to by checking the
> challenge token.
>
> In the case that proof of possession is not required, and there is no need
> to commit to policies, the challenge token can be omitted, and the
> registration can proceed exactly as it is specified today.
>
> OS
>
>
>
> On Wed, Dec 6, 2023 at 8:10 AM Orie Steele <[e-mail]>
> wrote:
>
>> Hello Transparency Enthusiasts,
>>
>> There are some artifacts that are meant to be controlled only by specific
>> parties.
>>
>> For example:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
>>
>> When registering a SD-JWT with key binding, the holder (issuer in scitt
>> terminology), needs to demonstrate that they control the public key that is
>> bound to the token using the `cnf` claim.
>>
>> In order to do this, they need to get a nonce from the verifier, and
>> include the nonce in their presentation (registration in scitt terminology).
>>
>> OAuth / OpenID for Connect / Browser APIs have ways to do this, but they
>> each are more complicated than what SCITT needs.
>>
>> In SCITT, we only need the transparency service to offer a "signed
>> challenge" instead of a nonce, and for the holder to sign this challenge so
>> the transparency service (verifier in other terminology), can be convinced
>> that the issuer controls the key bound to the artifact.
>>
>> In reviewing relevant RFCs, I re-read ACME, and there are a lot of
>> excellent ideas in it, many of which are relevant to "DIDs" or proving
>> control of existing identifiers:
>>
>> https://www.rfc-editor.org/rfc/rfc8555.html
>>
>> I built a small PoC that is inspired by ACME, but focused only on
>> delivering this challenge from the verifier to the holder.
>>
>>
>> https://github.com/transmute-industries/dune/blob/ac75ff595ae87f19b3cbef693b3f61ed02b2e845/scripts/present-with-key-binding.sh
>>
>> Although this example uses W3C Verifiable Credentials and SD-JWT / YAML.
>>
>> The same approach works with CBOR and COSE, or SD-CWT:
>> https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/
>>
>> This "dune" prototype was built for
>> https://datatracker.ietf.org/group/spice/about/ ... but it has the same
>> key discovery and identity building blocks as SCRAPI.
>>
>> Specifically, they both use well-known URIs to discover the transparency
>> service's issuer metadata:
>>
>>
>> https://github.com/transmute-industries/dune/blob/ac75ff595ae87f19b3cbef693b3f61ed02b2e845/public/openapi.yml#L20
>>
>> https://github.com/ietf-scitt/draft-birkholz-scitt-scrapi/blob/main/oas/openapi.yml#L21
>>
>> A few questions for the list:
>>
>> - Is this challenge / nonce approach ok? I prefer to not make the
>> verifier be stateful in the way ACME is stateful wrt tokens and key
>> authorizations.
>> - Is registration with pop in scope for SCITT?
>> - Would it be helpful if I were to update dune to support the SCRAPI
>> interfaces, and demonstrate the same things with COSE / CBOR ?
>>
>> Regards,
>>
>> OS
>>
>>
>> --
>>
>>
>> ORIE STEELE
>> Chief Technology Officer
>> www.transmute.industries
>>
>> <https://transmute.industries>
>>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>