Re: [SCITT] Constraints on unprotected data in receipt...

[Orie Steele <[e-mail]>]

I think Ray is interested in the issuer, not the specific key the issuer is
using... But I could be mistaken.

How do you know a given key was authoritative for an issuer, when the
signature was produced?

In OIDC, you can discover current signing keys, but not previous signing
keys for the authorization server (unless you make the historic keys for
the AS transparent somehow).

Same thing is true of certificates, perhaps review
https://certificate.transparency.dev

The purpose of scitt is to do this for software artifacts, and I think what
we are all slowly learning is that software artifacts include identity and
key material...

- https://www.apple.com/certificateauthority/
- https://www.xda-developers.com/android-14-root-certificates-updatable/
-
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/trusted-root-certification-authorities-certificate-store

The idea behind scitt is that it can be used to secure any opaque content
types, by leveraging the `cty` / `content-type` header property of
cose sign1 envelopes:

https://www.rfc-editor.org/rfc/rfc8152#section-3.1

Here are a few content types related to issuer identity, or establishing it:

- https://www.iana.org/assignments/media-types/application/jwk+json
- https://www.iana.org/assignments/media-types/application/jwk-set+json
-
https://www.iana.org/assignments/media-types/application/pem-certificate-chain
- https://www.iana.org/assignments/media-types/application/pgp-keys
- https://www.iana.org/assignments/media-types/application/pkcs10

Next consider the registration policy for any of these content types might
require the signature to come from a previously accepted key, or with a
chain of trust that terminates in a previously registered key.

The specifics of those policies are out of scope for SCITT, but if your
transparency service is managing binaries for mobile apps, it might be
managing certificates that are authorized for developers.

How you configure your policies, what identity solutions you support, and
what content type you accept for registration is all out of scope for scitt.

The part that is in scope (currently) is the architecture, the signed
statement and transparent statement formats, and the REST API for
interoperability.

Regards,

OS



On Fri, May 12, 2023 at 5:38 AM Hannes Tschofenig <[e-mail]>
wrote:

> Hi Ray,
>
>
> before I share my view I have a few questions
>
>  > The question is: Should the public key appear in the unprotected
> portion of the receipt, or can it be an id of the public key.
>
>
> Which public key are we talking about? The receipt is signed by the
> transparency service. Are you talking about the public key of the
> transparency service? It could also be the public key of the issuer? Or
> both?
>
>
> What do you mean by "id of the public key"? Are you trying to stay that
> there could also be a reference to the public key (in comparison to
> sending the public key directly)?
>
>
> Why would the public key be included in the receipt? Convenience for the
> recipient? Does it need to be the public key? Could be the hash of the
> public key? Could be a certificate or even a certificate chain?
>
>
> Ciao
>
> Hannes
>
>
> --
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>