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

[Dick Brooks <[e-mail]>]

Orie nailed it. 

 

The CA’s are working on a new revocation process that will revoke a key/certificate if it has been used to sign malware.

This is an improvement over today’s process and is covered in our first use case when we say “and is still valid” when referring to the signing key/cert.

See section 4.9.1:

https://github.com/cabforum/code-signing/pull/17/files#diff-904962f0e52198f4a232d6ef6732d57ccb47433d4bba47b3472d681405360e31

 

A CA MUST revoke a Code Signing Certificate in any of the four circumstances: (1) the Application Software Supplier requests revocation, (2) the subscriber requests revocation, (3) a third party provides information that leads the CA to believe that the certificate is compromised or is being used for Suspect Code, or (4) the CA otherwise decides that the certificate should be revoked. 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

 

From: SCITT <[e-mail]> On Behalf Of Orie Steele
Sent: Friday, May 12, 2023 11:10 AM
To: Hannes Tschofenig <[e-mail]>
Cc: Ray Lutz <[e-mail]>; [e-mail]
Subject: Re: [SCITT] Constraints on unprotected data in receipt...

 

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 <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] <mailto:[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] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/scitt




 

-- 

ORIE STEELE

Chief Technical Officer

www.transmute.industries

 

 <https://www.transmute.industries/>