search

cose-wg / CBOR-certificates

Other
9 stars 7 forks source link

Storing C509 certificates in DNS, using DANE: add new IANA consideration #104

Open highlunder opened 1 year ago

highlunder commented 1 year ago

DNS could be used to store C509 certificates, using DANE:

The DANE RR (TLSA) has four semantics for the "Certificate Usage Field", see section 2.1.1 of RFC6698, https://www.rfc-editor.org/rfc/rfc6698

To include C509 as an accepted format, a new selector value should be added, as an IANA consideration in the current draft.

See also "[COSE] Comments about draft-ietf-cose-cbor-encoded-cert" from 2022-11-08

highlunder commented 1 year ago

The comment from mcr was:

I think that Bob wants to store C509 certificates in DNS, using DANE. The DANE RR (TLSA) has four semantics for the "Certificate Usage Field" (see section 2.1.1 of RFC6698).

The stuff inside the RR is either an X.509 format certificate, or it may be a SubjectPublicKeyInfo (RPK), or a SHA-256/512 of the above.

I think that Bob is asking if we should have a new Selector value for C509. That would be IANA Considerations work that cose-cbor-encode-cert would do, much like it does the TLS Certificates Types Registry. (That field is Specification Required, so our document would be enough)

highlunder commented 1 year ago

Status: Göran and John to bring up in discussions with Robert Moskowitz to clarify

gselander commented 10 months ago

Is this just a matter of a value for C509 in the TLSA Selectors registry?

https://www.iana.org/assignments/dane-parameters/dane-parameters.xhtml#selectors

bellebaum commented 8 months ago

@gselander Not quite. The quote from RFC 6698, section 2.1.1:

The certificate usages defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding [X.690]. If TLS allows other formats later, or if extensions to this RRtype are made that accept other formats for certificates, those certificates will need their own certificate usage values.

There are probably some interesting interactions between the formats, given that you can convert between them without changing the signature. This will require a sentence or two of clarifications on how to interpret the above quote, I guess. Maybe even referencing RFC 6698 as being updated by this draft to lessen the restriction?