On Fri, Sep 1, 2023 at 11:37 AM Ilari Liusvaara <[email protected]> wrote:
> On Fri, Sep 01, 2023 at 01:12:28AM +0000, Michael Jones wrote: > > I've published > https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-algorithms-01.html > , > > which renames the EdDSA algorithm identifiers by popular acclaim! > > It adds acknowledgements for new contributors. And it adds a "To > > Do" note about key representations. > > What does "key representations" mean exactly? What are the acccepted > keys in COSE_Key and JWK formats (AFAIK, neither COSE or JOSE require > using their key formats)? > > If so, the list seems to be: > > - ESP256 ("ES256" in JOSE): > * JWK with kty="EC", crv="P-256". > * COSE_Key with kty=2, crv=1 > > - ESP384 ("ES384" in JOSE): > * JWK with kty="EC", crv="P-384". > * COSE_Key with kty=2, crv=2 > > - ESP512 ("ES384" in JOSE): > * JWK with kty="EC", crv="P-521". > * COSE_Key with kty=2, crv=3 > > - Ed25519: > * JWK with kty="OKP", crv="Ed25519" > * COSE_Key with kty=1, crv=6 > > - Ed448: > * JWK with kty="OKP", crv="Ed448" > * COSE_Key with kty=1, crv=7 > > > I agree with the examples above. > Then I think the prohibition of polymorphic algorithms should be scoped > on signatures. Perhaps it is intended that things like ECDH-ES are not > polymorphic, but this is not clear. > > Fully specifying signatures is both easy to do (as evidenced by this > draft) and easy to maintain (due to COSE/JOSE having signature > framework, and things not being prone to combinatorial explosions). > Also, in JOSE, signatures were originally fully specified. > > In contrast, fully specifying asymmetric encryption is much more > messy affair: There are no frameworks and things tend to combinatorially > explode. Also, in JOSE asymmetric encryption was not even originally > fully specified. > > I also agree with this comment, however, as you pointed out previously, it's possible someone might attempt a cross curve ECDH operation on curves that share a cofactor... the algorithm restriction would not help protect them in this case, they would have to look at ephemeral keys or kem_id in this case right? Pulling an example from a JWE Header { "alg": "ECDH-ES+A128KW", "enc": "A128GCM", "epk": { "crv": "P-256", "kty": "EC", "x": "4fgWhcMd4ZhjCtLX9tZrwE4OKmEmkMs2_871YoK2JoA", "y": "7RUW8tBaWN0756o2WJVr3qDmENuuwRPmaD1-m-OnmGs" } } Let's ignore "enc" here. If your recipient public key looks like: { "kty": "EC", "crv": "P-256", "x": "mWuLJFCnQFt54rcH57iw60LQQQ6HWOYpBfoZOJ8CH1g", "y": "FTuAjcckOoexVL4fWaOcbjR3M938g6MmoR6JCePRNBE", "use": "enc", "key_ops": [ "deriveBits" ], "alg": "ECDH-ES+A128KW" } This is the "happy case". In the case your recipient public key looks like: { "kty": "OKP", "crv": "X25519", "x": "jfjsSAxJhpkk1M_ydfc9mjxb4i4PQzlUik886dh4H1I" "use": "enc", "key_ops": [ "deriveBits" ], "alg": "ECDH-ES+A128KW" } This is the "sad case". Just for the sake of seeing the opportunity to leverage algorithmic restriction to mitigate the sad case, if the algorithm where "fully specified", it might look something like this: - ECDH-ES+P-256+A128KW - ECDH-ES+X25519+A128KW ^ is this "worth it" ? Do we have cases where cross curve ECDH caused problems that "fully specifying" might have helped mitigate? A quick google search turned up a few potential references worth reviewing: > The JSON Web Algorithm (JWA) ECDH-ES KDF construction does not mix keys into the final shared secret. In key exchange, such mixing could be a bad mistake; whereas here either the receiver public key has to be chosen maliciously or the sender has to be malicious in order to cause problems. In either case, all security evaporates. - https://datatracker.ietf.org/doc/html/rfc8037#section-4 - https://zisc.ethz.ch/wp-content/uploads/2017/02/sanso_jwe.pdf I'm not enough of a crypto expert to fully understand if fully specified ECDH-ES is an improvement or just extra registry entries, for no real value. Perhaps others can comment. OS > > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
