Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.
Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.
Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.
Ai-je écrit qu'il ne fallait pas télécharger et vérifier cette CRL? A
Un utilisateur peut configurer son logiciel de courrier pour télécharger
*la* CRL, mais honnètement, il ne devrait pas le faire.
^^^^^^^^^^^^^^^^^^^^^^^^^^
Ai-je écrit qu'il ne fallait pas télécharger et vérifier cette CRL? A
Un utilisateur peut configurer son logiciel de courrier pour télécharger
*la* CRL, mais honnètement, il ne devrait pas le faire.
^^^^^^^^^^^^^^^^^^^^^^^^^^
Ai-je écrit qu'il ne fallait pas télécharger et vérifier cette CRL? A
Un utilisateur peut configurer son logiciel de courrier pour télécharger
*la* CRL, mais honnètement, il ne devrait pas le faire.
^^^^^^^^^^^^^^^^^^^^^^^^^^
Erwann ABALEA wrote:Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.
Je crois qu'il y a des référence dans les documents de Microsoft comme
quoi leur certificat officiel de code signing est stocké sur hardware.
Erwann ABALEA wrote:
Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.
Je crois qu'il y a des référence dans les documents de Microsoft comme
quoi leur certificat officiel de code signing est stocké sur hardware.
Erwann ABALEA wrote:Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.
Je crois qu'il y a des référence dans les documents de Microsoft comme
quoi leur certificat officiel de code signing est stocké sur hardware.
On Tue, 18 Jan 2005, Christophe HENRY wrote:Pas obligatoirement. Lorsque je publie sur une liste, bien souvent les
lecteurs n'ont que mon adresse de courriel pour le premier contact. Et mon
identité est confondue avec cette adresse, que la signature électronique
(gnupg+thunderbird+enigmail) authentifie par la suite.
Puisque cette adresse email ne fait pas partie des éléments signés, elle
ne peut donc pas être authentifiée. La quantité de spams que je reçois
tous les jours me prouve que je ne peux absolument pas faire confiance à
cette adresse email, d'ailleurs.
Si dans ma clé GnuPG je ne place pas mon adresse email, comment allez-vous
faire le lien? Vous n'aurez que mon identité déclarée.
A mon humble avis, ça dépend du contexte d'utilisation. Si un
interlocuteur que je reconnais fiable (connaissances, language utilisé,
etc.) utilise un certificat gnupg, je saurai que je peux lui faire
confiance.
Tout dépend en fait de la méthode pour relier l'identité au
certificat. Et encore, si tu m'envoies un courriel signé de la sorte
je ferais le lien entre ton adresse de courriel et ton certificat.
Mais si je change d'adresse email mais utilise la même clé, est-ce que
le message devient du même coup invalide? Non, et pourtant les
logiciels actuels, en S/MIME, diront que oui. Mais c'est toujours la
même identité certifiée qui a signé ce message.
Je suis bien d'accord. Les logiciels testent l'adéquation entre l'adresse
de courriel et le certificat pour éviter les usurpations d'identité,
sinon je pourrais envoyer un courriel semblant émaner ""
signé numériquement.
Tu n'auras pas mon état civil, seulement mon identité fiscale. Tu
pourras seulement être certain que tu discutes bien avec l'usager ayant
tel identifiant fiscal (en l'occurrence un morceau du nom, du prénom,
et un numéro). Puisque le notion d'identité au sein de cette AC ne va
pas plus loin, tu ne pourras pas aller plus loin.
D'accord. C'est pour ça que je ne cherche même pas à utiliser ce
certificat-là :-) Il y a des limites à l'usage de ce genre de certificat
qui sont les moyens de reconnaître l'identité d'un interlocuteur.
ne vous inquiétez pas, ce n'est pas possible via Usenet :)
-+-LW in Guide du Neuneu Usenet - Après les mouches, à qui le tour ? -+-
On Tue, 18 Jan 2005, Christophe HENRY wrote:
Pas obligatoirement. Lorsque je publie sur une liste, bien souvent les
lecteurs n'ont que mon adresse de courriel pour le premier contact. Et mon
identité est confondue avec cette adresse, que la signature électronique
(gnupg+thunderbird+enigmail) authentifie par la suite.
Puisque cette adresse email ne fait pas partie des éléments signés, elle
ne peut donc pas être authentifiée. La quantité de spams que je reçois
tous les jours me prouve que je ne peux absolument pas faire confiance à
cette adresse email, d'ailleurs.
Si dans ma clé GnuPG je ne place pas mon adresse email, comment allez-vous
faire le lien? Vous n'aurez que mon identité déclarée.
A mon humble avis, ça dépend du contexte d'utilisation. Si un
interlocuteur que je reconnais fiable (connaissances, language utilisé,
etc.) utilise un certificat gnupg, je saurai que je peux lui faire
confiance.
Tout dépend en fait de la méthode pour relier l'identité au
certificat. Et encore, si tu m'envoies un courriel signé de la sorte
je ferais le lien entre ton adresse de courriel et ton certificat.
Mais si je change d'adresse email mais utilise la même clé, est-ce que
le message devient du même coup invalide? Non, et pourtant les
logiciels actuels, en S/MIME, diront que oui. Mais c'est toujours la
même identité certifiée qui a signé ce message.
Je suis bien d'accord. Les logiciels testent l'adéquation entre l'adresse
de courriel et le certificat pour éviter les usurpations d'identité,
sinon je pourrais envoyer un courriel semblant émaner "j.chir@france.fr"
signé numériquement.
Tu n'auras pas mon état civil, seulement mon identité fiscale. Tu
pourras seulement être certain que tu discutes bien avec l'usager ayant
tel identifiant fiscal (en l'occurrence un morceau du nom, du prénom,
et un numéro). Puisque le notion d'identité au sein de cette AC ne va
pas plus loin, tu ne pourras pas aller plus loin.
D'accord. C'est pour ça que je ne cherche même pas à utiliser ce
certificat-là :-) Il y a des limites à l'usage de ce genre de certificat
qui sont les moyens de reconnaître l'identité d'un interlocuteur.
ne vous inquiétez pas, ce n'est pas possible via Usenet :)
-+-LW in Guide du Neuneu Usenet - Après les mouches, à qui le tour ? -+-
On Tue, 18 Jan 2005, Christophe HENRY wrote:Pas obligatoirement. Lorsque je publie sur une liste, bien souvent les
lecteurs n'ont que mon adresse de courriel pour le premier contact. Et mon
identité est confondue avec cette adresse, que la signature électronique
(gnupg+thunderbird+enigmail) authentifie par la suite.
Puisque cette adresse email ne fait pas partie des éléments signés, elle
ne peut donc pas être authentifiée. La quantité de spams que je reçois
tous les jours me prouve que je ne peux absolument pas faire confiance à
cette adresse email, d'ailleurs.
Si dans ma clé GnuPG je ne place pas mon adresse email, comment allez-vous
faire le lien? Vous n'aurez que mon identité déclarée.
A mon humble avis, ça dépend du contexte d'utilisation. Si un
interlocuteur que je reconnais fiable (connaissances, language utilisé,
etc.) utilise un certificat gnupg, je saurai que je peux lui faire
confiance.
Tout dépend en fait de la méthode pour relier l'identité au
certificat. Et encore, si tu m'envoies un courriel signé de la sorte
je ferais le lien entre ton adresse de courriel et ton certificat.
Mais si je change d'adresse email mais utilise la même clé, est-ce que
le message devient du même coup invalide? Non, et pourtant les
logiciels actuels, en S/MIME, diront que oui. Mais c'est toujours la
même identité certifiée qui a signé ce message.
Je suis bien d'accord. Les logiciels testent l'adéquation entre l'adresse
de courriel et le certificat pour éviter les usurpations d'identité,
sinon je pourrais envoyer un courriel semblant émaner ""
signé numériquement.
Tu n'auras pas mon état civil, seulement mon identité fiscale. Tu
pourras seulement être certain que tu discutes bien avec l'usager ayant
tel identifiant fiscal (en l'occurrence un morceau du nom, du prénom,
et un numéro). Puisque le notion d'identité au sein de cette AC ne va
pas plus loin, tu ne pourras pas aller plus loin.
D'accord. C'est pour ça que je ne cherche même pas à utiliser ce
certificat-là :-) Il y a des limites à l'usage de ce genre de certificat
qui sont les moyens de reconnaître l'identité d'un interlocuteur.
ne vous inquiétez pas, ce n'est pas possible via Usenet :)
-+-LW in Guide du Neuneu Usenet - Après les mouches, à qui le tour ? -+-
A mon humble avis, ça dépend du contexte d'utilisation. Si un
interlocuteur que je reconnais fiable (connaissances, language utilisé,
etc.) utilise un certificat gnupg, je saurai que je peux lui faire
confiance.
Y'a quelque chose que je ne comprend pas, c'est peut-être la fièvre :(
Quand tu reçois un courrier signé par une clé GnuPG que tu connais
(vérification de l'empreinte, poignée de main, toussa) avec dans le
'From:' une adresse email Est-ce que ça te suffit pour
associer cette adresse email à cette identité, de sorte qu'un courrier non
signé arrivant de cette adresse te paraitrait authentique? Pour moi,
clairement non. Et mon utilisation de PGP me dit que non, le message signé
est complètement dissocié de l'enveloppe (email).
Que je fasse confiance à un mail non signé en me basant sur le style de
l'auteur et le contenu du message, c'est une chose. Mais cette confiance
n'est pas aussi forte qu'avec un courrier signé (par une clé dûment
authentifiée, etc). L'adresse email de l'enveloppe n'y change rien, elle
n'ajoute rien non plus.
Ou alors je suis trop naze pour comprendre, et je ferais mieux d'aller au
lit, ce qui est possible...
Je suis bien d'accord. Les logiciels testent l'adéquation entre l'adresse
de courriel et le certificat pour éviter les usurpations d'identité,
sinon je pourrais envoyer un courriel semblant émaner ""
signé numériquement.
Si tu as un certificat valide qui mentionne l'adresse "",
et que cette adresse n'est pas la tienne, il y a un problème. Si ton
certificat mentionne une autre adresse email, et que tu utilises ce compte
mail (j.chir), là encore je ne vois aucun problème, puisque ce qui est
signé, c'est le contenu, pas le contenant. Dans ce cas, le logiciel
devrait clairement indiquer l'identité de celui qui a signé le message,
prioritairement à l'adresse email déclarée dans l'enveloppe.
Dodo maintenant. :(
A mon humble avis, ça dépend du contexte d'utilisation. Si un
interlocuteur que je reconnais fiable (connaissances, language utilisé,
etc.) utilise un certificat gnupg, je saurai que je peux lui faire
confiance.
Y'a quelque chose que je ne comprend pas, c'est peut-être la fièvre :(
Quand tu reçois un courrier signé par une clé GnuPG que tu connais
(vérification de l'empreinte, poignée de main, toussa) avec dans le
'From:' une adresse email toto@coincoin.com. Est-ce que ça te suffit pour
associer cette adresse email à cette identité, de sorte qu'un courrier non
signé arrivant de cette adresse te paraitrait authentique? Pour moi,
clairement non. Et mon utilisation de PGP me dit que non, le message signé
est complètement dissocié de l'enveloppe (email).
Que je fasse confiance à un mail non signé en me basant sur le style de
l'auteur et le contenu du message, c'est une chose. Mais cette confiance
n'est pas aussi forte qu'avec un courrier signé (par une clé dûment
authentifiée, etc). L'adresse email de l'enveloppe n'y change rien, elle
n'ajoute rien non plus.
Ou alors je suis trop naze pour comprendre, et je ferais mieux d'aller au
lit, ce qui est possible...
Je suis bien d'accord. Les logiciels testent l'adéquation entre l'adresse
de courriel et le certificat pour éviter les usurpations d'identité,
sinon je pourrais envoyer un courriel semblant émaner "j.chir@france.fr"
signé numériquement.
Si tu as un certificat valide qui mentionne l'adresse "j.chir@france.fr",
et que cette adresse n'est pas la tienne, il y a un problème. Si ton
certificat mentionne une autre adresse email, et que tu utilises ce compte
mail (j.chir), là encore je ne vois aucun problème, puisque ce qui est
signé, c'est le contenu, pas le contenant. Dans ce cas, le logiciel
devrait clairement indiquer l'identité de celui qui a signé le message,
prioritairement à l'adresse email déclarée dans l'enveloppe.
Dodo maintenant. :(
A mon humble avis, ça dépend du contexte d'utilisation. Si un
interlocuteur que je reconnais fiable (connaissances, language utilisé,
etc.) utilise un certificat gnupg, je saurai que je peux lui faire
confiance.
Y'a quelque chose que je ne comprend pas, c'est peut-être la fièvre :(
Quand tu reçois un courrier signé par une clé GnuPG que tu connais
(vérification de l'empreinte, poignée de main, toussa) avec dans le
'From:' une adresse email Est-ce que ça te suffit pour
associer cette adresse email à cette identité, de sorte qu'un courrier non
signé arrivant de cette adresse te paraitrait authentique? Pour moi,
clairement non. Et mon utilisation de PGP me dit que non, le message signé
est complètement dissocié de l'enveloppe (email).
Que je fasse confiance à un mail non signé en me basant sur le style de
l'auteur et le contenu du message, c'est une chose. Mais cette confiance
n'est pas aussi forte qu'avec un courrier signé (par une clé dûment
authentifiée, etc). L'adresse email de l'enveloppe n'y change rien, elle
n'ajoute rien non plus.
Ou alors je suis trop naze pour comprendre, et je ferais mieux d'aller au
lit, ce qui est possible...
Je suis bien d'accord. Les logiciels testent l'adéquation entre l'adresse
de courriel et le certificat pour éviter les usurpations d'identité,
sinon je pourrais envoyer un courriel semblant émaner ""
signé numériquement.
Si tu as un certificat valide qui mentionne l'adresse "",
et que cette adresse n'est pas la tienne, il y a un problème. Si ton
certificat mentionne une autre adresse email, et que tu utilises ce compte
mail (j.chir), là encore je ne vois aucun problème, puisque ce qui est
signé, c'est le contenu, pas le contenant. Dans ce cas, le logiciel
devrait clairement indiquer l'identité de celui qui a signé le message,
prioritairement à l'adresse email déclarée dans l'enveloppe.
Dodo maintenant. :(
On Wed, 19 Jan 2005, Sylvain wrote:On Tue, 18 Jan 2005, Sylvain wrote:
La norme X.509 ne se réfère pas au PKCS#6, pas besoin. Les extensions des
certificats sont complètement définis dans la norme X.509.
meaningless, autant dire que X509 n'est pas basé sur ASN.1
C'est marrant le nombre de gens qui commentent la X.509 sans l'avoir lue.
X.509 est basée sur ASN.1 (X.208/X.680), explicitement. X.509 est basée
sur DER (X;209/X.690), explicitement. Mais X.509 n'utilise aucune
définition de PKCS#6, et la définition d'une extension X.509 n'est pas la
même qu'un attribut PKCS#6,
de même qu'un certificat X.509v3 n'a pas le
même format qu'un 'ExtendedCertificate' de PKCS#6.
PKCS#6 et X.509v3.
La branche 2.16.840.1.113733 appartient à VeriSign,
c'est acquis depuis le début du thread.
Je ne suis pas certain que tous les lecteurs aient en tête l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.
Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.
On Wed, 19 Jan 2005, Sylvain wrote:
On Tue, 18 Jan 2005, Sylvain wrote:
La norme X.509 ne se réfère pas au PKCS#6, pas besoin. Les extensions des
certificats sont complètement définis dans la norme X.509.
meaningless, autant dire que X509 n'est pas basé sur ASN.1
C'est marrant le nombre de gens qui commentent la X.509 sans l'avoir lue.
X.509 est basée sur ASN.1 (X.208/X.680), explicitement. X.509 est basée
sur DER (X;209/X.690), explicitement. Mais X.509 n'utilise aucune
définition de PKCS#6, et la définition d'une extension X.509 n'est pas la
même qu'un attribut PKCS#6,
de même qu'un certificat X.509v3 n'a pas le
même format qu'un 'ExtendedCertificate' de PKCS#6.
PKCS#6 et X.509v3.
La branche 2.16.840.1.113733 appartient à VeriSign,
c'est acquis depuis le début du thread.
Je ne suis pas certain que tous les lecteurs aient en tête l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.
Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.
On Wed, 19 Jan 2005, Sylvain wrote:On Tue, 18 Jan 2005, Sylvain wrote:
La norme X.509 ne se réfère pas au PKCS#6, pas besoin. Les extensions des
certificats sont complètement définis dans la norme X.509.
meaningless, autant dire que X509 n'est pas basé sur ASN.1
C'est marrant le nombre de gens qui commentent la X.509 sans l'avoir lue.
X.509 est basée sur ASN.1 (X.208/X.680), explicitement. X.509 est basée
sur DER (X;209/X.690), explicitement. Mais X.509 n'utilise aucune
définition de PKCS#6, et la définition d'une extension X.509 n'est pas la
même qu'un attribut PKCS#6,
de même qu'un certificat X.509v3 n'a pas le
même format qu'un 'ExtendedCertificate' de PKCS#6.
PKCS#6 et X.509v3.
La branche 2.16.840.1.113733 appartient à VeriSign,
c'est acquis depuis le début du thread.
Je ne suis pas certain que tous les lecteurs aient en tête l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.
Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.
On Wed, 19 Jan 2005, Sylvain wrote:
btw, j'ai pas pu lire le draft de la v4, z'auriez pas une copie ?
X.509 est basée sur ASN.1 (X.208/X.680), explicitement. X.509 est basée
sur DER (X.209/X.690), explicitement. Mais X.509 n'utilise aucune
définition de PKCS#6, et la définition d'une extension X.509 n'est pas la
même qu'un attribut PKCS#6,
au sens RFC 1422 ?
de même qu'un certificat X.509v3 n'a pas le
même format qu'un 'ExtendedCertificate' de PKCS#6.
forcément puisque le second contient le premier.
le point d'origine était une extension est un OID et une valeur encodé
Je ne suis pas certain que tous les lecteurs aient en tête l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.
donnons leur la clé dans ce cas:
http://www.alvestrand.no/cgi-bin/hta/oidwordsearch/?text=2.16.840.1.113733
On Wed, 19 Jan 2005, Sylvain wrote:
btw, j'ai pas pu lire le draft de la v4, z'auriez pas une copie ?
X.509 est basée sur ASN.1 (X.208/X.680), explicitement. X.509 est basée
sur DER (X.209/X.690), explicitement. Mais X.509 n'utilise aucune
définition de PKCS#6, et la définition d'une extension X.509 n'est pas la
même qu'un attribut PKCS#6,
au sens RFC 1422 ?
de même qu'un certificat X.509v3 n'a pas le
même format qu'un 'ExtendedCertificate' de PKCS#6.
forcément puisque le second contient le premier.
le point d'origine était une extension est un OID et une valeur encodé
Je ne suis pas certain que tous les lecteurs aient en tête l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.
donnons leur la clé dans ce cas:
http://www.alvestrand.no/cgi-bin/hta/oidwordsearch/?text=2.16.840.1.113733
On Wed, 19 Jan 2005, Sylvain wrote:
btw, j'ai pas pu lire le draft de la v4, z'auriez pas une copie ?
X.509 est basée sur ASN.1 (X.208/X.680), explicitement. X.509 est basée
sur DER (X.209/X.690), explicitement. Mais X.509 n'utilise aucune
définition de PKCS#6, et la définition d'une extension X.509 n'est pas la
même qu'un attribut PKCS#6,
au sens RFC 1422 ?
de même qu'un certificat X.509v3 n'a pas le
même format qu'un 'ExtendedCertificate' de PKCS#6.
forcément puisque le second contient le premier.
le point d'origine était une extension est un OID et une valeur encodé
Je ne suis pas certain que tous les lecteurs aient en tête l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.
donnons leur la clé dans ce cas:
http://www.alvestrand.no/cgi-bin/hta/oidwordsearch/?text=2.16.840.1.113733
Je ne suis pas certain que tous les lecteurs aient en tête
l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.
donnons leur la clé dans ce cas:
http://www.alvestrand.no/cgi-bin/hta/oidwordsearch/?text=2.16.840.1.113733
Ou
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=2.16.840.1.113733&action =display
qui même s'il ne semble pas aussi complet sur l'arbre des OID
offre plein
de documentation sur ASN.1, DER, BER, XER, ... Je crois (mais je n'en
suis
pas sûr) que asn1.elibel.tm.fr est un site "officiel" du groupe de
travail
qui fait évoluer ASN.1 et consors. Quelqu'un peut-il
confirmer/infirmer?
Je ne suis pas certain que tous les lecteurs aient en tête
l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.
donnons leur la clé dans ce cas:
http://www.alvestrand.no/cgi-bin/hta/oidwordsearch/?text=2.16.840.1.113733
Ou
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=2.16.840.1.113733&action =display
qui même s'il ne semble pas aussi complet sur l'arbre des OID
offre plein
de documentation sur ASN.1, DER, BER, XER, ... Je crois (mais je n'en
suis
pas sûr) que asn1.elibel.tm.fr est un site "officiel" du groupe de
travail
qui fait évoluer ASN.1 et consors. Quelqu'un peut-il
confirmer/infirmer?
Je ne suis pas certain que tous les lecteurs aient en tête
l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.
donnons leur la clé dans ce cas:
http://www.alvestrand.no/cgi-bin/hta/oidwordsearch/?text=2.16.840.1.113733
Ou
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=2.16.840.1.113733&action =display
qui même s'il ne semble pas aussi complet sur l'arbre des OID
offre plein
de documentation sur ASN.1, DER, BER, XER, ... Je crois (mais je n'en
suis
pas sûr) que asn1.elibel.tm.fr est un site "officiel" du groupe de
travail
qui fait évoluer ASN.1 et consors. Quelqu'un peut-il
confirmer/infirmer?
Erwann ABALEA wrote:
http://www.alvestrand.no/cgi-bin/hta/oidwordsearch/?text=2.16.840.1.113733Ou
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=2.16.840.1.113733&action=display
Le site http://oid.elibel.tm.fr offre à ce jour la description de
72657 OID, soit *19* fois plus que le site d'Alvestrand qui n'est plus
mis à jour depuis longtemps, me semble-t-il.
Erwann ABALEA wrote:
http://www.alvestrand.no/cgi-bin/hta/oidwordsearch/?text=2.16.840.1.113733
Ou
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=2.16.840.1.113733&action=display
Le site http://oid.elibel.tm.fr offre à ce jour la description de
72657 OID, soit *19* fois plus que le site d'Alvestrand qui n'est plus
mis à jour depuis longtemps, me semble-t-il.
Erwann ABALEA wrote:
http://www.alvestrand.no/cgi-bin/hta/oidwordsearch/?text=2.16.840.1.113733Ou
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=2.16.840.1.113733&action=display
Le site http://oid.elibel.tm.fr offre à ce jour la description de
72657 OID, soit *19* fois plus que le site d'Alvestrand qui n'est plus
mis à jour depuis longtemps, me semble-t-il.
Erwann ABALEA wrote:
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=2.16.840.1.113733&action=displayqui même s'il ne semble pas aussi complet sur l'arbre des OID
Le site http://oid.elibel.tm.fr offre à ce jour la description de
72657 OID, soit *19* fois plus que le site d'Alvestrand qui n'est plus
mis à jour depuis longtemps, me semble-t-il. La base d'Harald
Alvestrand a été incluse dans notre site avec son accord (elle
contenait 3781 OID au moment de l'intégration) et quelques erreurs
détectées ont été corrigées.
Tous les OID définis dans tous les RFC d'Internet ont été
automatiquement ajoutés. Tous les OID définis dans toutes les
Recommandations de l'UIT-T ont aussi été saisis. Il resterait à
faire le même travail pour les Normes Internationales de l'ISO.
Il est prévu que ce répertoire d'OID migre sur le site de l'UIT (et
acquiert un caractère plus officiel) avant la fin de cette année.
de site officiel du groupe de travail. Mais ça semble être le seul
site qui rassemble autant d'information sur la technologie ASN.1.
Erwann ABALEA wrote:
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=2.16.840.1.113733&action=display
qui même s'il ne semble pas aussi complet sur l'arbre des OID
Le site http://oid.elibel.tm.fr offre à ce jour la description de
72657 OID, soit *19* fois plus que le site d'Alvestrand qui n'est plus
mis à jour depuis longtemps, me semble-t-il. La base d'Harald
Alvestrand a été incluse dans notre site avec son accord (elle
contenait 3781 OID au moment de l'intégration) et quelques erreurs
détectées ont été corrigées.
Tous les OID définis dans tous les RFC d'Internet ont été
automatiquement ajoutés. Tous les OID définis dans toutes les
Recommandations de l'UIT-T ont aussi été saisis. Il resterait à
faire le même travail pour les Normes Internationales de l'ISO.
Il est prévu que ce répertoire d'OID migre sur le site de l'UIT (et
acquiert un caractère plus officiel) avant la fin de cette année.
de site officiel du groupe de travail. Mais ça semble être le seul
site qui rassemble autant d'information sur la technologie ASN.1.
Erwann ABALEA wrote:
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=2.16.840.1.113733&action=displayqui même s'il ne semble pas aussi complet sur l'arbre des OID
Le site http://oid.elibel.tm.fr offre à ce jour la description de
72657 OID, soit *19* fois plus que le site d'Alvestrand qui n'est plus
mis à jour depuis longtemps, me semble-t-il. La base d'Harald
Alvestrand a été incluse dans notre site avec son accord (elle
contenait 3781 OID au moment de l'intégration) et quelques erreurs
détectées ont été corrigées.
Tous les OID définis dans tous les RFC d'Internet ont été
automatiquement ajoutés. Tous les OID définis dans toutes les
Recommandations de l'UIT-T ont aussi été saisis. Il resterait à
faire le même travail pour les Normes Internationales de l'ISO.
Il est prévu que ce répertoire d'OID migre sur le site de l'UIT (et
acquiert un caractère plus officiel) avant la fin de cette année.
de site officiel du groupe de travail. Mais ça semble être le seul
site qui rassemble autant d'information sur la technologie ASN.1.
