> 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
> On 13 Mar 2018, at 14:21, Stephen Farrell wrote:
>
> Just to be clear: I'm still waiting for the chairs and/or
> AD to explain how the proposed discussion of this draft
> is consistent with IETF processes, given the results of
> the discussion in Prague (a very clear lack of consensus
> to ev
> On 19 Mar 2018, at 15:18, Dan Brown wrote:
>
> PS: I never directly worked on enterprise security (usually, I just think
> about the math of basic crypto primitives), but I don't recall hearing about
> such a "visibility" feature in the enterprise security work of colleagues
> (whom I do _
On 8 Nov 2018, at 08:44, Ryan Carboni wrote:
>
> This might be a radical proposal, but maybe the certificate hash could be
> placed in a DNS TXT record.
This is a bad idea.
Overloading TXT records with special semantics rarely, if ever, has a happy
ending. For instance application software wo
I’ve got a few concerns/issues with the document.
1) There probably needs to be clearer guidance about the use cases for this
extension and the trade-offs between TLS clients doing DNSSEC validation for
themselves instead of sending DNS lookups to a validating resolver server. How
does an appli
> On 5 Jul 2017, at 18:12, Viktor Dukhovni wrote:
>
> On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote:
>
>> 1) There probably needs to be clearer guidance about the use cases for
>> this extension and the trade-offs between TLS clients doing DNSSEC
>> val
> On 7 Jul 2017, at 02:47, Shumon Huque wrote:
>
> I assume you're referring to the examples in Appendix D (Test Vectors)?
Yes.
> These are working examples that implementers can test code against. But it
> looks like the testbed involved in these examples uses combined signing keys
> (i.e.
> On 7 Jul 2017, at 16:06, Shumon Huque wrote:
>
> IMO, the real gain from having the client cache data, is that the server
> could then potentially send a much smaller DNSSEC chain. But this requires
> the client to signal what they've cached, and makes the protocol more
> complex. I would p
