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

Christian O'Flaherty oflaherty at isoc.org
Tue Jun 25 11:53:26 BRT 2013



> 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.

Si, también puede ser… 

Christian

> 
> 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
>>>>>> 
>>>> 
>> 




More information about the Ietf-lac mailing list