Draft: draft-ietf-tls-subcerts

Commentary: Forbid PKC15 in DCs . Should fix Recording the consensus here : 
 TLS 1.3 prohibits the use of PKCSv1.5 signatures , but this does n't really say anything about the situation . A question came up about it . It might help to be explicit . 
 We had some questions about what to do with , which I think all roll up into a different question : what to do about an RSA SPKI . I suspect that RSA is n't going to be part of common configurations , but implementations could still implement this . If someone offers and a PKCSv1.5 SPKI , is it OK ? It seems like it should be by the terms of the spec , but if we require PSS support , why not simply mandate the use of and a PSS SPKI instead ? This has the effect of carrying the constraints on scheme in the SPKI directly , which actually makes the signature scheme redundant ( I think ) , which is nice . The downside is that generating a PSS SPKI is less simple ; I had to write custom code for that case . Narrowing the SPKI to PSS would be nice if people were willing to accept the constraints ( a small increase in size for the SPKI ; code complexity ) . 
 By PKCSv1.5 SPKI do you mean an rsaEncryption OID in the certificate ? 
 If I 'm reading correctly , any rsaEncryption oids for the AlgorithmIdentifier do not restrict the signing algorithm for the RSA key . So I believe it is okay . Currently most people 's rsa certs are signed with rsaEncryptionWithSha256 , so people mostly end up using rsapssrsaesha256 . I do n't think CA 's support generation of pure PSS oids yet fully , so it might be a deployment issue if we enforce a constraint of using rsapsspsssha256 . 
 I 'm not talking about the certificate . As you say , most certificates issued by CAs will use an rsaEncryption OID . I 'm talking specifically about the SPKI we put in the delegated credential . is the code in NSS that creates the SPKI , which I imagine other stacks will have similar constructs for . My guess is that anyone who just calls the " public key to SPKI " function will not get a PSS SPKI ( as defined in ) that has the id - RSASSA - PSS OID and associated RSASSA - PSS - params . 
 Oh I see . Ya That ’s a very interesting question . I have a feeling that treating the constraints differently between Certs and dcs might add more unknown complexities . For example if a clients pki library can only deal with rsae for  but its ssl library can deal with  ( for some reason ) the cert sig  would have to offer only rsae , and the Ssl library can not use dcs . Often the pki and ssl libraries are different ( like in the case of fizz or s2n , not sure about mozpkix ) Are you thinking about this in terms of cleaning up cruft or in terms of adding security ? 
 The most important thing is to be very crisp about what is required . But then yeah , I do n't want cruft , especially when that means more code to carry . I really do n't want to have to support two types of SPKI when there is only one sort of signature we are permitting . 
  at the core of this issue is that there is no separate list for sigalgs for dcs vs certs . You have to have rsae for certs , but if you have them you implicitly allow them for dcs as well . We could have the one off " allowed vs disallowed " list since the problem seems like it 's very RSA specific . The alternative , i.e. the status quo , is to commit to supporting an algorithm you advertise for certs in dcs as well . Maybe taking it to the list . what do you think ? 
 I think this should be taken to the list . It 's a subtle point I do n't quite get .  , are you suggesting these two options ? remove  from the Credential in favor of simply relying on the SPKI to determine the signature scheme explicitly forbid RSA DCs from having PKCSv1.5 as SubjectPublicKeyInfo ? I 'm in favor of explicitly forbidding PKCSv1.5 SKIs and not having to deal with a client that sends rsapssrsae_sha256 as the signature scheme and deciding to use a signature algorithm that is mismatched with the SKI . Of these options , 2 ) seems more similar to what is done in TLS . However , 1 ) seems like it fixes a protocol redundancy at the cost of some code complexity . I 'd lean towards 2 ) , myself . 
 I think the simplest thing to do might be to require the signature_algorithms extension contain the DC 's algorithm , and use rsaEncryption OID in the SPKI as RFC 8446 does for certificates . This way the same code should work for verifying CertificateVerify messages regardless of the presence or absence of the delegated credential and delegated credentials will only be internal to the TLS library , not requiring much to do with PKIX . This may or may not be what meant by not supporting two SPKIs , I 'm not sure I entirely followed that remark . This may need to go to the list , I 'm not sure what happens with RSA DCs in the current implementation : some experimentation may need to happen to figure it out ! 
 Talking to offline , I 'm also in favor of requiring pss oids for DCs . I do n't think it should cause a huge issue . 
 I also feel like I do n't have a firm grasp of the problem . That said , here 's my $ 0.02 : Like says , the intention of the DC spec is that the DC signature algorithm should be the same as the signature algorithm chosen by the server for signing the handshake . My understanding is that TLS 1.3 explicitly forbids using PKCSv1.5 for the handshake signature , so the DC spec would , too . Thus , at a high - level , I 'd opt for whatever option makes preserving this semantics easier . Is the core of the problem is the manner in which the algorithm is selected ? For example , the client might ( a ) choose the algorithm based on the code point in the handshake message ( , if memory serves ) or ( b ) based on the SPKI in the DC . I think option ( a ) is better in terms of cryptographic agility , but I suppose there are times when ( b ) is more convenient . Am I missing something ? Is the issue that the code point in the handshake message does n't fully specify an algorithm ? 
 Considering the subsequent comments , I think I have a cleaner set of options : Allow RSA Credentials with the rsaEncryption OID in the SPKI to be used with the  signature schemes , but disallow rsapkcs1 signature schemes Forbid RSA Credentials with the rsaEncryption OID and require RSA PSS OIDs for rsapsspss signature schemes My sense is that the  _ suites are a hack created for backwards - compatibility with rsaEncryption OID certs . We do n't have this legacy here , so I 'm inclined to prefer 2 ) . The only reason I see to go for 1 ) is because the RSA PSS OIDs are hard to get right in code , but considering that RSA DCs are unlikely to be widely used , I think this is a fine requirement . I 'll take it to the list . 
 Looks good to me .
Mailing list commentary: This makes sense . In the current text , signaturealgorithmscert 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 does n't seem like too big of a deal . I 'd be interested in hearing from other client implementations on this issue ( cc : ) .
Paragraph (version B):
draft-05 * Removed support for PKCS 1.5 RSA signature algorithms.  *
Additional security considerations.
Paragraph (version A):
The signature algorithm of the credential key pair, where the type
SignatureScheme is as defined in RFC8446.  This is expected to be
the same as CertificateVerify.algorithm sent by the server.
Paragraph (version B):
The signature algorithm of the credential key pair, where the type
SignatureScheme is as defined in RFC8446.  This is expected to be
the same as CertificateVerify.algorithm sent by the server.  Only
signature algorithms allowed for use in CertificateVerify messages
are allowed.  When using RSA, the public key MUST NOT use the
rsaEncryption OID, as a result, the following algorithms are not
allowed for use with delegated credentials: rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.
Paragraph (version A):
Verify that expected_cert_verify_algorithm matches the scheme
indicated in the peer's CertificateVerify message.
Paragraph (version B):
Verify that expected_cert_verify_algorithm matches the scheme
indicated in the peer's CertificateVerify message and that the
algorithm is allowed for use with delegated credentials.