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

Hi Bob,

> But all this just SCREAMS for CBOR support.

About your original question, I’m not aware of any discussions of storing CBOR encoded X509 in DNS, but considering your setting it does make sense. Perhaps initially for the reversible (type 1), and later down the road the natively signed CBOR (type 0).

Göran

From: COSE <cose-bounces@ietf.org> on behalf of Robert Moskowitz <rgm-sec@htt-consult.com>
Date: Monday, 1 August 2022 at 15:54
To: Orie Steele <orie@transmute.industries>
Cc: cose@ietf.org <cose@ietf.org>
Subject: Re: [COSE] cose-cbor-encoded-cert in DNS?

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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-24d5d9a60908d82f&q=1&e=d5a277d2-e58d-448a-a771-0c222822db93&u=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fcert-rr-types%2Fcert-rr-types.xhtml>
- https://datatracker.ietf.org/doc/html/rfc6698
- https://www.rfc-editor.org/rfc/rfc4398.html<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b93db923149bae5e&q=1&e=d5a277d2-e58d-448a-a771-0c222822db93&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc4398.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/ <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3d3fd437ab736efa&q=1&e=d5a277d2-e58d-448a-a771-0c222822db93&u=https%3A%2F%2Fdanubetech.github.io%2Fdid-method-dns%2F> (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<mailto: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<mailto:COSE@ietf.org>
https://www.ietf.org/mailman/listinfo/cose

--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=d5a277d2-e58d-448a-a771-0c222822db93&u=http%3A%2F%2Fwww.transmute.industries%2F>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c169100f194b3f01&q=1&e=d5a277d2-e58d-448a-a771-0c222822db93&u=https%3A%2F%2Fwww.transmute.industries%2F>

_______________________________________________

COSE mailing list

COSE@ietf.org<mailto:COSE@ietf.org>

https://www.ietf.org/mailman/listinfo/cose