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 > <nick=40cloudflare....@dmarc.ietf.org> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
