> On Jul 20, 2015, at 11:32 AM, Viktor Dukhovni <[email protected]> wrote: > > On Mon, Jul 20, 2015 at 03:17:17PM +0000, Wiley, Glen wrote: > >> After reading your response it occurs to me that James was suggesting >> adding _at as a label rather than encoding it in the hash - makes >> more sense. > > Specifically: > > <some-local-part-encoding>._at.example.com. IN SMIMEA 3 0 0 > <leaf-certificate> > <some-local-part-encoding>._at.example.com. IN OPENPGPKEY 3 0 0 > <public-keyring> > > are shorter than: > > <some-local-part-encoding>._smimecert.example.com. IN SMIMEA 3 0 0 > <leaf-certificate> > <some-local-part-encoding>._openpgpkey.example.com. IN OPENPGPKEY 3 0 0 > <public-keyring> > > >> Having said that, I still question whether _at really helps much since >> humans aren't likely to read/write the encoded user name. Even if we >> decide to not hash the user name it will need to be encoded because of >> special characters. > > The advantage is for the administrator managing the zone, not the > user querying it, and shorter labels reduce the pressure (if any) > on the combined length limit of 255 for the full qname. > > I can't claim that this is a compelling rationale, but it makes > sense to me.
Another point: the chances that a zone may already want to use ``_at’’ for some other reasons (and thus causing a collision) are higher than the more descriptive ``_openpgpkey,’’ or ``_smimecert’’ labels. As of now, it seems very unlikely (imho) that a zone would already be using those latter labels for something else, but I would hesitate to say the same about the former. Not to mention, being descriptive in our labels could be advantageous for reasons I think I have seen others mention on the list. Eric _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
