The aim of this draft is to document and consolidate current practice. And do so in as simple and straightforward way as possible. Despite RFC7250 existing, current practice is largely x509. So that's the focus/scope of the document.
On Sun, Feb 19, 2023, 4:08 PM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Sun, Feb 19, 2023 at 07:39:18AM -0700, Brian Campbell wrote:
> Thank you James, appreciate you taking the time to review the document.
A quick question about the document. I notice that the certifificate
type is implicitly restricted to x509. This means that there isn't a
way for the proxy to use this header to represent RFC7250 raw public
keys.
Is it intended that a different header be used for that purpose? Or
would it make sense to signal the certificate type value and then the
certificate, allowing other certificate types to be encoded (just as in
the TLS certificate message, after first negotiating the type via a
separate extension)?
--
Viktor.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
