Re: [COSE] cose-cbor-encoded-cert in DNS?

Robert Moskowitz <rgm-sec@htt-consult.com> Mon, 01 August 2022 13:54 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5497DC13C520 for <cose@ietfa.amsl.com>; Mon, 1 Aug 2022 06:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 hoD_-VJLP-SZ for <cose@ietfa.amsl.com>; Mon, 1 Aug 2022 06:54:28 -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 2D99EC13C51A for <cose@ietf.org>; Mon, 1 Aug 2022 06:54:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4977362569; Mon, 1 Aug 2022 09:53:37 -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 Hp+c0lV8US1S; Mon, 1 Aug 2022 09:53:23 -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 DA367623C1; Mon, 1 Aug 2022 09:53:22 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------T39b00RgYWQOelbl1QzzQ120"
Message-ID: <acbbddc7-67cd-726d-5c5f-03b552ae5461@htt-consult.com>
Date: Mon, 01 Aug 2022 09:54:05 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: Orie Steele <orie@transmute.industries>
Cc: "cose@ietf.org" <cose@ietf.org>
References: <6232ba5d-6a59-ec35-54bf-41de112ecec2@htt-consult.com> <CAN8C-_+CwkShUivm+Nj0xF3BpsNwF=4=puEosR+vLCbJt5U-Xw@mail.gmail.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
In-Reply-To: <CAN8C-_+CwkShUivm+Nj0xF3BpsNwF=4=puEosR+vLCbJt5U-Xw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/_z3zs0Do-2NeXgHBSg39T1DQSy0>
Subject: Re: [COSE] cose-cbor-encoded-cert in DNS?
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2022 13:54:32 -0000


On 8/1/22 09:33, Orie Steele wrote:
> Bob,
>
> Interesting RFCs...
>
> - https://www.iana.org/assignments/cert-rr-types/cert-rr-types.xhtml
> - https://datatracker.ietf.org/doc/html/rfc6698
> - https://www.rfc-editor.org/rfc/rfc4398.html

Very much so.  Also 8005 for HIP has its own RR that uses IPSECKEY to 
represent the public key encoding.

> I am also aware or some "DID Methods" that look similar:
>
> - https://danubetech.github.io/did-method-dns/ (relatively new)
> - https://tools.ietf.org/id/draft-mayrhofer-did-dns-03.html (fairly old)

I stuck with what is in DNS RR.  I have not looked into DID; I have my 
own scheme...

> I am also interested in your motives :)
>
> Are there any systems that are deployed today that look like this?

Check out draft-ietf-drip-registries.

It will be getting a big kick after work last week, including likely 
being split in half, but you can still see our intent.

The DET, which is an Identifier is mapped to an FQDN for DNS lookup.  In 
this FQDN is the Public Key either, or both available via HIP or TLSA 
RR.  Of course for TLSA, we have to stuff it into an ASN.1 OID because 
that is just how it is done...

But also we are putting the HDA's evidence of the UA's DET registration 
into CERT records using the OID Private because that is the only hammer 
to get that nail into the RR.  And for OID, we are using my arc from 
IANA's Enterprise Number.  Eventually we will get a better OID...

But all this just SCREAMS for CBOR support.

Particularly if you want to work within DNS for your stuff here.

Bob


>
> Regards,
>
> OS
>
>
>
> On Sun, Jul 31, 2022 at 7:15 PM Robert Moskowitz 
> <rgm-sec@htt-consult.com> wrote:
>
>     I have really not paid attention over here.  Got other fish to fly
>     for
>     the most part.  But...
>
>     Has there been any discussions of storing these certs in DNS?
>
>     Like in TLSA and CERT RR?
>
>     Any plans to update these two RFCs: 4398 & 6698?
>
>     I have some alterior motives in adding CBOR objects for these RR.
>
>     Bob
>
>     _______________________________________________
>     COSE mailing list
>     COSE@ietf.org
>     https://www.ietf.org/mailman/listinfo/cose
>
>
>
> -- 
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose