Subject: [TLS] Delegated Credentials Question about PSS

From: Nick Sullivan <[email-masked]>
Date: Tue, 15 Oct 2019 15:34:43 -0700

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Oct 2019 18:58:28 -0400

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=[email-masked]> 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>.
> 
> 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.
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 15 Oct 2019 16:59:59 -0700

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:
>

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 15 Oct 2019 17:13:13 -0700

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 <[email-masked]> 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.
>
> > > 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>.
> > >
> > > 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.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 16 Oct 2019 16:13:08 -0700

On Tue, Oct 15, 2019, at 17:13, Nick Sullivan wrote:
> 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. 

Good point.  But I'm not sure that I'm happy with that property.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 16 Oct 2019 20:32:07 -0700

> Good point.  But I'm not sure that I'm happy with that property.

In TLS 1.3 it seems to have been assumed this wouldn't happen and we could
split signature algorithms from signature algorithms cert.

If that's not actually the case it affects more than just DCs. DCs are a
good way to restore extensibility if there is a problem here, provided we
can come up with a solution.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 22 Oct 2019 09:33:56 +1100

On Thu, Oct 17, 2019, at 14:32, Watson Ladd wrote:
> In TLS 1.3 it seems to have been assumed this wouldn't happen and we 
> could split signature algorithms from signature algorithms cert.
> 
> If that's not actually the case it affects more than just DCs. DCs are 
> a good way to restore extensibility if there is a problem here, 
> provided we can come up with a solution.

Yeah, I think that this is the clincher.

FWIW, in Firefox we have a separation between TLS and the certificate validation logic.  The latter cares about the SPKI of all certificates in the certification path because it applies policy related to choice of keys.  As a result, that code cares about DC also.  So we don't really get to advertise an algorithm until it is supported in both places.  For that reason signature_algorithms_cert, as much as it is intended to address this sort of split, doesn't really help us.

Logically, there is a split between the certification path construction and the policy pieces, and the structure of the code recognizes this, but in practice they are somewhat coupled.

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 24 Oct 2019 14:04:25 -0700

On Mon, Oct 21, 2019 at 3:34 PM Martin Thomson <[email-masked]> wrote:

> FWIW, in Firefox we have a separation between TLS and the certificate
> validation logic.  The latter cares about the SPKI of all certificates in
> the certification path because it applies policy related to choice of
> keys.  As a result, that code cares about DC also.  So we don't really get
> to advertise an algorithm until it is supported in both places.  For that
> reason signature_algorithms_cert, as much as it is intended to address this
> sort of split, doesn't really help us.
>
> Logically, there is a split between the certification path construction
> and the policy pieces, and the structure of the code recognizes this, but
> in practice they are somewhat coupled.
>

This makes sense. In the current text, signature_algorithms_cert only
applies to the cert chain, which is fine. It's slightly annoying that
supporting new SPKIs in DCs makes implementations have to support the new
SPKI in certificates, but it doesn't seem like too big of a deal.

I'd be interested in hearing from other client implementations on this
issue (cc: David Benjamin).