Valery Smyslov writes: > > Yes, I think we discussed it, but I think we should really see at > > least one implementation before we pick it as SHOULD+ level... > > > > Has anybody implemented this yet? > > Yes.
Good to know. Do you know if there has been any interoperability tests with it? > > Also as we do say that RSASSA-PSS MUST be implemented, that means > > that every implementation which sends out the > > SIGNATURE_HASH_ALGORITHMS and conforms to this document, must > > support RSASSA-PSS, thus implementations can always use it when > > using RSA keys. > > > > Only reason to support RSASSA-PKCS1-v1.5 is to support RFC7427 > > implementations which are made before this 4307bis document came out, > > and which do not support RSASSA-PSS required here. > > I don't think it is a good idea in general to link support for > RSASSA-PSS with support for RFC7427. However, I don't know a better > solution for now. To provide interoperability we need to pick some signature methods as mandatory to implement for the RFC7427 in the future, and my guess is that it will be RSASSA-PSS. > 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. In general this is not usually a problem, as quite often the initiator has one private key configured, and this is what he will be using for the specific server. I.e., the public key type is known from the configuration. The responder will simply pick the same type of key than the initiator used. I.e., it is not normally question whether the other end implements certain public key method, it is more or less question whther the private / public key will be accepted by the other end in the configuration. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
