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

On 8/1/22 10:29, Göran Selander wrote:
>
> 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 X509in 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).
>

And something like OID Private for CBOR Attestations and Evidence 
structures.  Why stick it on a string which happens to be an OID becuase 
that is the only option?

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