Re: [TLS] TLS 1.3 certificate delegation?

Peter Sylvester <> Sat, 09 November 2013 09:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5867A11E81BA for <>; Sat, 9 Nov 2013 01:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 12dBdgYvTncq for <>; Sat, 9 Nov 2013 01:55:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6325611E81B8 for <>; Sat, 9 Nov 2013 01:55:14 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 52FD15E05E; Sat, 9 Nov 2013 10:49:42 +0100 (CET)
Received: from [] (unknown []) by (Postfix) with ESMTP id D5B465E04B; Sat, 9 Nov 2013 10:49:41 +0100 (CET)
Message-ID: <>
Date: Sat, 09 Nov 2013 10:55:11 +0100
From: Peter Sylvester <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS 1.3 certificate delegation?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Nov 2013 09:55:19 -0000

On 11/08/2013 05:34 PM, Martin Rex wrote:
> Johannes Merkle wrote:
>>>> FWIW, there's precedent for using new TLS versions to expand the set
>>>> of allowable certificates.  If I"m reading it correctly, TLS 1.2
>>>> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
>>>> will reject those.
>>> TLSv1.1 will certainly not reject those.
>>> It is only rfc4492 that incorrectly alleges that those should be rejected.
>> I think you are wrong: Section 7.4.2 of RFC 4346 states
>>                                Unless otherwise specified, the signing
>>        algorithm for the certificate MUST be the same as the algorithm
>>        for the certificate key.
Taking this out of context is not helpful
The specificatiosn makes staements about what the sender has to
do, not what the receiver has to verify.

7.4.2. Server Certificate

    When this message will be sent:

> The history of this obvious defect starts in rfc2246.

> There exists no such artificial limitation in SSLv3, and when I looked
> at implementations I've been using for interop testing a few
> years ago (Microsoft SChannel, OpenSSL, Firefox), they would
> happily interoperate with an RSA server cert signed by a CA with a
> DSA key.  To me it looks like most implementors were either not
> aware of this bogus, backwards-incompatible requirement,
> or they applied common sense and deliberately ignored it.
What is bogus in restricting a sender to be conservative?
> One can not "violate" rfc2119 Section 6 more than with the above
> statement, so it is null and void.
Be strict in what you send, that's violated by some, be liberal
in what to receive, this enhances interop in some cases.

> Not only is this method "must be the same algorithm" not required
> for interop, it is the the worst possible way to impair interop
> without a cause.NO
Only if a receiver misinterpretes the rulles about what a sender MUST do as
'you have to verify this and reject if you can detect it'. But that is not what
is written.

By default a receiver can accept any kinf of garbage, not verify
signatures, etc.