IETF Logo Mail Archive

Re: [TLS] Why TLSA RR and not CERT RR?

Phillip Hallam-Baker <ietf@hallambaker.com> Wed, 13 July 2022 10:38 UTC

Return-Path: <hallam@gmail.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 80F1AC16ECF6 for <tls@ietfa.amsl.com>; Wed, 13 Jul 2022 03:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.408
X-Spam-Level:
X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 t3AhTvzxCCtD for <tls@ietfa.amsl.com>; Wed, 13 Jul 2022 03:38:23 -0700 (PDT)
Received: from mail-oa1-f43.google.com (mail-oa1-f43.google.com [209.85.160.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE04C157B55 for <tls@ietf.org>; Wed, 13 Jul 2022 03:38:23 -0700 (PDT)
Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-10c8e8d973eso11715687fac.5 for <tls@ietf.org>; Wed, 13 Jul 2022 03:38:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8eVyBuKkahiB5ac9wuMFCFIZYfvIWJDPj6QrA8De38c=; b=AIM0CELr15pUHS9fwEO8pwMDA41PTiuU3JGrUVxvrFEpPbiWjfhpTefm+MVAjfjiBV FeOYaQAAdtprlnUZFMdVIm2OjtyBvtf7wO/77oguAa3rVPiinHpdjZ41t9UFy1yv8y2F bolvwmajwELtYDFY/Am79CZwrJ7TloN5XpqbkRLSvxtXmS0hiAHPaV2a8XhGVBI/Yope +Ly+rLi/vR6wqOWZTvPH6tBZuPh2QPFbU/haHuUDyG51KuD94D6RiDN+Etu6T77ykuNI zniKgdBS84tdLBgY59fAzo/+9zrsDL2bHHkm/c3IcQ/0j32g5b5qX+udCnOI75YjPyim 9Yeg==
X-Gm-Message-State: AJIora9oAJ2+U0hTSu2cF7hKVwy8kGyLIzqXHcAwBur+PKidx4vneNP8 vr50EJDcKCqL/nEbd1Y5Q48gq8/2NOVM/lZTO9MVd3+DFu3fiLQw
X-Google-Smtp-Source: AGRyM1uDh3eQKz7HFapo3r309PfFUDWpWh9q7ME1KXB8DcalezS2i5SIlWnUOeCrf89iqgwBy526TYPG0FriXQJYo2g=
X-Received: by 2002:a05:6870:9590:b0:de:27ca:c60c with SMTP id k16-20020a056870959000b000de27cac60cmr4246207oao.108.1657708702518; Wed, 13 Jul 2022 03:38:22 -0700 (PDT)
MIME-Version: 1.0
References: <fbd4826a-8604-9170-b7ea-a5ed86ef1462@htt-consult.com>
In-Reply-To: <fbd4826a-8604-9170-b7ea-a5ed86ef1462@htt-consult.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
Date: Wed, 13 Jul 2022 11:38:11 +0100
Message-ID: <CAMm+Lwgj8kKwh4vPnaLT16O2+s=p0K9qjXb6-VSjM6SPMuK-xw@mail.gmail.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Cc: tls <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005ad4e605e3ad627c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iGDnmkY77BKbHDwQGM31tGg7ckc>
Subject: Re: [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: Wed, 13 Jul 2022 10:38:25 -0000

Going back to the original as I don't think the question was ever answered.

rfc4398 is describing a means of using the DNS as a certificate publication
service. It is a replacement for HTTP or LDAP publication. There is no
semantic associated with publishing the cert in a domain.

rfc6698 enables publication of assertions in the DNS that make specific
claims about the relationship of a certificate to the domain.


These are very separate applications.


On Sun, Jun 26, 2022 at 1:05 PM Robert Moskowitz <rgm-sec@htt-consult.com>
wrote:

> 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.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email