Yubico / java-webauthn-server

Server-side Web Authentication library for Java https://www.w3.org/TR/webauthn/#rp-operations
Other
439 stars 137 forks source link

Signing keys for com.augustcellars.cose:cose-java #348

Closed philsmart closed 4 months ago

philsmart commented 5 months ago

I realise this is perhaps not directly your problem, but webauthn-server-core depends on the com.augustcellars.cose:cose-java library which we are (as probably everyone will) acquiring from Maven Central [1]. For us to use webauthn-server-core we will need to also ship com.augustcellars.cose:cose-java. However, we are currently unable to verify the signing key used in Maven Central belongs to a trustworthy identity without that project publishing their signing key fingerprints [2], and they do not seem to be very active in the last few years. Yubico are particularly strong in this area [3] (which is great, thanks), we [4] are just wondering how you view this situation, and if and how you verify this library.

[1] https://mvnrepository.com/artifact/com.augustcellars.cose/cose-java/1.1.0 [2] https://github.com/cose-wg/COSE-JAVA/issues/113 [3] https://developers.yubico.com/Software_Projects/Software_Signing.html [4] https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/3269918721/Supply+Chain+Defence+for+the+Shibboleth+Java+Products

emlun commented 4 months ago

Hi,

The short answer is that I have looked through the COSE-Java sources at some point to make sure it's not obviously malicious, but we do not routinely re-inspect it. Our releases also don't verify the COSE-Java release signatures since we don't technically redistribute the COSE-Java JARs due to the Maven Central distribution model. For much the same reasons we don't pin a particular COSE-Java version, since that would cause dependency resolution issues downstream. I don't know here to find the public key to verify COSE-Java releases.

However I did, for unrelated reasons, start a little bit towards an effort to eliminate this dependency a while ago; see the wip/eliminate-cose-java branch. The reason for this was mainly that over time we'd ended up using very little of the library, and it didn't seem like much of a stretch to implement the necessary parts (mostly importing public keys into JCA) locally.

Anyway, your issue seems like a good reason to continue that effort and try to drop the dependency. Pre-release 2.6.0-alpha1 did add RegistrationResult.getParsedPublicKey() which exposes COSE.CoseException in the public API, so it's fortunate that we haven't stabilized the 2.6.0 release yet. This would be a breaking change, as any downstream implementations that try to catch this exception would no longer compile, but we can still do it as long as we do it no later than version 2.6.0.

philsmart commented 4 months ago

That would be perfect. It's better (for us) to have fewer individual dependencies to ship. Thanks for looking into it.

philsmart commented 4 months ago

Many thanks again for handling this. Do you know approximately when 2.5.1 will be released?

emlun commented 4 months ago

RC should go up today, then we usually wait about 2 weeks before promoting it to a stable release.

philsmart commented 4 months ago

Excellent. Thank you.

emlun commented 4 months ago

It's not visible in mvnrepository.com search results yet, but release 2.5.1-RC1 is available to build tools now on Maven Central!

philsmart commented 4 months ago

I pulled in version 2.5.1-RC1 and our signature checks are now passing. The dependency on cose-java has been removed. I will update to version 2.5.1 when it becomes available. Thank you.

I will close those now.