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

Carlos M. martinez carlosm3011 at gmail.com
Tue Jun 25 11:30:05 BRT 2013


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



More information about the Ietf-lac mailing list