Hi,
> Has anybody implemented this yet?
Yes.
Good to know. Do you know if there has been any interoperability tests
with it?
We are interoperable with ourselves (not a surprise) and with strongSwan
(no RSASSA-PSS was tested yet though).
I think it is a deficiency of RFC7427 that it only allows to
indicate the list of supported hash functions and doesn't allow to
indicate supported signature formats.
The RFC7427 explains why this is not needed in section 5, and we had
discussion about this when the RFC was being written.
No. it was different discussion. We discussed the situation
when peers have several private keys for different algorithms
(say RSA and ECDSA) and the way they select the proper one.
Now consider the situation when a host has a single key pair for RSA.
However, it can either prepare RSASSA-PKCS1-v1.5 signature
or RSASSA-PSS signature. The problem is that the host
doesn't know if its peer supports RSASSA-PSS or not and RFC7427
doen't allow peers to indicate what formats are supported - only hashes
are exchanged.
In your draft you artificially link Digital Signature auth with
support for RSASSA-PSS, so if you support Digital Signature authentication
them you MUST support RSASSA-PSS. I understand that this is probably
the only possible solution for now, but in general this linkage is not a good
thing.
If tomorrow RSASSA-PSS is updated and a new uncompatible RSASSA-PSSv2
is adopted, then how will the peers indicate that this new format
is supported? We'll have a lot of interoperability issues...
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
