One may note that no matter what the choice is with respect to RSA, this particular wrinkle also applies more broadly. For example, if a client advertises support for ed25519 in "signature_algorithms" in order to support ed25519 delegated credentials, it should also be prepared to receive an ed25519 certificate.
Nick On Tue, Oct 15, 2019 at 5:00 PM Martin Thomson <m...@lowentropy.net> wrote: > 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 <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 > > > > _______________________________________________ > 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
