#142: Specify what TLS clients should send in the extension_data of the transparency_info TLS extension
Comment (by [email protected]): Advice obtained from exchange with Adam Langley: - The server doesn't have much control over which logs it has SCTs from so it may not be entirely useful to specify them. - Because we aren't certain what we'll need we'll just be building an extension-within-extension mechanism, might as well use the existing TLS extensions mechanism. - Specifying that the client sends nothing but the server does not reject non-empty extension_data, but, because we won't be using it initially, "it might get bug-rusted before you can use it". So the conclusion is we leave the extension data empty, which simplifies the protocol but does not prevent us from sending additional data in the future using a different TLS extension. -- --------------------------------------+------------------------------- Reporter: [email protected] | Owner: [email protected] Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------- Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/142#comment:2> trans <https://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
