[Ietf-lac] RFC6962: “Certificate Transparency” (era Re: DNS y ccTLD)

[Carlos M. Martinez]

Buen análisis, ¡gracias!

On 6/25/13 12:19 PM, Arturo Servin wrote:
> 
> 
>     No creo que el IETF pudiera hacer un tld sin ICANN, y tambien veo
> dificil tener algo sobre ARPA sin contar con ICANN. Si bien el IETF
> puede definir un TLD nuevo (esto lo pongo en tela de duda) o algo sobre
> .arpa (esto su lo pudiera hacer a traves del IAB pidiendolo a IANA) para
> operar DANE, al final la parte de politicas, quien lo operaria, etc.
> tendria que ir a ICANN.
> 
>     Si bien sobre .arpa podria crear dominios para operacion de algun
> tipo (por ejemplo lo que se esta discutiendo en WEIRDS sobre rdap) al
> final sobre DANE tendria un caracter comercial y no de infraestructura,
> y ahi es donde ICANN tendria que entrar.
> 
> Slds
> as
> 
>    
> On 6/25/13 3:30 PM, Carlos M. martinez wrote:
>> Hola!
>>
>> Estoy de acuerdo que esta interesante tener un dominio con políticas mas
>> estrictas para uso con DANE, mi pregunta venia de porque tenia que ser
>> un TLD y no podia ser algo como 'dane.arpa' o 'tlsa.arpa' o algo asi, y
>> de esa manera evitarse cualquier fricción con ICANN.
>>
>> s2
>>
>> ~C.
>>
>> On 6/25/13 10:21 AM, Christian O'Flaherty wrote:
>>>> No vengo siguiendo la discusión de DANE en profundidad, pero, para que
>>>> necesitan un nuevo TLD ? Podrían crear algo bajo .arpa tranquilamente.
>>> Mi propuesta fue en respuesta al problema que tuvo .biz días atrás
>>> (https://isc.sans.edu/diary/.biz+DNSSEC+DNSKEY+is+Invalid/16046)
>>>
>>> Si tenemos una rama en el árbol de DNS con procedimientos enfocados en
>>> DNSSEC será mas confiable y usable esa información. 
>>>
>>> No es para tomarla en serio… Es solo un ejemplo de mejora (no solución)
>>> que podría aparecer como propuesta en un draft 
>>>
>>> Christian
>>>
>>>> On 6/25/13 10:05 AM, Christian O'Flaherty wrote:
>>>>> Una propuesta para ese WG (el que distribuye certificados vía DNSSEC)
>>>>> puede ser la creación de un nuevo dominio en la raíz (TLD) que exija
>>>>> procedimientos mas seguros en los registres.
>>>>>
>>>>> Será un ejercicio interesante que el IETF pueda crear un TLD sin
>>>>> permiso de ICANN :-)  Hasta podría incluírse que la actualización en
>>>>> la raíz para ese TLD tenga un proceso diferente… (que sea necesario y
>>>>> suficiente un pedido del IETF)
>>>>>
>>>>> Tal vez esa no es una buena idea, pero este tema es un buen ejemplo
>>>>> de: tema importante, no resuelto, discutido actualmente y que está en
>>>>> un buen momento para que los interesados se puedan involucrar
>>>>> (pensando en los estudiantes o docentes que están buscando temas de
>>>>> trabajo).
>>>>>
>>>>> Christian
>>>>>
>>>>> On Jun 25, 2013, at 10:45 AM, "Carlos M. martinez"
>>>>> <carlosm3011 at gmail.com <mailto:carlosm3011 at gmail.com>>
>>>>> wrote:
>>>>>
>>>>>> Jua! O varios otros BTW.
>>>>>>
>>>>>> On 6/25/13 9:26 AM, Arturo Servin wrote:
>>>>>>>   Mientras no tengas tu dominio bajo .biz todo esta bien.
>>>>>>>
>>>>>>> :D
>>>>>>>
>>>>>>>   Lo siento, no lo pude evitar.
>>>>>>>
>>>>>>> Slds
>>>>>>> as
>>>>>>>
>>>>>>> On 6/25/13 2:22 PM, Christian O'Flaherty wrote:
>>>>>>>> Una idea para un próximo artículo del Blog puede ser DANE
>>>>>>>> (https://datatracker.ietf.org/wg/dane/charter/)
>>>>>>>>
>>>>>>>> Me parece una solución mejor que los CA y si empezamos a usarlo
>>>>>>>> afectará mucho el negocio de los certificados.
>>>>>>>>
>>>>>>>> Christian O'Flaherty - oflaherty at isoc.org
>>>>>>>> <mailto:oflaherty at isoc.org> <mailto:oflaherty at isoc.org>
>>>>>>>> Regional Development - Internet Society
>>>>>>>> Skype/Gmail/Yahoo/Hotmail: christian.oflaherty
>>>>>>>> Phone:+1 7034392761 Mobile:+598 98769636
>>>>>>>>
>>>>>>>> On Jun 25, 2013, at 5:36 AM, Arturo Servin <aservin at lacnic.net
>>>>>>>> <mailto:aservin at lacnic.net>
>>>>>>>> <mailto:aservin at lacnic.net>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>  Claro, pero de donde salen esos auditores?
>>>>>>>>>
>>>>>>>>>  Al final creo que caemos en lo mismo, dependemos de que alguna
>>>>>>>>> entidad haga bien su trabajo.
>>>>>>>>>
>>>>>>>>>  La idea parace buena, pero desde mi punto de vista solo cambiamos de
>>>>>>>>> manos el problema, en este caso le delegamos la confianza de la
>>>>>>>>> CA, por
>>>>>>>>> ejemplo a Google. No?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Slds
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>> On 6/24/13 5:03 PM, Hugo Salgado wrote:
>>>>>>>>>> On 06/24/2013 11:57 AM, Arturo Servin wrote:
>>>>>>>>>>>  OK.
>>>>>>>>>>>
>>>>>>>>>>>  Pero, si una CA poco escrupulosa envia el certificado por
>>>>>>>>>>> ejemplo de
>>>>>>>>>>> "gmail" entonces quedamos igual porque en el repositorio habria dos
>>>>>>>>>>> entradas; la de la CA buena y el de la CA poco escrupulosa.
>>>>>>>>>> Supongo que a esa altura sería política del repositorio hacer los
>>>>>>>>>> chequeos antes de entregar el SCT. Y de todas formas, en el esquema
>>>>>>>>>> propuesto, además hay "auditores" externos que son los que están
>>>>>>>>>> verificando en el repositorio que no aparezcan certificados
>>>>>>>>>> ilegítimos.
>>>>>>>>>>
>>>>>>>>>> Saludos,
>>>>>>>>>>
>>>>>>>>>> Hugo
>>>>>>>>>>
>>>>>>>>>> _____________________________________________
>>>>>>>>>> Ietf-lac mailing list
>>>>>>>>>> Ietf-lac at lacnog.org <mailto:Ietf-lac at lacnog.org>
>>>>>>>>>> <mailto:Ietf-lac at lacnog.org>
>>>>>>>>>> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>>>>>>>>>> <mailto:ietf-lac-unsubscribe at lacnog.org>
>>>>>>>>> _____________________________________________
>>>>>>>>> Ietf-lac mailing list
>>>>>>>>> Ietf-lac at lacnog.org <mailto:Ietf-lac at lacnog.org>
>>>>>>>>> <mailto:Ietf-lac at lacnog.org>
>>>>>>>>> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>>>>>>>>> <mailto:ietf-lac-unsubscribe at lacnog.org>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _____________________________________________
>>>>>>> Ietf-lac mailing list
>>>>>>> Ietf-lac at lacnog.org <mailto:Ietf-lac at lacnog.org>
>>>>>>> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>>>>>>>
>