[TLS] Why TLSA RR and not CERT RR?
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
Re: [TLS] Why TLSA RR and not CERT RR?
Well, this really isn't a question for the TLS WG as DANE is external to TLS. With that said, ISTM that the primary purpose of DANE is to indicate which certificates are acceptable rather than to convey them, as TLS already knows how to convey them. -Ekr On Sun, Jun 26, 2022 at 5:05 AM Robert Moskowitz 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
Kind of thought so. So where do I ask where CERT records are being used? thanks On 6/26/22 09:22, Eric Rescorla wrote: Well, this really isn't a question for the TLS WG as DANE is external to TLS. With that said, ISTM that the primary purpose of DANE is to indicate which certificates are acceptable rather than to convey them, as TLS already knows how to convey them. -Ekr On Sun, Jun 26, 2022 at 5:05 AM Robert Moskowitz 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
Ah, RFC 6944... Yes, not a TLS issue; did not think it was, directly. But I see. DIG, dig, dig.. On 6/26/22 09:32, Robert Moskowitz wrote: Kind of thought so. So where do I ask where CERT records are being used? thanks On 6/26/22 09:22, Eric Rescorla wrote: Well, this really isn't a question for the TLS WG as DANE is external to TLS. With that said, ISTM that the primary purpose of DANE is to indicate which certificates are acceptable rather than to convey them, as TLS already knows how to convey them. -Ekr On Sun, Jun 26, 2022 at 5:05 AM Robert Moskowitz 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
I'm not aware of any major application which uses CERT records. -Ekr On Sun, Jun 26, 2022 at 6:41 AM Robert Moskowitz wrote: > Ah, RFC 6944... > > Yes, not a TLS issue; did not think it was, directly. But I see. > > DIG, dig, dig.. > > On 6/26/22 09:32, Robert Moskowitz wrote: > > Kind of thought so. > > So where do I ask where CERT records are being used? > > thanks > > On 6/26/22 09:22, Eric Rescorla wrote: > > Well, this really isn't a question for the TLS WG as DANE is external to > TLS. > > With that said, ISTM that the primary purpose of DANE is to indicate which > certificates are acceptable rather than to convey them, as TLS already > knows how to convey them. > > -Ekr > > > On Sun, Jun 26, 2022 at 5:05 AM Robert Moskowitz > 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 >> > > > ___ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
Thanks Eric! I will use them in draft-ietf-drip-registries for our X.509 certs and our 'custom' attestation certs (private OID will be needed). And then the powers-that-be can sort it out as we move forward. But at least this way I can put forth the discussion point and the implementors can proceed with their PoC. And most likely take it to a DNS list. And hall talk at 114! Bob On 6/26/22 16:14, Eric Rescorla wrote: I'm not aware of any major application which uses CERT records. -Ekr On Sun, Jun 26, 2022 at 6:41 AM Robert Moskowitz wrote: Ah, RFC 6944... Yes, not a TLS issue; did not think it was, directly. But I see. DIG, dig, dig.. On 6/26/22 09:32, Robert Moskowitz wrote: Kind of thought so. So where do I ask where CERT records are being used? thanks On 6/26/22 09:22, Eric Rescorla wrote: Well, this really isn't a question for the TLS WG as DANE is external to TLS. With that said, ISTM that the primary purpose of DANE is to indicate which certificates are acceptable rather than to convey them, as TLS already knows how to convey them. -Ekr On Sun, Jun 26, 2022 at 5:05 AM Robert Moskowitz 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
On Sun, Jun 26, 2022 at 04:29:38PM -0400, Robert Moskowitz wrote: > I will use them in draft-ietf-drip-registries for our X.509 certs and > our 'custom' attestation certs (private OID will be needed). And then > the powers-that-be can sort it out as we move forward. Why do the certificates need to be delivered via DNS? Are TLS or DTLS not suitable as protocols between the subject and relying party? What is the management model for these certificates? How will key rollover at the subject be coördinated with changes in the DNS? TLSA records are flexible in that they can specify trust-anchor keys or certificates (typically their digests) as well as EE keys or certificates. Multiple TLSA records can be published at the same RRset, and rollover is facilitated by requiring only one to match. The need to tightly synchronise regular certificate rollovers with DNS changes can be avoided by keeping EE keys stable, or publishing a stable issuer trust-anchor key. Alternatively, one can pre-publish future EE public keys and then use that key in a later certificate rollover if observed in DNS for a sufficient number of TTLs, or else renew the certificate with the extant key. So there are well-understood (if not yet universally practiced) operational practices that enable robust deployments of DANE TLSA. Is there something similar for the proposed use of CERT? Is publication of (often multi-kilobyte) full certificates in DNS a good idea? -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
> On 26 Jun 2022, at 14:32, Robert Moskowitz wrote: > > So where do I ask where CERT records are being used? Maybe in the dnsop WG. Or at the DNS-OARC meeting immediately after IETF114. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
Viktor, thank you for your response. For those uses that are DANE/DANCE/TLS related, TLSA records WILL be used. See draft-moskowitz-drip-secure-nrid-c2 Which I am working on an update to correct some errors and add MAVlink as a message format for NRID. and these TLSA records will be installed? in DNS via draft-ietf-drip-registries (still in need of serious work) But in draft-ietf-drip-auth, we have attestations that are carried in very contrained messages, and there have been various opinions that these should also be in DNS. So how? CERT RR, it seems. And again this will be done in drip-registries. So there is a part of this which is TLS (and IPsec and HIP) and a part which is custom design work to fit into the mandated Unmanned Aircraft comm. Fun to be had. Bob On 6/26/22 16:55, Viktor Dukhovni wrote: On Sun, Jun 26, 2022 at 04:29:38PM -0400, Robert Moskowitz wrote: I will use them in draft-ietf-drip-registries for our X.509 certs and our 'custom' attestation certs (private OID will be needed). And then the powers-that-be can sort it out as we move forward. Why do the certificates need to be delivered via DNS? Are TLS or DTLS not suitable as protocols between the subject and relying party? What is the management model for these certificates? How will key rollover at the subject be coördinated with changes in the DNS? TLSA records are flexible in that they can specify trust-anchor keys or certificates (typically their digests) as well as EE keys or certificates. Multiple TLSA records can be published at the same RRset, and rollover is facilitated by requiring only one to match. The need to tightly synchronise regular certificate rollovers with DNS changes can be avoided by keeping EE keys stable, or publishing a stable issuer trust-anchor key. Alternatively, one can pre-publish future EE public keys and then use that key in a later certificate rollover if observed in DNS for a sufficient number of TTLs, or else renew the certificate with the extant key. So there are well-understood (if not yet universally practiced) operational practices that enable robust deployments of DANE TLSA. Is there something similar for the proposed use of CERT? Is publication of (often multi-kilobyte) full certificates in DNS a good idea? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
On 6/26/22 17:40, Jim Reid wrote: On 26 Jun 2022, at 14:32, Robert Moskowitz wrote: So where do I ask where CERT records are being used? Maybe in the dnsop WG. Or at the DNS-OARC meeting immediately after IETF114. And I am splitting early Friday morning. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
Viktor, One thing I left off is that it is possible that draft-moskowitz-drip-nrid-c2 will be a major use case for DANCE as I have discussed on the DANCE list. The DRIP chairs want to wrap up current work before we tackle phase 2, but I have external players that want PoC for secure nrid NOW. So I keep working on all drafts in parallel. Bob On 6/26/22 16:55, Viktor Dukhovni wrote: On Sun, Jun 26, 2022 at 04:29:38PM -0400, Robert Moskowitz wrote: I will use them in draft-ietf-drip-registries for our X.509 certs and our 'custom' attestation certs (private OID will be needed). And then the powers-that-be can sort it out as we move forward. Why do the certificates need to be delivered via DNS? Are TLS or DTLS not suitable as protocols between the subject and relying party? What is the management model for these certificates? How will key rollover at the subject be coördinated with changes in the DNS? TLSA records are flexible in that they can specify trust-anchor keys or certificates (typically their digests) as well as EE keys or certificates. Multiple TLSA records can be published at the same RRset, and rollover is facilitated by requiring only one to match. The need to tightly synchronise regular certificate rollovers with DNS changes can be avoided by keeping EE keys stable, or publishing a stable issuer trust-anchor key. Alternatively, one can pre-publish future EE public keys and then use that key in a later certificate rollover if observed in DNS for a sufficient number of TTLs, or else renew the certificate with the extant key. So there are well-understood (if not yet universally practiced) operational practices that enable robust deployments of DANE TLSA. Is there something similar for the proposed use of CERT? Is publication of (often multi-kilobyte) full certificates in DNS a good idea? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why TLSA RR and not CERT RR?
It appears that Jim Reid said: > > >> On 26 Jun 2022, at 14:32, Robert Moskowitz wrote: >> >> So where do I ask where CERT records are being used? > >Maybe in the dnsop WG. Or at the DNS-OARC meeting immediately after IETF114. The authors of the CERT RFC are still around. Meybe they'd know. R's, John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
