En las páginas oficiales del DNI electrónico, los chicos de la Oficina Técnica nos han hecho un regalo: la publicación del Manual de Comandos del DNI electrónico (oficialmente "DNI electrónico: guía de Referencia Técnica").
En dicha publicación se recoge toda la información necesaria para que cualquier desarrollador pueda escribir -por ejemplo- su propia implementación PKCS#11. ¡Incluye incluso anexos con las claves y certificados!
No sólo eso: la "licencia" (aunque ellos prefieren llamarlo "acuerdo" de desarrollo) prácticamente da libertad para copiar, modificar y redistribuir sin limitación. Básicamente se trata de una Creative Commons con atribución de autor, disclaimer, y aviso en caso de modificación.
Es una grandísima noticia...
Pero ahora vienen los peros.
El documento no es público: hay que solicitarlo según un procedimiento que garantiza la identidad del solicitante, así como que sólo lo recibe éste. Básicamente se trata de firmar digitalmente el acuerdo (licencia) de desarrollo y generar y firmar un par de claves que se utilizarán para el envío cifrado del documento
La pregunta inmediata es: ¿Para qué tanta precaución si luego la licencia te permite redistribuir casi sín límites? No tiene mucho sentido... ¿o sí?
Por otro lado, en todo momento se habla de desarrolladores individuales: la licencia explícitamente deja fuera empresas y/o grupos de trabajo. Parece una licencia de desarrollo tipo Apple o Android.
En mi opinión (que puede ser errónea: no tengo todavía los documentos) la única explicación es que los documentos que se envian deben estar personalizados: los certificados y claves del Anexo 3 serían específicos para cada desarrollador, de manera que el código y documentación pudieran ser "rastreados".
Tiene sentido... salvo que no costaría mucho cambiar los certificados y claves personales por los extraídos de los binarios publicados... y la funcionalidad se mantendría. Lo cual nos mete en vericuetos legales que harían las delicias de un abogado con ganas de bronca.
En cualquier caso, tengo ya el documento firmado, las claves generadas, (con el certificado de la FNMT: todavía tengo el DNIe estropeado y la cita para renovar es en Noviembre), y estoy a la espera de que algún experto legal (¿hay algún abogado en la sala?) me diga que no me meto en una ratonera si solicito la documentación.
Y todavía falta por establecer y publicar la política de desarrollo y distribución para empresas y grupos de trabajo...
Lo dicho: en cualquier caso es una muy buena noticia: el código publicado de OpenSC es a día de hoy papel mojado, inútil salvo como documentación. Disponer de un manual de referencia para desarrolladores abre la puerta a poder empezar a pensar en serio en una implementación independiente y sin problemas de licencia (salvo claves... :-)
Juan Antonio
Acciones
jorgealamo11 Octubre 2010 - 4:55pm
Hola Juan Antonio, había escrito una nueva propuesta antes de conocer tu comentario, supongo que se publicará en breve.
Sobre lo que comentas, es cierto que muchas veces no nos "permiten" hacer las cosas de otra manera, aún así, y con ánimo de mejorar, tenemos los ojos puestos en este debate y poco a poco estamos recogiendo vuestras demandas. Creedme que no es fácil convencer de todo lo que nos gustaría hacer desde el punto de vista "linuxero", pero para eso está CENATIC, entre otras cosas. No me canso de repetir que queremos colaborar con la Comunidad porque nosotros también somos Comunidad.
Respecto al tema de las garantías estaríamos encantados con vuestras propuestas, se nos ocurre, tal y como se hace en otras Comunidades, crear un documento de Gobierno de la Comunidad , totalmente consensuado con vosotros, público y abierto, donde se recojan todas estas peticiones y un Mission Statement claro y conciso.
Gracias por tu reflexión.
Un saludo.
Sobre claves
jorgealamo11 Octubre 2010 - 11:10am
Como se podrá entender, nosotros no decidimos cuándo se publican las claves, lo que sí podemos decir es que hemos trabajado para que fuesen públicas y que lo fuesen de una forma legal. El hecho de hacer mención a la publicación de las mismas por nuestra parte es para hacer hincapié en la transparencia por nuestra parte, la cual queremos que esté presente en todo el proceso.
Entendemos vuestras reticencias, de nuevo reitero mi ofrecimiento a trabajar juntos en este proyecto, os tendemos la mano y ponemos a vuestra disposición nuestras herramientas y colaboración.
Un saludo.
Me parece perfecto
anv11 Octubre 2010 - 3:33pm
Me parece perfecto que quieran ayudar en lo posible. Pero yo creo que además de publicar un documento así, ustedes mismos deberían haber hecho llegar a la gente de opensc todo lo necesrio para que trabajaran en el driver. Lo que tienen que entender es que si quieren que la cosa funcione, tienen que dejar que los que llevan el proyecto opensc hagan su trabajo. A ustedes, como responsables del hardware, lo que les corresponde es publicar toda la información necesaria, y si desean una rápida creación del software, enviar a los desarrolladores la información y un hardware con qué hacer pruebas. El grupo de opensc estará feliz de encargarse del resto.
Ni blanco ni negro.
jonsito11 Octubre 2010 - 4:33pm
Alejandro, creo que te estás equivocando de destinatario en tus quejas.
Hasta donde yo sé tanto Cenatic como Inteco, han luchado bastante por el tema DNIe desde el "otro bando". Cierto es que se podían -y debían- hacer las cosas de otra forma, pero hay culpas para repartir a todos. Empezando por nosotros mismos que muchas veces no hacemos sino "gritar" y poner a parir a los demas en cuanto no hacen las cosas como a nosotros nos gusta.
¿Cuantos de los que leen esto han escrito a la DGP solicitando, primero los drivers, luego las claves, y finalmente un cambio de licencia? Posiblemente nos podamos contar con una sola mano
¿Es de recibo que la gente de OpenSC haya tenido que buscar apoyo y asistencia legal fuera de España porque aquí había solo cuatro frikis haciéndoles caso?
¿Cuántos han analizado el código?, ¿cuántos han intentado ver cómo se podía arreglar el desaguisado?
¿Cuántos han tenido en cuenta las implicaciones más allá del código en sí? ¿cuántos han buscado abogados, estudiado las leyes y visto las posibilidades?
Tirar una web abajo es muy fácil. Lo difícil es convencer a los gestores de esa web de que hagan las cosas como deben, especialmente cuando no se quieren convencer y además la ley y el gobierno les protegen. Del mismo modo, lo fácil es protestar y chillar. Lo difícil es trabajar verdaderamente juntos. Ciertamente hay cosas que chirrían, como publicar la documentación (incompleta) como hojas PDF sueltas, o las claves en pdf en lugar de en un fichero "keys.c", o el uso de una licencia que impide el feedback a OpenSC, o.... pero el que esté libre de pecado que tire la primera piedra. (no, el diputado valenciano ese no vale)
A mí no me preocupa quién reciba la subvención (hombre, si cae algo, mejor que mejor :-). Me preocupa más bien que la subvención exista, que haya gente que ha cobrado -y quien ha pagado- lo que no está escrito por este código. Me preocupa que las cosas se han hecho de manera que no es posible un retorno del código a los verdaderos padres de la criatura.
No me importaría alogar el trabajo en la web de Cenatic siempre y cuando pudiera hacerlo con garantías de que el código se integra en OpenSC, y que no va a haber trabas ni técnicas ni legales.
El sitio natural del desarrollo, es evidentemente el site de OpenSC, pero la posibilidad de que un organismo oficial pueda resolver dudas técnicas o legales, o incluso proporcionar infraestructura (pe: tarjetas de prueba) no debe ser desdeñada.
Pero debe existir esa posibilidad. Y las relaciones con OpenSC deben ser claras y fluídas. No se puede presumir de "marco europeo de interoperabilidad" cuando se está bloqueando ésta
En Noviembre se empieza a distribuír el DNI electrónico alemán. Por supuesto, los alemanes ya tienen el driver OpenSC, y ya se están empezando a volcar al repositorio los primeros bytes del código, y hablando de cómo se va a mantener la colaboración a nivel oficial
Joer, no es tan difícil... El repositorio oficial en OpenSC, con una rama de desarrollo en Cenatic, los foros, listas y "servicio técnico" en Cenatic, una licencia dual LGPL(OpenSC)/GPL(todos los demás), y unos cauces de comunicación con OpenSC bien establecidos y engrasados, en lugar de una "oficinatecnica" que la mayor parte de las veces no sabe, no contesta
y a la hora de la subvención a repartir ¿eh? :-), que los pobres maestros de laboratorio también tenemos que comer....
Juan Antonio
Laboratorio DNIe de CENATIC
jorgealamo11 Octubre 2010 - 4:21pm
Hola, dentro de unos días inauguramos el nuevo edificio de CENATIC, en él, disponemos de un laboratorio para el DNIe que ponemos a vuestra disposición. Consta de varios puesto de trabajo totalmente equipados, lectores de distintas marcas, teclados con lectores, etc.
Hemos pensado que podíamos organizar una/s jornada/s sobre el DNIe dedicadas a la Comunidad de desarrollo, en ellas se podría aprovechar para iniciar un diálogo sincero y transparente sobre la evolución de los drivers. Tendríais a vuestra disposición el laboratorio y todo lo necesario para realizar todo tipo de pruebas.
Como todo esto queremos que se haga de forma conjunta os agradecería una respuesta sobre el asunto, y en el caso de que ésta sea afirmativa, que debatamos aquí el esquema de la/s jornadas, participantes, temas de debate, pruebas, etc.
Por supuesto que nuestra intención no es reducirlo a una jornada, esperamos que la primera sea el punto de partida de muchas más.
Quedo a la espera de vuestras noticias.
Saludos.
Me da la risa
jmp711 Octubre 2010 - 10:46am
... "prueba de ello es la RÁPIDA publicación de las claves" ...
Siento meterme tan de golpe, pero es que llevo siguiendo el tema unos meses y me parece bochornoso.
Proyecto openDNIe de CENATIC. Publicación de claves y Comunidad.
jorgealamo4 Octubre 2010 - 9:30am
Hola, en CENATIC también hemos publicado las claves privadas y los comandos APDU en nuestra forja: http://forja.cenatic.es/docman/?group_id=160. En la forja también tenemos el código original liberado por la DGPGC. En el blog http://opendnie.cenatic.es explicamos qué se pretende desde CENATIC con estas acciones.
Esperamos empezar una nueva etapa de colaboración con todos vosotros. Cualquier duda, aportación o comentario será bienvenido. Muchas gracias.
Un saludo.
Jorge Martín
Área de Proyectos de CENATIC
jorge.martin@cenatic.es
No entiendo nada
jonsito4 Octubre 2010 - 10:59am
Jorge:
- Estoy seguro de que sabéis que el código publicado por la DGP no vale de nada en la nueva versión OpenSC-0.12 (y más si tenemos en cuenta los cambios recientes)
- Estoy seguro de que sabéis que en OpenSC hay habierto un repositorio git donde Martin, yo y otros estamos actualizando y adaptando dicho código a OpenSC-0.12
- Estoy seguro de que sabéis tambien que para compilar modulos para el dnie (incluso aunque se trate de módulos dinámicos) ya no se puede hacer de manera independiente, sino que hay que integrar el código con OpenSC y hacer una compilación conjunta
- Estoy también seguro de que sabéis que la intención del equipo de OpenSC es remover a corto plazo la posibilidad de carga dinámica de módulos
- Del mismo modo, la licencia GPL prohibe la integración del código dentro del mainstream de OpenSC. La única solución posible es un fork y publicar una versión alternativa bajo licencia GPL
Todo lo cual me lleva a varias conclusiones:
- O bien estáis planeando un fork del OpenSC oficial
- O bien estáis planeando una implementación alternativa de un PKCS#11 bajo Licencia GPL.. Por cierto ¿sabéis que no se puede enlazar un trabajo no gpl a una biblioteca GPL? ¿quién y como podría utilizar un pkcs#11 GPL alternativo?
- O bien, la DGP va a permitir relicenciar el código bajo LGPL para su integración final con OpenSC (lo que sería la solución obvia y la más sencilla), en cuyo caso sobraría vuestra web
- O bien queréis implementar una versión alternativa de un módulo DNIe LGPL para opensc, de manera independiente al código publicado, en cuyo caso os digo que también estamos trabajando en el tema desde OpenSC
- O bien no entiendo nada
Decís en la web:
Pero esas herramientas ya existen en la web oficial de OpenSC. No solo eso, sino que ya hay trabajos en curso sobre el tema, realizados por el equipo de OpenSC. Y en cualquier caso, mientras no se relicencie el código como LGPL no se puede integrar el trabajo, salvo como fork
De verdad, confieso mi escasa capacidad para encontrar razones a todo ésto.
Una pregunta
anv8 Octubre 2010 - 3:24pm
Una pregunta, con esta publicación ya desaparece el problema de las keys? Podrán incluir keys reales en los fuentes que se distribuyen?
Porque he estado mirando en el repositorio git que mencionas y me parece que no están las claves reales.
Me temo que en OpenSC est'an
jonsito8 Octubre 2010 - 4:52pm
Me temo que en OpenSC est'an como locos preparando la nueva OpenSC-0.12 (antes de ayer sacaron la RC1) Martin no me ha dado permiso de escritura en el git, con lo que mis parches estan "en cola"...
Si alguien est'a interesado, que me avise por correo, y le paso el diff actualizado (y con claves) a la openSC-0.12.0rc1 por emilio a donde guste. No lo quiero publicar (ni en cenatic ni en ning'un sitio), porque habr'ia que hacerlo bajo GPL, y maldita la gracia que me hace el cambio de licencia...
A todo esto. ?alguien ha solicitado y recibido el manual? Porque por m'as direcciones que pruebo, la polic'ia no sabe, no contesta...
(Escribiendo desde mi flamante -pero sin tildes ni e'nes- nuevo tablet android zt-180 )
Finalmente me han respondido...
jonsito8 Octubre 2010 - 10:45pm
... Aunque hubiera sido mejor que nunca lo hubieran hecho.
http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015115...
Siento verguenza ajena por esta situación.
Jamás pensé que un organismo público del Gobierno de España pudiera llegar al
sarcasmo de utilizar una licencia de software libre para -y con la excusa de
la directiva europea de interoperabilidad- llegar a poner trabas a un proyecto
europeo del que se ha estado aprovechando durante dos años....
....y que además es un proyecto de software libre.
Todo lo que se me viene a la cabeza es impublicable
En fin. intentaré este fin de semana sudar la gripe otoñal que me ha caído
(justamente en el puente: no falla una); y luego ya veremos
Traducción
RedDwarf9 Octubre 2010 - 9:09pm
Pues pasando de todo. Lo mejor que podemos hacer es traducir https://www.tractis.com/ManualComandosDNIe y enviarlo a la lista de OpenSC. OpenOffice.org puede importar PDFs... hay alguien que se haya puesto a ello?
Traduciendo no, pero lo que es codificando...
jonsito10 Octubre 2010 - 3:21am
Estoy matando la gripe a golpe de tecla. Y funciona:
Visto en conjunto, al final va a ser una ventaja el tener que escribir el driver, una vez que ya tenemos (espero) toda la documentación. Porque el driver de la DGP fué escrito hace más de dos años, para una versión de OpenSC que ya estaba obsoleta en el momento de escribir el driver...
Por ejemplo: la función match_atr, que en el código de la DGP se "funde" 37 líneas, con el OpenSC moderno la acabo de escribir !en 2 líneas!
Otro ejemplo: como en su origen el driver estaba pensado para ser escrito como módulo, los chicos de la FNMT "tomaron prestadas" muchas funciones que en aquel momento no estaban exportadas por la biblioteca. Las funciones contenidas en los ficheros xxx_standard, no solo no son necesarias, sino que están obsoletas y contienen fallos. Lo mismo se puede decir de las rutinas de compresión de datos, o !incluso del código para el establecimiento del canal seguro!
Y así podría continuar con casi cada función que hay que implementar... y eso sin contar con los errores que he detectado: arrays de estructuras mal terminados , variables sin inicializar, o inicializadas en lugar erróneo, etc,etc,etc...
En resumen: salvo que haya alguna trampa oculta en el S.O. de la tarjeta, somos perfectamente capaces de no solo re-escribir, sino re-implementar completamente el driver sin copiar una sola línea de código de las fuentes de la DGP. No solo eso sino que podemos ampliar la funcionalidad: generar claves, firmar y cifrar con las claves generadas; o por ejemplo conseguir que funcione la firma en firefox (el error está documentado -no por la DGP, claro-) y es resoluble
Voy a hablar con la gente de OpenSC para ver cómo podemos dar vida al repositorio git, y que esté actualizado y sincronizado con el mainstream. Por cierto: voy a sugerir que la licencia sea dual: LGPL para OpenSC... y GPL para todo lo demás. Quien a hierro mata, a hierro muere
Los que no se apunten a codificar... pues a traducir, o a dar publicidad de lo sucedido, o...
Estamos tardando.
Juan Antonio
Ofrecimiento de CENATIC
jorgealamo11 Octubre 2010 - 9:00am
Hola de nuevo, tras leer éstos últimos comentarios, desde CENATIC queremos hacer varias observaciones. En primer lugar, CENATIC no obliga a utilizar un tipo u otro de licencia, de hecho, nuestro trabajo también consiste en asesorar en el licenciamiento a la hora de liberar código, por lo tanto, ponemos a vuestra disposición nuestra asesoría jurídica en el caso de que tengáis alguna duda.
En segundo lugar, os proponemos crear un proyecto nuevo en nuestra forja con el nombre que vosotros decidáis y, por supuesto, con la licencia que estiméis oportuna. Ahí, como sabéis, disponéis de todas las herramientas necesarias para la evolución del driver o su reescritura, foros, listas, subversion, documentación, wiki, bugtracking blog, etc.
Queremos colaborar con vosotros porque también somos parte de la Comunidad, prueba de ello es la rápida publicación de las claves.
Quedamos a la espera de vuestras noticias y posibles dudas.
Un saludo.
Eso de "generar claves"
NrNp10 Octubre 2010 - 11:05pm
Eso de "generar claves" y "cifrar",... lo dirás de broma, ¿verdad? Por que si va en serio sería un cañonazo especialmente poderoso contra la seguridad del DNIe... ¿Acaso sabes algo que no aparece en el manual que han publicado? :-)
no, no es broma
jonsito11 Octubre 2010 - 12:02pm
A base de buscar y buscar, he encontrado referencias a gente que ha conseguido que el dnie pueda generar claves, y hacer un uso limitado de ellas. Al fin y al cabo el DNIe es bastante más estandard de lo que parece.
El propio manual publicado por la DGP dice que es posible... pero tambien dice expresamente que no se pueden generar certificados (salvo los dos que incorpora el documento y que solo se pueden crear en las oficinas de la DGP)
Ignoro el alcance de la funcionalidad, y hasta donde se puede llegar, pero a menos que en esos papers se estén tiranto el moco, se puede.
Lo que me importa de verdad en cuanto a funcionalidades nuevas, es el tema de la firma: el procedimiento descrito por la DGP para el firmado (el standard CWA) , es distinto del implementado en el código publicado, lo que provoca por ejemplo que no funcione bien la firma con firefox en Linux. Las funciones de hash y cifrado que deberían estar codificadas, están puestas a "NULL", y en su lugar hay un código que maneja unas APDU's "9C 58 00..." y "9C 5A 00..." que no corresponden al procedimiento estandard de firma que la propia DGP describe.
Por otro lado, no veo en qué dicha posibilidad significa un cañonazo contra la seguridad del dni... si, puedes tener tus propias claves, pero no puedes ni crear certificados nuevos, ni tocar los ya existentes.
Por cierto: estos enlaces son tanto o más importantes que el propio manual de la DGP.
Sugiero su descarga y estudio :-)
http://www.limited-entropy.com/dnie-device-auth
http://www.limited-entropy.com/dnie-secure-messaging
http://www.limited-entropy.com/dnie-hash-sign
Juan Antonio
traducción
anv10 Octubre 2010 - 1:07pm
Yo puedo traducir el manual. Son 67 páginas así que me llevará algún tiempo. Si hay alguien trabajando en eso que avise para no duplicar esfuerzos.
¿Hay alguna lista donde estén charlando sobre el tema? (aparte de la de opensc). Tal vez deberían crear una lista aunque sea en google.
Si queréis
admin10 Octubre 2010 - 1:14pm
aquí mismo podemos crear de todo, incluido un grupo de trabajo con medios específicos.
Whatever it takes, you've got it!
grupo de trabajo
jonsito10 Octubre 2010 - 1:31pm
En cuanto a lo del repositorio... voy a ver que dicen en OpenSC (aunque me temo que con la release de la 0.12 están más liados que la pata de un romano :-).
Evidentemente, y dado que los de Cenatic se empeñan en que la licencia sea GPL, está claro que no se puede trabajar allí. Por cierto, vi su "stand" en el SIMO.... (bueno, de hecho ví el simo entero... en media hora. Pena de feria)
Estoy escribiendo un pequeño "diario" sobre el código que estoy generando, con comentarios, todo's, documentando las fuentes del código que escribo, analizando el fuente de la DGP... básicamente para que todo quede en claro y documentado, y nadie pueda decir que "hemos copiado"... (aunque la verdad, no es posible copiar: el codigo es demasiado .... digamos antiguo...)
En cuanto a formar un grupo de discusión aquí y un repositorio de traducción y documentación, por mi perfecto. En cuanto al código, hay que esperar respuesta de OpenSC
Juan Antonio
Yo te la explico
serhost24 Octubre 2010 - 1:26pm
Yo te la explico, se llama subvención (hay que justificarla). Y si suena poco educado lo siento, pero es lo que es.
Colaboración con OpenSC
jorgealamo4 Octubre 2010 - 5:49pm
Hola, el código liberado por la DGPGC es una implementación del PKCS#11 a modo de ejemplo, es decir, se considera el código liberado como un banco de prueba, una implementación.
Conocemos el interés de varias empresas e instituciones en el desarrollo de un nuevo PKCS#11 que esté en línea con el paquete oficial de OpenSC, éste sería completamente integrable y compatible con OpenSC.
En cualquier caso, si CENATIC participa en esta iniciativa, será a través de esta Comunidad.
Iremos informado de todo a medida que vayan transcurriendo los acontecimientos, gracias.
Un saludo.
Comentario sobre la licencia
jonsito4 Octubre 2010 - 9:55pm
Una observación: la licencia GPL prohibe el enlazado con código que no sea GPL. Si vais a hacer una biblioteca con dicha licencia, obligaréis a que todo programa que la use sea a su vez GPL. Estoy seguro que las empresas no se van a sentir muy felices con dicha obligación...
De hecho este truco se usa en algunas bibliotecas en las que los desarrolladores no quieren que los clientes finales se "aprovechen" de ellos. En el caso del kernel Linux, el API (las llamadas al sistema) son excluídas de la GPL, de manera que la libc (que es LGPL) pueda enlazarse sin problemas
Si vuestro objetivo es pues tener un repositorio para un desarrollo independiente de una nueva biblioteca pkcs#11, usando como implementación de referencia el código de la DGP, deberíais seriamente considerar un cambio en la licencia del site.
Respuestas
jonsito3 Octubre 2010 - 1:05pm
Tengo que confesar que soy un conspiranoico:
Lo único que está personalizado es el destinatario del documento: las claves son comunes para todos, y además coinciden con las publicadas en los drivers oficiales. Por lo visto la intención de la DGP al especificar el procedimiento de solicitud es poder dar al solicitante la garantía de recibir un documento original y autenticado, en lugar de tener que confiar en lo que se publique por la red.
Me imagino que en breves momentos en KP habrá más información al respecto :-)
Malpensado que es uno. Por una vez me he pasado de frenada.
El documento es ya público y está publicado (y descargado :-)) Es alucinante. Contiene no solo las claves, sino mucha información que antes había que deducir del código fuente. Además proporciona ideas para desarrollos y funcionalidades no contempladas en el driver oficial. No, no se puede leer la huella dactilar ni la foto... ni se podrá (al menos por ahora)
La puerta queda (por fin) abierta a un desarrollo abierto y distinto a los fuentes oficiales. Solo queda por aclarar el status legal del documento para empresas y grupos de trabajo como OpenSC
Ya está publicado en Internet
Almorca3 Octubre 2010 - 1:02pm
Si quieres ver el contenido del manual la gente de Tractis ya lo ha publicado.
Todas las copias del Manual son exactamente iguales
david.blanco3 Octubre 2010 - 12:55pm
Hola Juan Antonio,
Me llamo David Blanco y formo parte del equipo de Tractis (https://www.tractis.com).
En relación a la parte en que comentas:
Desde Tractis nos hicimos la misma pregunta y escribimos al SAC del DNIe (soporte.sacdni@policia.es).
Incluyo su respuesta sobre el contenido personalizado del Manual a continuación:
Respecto a la razón del procedimiento habilitado:
Hemos publicado la versión del Manual que hemos recibido en nuestro blog (http://blog.negonation.com/es/publicacion-del-manual-de-comandos-apdu-de...). Lo comento por si alguien quiere comparar su versión con la nuestra (https://www.tractis.com/ManualComandosDNIe).
Un saludo,
David
Disculpas
admin3 Octubre 2010 - 12:54pm
Por algún error mío esta nota tenía desactivados los comentarios.