Closed ysknkd closed 1 day ago
No, there are no concerns and your suggestion of changing the order based on the ES algorithm sounds good.
I also noticed a bug in the server code you've pasted above. The server code only checks for ES256 which is not quite correct. That applies to all ES types (ES256, ES384 and ES512).
I'll make the changes in the next couple of days once I catch up with all of my pending stuff since I was on vacation the last couple of weeks.
Thank you very much for resolving the issue.
We're considering migrating from the traditional Athenz format Policy to JWS Policy, but ZpeUpdPolLoader outputs the following error logs at startup:
The cause is that ZpeUpdPolLoader, when reading the JWS Policy, first attempts to verify signatures that are not in P1363 format. https://github.com/AthenZ/athenz/blob/f9f1240a770df867206aa94311e091d7ac49115b/clients/java/zpe/src/main/java/com/yahoo/athenz/zpe/ZpeUpdPolLoader.java#L336-L353
To accurately determine whether a signature is in P1363 format or not, it is necessary to verify the signature, which means two rounds of verification are needed. However, outputting error logs despite normal operation could cause confusion for users.
When zpu requests JWS Policies, it requests signatures in P1363 format, and if the ZTS signing algorithm is ES256, it will sign in P1363 format. https://github.com/AthenZ/athenz/blob/f9f1240a770df867206aa94311e091d7ac49115b/utils/zpe-updater/zpu_client.go#L90-L94 https://github.com/AthenZ/athenz/blob/f9f1240a770df867206aa94311e091d7ac49115b/servers/zts/src/main/java/com/yahoo/athenz/zts/ZTSImpl.java#L1405-L1407
Considering the implementations of zpu and ZTS, if the algorithm in the protected header is ES256, it seems reasonable to first attempt to verify the signature in P1363 format. Are there any concerns regarding this approach?