IETF Logo Mail Archive

[TLS] Why TLSA RR and not CERT RR?

Robert Moskowitz <rgm-sec@htt-consult.com> Sun, 26 June 2022 12:04 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18352C17A75A for <tls@ietfa.amsl.com>; Sun, 26 Jun 2022 05:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAZFJsGGN6CZ for <tls@ietfa.amsl.com>; Sun, 26 Jun 2022 05:04:57 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2202BC157B3B for <tls@ietf.org>; Sun, 26 Jun 2022 05:04:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id AAAC36250B for <tls@ietf.org>; Sun, 26 Jun 2022 08:04:10 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z3tV7FVf2T9P for <tls@ietf.org>; Sun, 26 Jun 2022 08:04:04 -0400 (EDT)
Received: from [192.168.160.11] (unknown [192.168.160.11]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A1A52624D4 for <tls@ietf.org>; Sun, 26 Jun 2022 08:04:01 -0400 (EDT)
Message-ID: <fbd4826a-8604-9170-b7ea-a5ed86ef1462@htt-consult.com>
Date: Sun, 26 Jun 2022 08:04:26 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
From: Robert Moskowitz <rgm-sec@htt-consult.com>
To: tls <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1N5G0kKldGkLAmCTFsyF-2UeZGA>
Subject: [TLS] Why TLSA RR and not CERT RR?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jun 2022 12:04:58 -0000

Recently I have been in a discussion about DNS RR that hold X.509 
certificates.

I am asking this here, as I *Think* there may be some knowledge here 
without me joining other lists...

I was aware of DANE's rfc6698 that holds both X.509 certs or 
SubjectPublicKeyInfo.

But I was pointed at rfc4398  Which does NOT handle 
SubjectPublicKeyInfo, but handles X.509 and other formats.

Interesting that they both end in '98' and this is way after Jon was 
around seeing to how RFC numbers were assigned  :)

What was the deciding point not to use 4398 for DANE?  (and now DANCE)

What is 4398 currently used for?  Why was it not just updated to add 
SubjectPublicKeyInfo rather than add a new RR?

And then there is rfc7250 which references 6698...

Thank you.

v2.23.0 | Report a Bug | By Email