I think that what Nick proposes is consistent with this, and it also matches my preference. Requiring a PSS OID is nice in that it creates a strong constraint.
However, there is a wrinkle. The way you signal support for the signature scheme is through the signature_algorithms extension. If you advertise rsa_pss_pss_*, then that means that you are also indicating support for an end entity certificate with a PSS SPKI. Some certificate validation software hasn't been updated to support that and might choke if they got a PSS SPKI in a certificate. I don't know if we could support RSA without double checking our code. Adding support shouldn't be too hard, and we don't current advertise PSS support, so it's not a complete deal breaker for us, but it's worth highlighting. On Tue, Oct 15, 2019, at 15:58, Russ Housley wrote: > When we were working on RFC 4055, we thought it would be important to > allow a certified RSA public key to be bound to a specific algorithm > (e.g., RSA-PSS or RSA-OAEP). However, in transition, we thought it > would be important for the certified RSA public key to be used with any > of the algorithms (constrained by key usage extension). > > Section 1.2 says: > > The rsaEncryption object identifier continues to identify the subject > public key when the RSA private key owner does not wish to limit the > use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP. > > ... > > When the RSA private key owner wishes to limit the use of the public > key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object > identifier MUST be used in the algorithm field within the subject > public key information ... > > When the RSA private key owner wishes to limit the use of the public > key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object > identifier MUST be used in the algorithm field within the subject > public key information ... > > I would like to continue with the approach. > > Russ > > > > On Oct 15, 2019, at 6:34 PM, Nick Sullivan > > <[email protected]> wrote: > > > > TLSWG, > > > > I'd like some feedback on a potential issue raised by Martin Thomson at the > > last IETF. The question is about the interaction between the SPKI and the > > signature scheme for RSA delegated credentials. The main concern is around > > the interaction between the rsaEncryption OID and the signature scheme, > > specifically PKCS#1v1.5, which we disallow in TLS 1.3 but not explicitly in > > DCs (yet). This issue is tracked on Github as issues/28 > > <https://github.com/tlswg/tls-subcerts/issues/28>. > > > > Given the feedback on Github, I see two main choices to resolve this issue: > > > > 1) Allow RSA Credentials with the rsaEncryption OID in the SPKI to be used > > with the rsa_pss_rsae_* signature schemes, but disallow rsa_pkcs1_* > > signature schemes. > > 2) Forbid RSA Credentials with the rsaEncryption OID (and associated > > signature schemes) and require an RSA PSS OIDs for rsa_pss_pss_* signature > > schemes. > > > > Does anyone have a strong preference for one of these options? > > > > My take: > > The rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to be > > backward-compatible with existing rsaEncryption OID certs while enabling > > RSA-PSS. We don't have this legacy in delegated credentials, so I'm > > inclined to prefer 2). > > > > The only reason I see to go for 1) is the risk of implementation > > difficulties. The RSA PSS OIDs are hard to get right in code. However, > > considering that RSA DCs are unlikely to be widely used in favor of > > elliptic-curve DCs, the implementation risk seems low and restricted to > > implementations who choose to support RSA DCs as an optional feature. > > > > Nick > > > > _______________________________________________ > > TLS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
