Re: [TLS] Draft 18 certificate signature algorithm requirements

[Ilari Liusvaara]

On Thu, Dec 01, 2016 at 04:36:17AM +, Peter Gutmann wrote:
> Viktor Dukhovni  writes:
> 
> >So I'd like to see the text in the first paragraph changed to a SHOULD or 
> >worst-case a qualified "MUST whenever possible".
> 
> Why is that whole thing even there in the first place?  From the previous 
> discussions where this came up, the pretty much universal consensus was that 
> people were ignoring the requirement because it served no obvious purpose 
> but broke interoperability.  Unless you're a server operator that chooses to 
> buy a whole bunch of $995 certs, one per algorithm, from a CA that allows 
> you to choose which algorithm gets used for signing, the whole thing is 
> completely inapplicable.  You send whatever cert chain the CA gave you to 
> the client, and it's up to them to decide whether they want to accept or 
> reject.  What would be lost by simply removing that entire block of text, 
> since it's being ignored by implementers anyway?  The solution is to remove
> it, not to fiddle with it until it becomes a no-op that matches what 
> everyone is doing anyway.

Using algorithms that are supported is kinda important for interop,
since if you send a non-(super-)TA certificate using algorithm the
client doesn't know, it is going to have trouble validating the
chain.

If you are referring to mixing RSA/ECDSA certs in one certificate
chain, that already works fine in TLS-1.2-as-of-spec (unless client
does something crazy[1]). TLS 1.3 removes the options for clients to
be crazy here.


[1] That's related to requirment of matching EE (not any CA) certificate
type and ciphersuite, causing client to be able to trip all sorts of bugs
and edge cases in ciphersuite selection.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Draft 18 certificate signature algorithm requirements

[Viktor Dukhovni]

> On Nov 30, 2016, at 10:51 PM, Eric Rescorla  wrote:
> 
> 
> 
> On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni  
> wrote:
> 
> The current text reads:
> 
>Section 4.4.1.2 ( 
> https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 )
> 
>All certificates provided by the server MUST be signed by a signature
>algorithm that appears in the "signature_algorithms" extension
>provided by the client, if they are able to provide such a chain (see
>Section 4.2.3).  Certificates that are self-signed or certificates
>that are expected to be trust anchors are not validated as part of
>the chain and therefore MAY be signed with any algorithm.
> 
> [...]
> 
> It's "MUST if... ". That's different from SHOULD unless because it
> means that the unless clause is that only reason for violating it, and then
> if that condition obtains it SHOULD do X but could presumably do
> other things.

Yes, I see.  The stretch of text between the "MUST" and the "if" just happened
to overflow my stack limit when I was rereading this today...  Please pardon
the short attention span.  So all is well, unless there is merit it trying
to word-smith the text to bring the "MUST" and "if" closer together

The good new is that the intent is already just right.

> I don't see any difference between "MUST whenever possible"
> and the current language.

Yes, fair enough...

> On a related note, is there in the current draft anything that
> requires ECDSA certificates to bear ECDSA issuer signatures?
> 
> No. Nor has that been true since TLS 1.2. See:
> https://tools.ietf.org/search/rfc5246#section-7.4.2

Great.  Thanks.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls