> > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather > > than a prefix, really that useful? > > > > It seems like something we're likely to need at some point, given that > there's still some diversity in validation methods. But if you're > uncomfortable, I think we can drop it from the CAA PR and handle it later > if it's needed. Sounds good to me.
> > RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific > > prefixes like domain names are still OK. So we could amend the ACME > > specification allowing challenge method names of the form > > "[email protected]", say (this is inspired by SSH capability names). This > > would have utility for vendors both in and outside of the context of > > ACME-CAA. > > > > I think you still run into the "x-" problem here. What happens when " > [email protected]" gets popular enough that "example.com" and "example.net" > also start using it? Then example.com is immortalised in history as a pioneer of that de facto standard - there's no issue here, is there? SSH uses [email protected] identifiers for extensions, but there's no implication that only example.com will implement those extensions, on the contrary. Nor is the XML namespace "http://www.w3.org/1999/xhtml"; is intended to only be used by the W3C. It would be very helpful if you could base comments on the current I-D: https://tools.ietf.org/html/draft-ietf-acme-caa-03 i.e., what diffs would you propose against this I-D? Yours, Hugo Landau _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
