On Apr 04, 2014, at 15:47, Geoff Huston <[email protected]> wrote: >> >> The authors of RFC 6487 can speak for themselves, but I think their >> intent was to avoid requests for "vanity names" (CN="Joe's Pizza" >> instead of CN="4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89"), which could >> be construed as eroding claims that the RPKI attests only to things >> like addresses and autonomous system numbers. > > As I recall the discussion at the time was based around a desire to > avoid any implication that the CA was attesting as to the identity of the > subject. i.e. the CA was explicitly not saying that the holder of the public > key was the individual described int subject field (section 4.5 of RFC6487). > > There was also some convenience in using a subject name that was linked > to the subject's public key, in so far as when the subject rolled keys > then the subject would request a new certificate and the issuer would > use a different subject name (section 4.5 once more). > > Geoff
Ah this last part I had glossed over. Would it make sense to have the name that goes in the router certificate then be something like “ROUTER-#-32_bit_BGP_Identifier” where the # gets incremented everytime there’s a new key? For those that love hard coded lengths this might be an issue if the # grows, but is that the only drawback? spt _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
