From owner-ietf-pkix@mail.imc.org Tue Jun 1 05:31:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09061 for ; Tue, 1 Jun 2004 05:31:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i51847CA061863; Tue, 1 Jun 2004 01:04:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i51847AZ061862; Tue, 1 Jun 2004 01:04:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from avir1.bancsabadell.com (tm01.bancsabadell.com [194.224.15.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i51845ha061790 for ; Tue, 1 Jun 2004 01:04:05 -0700 (PDT) (envelope-from gonzalezcarlos@netfocus.es) Received: from EFYBEM279076 (privadas.nuria.telefonica-data.net [172.18.16.2]) by mail.bancsabadell.com; Tue, 01 Jun 2004 10:00:04 +0200 Reply-To: From: =?iso-8859-1?Q?Carlos_Gonz=E1lez-Cadenas?= To: Subject: questions Date: Tue, 1 Jun 2004 10:02:25 +0200 Organization: NetFocus Message-ID: <000f01c447ae$c6b3a4c0$021012ac@extendforce.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C447BF.8A3C74C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C447BF.8A3C74C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =0D Two questions =0D * It=92s a common practice for a CA to issue different kinds of certificates (i.e. a CA issuing email certificates can issue two certificates, a certificate for signing and another one for encryption (key encipherment). Normally, when people want to differentiate this= certificates sintetically (not looking at the certificate characteristics, but looking= to an OID or similar), they derive the policy under the certificate is issued with an identifier determining the certificate type.=0D =0D Example: The class 2 certificate policy is identified under OID 1.3.6.1.4.1.x.100.2. So, we can obtain two more OIDs for the two different types of certificates 1.3.6.1.4.1.x.100.2.1 for the signing cert 1.3.6.1.4.1.x.100.2.2 for the encryption cert =0D I think using the policies this way we are somewhat perverting the= standard. What we must include in the Certificate Policies (in EE certs) is the= policy under the certificate is issued, not an hybrid between the policy and a qualifier of the certificate. =0D Questions about that: *Is this an ad-hoc standard?? (What=92s your oppinion about that??) *Is there any place (standard one) to include the certificate type OID? *Are there some ideas about this in son-of-3280?? (I wasn=92t able to find nothing comparable to that in 3280). =0D * I=92m trying to configure a hierarchy of tree levels of CAs, plus another level of end entity certificates.=0D =0D I want to maintain compatibility with Certificate Path Validation= algorithms in RFC3280, specially when referring to policy-tree validation. I want to assert that the points stated below are ok,=0D =0D * For the root certificate, no policies at all (it=92s a trust anchor, and by default can issue certificates with any policy).=0D * For the first intermediate certificate (it represents an organization), I must assert the anyPolicy special policy in the= Certificate Policies, if not, the policy tree gets null after evaluating this node.=0D * For the second intermediate certificate (it represents a class CA, issuing certificates under some well-known policies), I include these policies in the Certificate Policies (to restrict the policies that the EE certificates can be issued under).=0D * In the End entity, I include these Policies in the Certificate Policies, to state that the certificate is issued under these policies.=0D =0D Questions, =0D *Is my configuration considered as a =93best practice=94? *What are the possible modifications for a son-of-3280?. This configuration will be affected adversely for that? =0D Thank you very much in advance =0D Carlos =0D =0D Carlos Gonz=E1lez-Cadenas Jefe de Departamento de Arquitectura Software=0D Software Architecture Department Manager Responsable de Seguridad de la Informaci=F3n=0D Information Security Responsible netfocus by Siemens-BancSabadell =0D =0D C/Sena, 12 nucli C planta 2 Edifici Landscape 08190 Sant Cugat del Vall=E8s phone: +34933556139 fax: +34933556142 mailto: gonzalezcarlos@netfocus.es web: www.netfocus.es =0D =0D =0D Advertencia legal: Este mensaje y, en su caso, los ficheros anexos son confidenciales, especialmente en lo que respecta a los datos personales, y se dirigen exclusivamente al destinatario referenciado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o= borrarlo, y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo= pena de incurrir en responsabilidades legales. El emisor no garantiza la= integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. =0D Advertiment legal: Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial, especialment pel que fa a les dades personals, i s'adrecen exclusivament al destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o= se li ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per= aquesta mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui= d'utilitzar, reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no= garanteix la integritat, la rapidesa o la seguretat d'aquest correu, ni es= responsabilitza de possibles perjudicis derivats de la captura, incorporacions de virus o qualsevol altres manipulacions que facin tercers. =0D Disclaimer: This message and any attached files transmitted with it, is confidential, especially as regards personal data. It is intended solely for the use of= the individual or entity to whom it is addressed. If you are not the intended= recipient and have received this information in error or have accessed it for any= reason, please notify us of this fact by email reply and then destroy or delete the= message, refraining from any reproduction, use, alteration, filing or communication= to third parties of this message and attached files on penalty of incurring legal responsibilities. The sender does not guarantee the integrity, the= accuracy, the swift delivery or the security of this email transmission, and assumes no responsibility for any possible damage incurred through data capture, virus incorporation or any manipulation carried out by third parties. ------=_NextPart_000_0010_01C447BF.8A3C74C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

Two questions

 

  • It’s a common practice for a CA to= issue different kinds of certificates (i.e. a CA issuing email certificates= can issue two certificates, a certificate for signing and another one for= encryption (key encipherment). Normally, when people want to differentiate this certificates sintetically (not looking at the certificate= characteristics, but looking to an OID or similar), they derive the policy under the certificate is issued with an identifier determining the certificate= type.

 

Example: The= class 2 certificate policy is identified under OID 1.3.6.1.4.1.x.100.2. So, we can= obtain two more OIDs for the two different types of certificates

1.3.6.1.4.1.x.100.2.1 for the signing cert

1.3.6.1.4.1.x.100.2.2 for the encryption cert

 

I think using the policies this way we are somewhat perverting the standard. What we must= include in the Certificate Policies (in EE certs) is the policy under the= certificate is issued, not an hybrid between the policy and a qualifier of the= certificate.

 

Questions about= that:

*Is this an= ad-hoc standard?? (What’s your oppinion about that??)

*Is there any= place (standard one) to include the certificate type OID?

*Are there some= ideas about this in son-of-3280?? (I wasn’t able to find nothing comparable= to that in 3280).

 

  • I’m trying to configure a hierarchy of tree levels of CAs, plus another level of end entity= certificates.

 

I want to= maintain compatibility with Certificate Path Validation algorithms in RFC3280,= specially when referring to policy-tree validation. I want to assert that the points stated below are ok,

 

    • For the root= certificate, no policies at all (it’s a trust anchor, and by default can issue certificates with any policy).=
    • For the first= intermediate certificate (it represents an organization), I must assert the= anyPolicy special policy in the Certificate Policies, if not, the policy tree= gets null after evaluating this node.=
    • For the second= intermediate certificate (it represents a class CA, issuing certificates under= some well-known policies), I include these policies in  the= Certificate Policies (to restrict the policies that the EE certificates can be= issued under).
    • In the End entity, I= include these Policies in the Certificate Policies, to state that the= certificate is issued under these policies.=

 

Questions,

 

*Is my= configuration considered as a “best practice”?

*What are the= possible modifications for a son-of-3280?. This configuration will be affected= adversely for that?

 

Thank you very much in advance

 

Carlos

 

 

Carlos Gonz= =E1lez-Cadenas

Jefe de Departamento de Arquitectura Software 

Software Architecture Department= Manager

Responsable de Seguridad de la Informaci= =F3n 

Information Security= Responsible

netf= ocus
by Siemens-BancSa= badell

 

 

C/Sena, 12= nucli C planta 2
Edifici Landscape
08190 Sant Cugat del Vall=E8s

phone:=   +34933556139
fax:      +34933556142
mailto:  gonzalezcarlos@netfocus.es
web:     www.netfocus.es

 

=0D
Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o=
 borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo=
 pena
de incurrir en responsabilidades legales. El emisor no garantiza la=
 integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.

=0D
Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o=
 se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per=
 aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui=
 d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no=
 garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es=
 responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualsevol altres manipulacions que facin tercers.

=0D
Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of=
 the
individual or entity to whom it is addressed. If you are not the intended=
 recipient
and have received this information in error or have accessed it for any=
 reason,
please notify us of this fact by email reply and then destroy or delete the=
 message,
refraining from any reproduction, use, alteration, filing or communication=
 to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the=
 accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.
------=_NextPart_000_0010_01C447BF.8A3C74C0-- From owner-ietf-pkix@mail.imc.org Wed Jun 2 02:29:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28290 for ; Wed, 2 Jun 2004 02:29:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i525QbqG020917; Tue, 1 Jun 2004 22:26:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i525QbWG020916; Tue, 1 Jun 2004 22:26:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av1-2-sn3.vrr.skanova.net (av1-2-sn3.vrr.skanova.net [81.228.9.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i525Qaxp020818 for ; Tue, 1 Jun 2004 22:26:36 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 37C6237EA4; Wed, 2 Jun 2004 07:26:32 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 298A737E4E; Wed, 2 Jun 2004 07:26:32 +0200 (CEST) Received: from arport (t12o913p60.telia.com [213.64.28.180]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id CA5F938008; Wed, 2 Jun 2004 07:26:27 +0200 (CEST) Message-ID: <006501c44861$ecf010c0$0500a8c0@arport> From: "Anders Rundgren" To: "David P. Kemp" , References: <005701c3e08e$9b392fe0$1400a8c0@augustcellars.local> <00c701c3e121$0ae3af90$0500a8c0@arport> <4017C963.8060600@bull.net> <200405121708.i4CH7dim022214@stingray.missi.ncsc.mil> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Date: Wed, 2 Jun 2004 07:24:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >It is my hope that PI will become an RFC in the near future, so >that certificates (from an un-named large PKI :-) that currently >handle PIs by munging them into Common Name (e.g., >CN="Kemp.David.P.0514101404") will have a saner alternative. Since you apparently plan to put PI through the litmus test, may I repeat my request for a brief description of how you see that likely DN name clashes should be handled when the current identifier is removed from CN? Among possible alternatives I note: 1. Ignoring subject DN name clashes [1] 2. Having the CA issue and keep a specific registry [2] of "nonsense" name disambiguers. Putting such disambiguers in serialNumber 3. Inserting the existing permanent identifier in serialNumber. This is more or less a duplication of the PI object 4. Other? best Anders R 1] violates RFC3039 2] is effectively an RFC3039 requirement as DNs must never be reassigned From owner-ietf-pkix@mail.imc.org Wed Jun 2 15:17:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12579 for ; Wed, 2 Jun 2004 15:17:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52I0aSF047250; Wed, 2 Jun 2004 11:00:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i52I0aFS047249; Wed, 2 Jun 2004 11:00:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52I0Zo0047231 for ; Wed, 2 Jun 2004 11:00:36 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200406021759.i52HtDii019283@stingray.missi.ncsc.mil> Date: Wed, 02 Jun 2004 13:57:57 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Rundgren CC: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt References: <005701c3e08e$9b392fe0$1400a8c0@augustcellars.local> <00c701c3e121$0ae3af90$0500a8c0@arport> <4017C963.8060600@bull.net> <200405121708.i4CH7dim022214@stingray.missi.ncsc.mil> <006501c44861$ecf010c0$0500a8c0@arport> In-Reply-To: <006501c44861$ecf010c0$0500a8c0@arport> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2004 17:58:02.0817 (UTC) FILETIME=[261C5B10:01C448CB] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The problem isn't ambiguity, the problem is permanence and signalling. It would be wonderful if a new subject distinguished name structure could be established along the lines you suggest: A. CN=David Kemp; SN=1234567; DC=megabank; DC=com or even using a new Account Assigning Authority RDN attribute: B. CN=David Kemp; SN=1234567; AA=megabank.com But I'm enough of a pragmatist to believe that Country-based kitchen-sink DNs will not go away in my lifetime no matter how ugly they are. Closed PKIs can choose to use clean account-based DNs, but as long as some PKIs might use DNs with nonce disambiguators, general purpose applications will need custom configuration and multiple logic paths to know if and where an account number / PI can be found, unless a PI standard is adopted. So to answer your question starting with the DN example from RFC3280, the original (#1 below) is invalid in general because it might clash, (2a and 2b) contain a nonce disambiguator, and (3a/3b/3c) contain a larger disambiguator that may or may not be a permanent identifier. If (3) is a PI, then it might be assigned by the issuing CA, by the subject's organization nist.gov.US, or by a third party such as DEERS for DoD users. 1. CN=Tim Polk; OU=nist; O=gov; C=US 2a. CN=Tim Polk.3; OU=nist; O=gov; C=US 2b. CN=Tim Polk; SN=3; OU=nist; O=gov; C=US 3a. CN=Tim Polk.1234567; OU=nist; O=gov; C=US 3b. CN=Tim Polk; SN=1234567; OU=nist; O=gov; C=US 3c. CN=Tim Polk; SN=1234567; E=wpolk@nist.gov; OU=nist; O=gov; C=US The problem that a PI standard needs to solve is allowing an application to examine a certificate following one of many pre-existing DN schemas and determine if that certificate contains a PI. So your alternative 3 would be "inserting the existing serialNumber in the permanent identifier", not the other way around. It would be nice to be able to avoid duplication, so alternative 4 would be for the PI altname to contain only the account assigner and for the DN serialNumber to contain the account number. Alternatives 2, 3, and 4 are all OK, 1 is not. ------------------------------ My preferred syntax for the PI otherName form would be: PermanentIdentifier ::= SEQUENCE { identifierValue UTF8String OPTIONAL, identifierAssigner UTF8String OPTIONAL } If the identifierValue field is omitted, the value MUST be contained in the last serialNumber RDN of the subject field of the certificate. The identifierAssigner field, if present, MUST contain a Domain Name System (DNS) name in the "preferred name syntax" as specified in RFC 1034. If the identifierAssigner field is omitted, the identifier assigner is the issuer of the certificate. Dave Anders Rundgren wrote: >>It is my hope that PI will become an RFC in the near future, so >>that certificates (from an un-named large PKI :-) that currently >>handle PIs by munging them into Common Name (e.g., >>CN="Kemp.David.P.0514101404") will have a saner alternative. > > > Since you apparently plan to put PI through the litmus test, may I > repeat my request for a brief description of how you see that likely > DN name clashes should be handled when the current identifier > is removed from CN? Among possible alternatives I note: > > 1. Ignoring subject DN name clashes [1] > > 2. Having the CA issue and keep a specific registry [2] of "nonsense" > name disambiguers. Putting such disambiguers in serialNumber > > 3. Inserting the existing permanent identifier in serialNumber. This > is more or less a duplication of the PI object > > 4. Other? > > best > Anders R > > 1] violates RFC3039 > > 2] is effectively an RFC3039 requirement as DNs must never be > reassigned > > From owner-ietf-pkix@mail.imc.org Wed Jun 2 15:47:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14719 for ; Wed, 2 Jun 2004 15:47:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52Im2gs054456; Wed, 2 Jun 2004 11:48:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i52Im2tm054455; Wed, 2 Jun 2004 11:48:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av2-1-sn3.vrr.skanova.net (av2-1-sn3.vrr.skanova.net [81.228.9.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52Im1ot054426 for ; Wed, 2 Jun 2004 11:48:01 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id B666837EE2; Wed, 2 Jun 2004 20:47:59 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id A720937EE0; Wed, 2 Jun 2004 20:47:59 +0200 (CEST) Received: from arport (t8o913p96.telia.com [213.64.26.216]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id BD09538008; Wed, 2 Jun 2004 20:47:56 +0200 (CEST) Message-ID: <01dc01c448d1$e3ceeb90$0500a8c0@arport> From: "Anders Rundgren" To: "David P. Kemp" Cc: References: <005701c3e08e$9b392fe0$1400a8c0@augustcellars.local> <00c701c3e121$0ae3af90$0500a8c0@arport> <4017C963.8060600@bull.net> <200405121708.i4CH7dim022214@stingray.missi.ncsc.mil> <006501c44861$ecf010c0$0500a8c0@arport> <200406021759.i52HtDii019283@stingray.missi.ncsc.mil> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Date: Wed, 2 Jun 2004 20:45:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >My preferred syntax for the PI otherName form would be: >PermanentIdentifier ::= SEQUENCE { > identifierValue UTF8String OPTIONAL, > identifierAssigner UTF8String OPTIONAL >} >If the identifierValue field is omitted, the value MUST be >contained in the last serialNumber RDN of the subject field >of the certificate. >The identifierAssigner field, if present, MUST contain a Domain >Name System (DNS) name in the "preferred name syntax" as specified >in RFC 1034. If the identifierAssigner field is omitted, the >identifier assigner is the issuer of the certificate. C'mon Dave, this PI scheme would be compatible with RFC3039 and much existing PI practice! I thought this was out of question? :-) :-) A margin comment: Although my ASN.1 surely sucks, shouldn't there be a [] or two to properly spice this up? best Anders From owner-ietf-pkix@mail.imc.org Wed Jun 2 16:32:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17825 for ; Wed, 2 Jun 2004 16:32:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52JRxoT063376; Wed, 2 Jun 2004 12:27:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i52JRxON063375; Wed, 2 Jun 2004 12:27:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52JRwYJ063342 for ; Wed, 2 Jun 2004 12:27:58 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200406021927.i52JLOiG022721@stingray.missi.ncsc.mil> Date: Wed, 02 Jun 2004 15:22:28 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Rundgren CC: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt References: <005701c3e08e$9b392fe0$1400a8c0@augustcellars.local> <00c701c3e121$0ae3af90$0500a8c0@arport> <4017C963.8060600@bull.net> <200405121708.i4CH7dim022214@stingray.missi.ncsc.mil> <006501c44861$ecf010c0$0500a8c0@arport> <200406021759.i52HtDii019283@stingray.missi.ncsc.mil> <01dc01c448d1$e3ceeb90$0500a8c0@arport> In-Reply-To: <01dc01c448d1$e3ceeb90$0500a8c0@arport> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2004 19:22:28.0956 (UTC) FILETIME=[F1C3D1C0:01C448D6] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ahh, I had fancied that my ASN.1 did not suck, but you have shattered that illusion. It does need a [] or two: PermanentIdentifier ::= SEQUENCE { identifierValue [0] UTF8String OPTIONAL, identifierAssigner [1] UTF8String OPTIONAL } Anders Rundgren wrote: > > A margin comment: Although my ASN.1 surely sucks, shouldn't > there be a [] or two to properly spice this up? > > best > Anders > From owner-ietf-pkix@mail.imc.org Thu Jun 3 05:29:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23023 for ; Thu, 3 Jun 2004 05:29:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5385eIN058568; Thu, 3 Jun 2004 01:05:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5385e3b058567; Thu, 3 Jun 2004 01:05:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5385a1I058457 for ; Thu, 3 Jun 2004 01:05:39 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id ACAA53406E; Thu, 3 Jun 2004 20:00:44 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BVnEC-00029S-5H; Thu, 03 Jun 2004 20:05:32 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: anders.rundgren@telia.com, dpkemp@missi.ncsc.mil Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Cc: ietf-pkix@imc.org In-Reply-To: <200406021927.i52JLOiG022721@stingray.missi.ncsc.mil> Message-Id: Date: Thu, 03 Jun 2004 20:05:32 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David P. Kemp" writes: >Ahh, I had fancied that my ASN.1 did not suck, but you have shattered that >illusion. It does need a [] or two: I wasn't sure of Anders was being sarcastic or not (that is, commenting on the massive overuse of redundant tags in most PKIX standards). Since it was a serious comment, it only needs one tag, on the second UTF8String. Peter. From owner-ietf-pkix@mail.imc.org Thu Jun 3 09:12:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08062 for ; Thu, 3 Jun 2004 09:12:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53Bs6rg034378; Thu, 3 Jun 2004 04:54:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53Bs6Qm034377; Thu, 3 Jun 2004 04:54:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53Bs5si034348 for ; Thu, 3 Jun 2004 04:54:05 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i53Bs0bl320602; Thu, 3 Jun 2004 07:54:00 -0400 Received: from d01ml062.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i53BslG0132162; Thu, 3 Jun 2004 07:54:48 -0400 To: "David P. Kemp" Cc: Anders Rundgren , ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Tom Gindin Message-ID: Date: Thu, 3 Jun 2004 07:53:52 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|May 18, 2004) at 06/03/2004 07:53:59, Serialize complete at 06/03/2004 07:53:59 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David: The first tag (for Value) is not needed. I would think that the second field should be called something like "assignerDomain" or "assignerNode". Tom Gindin "David P. Kemp" Sent by: owner-ietf-pkix@mail.imc.org 06/02/2004 03:22 PM To: Anders Rundgren cc: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Ahh, I had fancied that my ASN.1 did not suck, but you have shattered that illusion. It does need a [] or two: PermanentIdentifier ::= SEQUENCE { identifierValue [0] UTF8String OPTIONAL, identifierAssigner [1] UTF8String OPTIONAL } Anders Rundgren wrote: > > A margin comment: Although my ASN.1 surely sucks, shouldn't > there be a [] or two to properly spice this up? > > best > Anders > From owner-ietf-pkix@mail.imc.org Thu Jun 3 10:38:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16565 for ; Thu, 3 Jun 2004 10:38:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53DUefP053170; Thu, 3 Jun 2004 06:30:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53DUeab053169; Thu, 3 Jun 2004 06:30:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53DUdiu053145 for ; Thu, 3 Jun 2004 06:30:40 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200406031329.i53DToWi000957@stingray.missi.ncsc.mil> Date: Thu, 03 Jun 2004 09:30:30 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Gindin CC: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2004 13:30:36.0064 (UTC) FILETIME=[F3E9EA00:01C4496E] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tom, As long as we're being technical, either the first or the second tag is not needed - all that is required is to unambiguously distinguish between one optional field and the other. I don't agree with Peter that two tags is massive overuse - there is no difference in the number of octets with IMPLICIT TAGS, and the ASN.1 looks more uniform when all optional fields are context-tagged. Maybe Peter is a free spirit who just doesn't like all his text lined up in straight columns :-). I hope this thread will morph into a discussion of the wisdom of using DNS name as the identifier for assigner, vs. using an OID, or a CHOICE of DNS or OID. I think that the IESG's objections to using a URI do not apply to using a DNS name, because the URI always implies an online access by the client to fetch some resource, while the DNS name implies that the assigner has registered a name but does not require any online access to a changeable value (A / MX / RR lookup) by the client. OID registration is more formal and is free; DNS registration is a little more "internet friendly" but requires a fee if an assigner does not already have an internet presence. I don't have a preference for one over the other. I do oppose a CHOICE because of the unnecessary complexity. There should be no situation where an assigner could not register either an OID or a DNS name, so standardizing on either one is preferable to requiring support for both. I don't have any particular preference for a name for the second field, although the emphasis should be on "Assigner" (the fact that there is a registered business entity) rather than on the syntax of the registered name (the fact that it is a DNS domain or node). Dave Tom Gindin wrote: > David: > > The first tag (for Value) is not needed. I would think that the > second field should be called something like "assignerDomain" or > "assignerNode". > > Tom Gindin From owner-ietf-pkix@mail.imc.org Thu Jun 3 11:40:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21125 for ; Thu, 3 Jun 2004 11:40:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53Ej4r7067745; Thu, 3 Jun 2004 07:45:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53Ej4tT067744; Thu, 3 Jun 2004 07:45:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53Ej3Nu067721 for ; Thu, 3 Jun 2004 07:45:03 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 3C60234028; Fri, 4 Jun 2004 02:40:17 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BVtSu-0000FQ-Lz; Fri, 04 Jun 2004 02:45:08 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dpkemp@missi.ncsc.mil, tgindin@us.ibm.com Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Cc: ietf-pkix@imc.org In-Reply-To: <200406031329.i53DToWi000957@stingray.missi.ncsc.mil> Message-Id: Date: Fri, 04 Jun 2004 02:45:08 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David P. Kemp" writes: >I don't agree with Peter that two tags is massive overuse - there is no >difference in the number of octets with IMPLICIT TAGS, and the ASN.1 looks >more uniform when all optional fields are context-tagged. Maybe Peter is a >free spirit who just doesn't like all his text lined up in straight columns >:-). Hiding type information via unnecessary tagging makes data checking/display using ASN.1 tools extremely difficult. There's nothing more painful than having to debug/pick apart some implementation's broken PDUs where every field is an implicit OCTET STRING. Peter. From owner-ietf-pkix@mail.imc.org Thu Jun 17 20:22:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28994 for ; Thu, 17 Jun 2004 20:22:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HN61dM043983; Thu, 17 Jun 2004 16:06:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HN61uP043982; Thu, 17 Jun 2004 16:06:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HN602x043948 for ; Thu, 17 Jun 2004 16:06:00 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5HN4XJ13586; Thu, 17 Jun 2004 16:04:33 -0700 (PDT) Message-Id: <200406172304.i5HN4XJ13586@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3779 on X.509 Extensions for IP Addresses and AS Identifiers Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 17 Jun 2004 16:04:33 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3779 Title: X.509 Extensions for IP Addresses and AS Identifiers Author(s): C. Lynn, S. Kent, K. Seo Status: Standards Track Date: June 2004 Mailbox: CLynn@BBN.Com, Kent@BBN.Com, KSeo@BBN.Com Pages: 27 Characters: 60732 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-x509-ipaddr-as-extn-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3779.txt This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040617160206.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3779 --OtherAccess Content-Type: Message/External-body; name="rfc3779.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040617160206.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Tue Jun 22 14:22:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12515 for ; Tue, 22 Jun 2004 14:22:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MH8rTO069737; Tue, 22 Jun 2004 10:08:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MH8rRt069736; Tue, 22 Jun 2004 10:08:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MH8qgB069727 for ; Tue, 22 Jun 2004 10:08:52 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5MH8gC0030871 for ; Tue, 22 Jun 2004 13:08:42 -0400 Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i5MH834B005688 for ; Tue, 22 Jun 2004 13:08:03 -0400 (EDT) Message-Id: <5.1.0.14.2.20040622130249.02af60c0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 22 Jun 2004 13:11:05 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: Agenda Requests, Please... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, The PKIX WG will be meeting at the 60th IETF in San Diego on Wednesday, August 4 from 9:30 - 11:30 AM. I would like to post a *draft* agenda for the PKIX WG by the end of this month . The final agenda will be posted towards the end of July, but the draft may help folks make their travel plans. I would appreciate receiving agenda requests by next Tuesday at the latest. I will post the draft agenda to the WG list the following day. WG activities will, as always, get preference for agenda time. However, we may be able to accomodate some "liasion" presentations. As always: (1) Please put the word "Agenda" in the subject line! (2) Please submit a new request *even if you sent me mail before*. I will try searching for the usual key words, but am likely to miss old requests. Thanks, Tim Polk From owner-ietf-pkix@mail.imc.org Tue Jun 22 15:08:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20394 for ; Tue, 22 Jun 2004 15:08:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8MEI082873; Tue, 22 Jun 2004 11:08:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MI8MvE082871; Tue, 22 Jun 2004 11:08:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from vahqex2.digitalnet.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8KRk082854; Tue, 22 Jun 2004 11:08:20 -0700 (PDT) (envelope-from Matt.Bertapelle@DigitalNet.com) Received: from [158.189.2.56] ([158.189.2.56]) by vahqex2.digitalnet.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jun 2004 14:08:23 -0400 Message-ID: <40D87595.50406@digitalnet.com> Date: Tue, 22 Jun 2004 14:08:21 -0400 From: Matt Bertapelle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: imc-cml , imc-sfl , ietf-pkix@imc.org Subject: v2.4 Certificate Management Library (CML) Now Available Content-Type: multipart/alternative; boundary="------------050304030007060200030803" X-OriginalArrivalTime: 22 Jun 2004 18:08:23.0571 (UTC) FILETIME=[E85EE630:01C45883] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------050304030007060200030803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, DigitalNet Government Solutions has delivered the Version 2.4 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux. The v2.4 CML and documentation is freely available at: . Applications requiring Public Key Infrastructure (PKI) security services can use the CML to meet their X.509 certificate and Certificate Revocation List (CRL) processing requirements. The v2.4 CML is described in the v2.4 CML Application Programming Interface (API) document. It implements the 2000 X.509 Recommendation certification path verification processing rules and SDN.706 profile. It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile requirements. There are some unsupported features such as Delta CRLs. The v2.4 CML Abstract Syntax Notation One (ASN.1) decodes X.509 Certificates and CRLs. It requires the v1.6 Enhanced SNACC ASN.1 software that is freely available from: . The CML provides robust certification path building capabilities such as using cross certificates. The CML uses the accompanying Storage and Retrieval Library (SRL) (optionally) to provide local certificate and CRL storage management functions. The SRL (optionally) provides remote directory retrieval capabilities using the Lightweight Directory Access Protocol (LDAP). The CML has been thoroughly tested including validating X.509 Certificates and CRLs created by a variety of Certification Authority (CA) products, and signed using the Digital Signature Algorithm (DSA) and RSA algorithms. Further enhancements, ports and testing of the CML are still in process. Further releases of the CML will be provided as significant capabilities are added. CML v2.4 includes the following enhancements (compared to v2.3 CML release): 1) Replaced the CTIL interface for the CML with a newly created PKCS#11 interface. 2) Implemention of a CRL server with support for the "Delta CRL" and "Freshest CRL" 2000 X.509 extensions. This architectural change is a step toward the CML's migration of OCSP compatability. 3) Enhanced the API to support the option for the application to request the CML log path building and validation events to aid in debugging and troubleshooting. 4) Enhanced the API to include callback functions to allow an application to perform its own revocation processing, rather than the crlapi library. 5) Added the capability to cache invalid certificates and CRLs. 6) Added a CRL grace period that can be specified by the application when creating a CML session. The grace period allows the application to specify the amount of time past a CRL's nextUpdate during which the CML will treat the CRL as still current. v2.4 SRL includes the following enhancements (compared to v2.3 SRL release): 1) Modified the default crlRefreshPeriod from 0 to LONG_MAX when CML creates an SRL session. When zero, the CRLs in the database were always being treated as stale; the new default is the always treat them as fresh. 2) Added a location mask to SRL_URLrequestObjs() so the caller can specify whether to search the local databse, the remote server, or both. 3) Enhnaced LDAPInitSettings_struct with a timeout field that controls how long to wait for the ldap_result() function. Previously, the timeout was hardcoded to 30 seconds. All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees. The CML was originally developed by the U.S. Government. DigitalNet is enhancing and supporting the CML under contract to the U.S. Government. The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software. The CML makes calls to an algorithm-independent CTIL API that provides access to a variety of external crypto libraries. There is a CTIL for each crypto library that maps the generic CTIL API calls to the specific calls for that crypto library. DigitalNet provides CTILs for the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used with the CML. The underlying, external crypto libraries are not distributed as part of the CML software. The CML has been successfully tested with the v2.4 S/MIME Freeware Library (SFL) that is freely available from . The CML has been successfully tested with the v2.4 Access Control Library (ACL) that is freely available to everyone from: . The CML has been successfully used to build and verify certificate paths used in the Bridge Certification Authority (BCA) demonstration which includes cross-certified hierarchical and non- hierarchical PKIs. The BCA Interoperability Test Suite (BITS) is a free and openly available test resource provided to facilitate vendor development of secure, interoperable Public Key Enabled applications. The CML has been used to successfully develop and verify the BITS X.509 certification paths available from . The National Institute of Standards and Technology (NIST) is providing a standard test suite of X.509 certificate paths that can be used for testing applications against RFC 2459. The CML was used to successfully process the NIST test data. The CML meets the requirements stated in the SDN.706 Certificate/ CRL Profile required by the U.S. Defense Message System (DMS) project. The Internet Mail Consortium (IMC) has established a CML web page and a CML mail list which is used to: distribute information regarding CML releases; discuss CML-related issues; and allow CML users to provide feedback, comments, bug reports, etc. Subscription information for the imc-cml mailing list is at the IMC web site listed above. All comments regarding the CML source code and documents are welcome. This CML release announcement was sent to several mail lists, but please send all messages regarding the CML to the imc-cml mail list ONLY. Please do not send messages regarding the CML to any of the IETF mail lists. We will respond to all messages sent to the imc-cml mail list. -- Matthew J. Bertapelle DigitalNet Government Solutions, LLC www.DigitalNet.com --------------050304030007060200030803 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
All,

DigitalNet Government Solutions has delivered the Version 2.4 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux.  The v2.4 CML and documentation is freely available at:
<http://www.digitalnet.com/knowledge/cml_home.htm>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.4 CML is described in the v2.4 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.4 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.6
Enhanced SNACC ASN.1 software that is freely available from:
<http://www.digitalnet.com/knowledge/snacc_home.htm>.

The CML provides robust certification path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  Further enhancements, 
ports and testing of the CML are still in process.  Further
releases of the CML will be provided as significant 
capabilities are added. 

CML v2.4 includes the following enhancements (compared to v2.3 CML release):

1) Replaced the CTIL interface for the CML with a newly created PKCS#11 interface.

2) Implemention of a CRL server with support for the "Delta CRL" and "Freshest CRL" 2000 X.509 extensions.  This architectural change is a step toward the CML's migration of OCSP compatability.

3) Enhanced the API to support the option for the application to request the CML log path building and validation events to aid in debugging and troubleshooting.

4) Enhanced the API to include callback functions to allow an application to perform its own revocation processing, rather than the crlapi library.

5) Added the capability to cache invalid certificates and CRLs.

6) Added a CRL grace period that can be specified by the application when creating a CML session.  The grace period allows the application to specify the amount of time past a CRL's nextUpdate during which the CML will treat the CRL as still current.

v2.4 SRL includes the following enhancements (compared to v2.3 SRL release):

1) Modified the default crlRefreshPeriod from 0 to LONG_MAX when CML creates an SRL session.  When zero, the CRLs in the database were always being treated as stale; the new default is the always treat them as fresh.

2) Added a location mask to SRL_URLrequestObjs() so the caller can specify whether to search the local databse, the remote server, or both.

3) Enhnaced LDAPInitSettings_struct with a timeout field that controls how long to wait for the ldap_result() function.  Previously, the timeout was hardcoded to 30 seconds.

 
All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees.  The CML was originally developed by the U.S. Government.  DigitalNet is enhancing and supporting the CML under contract to the U.S. Government.  The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software.
The CML makes calls to an algorithm-independent CTIL API that provides
access to a variety of external crypto libraries. There is a CTIL for
each crypto library that maps the generic CTIL API calls to the
specific calls for that crypto library. DigitalNet provides CTILs for
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and
FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used
with the CML. The underlying, external crypto libraries are not
distributed as part of the CML software.


The CML has been successfully tested with the v2.4 S/MIME Freeware
Library (SFL) that is freely available from
<http://www.DigitalNet.com/knowledge/sfl_home.htm>.

The CML has been successfully tested with the v2.4 Access Control
Library (ACL) that is freely available to everyone from:
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The CML has been successfully used to build and verify
certificate paths used in the Bridge Certification Authority (BCA)
demonstration which includes cross-certified hierarchical and non-
hierarchical PKIs. The BCA Interoperability Test Suite (BITS)
is a free and openly available test resource provided to
facilitate vendor development of secure, interoperable Public
Key Enabled applications. The CML has been used to successfully
develop and verify the BITS X.509 certification paths available
from <http://bcatest.atl.DigitalNet.com>.

The National Institute of Standards and Technology (NIST) is
providing a standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be
used for testing applications against RFC 2459. The CML was
used to successfully process the NIST test data.

The CML meets the requirements stated in the SDN.706 Certificate/
CRL Profile required by the U.S. Defense Message System (DMS)
project.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml> and a CML mail list which is used to:
distribute information regarding CML releases; discuss CML-related
issues; and allow CML users to provide feedback, comments, bug
reports, etc. Subscription information for the imc-cml mailing list
is at the IMC web site listed above.

All comments regarding the CML source code and documents are welcome.
This CML release announcement was sent to several mail lists, but
please send all messages regarding the CML to the imc-cml mail list
ONLY. Please do not send messages regarding the CML to any of the IETF
mail lists. We will respond to all messages sent to the imc-cml mail
list. 
-- 
Matthew J. Bertapelle
DigitalNet Government Solutions, LLC
www.DigitalNet.com

--------------050304030007060200030803-- From owner-ietf-pkix@mail.imc.org Tue Jun 22 16:30:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26419 for ; Tue, 22 Jun 2004 16:30:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJKSSA096922; Tue, 22 Jun 2004 12:20:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MJKSUW096921; Tue, 22 Jun 2004 12:20:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av9-1-sn1.fre.skanova.net (av9-1-sn1.fre.skanova.net [81.228.11.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJKStY096884 for ; Tue, 22 Jun 2004 12:20:28 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av9-1-sn1.fre.skanova.net (Postfix, from userid 502) id 8EE0337E71; Tue, 22 Jun 2004 21:20:20 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id 810B637E5E for ; Tue, 22 Jun 2004 21:20:20 +0200 (CEST) Received: from arport (t12o913p113.telia.com [213.64.28.233]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id B0E5F37E44 for ; Tue, 22 Jun 2004 21:20:19 +0200 (CEST) Message-ID: <006001c4588d$a95d3ef0$0500a8c0@arport> From: "Anders Rundgren" To: Subject: New DN attribute - Problem or not? Date: Tue, 22 Jun 2004 21:18:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sombody suggested (extract from a PI discussion): "That attribute could be a generic "URI" attribute (like the email address attribute), which could be referenced (like SN) from a future version of the PI RFC, or it could be a specific "PI Authority" attribute which would eliminate the need for the PI SubjectAltName extension entirely for PKIs that adopt that attribute." Question: Is it a viable approach to introduce new DN attributes from an interoperability point of view? Anders From owner-ietf-pkix@mail.imc.org Thu Jun 24 04:09:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13463 for ; Thu, 24 Jun 2004 04:09:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O71H41039613; Thu, 24 Jun 2004 00:01:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O71HfI039612; Thu, 24 Jun 2004 00:01:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.2wire.ch (mail.2wire.ch [62.65.128.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O71FaC039433 for ; Thu, 24 Jun 2004 00:01:16 -0700 (PDT) (envelope-from joseph.doekbrijder@swisssign.com) Received: (qmail 5234 invoked by uid 89); 24 Jun 2004 07:00:56 -0000 Received: from unknown (HELO swisssign.com) (62.65.151.222) by mail.2wire.ch with SMTP; 24 Jun 2004 07:00:56 -0000 Message-ID: <40DA7C24.7040607@swisssign.com> Date: Thu, 24 Jun 2004 09:00:52 +0200 From: Joseph Doekbrijder Organization: SwissSign AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-ch, en-us, en, fr-ch MIME-Version: 1.0 To: Anders Rundgren CC: ietf-pkix@imc.org Subject: Re: New DN attribute - Problem or not? References: <006001c4588d$a95d3ef0$0500a8c0@arport> In-Reply-To: <006001c4588d$a95d3ef0$0500a8c0@arport> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050006070706010607070001" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050006070706010607070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Anders This issue would ad yet another variable to the stuff that can be put into the cert. But since we can make PKI work without all these variables (all we need in a cert, really, is a name and an emailaddress) there is no need for it. I do understand that certain environments would be helped with such a "fix" variable but there are very elegant solutions available to solve these requirements in other ways.... I still favour the approach to have a little information as possible in a certificate (Ideally they are empty :-) ) Cheers Josh -- Joseph A. Doekbrijder -------------------------------------------------- SwissSign AG Löwenstrasse 1, CH-8001 Zürich Tel: +41 43 344 88 11 / Mobile: +41 79 211 24 46 www.swisssign.com -------------------------------------------------- This message has been digitally signed to ensure unaltered and authenticated reception. Should you receive an error message regarding the validity of the signature, please click and download the SwissSign root certificate using the following link https://swisssign.net/trust/ After installation, your mail client will be able to automatically verify the authenticity of e-mail messages sent to you by users of SwissSign certificates. Anders Rundgren wrote: >Sombody suggested (extract from a PI discussion): > > "That attribute could be a generic "URI" attribute (like the > email address attribute), which could be referenced (like SN) > from a future version of the PI RFC, or it could > be a specific "PI Authority" attribute which would eliminate > the need for the PI SubjectAltName extension entirely for > PKIs that adopt that attribute." > >Question: Is it a viable approach to introduce new DN attributes >from an interoperability point of view? > >Anders > > > --------------ms050006070706010607070001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWiTCC A2EwggJJoAMCAQICCGQgZ70rBHuyMA0GCSqGSIb3DQEBBQUAMGkxIzAhBgNVBAMTGlN3aXNz U2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5j b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMjExMTQzOTA1WhcN MDQxMjExMTQzOTA1WjB4MSQwIgYDVQQDExtKb3NlcGggQW50b25pdXMgRG9la2JyaWpkZXIx LzAtBgkqhkiG9w0BCQEWIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMRIwEAYD VQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCpc7LucWH/EP2YmDBOMZVmPzy8JfYovxAL8wbfuXjFQLg4/orh+8AonyozzaK0fJzFw/D4 46z3siNvu065E6AKM3BFPSsyS5RrUPnYjtxcLAmfv+OsR5gAMA1hhsS571XCWaVPvEuCIltW RvpcKVeuAsdpR6p7eW7UPQuO0EgR4QIDAQABo4GBMH8wHwYDVR0jBBgwFoAU8jaGz72k1nnf MpmM0FlpHQWVLIYwDgYDVR0PAQH/BAQDAgQwMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQGCCsG AQUFBwMEMCsGA1UdEQQkMCKBIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMA0G CSqGSIb3DQEBBQUAA4IBAQBY4/HrZkMYrF0LKNWpDrYTbEM7wRjHKtpjMHWb1DlAm1qRBWAB 0Ns/jyCHLedGlRydHuVPh+THO9PPgRESIWoWq88uz+gpue3A4DWpuk7BqrYKXFfKTa1uKsfE L62LJ0cO8Q09aCkkEpETL8u92s68328QPhSgFmX5wgToyG3Vw2EOMTcbCeKFRYSkZTywe2NV IMkDKKUDuRYBYZZ1Db8P3SzF26bszuUH+4HsbgIg8K+mrEeln9aHpbujAUVx8huCpYR25Ziz rtK2vHmDd2VQUfOs+gA4dns7Ys+sOYXYWn2ZvXycCirQktDuaOTAxRXrBXByGLTNDsJBsNQI FbZdMIIDqTCCApGgAwIBAgIIXLEyej+EomAwDQYJKoZIhvcNAQEFBQAwZDEcMBoGA1UEAxMT U3dpc3NTaWduIFNpbHZlciBDQTEjMCEGCSqGSIb3DQEJARYUc2lsdmVyQHN3aXNzc2lnbi5j b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDEyMTEzODIyWhcN MTUxMDA2MTMzNjU3WjBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3 DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYT AkNIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAstKfzDugVAxC63Qhl8+Cko7T Kjh0aMls6o0iYfPE6LU9jRHGRE2FyEoI4+3EgotNIVEX7GOTtQUL3YRzkJ55T/urzNtWDead etokNxoH1KrYObxIuFeSyepEN/QKcNedliNqwGF3wPqKCGna554QeyV44pRhvNH3+hFL3Mz3 Tazf2wtmE/et/JSAFFUPWfSqrugURE1G2kaB9o2tt/BFtEjslSD41D9g7nexjvgHDyRKsoY3 FoEHexV/ttvFZNzGJJ7NLwgC84JvCdLi3RvNyGfiWnqkjuRdQOohAsWNJcjn7aoksB5y/Ipr BjsivtY/LBYQ7zq+Sc8v+8bf3T1lzwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUtGz1MEEswDyRjDQnY/pVvPzntD8wHwYDVR0jBBgwFoAU EvoMgVv/f9El2B5zMDUPRhg2snUwDQYJKoZIhvcNAQEFBQADggEBADG0plqQXp/SAJjFJYax q1R+3LaDheER1IgXaIem+nofwcBaCvEP+vkWkEuBwFbvI97tKlO6oY1WtVlJHbkfHXcvRAiv s8W9EbuQlXJ9g1J+ZKJbnI/KmTwsNYvHj5PBe9+PwvA1oZwTJDEEBSaUcdOxaNw3ceka7oTd dWXfAWUhGXDmS3O2yTHVovUrFAshmYEz9r4YRvbUzkKYcP12zOu2UmdrCOzSWua2EOuSimLM se00IOJTlhJMfL+ly6O8G1MA7wTqKkSgnDbVe0XsMQYmSJaiVqSkRGIUYE7mvlq9YKCguBZ1 fpmurO0BeWvmzZxZT/7VBjcfMzwS1tZ4CeAwggOuMIIClqADAgECAggQSAsMRGstRTANBgkq hkiG9w0BAQUFADBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3DQEJ ARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNI MB4XDTAzMTAxMjExNTgyMloXDTA2MTAxMjExNTgyMlowaTEjMCEGA1UEAxMaU3dpc3NTaWdu IFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNvbTES MBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMZmnWhcHmQ8GZB+9uoZyb+LmqUqYRWWL6vSFwWMSQdtn7aMT0zVI1N37y2I LN5/KurG53SonxgMfwqsxgdD3jI77yyJwsN0aMdBDotcL+pXSJqlC1gpDsVHtMIyQs5PqYTx Y3uUJVbBERchLFLv/2VJ0iBGXg009lyNVULa9VFcG/F2UF34YranOWBW4OSQowf1kJYNXr4A eKhpLnNhv30/fdIMRrihygQCPaMJ0nQAEuBVbFSfOUQPvMDDBwYKC+yMkcm5QWgnVGXAeyrA x7k8+rKPfNbYqnyeL9aAnyUMkYm6FtUsaM5I6HNWJY63gfqqPeprFuogZNY1Rwq2mNMCAwEA AaNjMGEwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPI2hs+9 pNZ53zKZjNBZaR0FlSyGMB8GA1UdIwQYMBaAFLRs9TBBLMA8kYw0J2P6Vbz857Q/MA0GCSqG SIb3DQEBBQUAA4IBAQCuHGJh9r2LiKenYuA4Imi1TZ0YWVB0o2Kfo6HD3CPZwavyPzXiShM0 0PGIoX/bs+K36PYj24E6gdp78B4hzqPP525wUapDy/WX8nur8XbrcdEwffWy+Cmz593an7Xy iFl18wIDGLGkpGpwtM/Jiu2QLUughU7Eh0/i6R1+oUPLF9wYcB0eoYnDBK0KWFvTEWkLAWYb F45PV4tsBXWI+UTQBB93rgdjQbJNxSv7K/kLAQY/mWs9fF2jp4X8+UMthm28TkHE7VAok0md Ma9x3X1ZrMDmb3ijkUxwJhFewelg9vMZdcXUHjezw5J83L5I8aBQmfKIHLDEg2XVcQUhMi/B MIIDwDCCAqigAwIBAgIJAOjyHqbBu/cuMA0GCSqGSIb3DQEBBQUAMHYxCzAJBgNVBAYTAkNI MRIwEAYDVQQKEwlTd2lzc1NpZ24xMjAwBgNVBAMTKVN3aXNzU2lnbiBDQSAoUlNBIElLIE1h eSA2IDE5OTkgMTg6MDA6NTgpMR8wHQYJKoZIhvcNAQkBFhBjYUBTd2lzc1NpZ24uY29tMB4X DTAzMTAwNjEzMzY1N1oXDTE1MTAwNjEzMzY1N1owZDEcMBoGA1UEAxMTU3dpc3NTaWduIEJy b256ZSBDQTEjMCEGCSqGSIb3DQEJARYUYnJvbnplQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoT CVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDA0TvGY7vE2Z2U4Ootl3tb6AZN4SPTTN6HYMyzL9OeKWzlMfnwJqEzv4yjkFMcaStrmyRO PMkwLEWcd3FiaxKBmr0eCN9ybgZuhKvSxYfaqcM5QAgPqK6yA2WQ+sgWAUlEH4PdhCUYd84q eOlswzzrtbggVWQsbh/LoT7edOeBJlDiIHufmmXTl5X7psFIImkWJbnegd7fidhRuUxMJF0X LcA/9WaJzZDZSmGONRSP+WOzlM/o4xunjPwIoCWKSIo9NMWtJ29az01/TcLehpyMjQg7a+PJ 3yFtl5PbS25Jm7W9IopISNPGYzucjOIVKYo9BQ5F32lGn8NJl418yNttAgMBAAGjYzBhMA4G A1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRygIjtngs9r6moa09a F+LUoY5lJDAfBgNVHSMEGDAWgBSW13HNOSrU/IixiqtTeGnvj0d+FjANBgkqhkiG9w0BAQUF AAOCAQEApFfZjNGeQ7OtxCPI3mI1rjF2gbxMTMtMeJeaxH2QSJsrvcKRQ29v0wzDLMmeKFR8 d3B8PDh8aqw2IGz1X3FcIn7CUTdoOvFCGuW0SpdvKzgt3RVOpp4HFcfMK6mxubSHCBV6f66A UyxbK+Sv7Rpwn3BZ6AYndMzYMEk6IrAvrurIz6h2DTrwEO3oH1GKRpYljlcoh+mKEnvZit6b vGNcLpLTMZNe+0dlKzw1uHNI9gqteNqn/BqunMDAqPcBX4uZ0em7P/ZJ8+SACnsz96+R5MSV EeoFqWQoRQAxNgjUXTy0xYa4cGRqeXtTO/s3mKgDBWktCFXU0f0kb0IQIBmGqDCCA/gwggLg oAMCAQICCQDemCdyDdsdVTANBgkqhkiG9w0BAQUFADBkMRwwGgYDVQQDExNTd2lzc1NpZ24g QnJvbnplIENBMSMwIQYJKoZIhvcNAQkBFhRicm9uemVAc3dpc3NzaWduLmNvbTESMBAGA1UE ChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDAeFw0wMzEwMTIxMTM2MzJaFw0xNTEwMDYxMzM2 NTdaMGQxHDAaBgNVBAMTE1N3aXNzU2lnbiBTaWx2ZXIgQ0ExIzAhBgkqhkiG9w0BCQEWFHNp bHZlckBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzPdBfCH+e+kxpt0cSTkKm1pJXXdRCNJ8 mrbsNpuX2O290pzz1dEF7DKFCH+k9bm8Yqj1KgyhKrt7JoNGUHW83sU+8jjrYG/ZPrfusCH+ 4iiVZciBCvPdM1t0qvPZvWrKVYdIb+3t8aQz8+L08zFLdkxG49M+4cMW5srECPy4YJ3kJzVr awrXBMAchqviMngsyWuKw5qV5FA9pp36wDsumItoZXL3BOsMsU2lh3z/OLhDpXA5D83mgEOW RbqkfSWyaT1lcIuoMZ/XMdT8ahU+3GWnZ8O9tQFg0//SfrlT3Zsp7Hhx0XEtsuIKQZTrsUHj QzR+bk9RlKLz3Sy5nxPRRQIDAQABo4GsMIGpMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBQS+gyBW/9/0SXYHnMwNQ9GGDaydTAfBgNVHSMEGDAWgBRygIjt ngs9r6moa09aF+LUoY5lJDBGBgNVHR8EPzA9MDugOaA3hjVodHRwczovL3N3aXNzc2lnbi5u ZXQvY2dpLWJpbi9hdXRob3JpdHkvY3JsP2NhPUJyb256ZTANBgkqhkiG9w0BAQUFAAOCAQEA qaVWxVi644azmxYNNglkRVA5pFsU3zN4zepYrjEmamFgGROsNKYCwf06cGDHXsJyxZzkzFPG FTR5/pRLoDWnEuFgfm+a6XA9qTUecun+909Dkz8EbNk/KsWaGEG+HxMjwnusctjeWhO32rRH +AWJW9VhNR+ggbkGwbVadRClY7359ChoWTwkySWb2hjTZU3BOnqAOYJ2QPKiWMrGODN9Jo94 +hfxcD6o08ak5KY/5Bza4EEL/sbS/quhoCZsg8TBD4+KeXgbVqU9XlPHk/gq1RTy49SPmRkQ lgwFSvQRRAD/5oQX3ZKxhXAVsEYHyGvqCsFvXWKagulb5NjNdD0pyTCCBAEwggLpoAMCAQIC CQCVT/juYWAhTDANBgkqhkiG9w0BAQUFADBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29u YWwgR29sZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQK EwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTIxMDIxNDAwMVoXDTA0MTIxMDIxNDAw MVoweDEkMCIGA1UEAxMbSm9zZXBoIEFudG9uaXVzIERvZWticmlqZGVyMS8wLQYJKoZIhvcN AQkBFiBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NT aWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJVGvsFb 4Ufs++D4cxTnv2yHvmLjKZQ2qfPT7YO2dfffZbiba4qkKQ8xLE05D1EqlLvXm+4dRksjDhty OzwZeWajZ/TGwPgP3jXOURlqkyhVrX0kt5EzW5EokcMC/Ais422LqtJ5kq2nOvK7NGYtevS0 pMbHi5NZtkWUwVZaRjjOJaTGO2xDkjAOdYIyI8vdEIedJIW6LGHIZsYjI+yW7sUlI6hCXhrV nsmdu/shG/TTsvDQUW28Yl7/l/uvikFsuy4erDKDHcbth/xKsI/KkfX40jGqGI0SlQ7fHBph DwbnbOKJJSu1wgMT1dvuwLyFEBqyf0OSPZROpK11T3d2LdcCAwEAAaOBnDCBmTAfBgNVHSME GDAWgBTyNobPvaTWed8ymYzQWWkdBZUshjAOBgNVHQ8BAf8EBAMCA8gwKQYDVR0lBCIwIAYI KwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3FAICMDsGA1UdEQQ0MDKgMAYKKwYBBAGCNxQC A6AiDCBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTANBgkqhkiG9w0BAQUFAAOC AQEAZTUBqQgk5nB+0W7Mozv/uD6lRurjZhWShstlaQ43qvVHcsDgb4mW/bynla9BDmM/NsQU 43ZsoFxjkJsxFCpgm5BuMt1KuD7FSHJ0mxRswaGf9mHxftU1cu/YhY/AjrsFHEnsPHZaYAAm jcKunHgT+yckvUZR3RQDkgVE4PQ3YpsG1EPKQSEAFbmWAd4+TxJmuBXThDM63gOkY4Q7gE1b Y1kjkdRlJ2TZ/gOItQ3AsfwS7mq+ANYnUBrWkrnUd85Nmgzv5ys7zxuz9tp64vS+xYW98mri ruGl9stN/b7SbOFTsp8SUm83e9qPOQZRYPS6TYYKUObj3LbaXJEIqKD51DGCA2IwggNeAgEB MHYwaTEjMCEGA1UEAxMaU3dpc3NTaWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0B CQEWEmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJD SAIJAJVP+O5hYCFMMAkGBSsOAwIaBQCgggHBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDYyNDA3MDA1MlowIwYJKoZIhvcNAQkEMRYEFJXKgI0kUfcd 0lfVVEmwmavBy4JzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGEBgkrBgEEAYI3 EAQxdzB1MGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZI hvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UE BhMCQ0gCCGQgZ70rBHuyMIGGBgsqhkiG9w0BCRACCzF3oHUwaTEjMCEGA1UEAxMaU3dpc3NT aWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNv bTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSAIIZCBnvSsEe7IwDQYJKoZIhvcN AQEBBQAEggEAkTHygBu9Qb1DMc3GQxYu4u7dVzbr7TUF87kyAqwZuadLLUy/LCGfwuZJTJVi SOHW6j6Qb90WtW24HSRIS4gMfInlIZYMUy15OI0in+2kerbqgzCfM2WA9+YnU/PDqRwaMdzr GBcnVqEx3sVVBYwBwH0Z+vKvU7oT+8T+uM4KzRTcJW8qc1FVxh0uxf2+ku3H6k338hORWeig 5qO/RvM1pFV4Pi44TBGgFTMF+6zyOEyoHNRQPOm4tpJcZepMez49pgWoZ4sAkwmHMUqJdTMk EqRta5ntL/1Bu4Dh5ewLsJuC/qYuWN0NC8Ru4Zur6iSNi1vgNeW6ZrEAUQ33u483uAAAAAAA AA== --------------ms050006070706010607070001-- From owner-ietf-pkix@mail.imc.org Thu Jun 24 14:01:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05760 for ; Thu, 24 Jun 2004 14:01:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OH1P8A074555; Thu, 24 Jun 2004 10:01:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OH1Pt8074554; Thu, 24 Jun 2004 10:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail1.atl.registeredsite.com (nobody@mail1.atl.registeredsite.com [64.224.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OH1Oob074548 for ; Thu, 24 Jun 2004 10:01:25 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail1.atl.registeredsite.com (8.12.11/8.12.8) with ESMTP id i5OH1RiX031204; Thu, 24 Jun 2004 17:01:27 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Thu, 24 Jun 2004 12:01:26 -0500 Message-ID: <40DB08DC.1090705@nma.com> Date: Thu, 24 Jun 2004 10:01:16 -0700 From: Ed Gerck User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Doekbrijder CC: Anders Rundgren , ietf-pkix@imc.org Subject: Re: New DN attribute - Problem or not? References: <006001c4588d$a95d3ef0$0500a8c0@arport> <40DA7C24.7040607@swisssign.com> In-Reply-To: <40DA7C24.7040607@swisssign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Joseph Doekbrijder wrote: >... > I still favour the approach to have a little information as possible in > a certificate ... Yes, also because the more fields (attributes) you have in a cert, the lesser its useful lifetime. The lifetime of a cert is the inversely proportional to the sum of the inverse lifetime of each attribute: 1/T ~ 1/A1 + 1/A2 + ... In particular, the lifetime of a certificate is less than the lifetime of any of its attributes. Cheers, Ed Gerck From owner-ietf-pkix@mail.imc.org Thu Jun 24 15:44:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20196 for ; Thu, 24 Jun 2004 15:44:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OJ043J086727; Thu, 24 Jun 2004 12:00:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OJ04Wk086725; Thu, 24 Jun 2004 12:00:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av2-1-sn3.vrr.skanova.net (av2-1-sn3.vrr.skanova.net [81.228.9.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OJ03rg086675 for ; Thu, 24 Jun 2004 12:00:03 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id CAA4B37EA3; Thu, 24 Jun 2004 20:59:53 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id BD61337E45; Thu, 24 Jun 2004 20:59:53 +0200 (CEST) Received: from arport (t8o913p20.telia.com [213.64.26.140]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id E2DD538007; Thu, 24 Jun 2004 20:59:51 +0200 (CEST) Message-ID: <00b501c45a1d$21856c00$0500a8c0@arport> From: "Anders Rundgren" To: "Ed Gerck" , "Joseph Doekbrijder" Cc: References: <006001c4588d$a95d3ef0$0500a8c0@arport> <40DA7C24.7040607@swisssign.com> <40DB08DC.1090705@nma.com> Subject: Re: New DN attribute - Problem or not? Date: Thu, 24 Jun 2004 20:57:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanx Guys, I think that you ansered another question which I did not put :-) But I agree with the "light" ID concept. Anders ----- Original Message ----- From: "Ed Gerck" To: "Joseph Doekbrijder" Cc: "Anders Rundgren" ; Sent: Thursday, June 24, 2004 19:01 Subject: Re: New DN attribute - Problem or not? Joseph Doekbrijder wrote: >... > I still favour the approach to have a little information as possible in > a certificate ... Yes, also because the more fields (attributes) you have in a cert, the lesser its useful lifetime. The lifetime of a cert is the inversely proportional to the sum of the inverse lifetime of each attribute: 1/T ~ 1/A1 + 1/A2 + ... In particular, the lifetime of a certificate is less than the lifetime of any of its attributes. Cheers, Ed Gerck From owner-ietf-pkix@mail.imc.org Sat Jun 26 09:29:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07588 for ; Sat, 26 Jun 2004 09:29:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QCD7IB070036; Sat, 26 Jun 2004 05:13:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5QCD73b070033; Sat, 26 Jun 2004 05:13:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from 21cn.com (send.forptr.21cn.com [61.140.60.50]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5QCD3rN070010; Sat, 26 Jun 2004 05:13:04 -0700 (PDT) (envelope-from matt.bertapelle@DigitalNet.com) Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm040dd8058; Sat, 26 Jun 2004 20:14:22 +0800 Received: from 21cn.com([10.2.1.9]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Sat, 26 Jun 2004 20:14:21 +0800 Received: from above.proper.com([10.2.100.8]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm4c40d8d44a; Wed, 23 Jun 2004 02:13:59 +0800 Received: from above.proper.com([208.184.76.39]) by 21cn.com(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 23 Jun 2004 02:12:21 +0800 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8MEI082873; Tue, 22 Jun 2004 11:08:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MI8MvE082871; Tue, 22 Jun 2004 11:08:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from vahqex2.digitalnet.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8KRk082854; Tue, 22 Jun 2004 11:08:20 -0700 (PDT) (envelope-from Matt.Bertapelle@DigitalNet.com) Received: from [158.189.2.56] ([158.189.2.56]) by vahqex2.digitalnet.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jun 2004 14:08:23 -0400 Message-ID: <40D87595.50406@digitalnet.com> Date: Tue, 22 Jun 2004 14:08:21 -0400 From: Matt Bertapelle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: imc-cml , imc-sfl , ietf-pkix@imc.org Subject: v2.4 Certificate Management Library (CML) Now Available Content-Type: multipart/alternative; boundary="------------050304030007060200030803" X-OriginalArrivalTime: 22 Jun 2004 18:08:23.0571 (UTC) FILETIME=[E85EE630:01C45883] List-Archive: List-ID: List-Unsubscribe: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-pkix@mail.imc.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: matt.bertapelle@DigitalNet.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------050304030007060200030803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, DigitalNet Government Solutions has delivered the Version 2.4 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux. The v2.4 CML and documentation is freely available at: . Applications requiring Public Key Infrastructure (PKI) security services can use the CML to meet their X.509 certificate and Certificate Revocation List (CRL) processing requirements. The v2.4 CML is described in the v2.4 CML Application Programming Interface (API) document. It implements the 2000 X.509 Recommendation certification path verification processing rules and SDN.706 profile. It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile requirements. There are some unsupported features such as Delta CRLs. The v2.4 CML Abstract Syntax Notation One (ASN.1) decodes X.509 Certificates and CRLs. It requires the v1.6 Enhanced SNACC ASN.1 software that is freely available from: . The CML provides robust certification path building capabilities such as using cross certificates. The CML uses the accompanying Storage and Retrieval Library (SRL) (optionally) to provide local certificate and CRL storage management functions. The SRL (optionally) provides remote directory retrieval capabilities using the Lightweight Directory Access Protocol (LDAP). The CML has been thoroughly tested including validating X.509 Certificates and CRLs created by a variety of Certification Authority (CA) products, and signed using the Digital Signature Algorithm (DSA) and RSA algorithms. Further enhancements, ports and testing of the CML are still in process. Further releases of the CML will be provided as significant capabilities are added. CML v2.4 includes the following enhancements (compared to v2.3 CML release): 1) Replaced the CTIL interface for the CML with a newly created PKCS#11 interface. 2) Implemention of a CRL server with support for the "Delta CRL" and "Freshest CRL" 2000 X.509 extensions. This architectural change is a step toward the CML's migration of OCSP compatability. 3) Enhanced the API to support the option for the application to request the CML log path building and validation events to aid in debugging and troubleshooting. 4) Enhanced the API to include callback functions to allow an application to perform its own revocation processing, rather than the crlapi library. 5) Added the capability to cache invalid certificates and CRLs. 6) Added a CRL grace period that can be specified by the application when creating a CML session. The grace period allows the application to specify the amount of time past a CRL's nextUpdate during which the CML will treat the CRL as still current. v2.4 SRL includes the following enhancements (compared to v2.3 SRL release): 1) Modified the default crlRefreshPeriod from 0 to LONG_MAX when CML creates an SRL session. When zero, the CRLs in the database were always being treated as stale; the new default is the always treat them as fresh. 2) Added a location mask to SRL_URLrequestObjs() so the caller can specify whether to search the local databse, the remote server, or both. 3) Enhnaced LDAPInitSettings_struct with a timeout field that controls how long to wait for the ldap_result() function. Previously, the timeout was hardcoded to 30 seconds. All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees. The CML was originally developed by the U.S. Government. DigitalNet is enhancing and supporting the CML under contract to the U.S. Government. The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software. The CML makes calls to an algorithm-independent CTIL API that provides access to a variety of external crypto libraries. There is a CTIL for each crypto library that maps the generic CTIL API calls to the specific calls for that crypto library. DigitalNet provides CTILs for the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used with the CML. The underlying, external crypto libraries are not distributed as part of the CML software. The CML has been successfully tested with the v2.4 S/MIME Freeware Library (SFL) that is freely available from . The CML has been successfully tested with the v2.4 Access Control Library (ACL) that is freely available to everyone from: . The CML has been successfully used to build and verify certificate paths used in the Bridge Certification Authority (BCA) demonstration which includes cross-certified hierarchical and non- hierarchical PKIs. The BCA Interoperability Test Suite (BITS) is a free and openly available test resource provided to facilitate vendor development of secure, interoperable Public Key Enabled applications. The CML has been used to successfully develop and verify the BITS X.509 certification paths available from . The National Institute of Standards and Technology (NIST) is providing a standard test suite of X.509 certificate paths that can be used for testing applications against RFC 2459. The CML was used to successfully process the NIST test data. The CML meets the requirements stated in the SDN.706 Certificate/ CRL Profile required by the U.S. Defense Message System (DMS) project. The Internet Mail Consortium (IMC) has established a CML web page and a CML mail list which is used to: distribute information regarding CML releases; discuss CML-related issues; and allow CML users to provide feedback, comments, bug reports, etc. Subscription information for the imc-cml mailing list is at the IMC web site listed above. All comments regarding the CML source code and documents are welcome. This CML release announcement was sent to several mail lists, but please send all messages regarding the CML to the imc-cml mail list ONLY. Please do not send messages regarding the CML to any of the IETF mail lists. We will respond to all messages sent to the imc-cml mail list. -- Matthew J. Bertapelle DigitalNet Government Solutions, LLC www.DigitalNet.com --------------050304030007060200030803 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
All,

DigitalNet Government Solutions has delivered the Version 2.4 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux.  The v2.4 CML and documentation is freely available at:
<http://www.digitalnet.com/knowledge/cml_home.htm>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.4 CML is described in the v2.4 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.4 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.6
Enhanced SNACC ASN.1 software that is freely available from:
<http://www.digitalnet.com/knowledge/snacc_home.htm>.

The CML provides robust certification path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  Further enhancements, 
ports and testing of the CML are still in process.  Further
releases of the CML will be provided as significant 
capabilities are added. 

CML v2.4 includes the following enhancements (compared to v2.3 CML release):

1) Replaced the CTIL interface for the CML with a newly created PKCS#11 interface.

2) Implemention of a CRL server with support for the "Delta CRL" and "Freshest CRL" 2000 X.509 extensions.  This architectural change is a step toward the CML's migration of OCSP compatability.

3) Enhanced the API to support the option for the application to request the CML log path building and validation events to aid in debugging and troubleshooting.

4) Enhanced the API to include callback functions to allow an application to perform its own revocation processing, rather than the crlapi library.

5) Added the capability to cache invalid certificates and CRLs.

6) Added a CRL grace period that can be specified by the application when creating a CML session.  The grace period allows the application to specify the amount of time past a CRL's nextUpdate during which the CML will treat the CRL as still current.

v2.4 SRL includes the following enhancements (compared to v2.3 SRL release):

1) Modified the default crlRefreshPeriod from 0 to LONG_MAX when CML creates an SRL session.  When zero, the CRLs in the database were always being treated as stale; the new default is the always treat them as fresh.

2) Added a location mask to SRL_URLrequestObjs() so the caller can specify whether to search the local databse, the remote server, or both.

3) Enhnaced LDAPInitSettings_struct with a timeout field that controls how long to wait for the ldap_result() function.  Previously, the timeout was hardcoded to 30 seconds.

 
All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees.  The CML was originally developed by the U.S. Government.  DigitalNet is enhancing and supporting the CML under contract to the U.S. Government.  The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software.
The CML makes calls to an algorithm-independent CTIL API that provides
access to a variety of external crypto libraries. There is a CTIL for
each crypto library that maps the generic CTIL API calls to the
specific calls for that crypto library. DigitalNet provides CTILs for
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and
FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used
with the CML. The underlying, external crypto libraries are not
distributed as part of the CML software.


The CML has been successfully tested with the v2.4 S/MIME Freeware
Library (SFL) that is freely available from
<http://www.DigitalNet.com/knowledge/sfl_home.htm>.

The CML has been successfully tested with the v2.4 Access Control
Library (ACL) that is freely available to everyone from:
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The CML has been successfully used to build and verify
certificate paths used in the Bridge Certification Authority (BCA)
demonstration which includes cross-certified hierarchical and non-
hierarchical PKIs. The BCA Interoperability Test Suite (BITS)
is a free and openly available test resource provided to
facilitate vendor development of secure, interoperable Public
Key Enabled applications. The CML has been used to successfully
develop and verify the BITS X.509 certification paths available
from <http://bcatest.atl.DigitalNet.com>.

The National Institute of Standards and Technology (NIST) is
providing a standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be
used for testing applications against RFC 2459. The CML was
used to successfully process the NIST test data.

The CML meets the requirements stated in the SDN.706 Certificate/
CRL Profile required by the U.S. Defense Message System (DMS)
project.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml> and a CML mail list which is used to:
distribute information regarding CML releases; discuss CML-related
issues; and allow CML users to provide feedback, comments, bug
reports, etc. Subscription information for the imc-cml mailing list
is at the IMC web site listed above.

All comments regarding the CML source code and documents are welcome.
This CML release announcement was sent to several mail lists, but
please send all messages regarding the CML to the imc-cml mail list
ONLY. Please do not send messages regarding the CML to any of the IETF
mail lists. We will respond to all messages sent to the imc-cml mail
list. 
-- 
Matthew J. Bertapelle
DigitalNet Government Solutions, LLC
www.DigitalNet.com

--------------050304030007060200030803-- From owner-ietf-pkix@mail.imc.org Tue Jun 29 16:45:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18432 for ; Tue, 29 Jun 2004 16:45:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJT9Iv017864; Tue, 29 Jun 2004 12:29:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJT928017863; Tue, 29 Jun 2004 12:29:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJT8Wk017857 for ; Tue, 29 Jun 2004 12:29:08 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11478; Tue, 29 Jun 2004 15:29:11 -0400 (EDT) Message-Id: <200406291929.PAA11478@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-04.txt Date: Tue, 29 Jun 2004 15:29:10 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Certification Path Building Author(s) : M. Cooper, et al. Filename : draft-ietf-pkix-certpathbuild-04.txt Pages : 74 Date : 2004-6-29 This document was written to provide guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate enabled application that can build valid certification paths across a wide range of PKI environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-certpathbuild-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-certpathbuild-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-29150236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-certpathbuild-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-certpathbuild-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29150236.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Tue Jun 29 16:48:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18941 for ; Tue, 29 Jun 2004 16:48:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJT4DO017854; Tue, 29 Jun 2004 12:29:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJT4hL017853; Tue, 29 Jun 2004 12:29:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJT3Jo017847 for ; Tue, 29 Jun 2004 12:29:03 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11471; Tue, 29 Jun 2004 15:29:06 -0400 (EDT) Message-Id: <200406291929.PAA11471@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ldap-crl-schema-02.txt Date: Tue, 29 Jun 2004 15:29:06 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure LDAP Schema for X.509 CRLs Author(s) : D. Chadwick, M. Sahalayev Filename : draft-ietf-pkix-ldap-crl-schema-02.txt Pages : 0 Date : 2004-6-29 This document describes an LDAP schema for X.509 CRLs. Each CRL is broken down into a set of attribute types. These attributes can then be stored in a CRL entry, or set of entries. Object classes are defined for these CRL entries. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ldap-crl-schema-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-29150229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ldap-crl-schema-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29150229.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Wed Jun 30 12:25:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27209 for ; Wed, 30 Jun 2004 12:25:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFFh0U006721; Wed, 30 Jun 2004 08:15:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFFhf3006720; Wed, 30 Jun 2004 08:15:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFFfo2006687 for ; Wed, 30 Jun 2004 08:15:42 -0700 (PDT) (envelope-from aalberti@axway.com) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i5UFFVKp028164 for ; Wed, 30 Jun 2004 17:15:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45EB5.14FFCE93" Subject: Cross-certification Date: Wed, 30 Jun 2004 17:15:30 +0200 Message-ID: Thread-Topic: Cross-certification Thread-Index: AcRetRPWyhao+cNrTA6QKJhWCo1ULw== From: "Alberti Antoine" To: X-OriginalArrivalTime: 30 Jun 2004 15:22:01.0140 (UTC) FILETIME=[FDAECF40:01C45EB5] X-Scanned-By: MIMEDefang 2.38 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C45EB5.14FFCE93 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Would there be any document where cross-certification and = non-hierarchical infrastructures are defined, please ? Regards. > = =20 > Antoine Alberti Axway. a Sopra Group company=09 > Tel : +33 (0)1 47 17 24 37 XFB R&D > Fax : +33 (0)1 47 17 24 25 26 Rue des Pavillons > email: aalberti@axway.com 92807 Puteaux Cedex - France >=20 >=20 >=20 ------_=_NextPart_001_01C45EB5.14FFCE93 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cross-certification

Would there be any document where = cross-certification and non-hierarchical infrastructures are defined, = please ?
Regards.

            =          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        

            = Antoine Alberti =         =         Axway.  a Sopra Group company  
            = Tel  : +33 (0)1 47 17 24 = 37     =         XFB = R&D
            = Fax : +33 (0)1 47 17 24 = 25      =         26 Rue des = Pavillons
            = email: = aalberti@axway.com       =         = 92807 Puteaux Cedex - = France



------_=_NextPart_001_01C45EB5.14FFCE93-- From owner-ietf-pkix@mail.imc.org Wed Jun 30 20:36:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03442 for ; Wed, 30 Jun 2004 20:36:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UNPfsK065247; Wed, 30 Jun 2004 16:25:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UNPfVA065246; Wed, 30 Jun 2004 16:25:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UNPeQs065222 for ; Wed, 30 Jun 2004 16:25:40 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5UNOVJ03748; Wed, 30 Jun 2004 16:24:31 -0700 (PDT) Message-Id: <200406302324.i5UNOVJ03748@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 3820 on Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 30 Jun 2004 16:24:30 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3820 Title: Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile Author(s): S. Tuecke, V. Welch, D. Engert, L. Pearlman M. Thompson Status: Standards Track Date: June 2004 Mailbox: tuecke@mcs.anl.gov, vwelch@ncsa.uiuc.edu, deengert@anl.gov, laura@isi.edu, mrthompson@lbl.gov Pages: 37 Characters: 86374 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-proxy-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3820.txt This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. This document is a product of the Public-Key Infrastructure (C.509) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040630162301.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3820 --OtherAccess Content-Type: Message/External-body; name="rfc3820.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040630162301.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UNPfsK065247; Wed, 30 Jun 2004 16:25:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UNPfVA065246; Wed, 30 Jun 2004 16:25:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UNPeQs065222 for ; Wed, 30 Jun 2004 16:25:40 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5UNOVJ03748; Wed, 30 Jun 2004 16:24:31 -0700 (PDT) Message-Id: <200406302324.i5UNOVJ03748@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 3820 on Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 30 Jun 2004 16:24:30 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3820 Title: Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile Author(s): S. Tuecke, V. Welch, D. Engert, L. Pearlman M. Thompson Status: Standards Track Date: June 2004 Mailbox: tuecke@mcs.anl.gov, vwelch@ncsa.uiuc.edu, deengert@anl.gov, laura@isi.edu, mrthompson@lbl.gov Pages: 37 Characters: 86374 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-proxy-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3820.txt This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. This document is a product of the Public-Key Infrastructure (C.509) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040630162301.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3820 --OtherAccess Content-Type: Message/External-body; name="rfc3820.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040630162301.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFFh0U006721; Wed, 30 Jun 2004 08:15:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFFhf3006720; Wed, 30 Jun 2004 08:15:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFFfo2006687 for ; Wed, 30 Jun 2004 08:15:42 -0700 (PDT) (envelope-from aalberti@axway.com) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i5UFFVKp028164 for ; Wed, 30 Jun 2004 17:15:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45EB5.14FFCE93" Subject: Cross-certification Date: Wed, 30 Jun 2004 17:15:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cross-certification Thread-Index: AcRetRPWyhao+cNrTA6QKJhWCo1ULw== From: "Alberti Antoine" To: X-OriginalArrivalTime: 30 Jun 2004 15:22:01.0140 (UTC) FILETIME=[FDAECF40:01C45EB5] X-Scanned-By: MIMEDefang 2.38 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C45EB5.14FFCE93 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Would there be any document where cross-certification and = non-hierarchical infrastructures are defined, please ? Regards. > = =20 > Antoine Alberti Axway. a Sopra Group company=09 > Tel : +33 (0)1 47 17 24 37 XFB R&D > Fax : +33 (0)1 47 17 24 25 26 Rue des Pavillons > email: aalberti@axway.com 92807 Puteaux Cedex - France >=20 >=20 >=20 ------_=_NextPart_001_01C45EB5.14FFCE93 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cross-certification

Would there be any document where = cross-certification and non-hierarchical infrastructures are defined, = please ?
Regards.

            =          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        

            = Antoine Alberti =         =         Axway.  a Sopra Group company  
            = Tel  : +33 (0)1 47 17 24 = 37     =         XFB = R&D
            = Fax : +33 (0)1 47 17 24 = 25      =         26 Rue des = Pavillons
            = email: = aalberti@axway.com       =         = 92807 Puteaux Cedex - = France



------_=_NextPart_001_01C45EB5.14FFCE93-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJT9Iv017864; Tue, 29 Jun 2004 12:29:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJT928017863; Tue, 29 Jun 2004 12:29:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJT8Wk017857 for ; Tue, 29 Jun 2004 12:29:08 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11478; Tue, 29 Jun 2004 15:29:11 -0400 (EDT) Message-Id: <200406291929.PAA11478@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-04.txt Date: Tue, 29 Jun 2004 15:29:10 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure: Certification Path Building Author(s) : M. Cooper, et al. Filename : draft-ietf-pkix-certpathbuild-04.txt Pages : 74 Date : 2004-6-29 This document was written to provide guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate enabled application that can build valid certification paths across a wide range of PKI environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-certpathbuild-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-certpathbuild-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-29150236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-certpathbuild-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-certpathbuild-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29150236.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJT4DO017854; Tue, 29 Jun 2004 12:29:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJT4hL017853; Tue, 29 Jun 2004 12:29:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJT3Jo017847 for ; Tue, 29 Jun 2004 12:29:03 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11471; Tue, 29 Jun 2004 15:29:06 -0400 (EDT) Message-Id: <200406291929.PAA11471@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ldap-crl-schema-02.txt Date: Tue, 29 Jun 2004 15:29:06 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure LDAP Schema for X.509 CRLs Author(s) : D. Chadwick, M. Sahalayev Filename : draft-ietf-pkix-ldap-crl-schema-02.txt Pages : 0 Date : 2004-6-29 This document describes an LDAP schema for X.509 CRLs. Each CRL is broken down into a set of attribute types. These attributes can then be stored in a CRL entry, or set of entries. Object classes are defined for these CRL entries. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ldap-crl-schema-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-29150229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ldap-crl-schema-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29150229.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QCD7IB070036; Sat, 26 Jun 2004 05:13:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5QCD73b070033; Sat, 26 Jun 2004 05:13:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from 21cn.com (send.forptr.21cn.com [61.140.60.50]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5QCD3rN070010; Sat, 26 Jun 2004 05:13:04 -0700 (PDT) (envelope-from matt.bertapelle@DigitalNet.com) Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm040dd8058; Sat, 26 Jun 2004 20:14:22 +0800 Received: from 21cn.com([10.2.1.9]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Sat, 26 Jun 2004 20:14:21 +0800 Received: from above.proper.com([10.2.100.8]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm4c40d8d44a; Wed, 23 Jun 2004 02:13:59 +0800 Received: from above.proper.com([208.184.76.39]) by 21cn.com(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 23 Jun 2004 02:12:21 +0800 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8MEI082873; Tue, 22 Jun 2004 11:08:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MI8MvE082871; Tue, 22 Jun 2004 11:08:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from vahqex2.digitalnet.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8KRk082854; Tue, 22 Jun 2004 11:08:20 -0700 (PDT) (envelope-from Matt.Bertapelle@DigitalNet.com) Received: from [158.189.2.56] ([158.189.2.56]) by vahqex2.digitalnet.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jun 2004 14:08:23 -0400 Message-ID: <40D87595.50406@digitalnet.com> Date: Tue, 22 Jun 2004 14:08:21 -0400 From: Matt Bertapelle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: imc-cml , imc-sfl , ietf-pkix@imc.org Subject: v2.4 Certificate Management Library (CML) Now Available Content-Type: multipart/alternative; boundary="------------050304030007060200030803" X-OriginalArrivalTime: 22 Jun 2004 18:08:23.0571 (UTC) FILETIME=[E85EE630:01C45883] List-Archive: List-ID: List-Unsubscribe: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-pkix@mail.imc.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: matt.bertapelle@DigitalNet.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------050304030007060200030803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, DigitalNet Government Solutions has delivered the Version 2.4 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux. The v2.4 CML and documentation is freely available at: . Applications requiring Public Key Infrastructure (PKI) security services can use the CML to meet their X.509 certificate and Certificate Revocation List (CRL) processing requirements. The v2.4 CML is described in the v2.4 CML Application Programming Interface (API) document. It implements the 2000 X.509 Recommendation certification path verification processing rules and SDN.706 profile. It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile requirements. There are some unsupported features such as Delta CRLs. The v2.4 CML Abstract Syntax Notation One (ASN.1) decodes X.509 Certificates and CRLs. It requires the v1.6 Enhanced SNACC ASN.1 software that is freely available from: . The CML provides robust certification path building capabilities such as using cross certificates. The CML uses the accompanying Storage and Retrieval Library (SRL) (optionally) to provide local certificate and CRL storage management functions. The SRL (optionally) provides remote directory retrieval capabilities using the Lightweight Directory Access Protocol (LDAP). The CML has been thoroughly tested including validating X.509 Certificates and CRLs created by a variety of Certification Authority (CA) products, and signed using the Digital Signature Algorithm (DSA) and RSA algorithms. Further enhancements, ports and testing of the CML are still in process. Further releases of the CML will be provided as significant capabilities are added. CML v2.4 includes the following enhancements (compared to v2.3 CML release): 1) Replaced the CTIL interface for the CML with a newly created PKCS#11 interface. 2) Implemention of a CRL server with support for the "Delta CRL" and "Freshest CRL" 2000 X.509 extensions. This architectural change is a step toward the CML's migration of OCSP compatability. 3) Enhanced the API to support the option for the application to request the CML log path building and validation events to aid in debugging and troubleshooting. 4) Enhanced the API to include callback functions to allow an application to perform its own revocation processing, rather than the crlapi library. 5) Added the capability to cache invalid certificates and CRLs. 6) Added a CRL grace period that can be specified by the application when creating a CML session. The grace period allows the application to specify the amount of time past a CRL's nextUpdate during which the CML will treat the CRL as still current. v2.4 SRL includes the following enhancements (compared to v2.3 SRL release): 1) Modified the default crlRefreshPeriod from 0 to LONG_MAX when CML creates an SRL session. When zero, the CRLs in the database were always being treated as stale; the new default is the always treat them as fresh. 2) Added a location mask to SRL_URLrequestObjs() so the caller can specify whether to search the local databse, the remote server, or both. 3) Enhnaced LDAPInitSettings_struct with a timeout field that controls how long to wait for the ldap_result() function. Previously, the timeout was hardcoded to 30 seconds. All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees. The CML was originally developed by the U.S. Government. DigitalNet is enhancing and supporting the CML under contract to the U.S. Government. The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software. The CML makes calls to an algorithm-independent CTIL API that provides access to a variety of external crypto libraries. There is a CTIL for each crypto library that maps the generic CTIL API calls to the specific calls for that crypto library. DigitalNet provides CTILs for the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used with the CML. The underlying, external crypto libraries are not distributed as part of the CML software. The CML has been successfully tested with the v2.4 S/MIME Freeware Library (SFL) that is freely available from . The CML has been successfully tested with the v2.4 Access Control Library (ACL) that is freely available to everyone from: . The CML has been successfully used to build and verify certificate paths used in the Bridge Certification Authority (BCA) demonstration which includes cross-certified hierarchical and non- hierarchical PKIs. The BCA Interoperability Test Suite (BITS) is a free and openly available test resource provided to facilitate vendor development of secure, interoperable Public Key Enabled applications. The CML has been used to successfully develop and verify the BITS X.509 certification paths available from . The National Institute of Standards and Technology (NIST) is providing a standard test suite of X.509 certificate paths that can be used for testing applications against RFC 2459. The CML was used to successfully process the NIST test data. The CML meets the requirements stated in the SDN.706 Certificate/ CRL Profile required by the U.S. Defense Message System (DMS) project. The Internet Mail Consortium (IMC) has established a CML web page and a CML mail list which is used to: distribute information regarding CML releases; discuss CML-related issues; and allow CML users to provide feedback, comments, bug reports, etc. Subscription information for the imc-cml mailing list is at the IMC web site listed above. All comments regarding the CML source code and documents are welcome. This CML release announcement was sent to several mail lists, but please send all messages regarding the CML to the imc-cml mail list ONLY. Please do not send messages regarding the CML to any of the IETF mail lists. We will respond to all messages sent to the imc-cml mail list. -- Matthew J. Bertapelle DigitalNet Government Solutions, LLC www.DigitalNet.com --------------050304030007060200030803 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
All,

DigitalNet Government Solutions has delivered the Version 2.4 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux.  The v2.4 CML and documentation is freely available at:
<http://www.digitalnet.com/knowledge/cml_home.htm>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.4 CML is described in the v2.4 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.4 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.6
Enhanced SNACC ASN.1 software that is freely available from:
<http://www.digitalnet.com/knowledge/snacc_home.htm>.

The CML provides robust certification path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  Further enhancements, 
ports and testing of the CML are still in process.  Further
releases of the CML will be provided as significant 
capabilities are added. 

CML v2.4 includes the following enhancements (compared to v2.3 CML release):

1) Replaced the CTIL interface for the CML with a newly created PKCS#11 interface.

2) Implemention of a CRL server with support for the "Delta CRL" and "Freshest CRL" 2000 X.509 extensions.  This architectural change is a step toward the CML's migration of OCSP compatability.

3) Enhanced the API to support the option for the application to request the CML log path building and validation events to aid in debugging and troubleshooting.

4) Enhanced the API to include callback functions to allow an application to perform its own revocation processing, rather than the crlapi library.

5) Added the capability to cache invalid certificates and CRLs.

6) Added a CRL grace period that can be specified by the application when creating a CML session.  The grace period allows the application to specify the amount of time past a CRL's nextUpdate during which the CML will treat the CRL as still current.

v2.4 SRL includes the following enhancements (compared to v2.3 SRL release):

1) Modified the default crlRefreshPeriod from 0 to LONG_MAX when CML creates an SRL session.  When zero, the CRLs in the database were always being treated as stale; the new default is the always treat them as fresh.

2) Added a location mask to SRL_URLrequestObjs() so the caller can specify whether to search the local databse, the remote server, or both.

3) Enhnaced LDAPInitSettings_struct with a timeout field that controls how long to wait for the ldap_result() function.  Previously, the timeout was hardcoded to 30 seconds.

 
All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees.  The CML was originally developed by the U.S. Government.  DigitalNet is enhancing and supporting the CML under contract to the U.S. Government.  The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software.
The CML makes calls to an algorithm-independent CTIL API that provides
access to a variety of external crypto libraries. There is a CTIL for
each crypto library that maps the generic CTIL API calls to the
specific calls for that crypto library. DigitalNet provides CTILs for
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and
FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used
with the CML. The underlying, external crypto libraries are not
distributed as part of the CML software.


The CML has been successfully tested with the v2.4 S/MIME Freeware
Library (SFL) that is freely available from
<http://www.DigitalNet.com/knowledge/sfl_home.htm>.

The CML has been successfully tested with the v2.4 Access Control
Library (ACL) that is freely available to everyone from:
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The CML has been successfully used to build and verify
certificate paths used in the Bridge Certification Authority (BCA)
demonstration which includes cross-certified hierarchical and non-
hierarchical PKIs. The BCA Interoperability Test Suite (BITS)
is a free and openly available test resource provided to
facilitate vendor development of secure, interoperable Public
Key Enabled applications. The CML has been used to successfully
develop and verify the BITS X.509 certification paths available
from <http://bcatest.atl.DigitalNet.com>.

The National Institute of Standards and Technology (NIST) is
providing a standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be
used for testing applications against RFC 2459. The CML was
used to successfully process the NIST test data.

The CML meets the requirements stated in the SDN.706 Certificate/
CRL Profile required by the U.S. Defense Message System (DMS)
project.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml> and a CML mail list which is used to:
distribute information regarding CML releases; discuss CML-related
issues; and allow CML users to provide feedback, comments, bug
reports, etc. Subscription information for the imc-cml mailing list
is at the IMC web site listed above.

All comments regarding the CML source code and documents are welcome.
This CML release announcement was sent to several mail lists, but
please send all messages regarding the CML to the imc-cml mail list
ONLY. Please do not send messages regarding the CML to any of the IETF
mail lists. We will respond to all messages sent to the imc-cml mail
list. 
-- 
Matthew J. Bertapelle
DigitalNet Government Solutions, LLC
www.DigitalNet.com

--------------050304030007060200030803-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OJ043J086727; Thu, 24 Jun 2004 12:00:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OJ04Wk086725; Thu, 24 Jun 2004 12:00:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av2-1-sn3.vrr.skanova.net (av2-1-sn3.vrr.skanova.net [81.228.9.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OJ03rg086675 for ; Thu, 24 Jun 2004 12:00:03 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id CAA4B37EA3; Thu, 24 Jun 2004 20:59:53 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id BD61337E45; Thu, 24 Jun 2004 20:59:53 +0200 (CEST) Received: from arport (t8o913p20.telia.com [213.64.26.140]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id E2DD538007; Thu, 24 Jun 2004 20:59:51 +0200 (CEST) Message-ID: <00b501c45a1d$21856c00$0500a8c0@arport> From: "Anders Rundgren" To: "Ed Gerck" , "Joseph Doekbrijder" Cc: References: <006001c4588d$a95d3ef0$0500a8c0@arport> <40DA7C24.7040607@swisssign.com> <40DB08DC.1090705@nma.com> Subject: Re: New DN attribute - Problem or not? Date: Thu, 24 Jun 2004 20:57:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanx Guys, I think that you ansered another question which I did not put :-) But I agree with the "light" ID concept. Anders ----- Original Message ----- From: "Ed Gerck" To: "Joseph Doekbrijder" Cc: "Anders Rundgren" ; Sent: Thursday, June 24, 2004 19:01 Subject: Re: New DN attribute - Problem or not? Joseph Doekbrijder wrote: >... > I still favour the approach to have a little information as possible in > a certificate ... Yes, also because the more fields (attributes) you have in a cert, the lesser its useful lifetime. The lifetime of a cert is the inversely proportional to the sum of the inverse lifetime of each attribute: 1/T ~ 1/A1 + 1/A2 + ... In particular, the lifetime of a certificate is less than the lifetime of any of its attributes. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OH1P8A074555; Thu, 24 Jun 2004 10:01:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OH1Pt8074554; Thu, 24 Jun 2004 10:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail1.atl.registeredsite.com (nobody@mail1.atl.registeredsite.com [64.224.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OH1Oob074548 for ; Thu, 24 Jun 2004 10:01:25 -0700 (PDT) (envelope-from egerck@nma.com) Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail1.atl.registeredsite.com (8.12.11/8.12.8) with ESMTP id i5OH1RiX031204; Thu, 24 Jun 2004 17:01:27 GMT Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Thu, 24 Jun 2004 12:01:26 -0500 Message-ID: <40DB08DC.1090705@nma.com> Date: Thu, 24 Jun 2004 10:01:16 -0700 From: Ed Gerck User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Doekbrijder CC: Anders Rundgren , ietf-pkix@imc.org Subject: Re: New DN attribute - Problem or not? References: <006001c4588d$a95d3ef0$0500a8c0@arport> <40DA7C24.7040607@swisssign.com> In-Reply-To: <40DA7C24.7040607@swisssign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Joseph Doekbrijder wrote: >... > I still favour the approach to have a little information as possible in > a certificate ... Yes, also because the more fields (attributes) you have in a cert, the lesser its useful lifetime. The lifetime of a cert is the inversely proportional to the sum of the inverse lifetime of each attribute: 1/T ~ 1/A1 + 1/A2 + ... In particular, the lifetime of a certificate is less than the lifetime of any of its attributes. Cheers, Ed Gerck Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O71H41039613; Thu, 24 Jun 2004 00:01:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O71HfI039612; Thu, 24 Jun 2004 00:01:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.2wire.ch (mail.2wire.ch [62.65.128.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O71FaC039433 for ; Thu, 24 Jun 2004 00:01:16 -0700 (PDT) (envelope-from joseph.doekbrijder@swisssign.com) Received: (qmail 5234 invoked by uid 89); 24 Jun 2004 07:00:56 -0000 Received: from unknown (HELO swisssign.com) (62.65.151.222) by mail.2wire.ch with SMTP; 24 Jun 2004 07:00:56 -0000 Message-ID: <40DA7C24.7040607@swisssign.com> Date: Thu, 24 Jun 2004 09:00:52 +0200 From: Joseph Doekbrijder Organization: SwissSign AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-ch, en-us, en, fr-ch MIME-Version: 1.0 To: Anders Rundgren CC: ietf-pkix@imc.org Subject: Re: New DN attribute - Problem or not? References: <006001c4588d$a95d3ef0$0500a8c0@arport> In-Reply-To: <006001c4588d$a95d3ef0$0500a8c0@arport> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050006070706010607070001" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050006070706010607070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Anders This issue would ad yet another variable to the stuff that can be put into the cert. But since we can make PKI work without all these variables (all we need in a cert, really, is a name and an emailaddress) there is no need for it. I do understand that certain environments would be helped with such a "fix" variable but there are very elegant solutions available to solve these requirements in other ways.... I still favour the approach to have a little information as possible in a certificate (Ideally they are empty :-) ) Cheers Josh -- Joseph A. Doekbrijder -------------------------------------------------- SwissSign AG Löwenstrasse 1, CH-8001 Zürich Tel: +41 43 344 88 11 / Mobile: +41 79 211 24 46 www.swisssign.com -------------------------------------------------- This message has been digitally signed to ensure unaltered and authenticated reception. Should you receive an error message regarding the validity of the signature, please click and download the SwissSign root certificate using the following link https://swisssign.net/trust/ After installation, your mail client will be able to automatically verify the authenticity of e-mail messages sent to you by users of SwissSign certificates. Anders Rundgren wrote: >Sombody suggested (extract from a PI discussion): > > "That attribute could be a generic "URI" attribute (like the > email address attribute), which could be referenced (like SN) > from a future version of the PI RFC, or it could > be a specific "PI Authority" attribute which would eliminate > the need for the PI SubjectAltName extension entirely for > PKIs that adopt that attribute." > >Question: Is it a viable approach to introduce new DN attributes >from an interoperability point of view? > >Anders > > > --------------ms050006070706010607070001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWiTCC A2EwggJJoAMCAQICCGQgZ70rBHuyMA0GCSqGSIb3DQEBBQUAMGkxIzAhBgNVBAMTGlN3aXNz U2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5j b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMjExMTQzOTA1WhcN MDQxMjExMTQzOTA1WjB4MSQwIgYDVQQDExtKb3NlcGggQW50b25pdXMgRG9la2JyaWpkZXIx LzAtBgkqhkiG9w0BCQEWIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMRIwEAYD VQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCpc7LucWH/EP2YmDBOMZVmPzy8JfYovxAL8wbfuXjFQLg4/orh+8AonyozzaK0fJzFw/D4 46z3siNvu065E6AKM3BFPSsyS5RrUPnYjtxcLAmfv+OsR5gAMA1hhsS571XCWaVPvEuCIltW RvpcKVeuAsdpR6p7eW7UPQuO0EgR4QIDAQABo4GBMH8wHwYDVR0jBBgwFoAU8jaGz72k1nnf MpmM0FlpHQWVLIYwDgYDVR0PAQH/BAQDAgQwMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQGCCsG AQUFBwMEMCsGA1UdEQQkMCKBIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMA0G CSqGSIb3DQEBBQUAA4IBAQBY4/HrZkMYrF0LKNWpDrYTbEM7wRjHKtpjMHWb1DlAm1qRBWAB 0Ns/jyCHLedGlRydHuVPh+THO9PPgRESIWoWq88uz+gpue3A4DWpuk7BqrYKXFfKTa1uKsfE L62LJ0cO8Q09aCkkEpETL8u92s68328QPhSgFmX5wgToyG3Vw2EOMTcbCeKFRYSkZTywe2NV IMkDKKUDuRYBYZZ1Db8P3SzF26bszuUH+4HsbgIg8K+mrEeln9aHpbujAUVx8huCpYR25Ziz rtK2vHmDd2VQUfOs+gA4dns7Ys+sOYXYWn2ZvXycCirQktDuaOTAxRXrBXByGLTNDsJBsNQI FbZdMIIDqTCCApGgAwIBAgIIXLEyej+EomAwDQYJKoZIhvcNAQEFBQAwZDEcMBoGA1UEAxMT U3dpc3NTaWduIFNpbHZlciBDQTEjMCEGCSqGSIb3DQEJARYUc2lsdmVyQHN3aXNzc2lnbi5j b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDEyMTEzODIyWhcN MTUxMDA2MTMzNjU3WjBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3 DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYT AkNIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAstKfzDugVAxC63Qhl8+Cko7T Kjh0aMls6o0iYfPE6LU9jRHGRE2FyEoI4+3EgotNIVEX7GOTtQUL3YRzkJ55T/urzNtWDead etokNxoH1KrYObxIuFeSyepEN/QKcNedliNqwGF3wPqKCGna554QeyV44pRhvNH3+hFL3Mz3 Tazf2wtmE/et/JSAFFUPWfSqrugURE1G2kaB9o2tt/BFtEjslSD41D9g7nexjvgHDyRKsoY3 FoEHexV/ttvFZNzGJJ7NLwgC84JvCdLi3RvNyGfiWnqkjuRdQOohAsWNJcjn7aoksB5y/Ipr BjsivtY/LBYQ7zq+Sc8v+8bf3T1lzwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUtGz1MEEswDyRjDQnY/pVvPzntD8wHwYDVR0jBBgwFoAU EvoMgVv/f9El2B5zMDUPRhg2snUwDQYJKoZIhvcNAQEFBQADggEBADG0plqQXp/SAJjFJYax q1R+3LaDheER1IgXaIem+nofwcBaCvEP+vkWkEuBwFbvI97tKlO6oY1WtVlJHbkfHXcvRAiv s8W9EbuQlXJ9g1J+ZKJbnI/KmTwsNYvHj5PBe9+PwvA1oZwTJDEEBSaUcdOxaNw3ceka7oTd dWXfAWUhGXDmS3O2yTHVovUrFAshmYEz9r4YRvbUzkKYcP12zOu2UmdrCOzSWua2EOuSimLM se00IOJTlhJMfL+ly6O8G1MA7wTqKkSgnDbVe0XsMQYmSJaiVqSkRGIUYE7mvlq9YKCguBZ1 fpmurO0BeWvmzZxZT/7VBjcfMzwS1tZ4CeAwggOuMIIClqADAgECAggQSAsMRGstRTANBgkq hkiG9w0BAQUFADBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3DQEJ ARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNI MB4XDTAzMTAxMjExNTgyMloXDTA2MTAxMjExNTgyMlowaTEjMCEGA1UEAxMaU3dpc3NTaWdu IFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNvbTES MBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMZmnWhcHmQ8GZB+9uoZyb+LmqUqYRWWL6vSFwWMSQdtn7aMT0zVI1N37y2I LN5/KurG53SonxgMfwqsxgdD3jI77yyJwsN0aMdBDotcL+pXSJqlC1gpDsVHtMIyQs5PqYTx Y3uUJVbBERchLFLv/2VJ0iBGXg009lyNVULa9VFcG/F2UF34YranOWBW4OSQowf1kJYNXr4A eKhpLnNhv30/fdIMRrihygQCPaMJ0nQAEuBVbFSfOUQPvMDDBwYKC+yMkcm5QWgnVGXAeyrA x7k8+rKPfNbYqnyeL9aAnyUMkYm6FtUsaM5I6HNWJY63gfqqPeprFuogZNY1Rwq2mNMCAwEA AaNjMGEwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPI2hs+9 pNZ53zKZjNBZaR0FlSyGMB8GA1UdIwQYMBaAFLRs9TBBLMA8kYw0J2P6Vbz857Q/MA0GCSqG SIb3DQEBBQUAA4IBAQCuHGJh9r2LiKenYuA4Imi1TZ0YWVB0o2Kfo6HD3CPZwavyPzXiShM0 0PGIoX/bs+K36PYj24E6gdp78B4hzqPP525wUapDy/WX8nur8XbrcdEwffWy+Cmz593an7Xy iFl18wIDGLGkpGpwtM/Jiu2QLUughU7Eh0/i6R1+oUPLF9wYcB0eoYnDBK0KWFvTEWkLAWYb F45PV4tsBXWI+UTQBB93rgdjQbJNxSv7K/kLAQY/mWs9fF2jp4X8+UMthm28TkHE7VAok0md Ma9x3X1ZrMDmb3ijkUxwJhFewelg9vMZdcXUHjezw5J83L5I8aBQmfKIHLDEg2XVcQUhMi/B MIIDwDCCAqigAwIBAgIJAOjyHqbBu/cuMA0GCSqGSIb3DQEBBQUAMHYxCzAJBgNVBAYTAkNI MRIwEAYDVQQKEwlTd2lzc1NpZ24xMjAwBgNVBAMTKVN3aXNzU2lnbiBDQSAoUlNBIElLIE1h eSA2IDE5OTkgMTg6MDA6NTgpMR8wHQYJKoZIhvcNAQkBFhBjYUBTd2lzc1NpZ24uY29tMB4X DTAzMTAwNjEzMzY1N1oXDTE1MTAwNjEzMzY1N1owZDEcMBoGA1UEAxMTU3dpc3NTaWduIEJy b256ZSBDQTEjMCEGCSqGSIb3DQEJARYUYnJvbnplQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoT CVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDA0TvGY7vE2Z2U4Ootl3tb6AZN4SPTTN6HYMyzL9OeKWzlMfnwJqEzv4yjkFMcaStrmyRO PMkwLEWcd3FiaxKBmr0eCN9ybgZuhKvSxYfaqcM5QAgPqK6yA2WQ+sgWAUlEH4PdhCUYd84q eOlswzzrtbggVWQsbh/LoT7edOeBJlDiIHufmmXTl5X7psFIImkWJbnegd7fidhRuUxMJF0X LcA/9WaJzZDZSmGONRSP+WOzlM/o4xunjPwIoCWKSIo9NMWtJ29az01/TcLehpyMjQg7a+PJ 3yFtl5PbS25Jm7W9IopISNPGYzucjOIVKYo9BQ5F32lGn8NJl418yNttAgMBAAGjYzBhMA4G A1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRygIjtngs9r6moa09a F+LUoY5lJDAfBgNVHSMEGDAWgBSW13HNOSrU/IixiqtTeGnvj0d+FjANBgkqhkiG9w0BAQUF AAOCAQEApFfZjNGeQ7OtxCPI3mI1rjF2gbxMTMtMeJeaxH2QSJsrvcKRQ29v0wzDLMmeKFR8 d3B8PDh8aqw2IGz1X3FcIn7CUTdoOvFCGuW0SpdvKzgt3RVOpp4HFcfMK6mxubSHCBV6f66A UyxbK+Sv7Rpwn3BZ6AYndMzYMEk6IrAvrurIz6h2DTrwEO3oH1GKRpYljlcoh+mKEnvZit6b vGNcLpLTMZNe+0dlKzw1uHNI9gqteNqn/BqunMDAqPcBX4uZ0em7P/ZJ8+SACnsz96+R5MSV EeoFqWQoRQAxNgjUXTy0xYa4cGRqeXtTO/s3mKgDBWktCFXU0f0kb0IQIBmGqDCCA/gwggLg oAMCAQICCQDemCdyDdsdVTANBgkqhkiG9w0BAQUFADBkMRwwGgYDVQQDExNTd2lzc1NpZ24g QnJvbnplIENBMSMwIQYJKoZIhvcNAQkBFhRicm9uemVAc3dpc3NzaWduLmNvbTESMBAGA1UE ChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDAeFw0wMzEwMTIxMTM2MzJaFw0xNTEwMDYxMzM2 NTdaMGQxHDAaBgNVBAMTE1N3aXNzU2lnbiBTaWx2ZXIgQ0ExIzAhBgkqhkiG9w0BCQEWFHNp bHZlckBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzPdBfCH+e+kxpt0cSTkKm1pJXXdRCNJ8 mrbsNpuX2O290pzz1dEF7DKFCH+k9bm8Yqj1KgyhKrt7JoNGUHW83sU+8jjrYG/ZPrfusCH+ 4iiVZciBCvPdM1t0qvPZvWrKVYdIb+3t8aQz8+L08zFLdkxG49M+4cMW5srECPy4YJ3kJzVr awrXBMAchqviMngsyWuKw5qV5FA9pp36wDsumItoZXL3BOsMsU2lh3z/OLhDpXA5D83mgEOW RbqkfSWyaT1lcIuoMZ/XMdT8ahU+3GWnZ8O9tQFg0//SfrlT3Zsp7Hhx0XEtsuIKQZTrsUHj QzR+bk9RlKLz3Sy5nxPRRQIDAQABo4GsMIGpMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBQS+gyBW/9/0SXYHnMwNQ9GGDaydTAfBgNVHSMEGDAWgBRygIjt ngs9r6moa09aF+LUoY5lJDBGBgNVHR8EPzA9MDugOaA3hjVodHRwczovL3N3aXNzc2lnbi5u ZXQvY2dpLWJpbi9hdXRob3JpdHkvY3JsP2NhPUJyb256ZTANBgkqhkiG9w0BAQUFAAOCAQEA qaVWxVi644azmxYNNglkRVA5pFsU3zN4zepYrjEmamFgGROsNKYCwf06cGDHXsJyxZzkzFPG FTR5/pRLoDWnEuFgfm+a6XA9qTUecun+909Dkz8EbNk/KsWaGEG+HxMjwnusctjeWhO32rRH +AWJW9VhNR+ggbkGwbVadRClY7359ChoWTwkySWb2hjTZU3BOnqAOYJ2QPKiWMrGODN9Jo94 +hfxcD6o08ak5KY/5Bza4EEL/sbS/quhoCZsg8TBD4+KeXgbVqU9XlPHk/gq1RTy49SPmRkQ lgwFSvQRRAD/5oQX3ZKxhXAVsEYHyGvqCsFvXWKagulb5NjNdD0pyTCCBAEwggLpoAMCAQIC CQCVT/juYWAhTDANBgkqhkiG9w0BAQUFADBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29u YWwgR29sZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQK EwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTIxMDIxNDAwMVoXDTA0MTIxMDIxNDAw MVoweDEkMCIGA1UEAxMbSm9zZXBoIEFudG9uaXVzIERvZWticmlqZGVyMS8wLQYJKoZIhvcN AQkBFiBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NT aWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJVGvsFb 4Ufs++D4cxTnv2yHvmLjKZQ2qfPT7YO2dfffZbiba4qkKQ8xLE05D1EqlLvXm+4dRksjDhty OzwZeWajZ/TGwPgP3jXOURlqkyhVrX0kt5EzW5EokcMC/Ais422LqtJ5kq2nOvK7NGYtevS0 pMbHi5NZtkWUwVZaRjjOJaTGO2xDkjAOdYIyI8vdEIedJIW6LGHIZsYjI+yW7sUlI6hCXhrV nsmdu/shG/TTsvDQUW28Yl7/l/uvikFsuy4erDKDHcbth/xKsI/KkfX40jGqGI0SlQ7fHBph DwbnbOKJJSu1wgMT1dvuwLyFEBqyf0OSPZROpK11T3d2LdcCAwEAAaOBnDCBmTAfBgNVHSME GDAWgBTyNobPvaTWed8ymYzQWWkdBZUshjAOBgNVHQ8BAf8EBAMCA8gwKQYDVR0lBCIwIAYI KwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3FAICMDsGA1UdEQQ0MDKgMAYKKwYBBAGCNxQC A6AiDCBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTANBgkqhkiG9w0BAQUFAAOC AQEAZTUBqQgk5nB+0W7Mozv/uD6lRurjZhWShstlaQ43qvVHcsDgb4mW/bynla9BDmM/NsQU 43ZsoFxjkJsxFCpgm5BuMt1KuD7FSHJ0mxRswaGf9mHxftU1cu/YhY/AjrsFHEnsPHZaYAAm jcKunHgT+yckvUZR3RQDkgVE4PQ3YpsG1EPKQSEAFbmWAd4+TxJmuBXThDM63gOkY4Q7gE1b Y1kjkdRlJ2TZ/gOItQ3AsfwS7mq+ANYnUBrWkrnUd85Nmgzv5ys7zxuz9tp64vS+xYW98mri ruGl9stN/b7SbOFTsp8SUm83e9qPOQZRYPS6TYYKUObj3LbaXJEIqKD51DGCA2IwggNeAgEB MHYwaTEjMCEGA1UEAxMaU3dpc3NTaWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0B CQEWEmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJD SAIJAJVP+O5hYCFMMAkGBSsOAwIaBQCgggHBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDYyNDA3MDA1MlowIwYJKoZIhvcNAQkEMRYEFJXKgI0kUfcd 0lfVVEmwmavBy4JzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGEBgkrBgEEAYI3 EAQxdzB1MGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZI hvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UE BhMCQ0gCCGQgZ70rBHuyMIGGBgsqhkiG9w0BCRACCzF3oHUwaTEjMCEGA1UEAxMaU3dpc3NT aWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNv bTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSAIIZCBnvSsEe7IwDQYJKoZIhvcN AQEBBQAEggEAkTHygBu9Qb1DMc3GQxYu4u7dVzbr7TUF87kyAqwZuadLLUy/LCGfwuZJTJVi SOHW6j6Qb90WtW24HSRIS4gMfInlIZYMUy15OI0in+2kerbqgzCfM2WA9+YnU/PDqRwaMdzr GBcnVqEx3sVVBYwBwH0Z+vKvU7oT+8T+uM4KzRTcJW8qc1FVxh0uxf2+ku3H6k338hORWeig 5qO/RvM1pFV4Pi44TBGgFTMF+6zyOEyoHNRQPOm4tpJcZepMez49pgWoZ4sAkwmHMUqJdTMk EqRta5ntL/1Bu4Dh5ewLsJuC/qYuWN0NC8Ru4Zur6iSNi1vgNeW6ZrEAUQ33u483uAAAAAAA AA== --------------ms050006070706010607070001-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJKSSA096922; Tue, 22 Jun 2004 12:20:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MJKSUW096921; Tue, 22 Jun 2004 12:20:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av9-1-sn1.fre.skanova.net (av9-1-sn1.fre.skanova.net [81.228.11.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJKStY096884 for ; Tue, 22 Jun 2004 12:20:28 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av9-1-sn1.fre.skanova.net (Postfix, from userid 502) id 8EE0337E71; Tue, 22 Jun 2004 21:20:20 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id 810B637E5E for ; Tue, 22 Jun 2004 21:20:20 +0200 (CEST) Received: from arport (t12o913p113.telia.com [213.64.28.233]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id B0E5F37E44 for ; Tue, 22 Jun 2004 21:20:19 +0200 (CEST) Message-ID: <006001c4588d$a95d3ef0$0500a8c0@arport> From: "Anders Rundgren" To: Subject: New DN attribute - Problem or not? Date: Tue, 22 Jun 2004 21:18:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sombody suggested (extract from a PI discussion): "That attribute could be a generic "URI" attribute (like the email address attribute), which could be referenced (like SN) from a future version of the PI RFC, or it could be a specific "PI Authority" attribute which would eliminate the need for the PI SubjectAltName extension entirely for PKIs that adopt that attribute." Question: Is it a viable approach to introduce new DN attributes from an interoperability point of view? Anders Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8MEI082873; Tue, 22 Jun 2004 11:08:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MI8MvE082871; Tue, 22 Jun 2004 11:08:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from vahqex2.digitalnet.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MI8KRk082854; Tue, 22 Jun 2004 11:08:20 -0700 (PDT) (envelope-from Matt.Bertapelle@DigitalNet.com) Received: from [158.189.2.56] ([158.189.2.56]) by vahqex2.digitalnet.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jun 2004 14:08:23 -0400 Message-ID: <40D87595.50406@digitalnet.com> Date: Tue, 22 Jun 2004 14:08:21 -0400 From: Matt Bertapelle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: imc-cml , imc-sfl , ietf-pkix@imc.org Subject: v2.4 Certificate Management Library (CML) Now Available Content-Type: multipart/alternative; boundary="------------050304030007060200030803" X-OriginalArrivalTime: 22 Jun 2004 18:08:23.0571 (UTC) FILETIME=[E85EE630:01C45883] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------050304030007060200030803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, DigitalNet Government Solutions has delivered the Version 2.4 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux. The v2.4 CML and documentation is freely available at: . Applications requiring Public Key Infrastructure (PKI) security services can use the CML to meet their X.509 certificate and Certificate Revocation List (CRL) processing requirements. The v2.4 CML is described in the v2.4 CML Application Programming Interface (API) document. It implements the 2000 X.509 Recommendation certification path verification processing rules and SDN.706 profile. It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile requirements. There are some unsupported features such as Delta CRLs. The v2.4 CML Abstract Syntax Notation One (ASN.1) decodes X.509 Certificates and CRLs. It requires the v1.6 Enhanced SNACC ASN.1 software that is freely available from: . The CML provides robust certification path building capabilities such as using cross certificates. The CML uses the accompanying Storage and Retrieval Library (SRL) (optionally) to provide local certificate and CRL storage management functions. The SRL (optionally) provides remote directory retrieval capabilities using the Lightweight Directory Access Protocol (LDAP). The CML has been thoroughly tested including validating X.509 Certificates and CRLs created by a variety of Certification Authority (CA) products, and signed using the Digital Signature Algorithm (DSA) and RSA algorithms. Further enhancements, ports and testing of the CML are still in process. Further releases of the CML will be provided as significant capabilities are added. CML v2.4 includes the following enhancements (compared to v2.3 CML release): 1) Replaced the CTIL interface for the CML with a newly created PKCS#11 interface. 2) Implemention of a CRL server with support for the "Delta CRL" and "Freshest CRL" 2000 X.509 extensions. This architectural change is a step toward the CML's migration of OCSP compatability. 3) Enhanced the API to support the option for the application to request the CML log path building and validation events to aid in debugging and troubleshooting. 4) Enhanced the API to include callback functions to allow an application to perform its own revocation processing, rather than the crlapi library. 5) Added the capability to cache invalid certificates and CRLs. 6) Added a CRL grace period that can be specified by the application when creating a CML session. The grace period allows the application to specify the amount of time past a CRL's nextUpdate during which the CML will treat the CRL as still current. v2.4 SRL includes the following enhancements (compared to v2.3 SRL release): 1) Modified the default crlRefreshPeriod from 0 to LONG_MAX when CML creates an SRL session. When zero, the CRLs in the database were always being treated as stale; the new default is the always treat them as fresh. 2) Added a location mask to SRL_URLrequestObjs() so the caller can specify whether to search the local databse, the remote server, or both. 3) Enhnaced LDAPInitSettings_struct with a timeout field that controls how long to wait for the ldap_result() function. Previously, the timeout was hardcoded to 30 seconds. All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees. The CML was originally developed by the U.S. Government. DigitalNet is enhancing and supporting the CML under contract to the U.S. Government. The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software. The CML makes calls to an algorithm-independent CTIL API that provides access to a variety of external crypto libraries. There is a CTIL for each crypto library that maps the generic CTIL API calls to the specific calls for that crypto library. DigitalNet provides CTILs for the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used with the CML. The underlying, external crypto libraries are not distributed as part of the CML software. The CML has been successfully tested with the v2.4 S/MIME Freeware Library (SFL) that is freely available from . The CML has been successfully tested with the v2.4 Access Control Library (ACL) that is freely available to everyone from: . The CML has been successfully used to build and verify certificate paths used in the Bridge Certification Authority (BCA) demonstration which includes cross-certified hierarchical and non- hierarchical PKIs. The BCA Interoperability Test Suite (BITS) is a free and openly available test resource provided to facilitate vendor development of secure, interoperable Public Key Enabled applications. The CML has been used to successfully develop and verify the BITS X.509 certification paths available from . The National Institute of Standards and Technology (NIST) is providing a standard test suite of X.509 certificate paths that can be used for testing applications against RFC 2459. The CML was used to successfully process the NIST test data. The CML meets the requirements stated in the SDN.706 Certificate/ CRL Profile required by the U.S. Defense Message System (DMS) project. The Internet Mail Consortium (IMC) has established a CML web page and a CML mail list which is used to: distribute information regarding CML releases; discuss CML-related issues; and allow CML users to provide feedback, comments, bug reports, etc. Subscription information for the imc-cml mailing list is at the IMC web site listed above. All comments regarding the CML source code and documents are welcome. This CML release announcement was sent to several mail lists, but please send all messages regarding the CML to the imc-cml mail list ONLY. Please do not send messages regarding the CML to any of the IETF mail lists. We will respond to all messages sent to the imc-cml mail list. -- Matthew J. Bertapelle DigitalNet Government Solutions, LLC www.DigitalNet.com --------------050304030007060200030803 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
All,

DigitalNet Government Solutions has delivered the Version 2.4 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux.  The v2.4 CML and documentation is freely available at:
<http://www.digitalnet.com/knowledge/cml_home.htm>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.4 CML is described in the v2.4 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.4 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.6
Enhanced SNACC ASN.1 software that is freely available from:
<http://www.digitalnet.com/knowledge/snacc_home.htm>.

The CML provides robust certification path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509 
Certificates and CRLs created by a variety of Certification 
Authority (CA) products, and signed using the Digital Signature
Algorithm (DSA) and RSA algorithms.  Further enhancements, 
ports and testing of the CML are still in process.  Further
releases of the CML will be provided as significant 
capabilities are added. 

CML v2.4 includes the following enhancements (compared to v2.3 CML release):

1) Replaced the CTIL interface for the CML with a newly created PKCS#11 interface.

2) Implemention of a CRL server with support for the "Delta CRL" and "Freshest CRL" 2000 X.509 extensions.  This architectural change is a step toward the CML's migration of OCSP compatability.

3) Enhanced the API to support the option for the application to request the CML log path building and validation events to aid in debugging and troubleshooting.

4) Enhanced the API to include callback functions to allow an application to perform its own revocation processing, rather than the crlapi library.

5) Added the capability to cache invalid certificates and CRLs.

6) Added a CRL grace period that can be specified by the application when creating a CML session.  The grace period allows the application to specify the amount of time past a CRL's nextUpdate during which the CML will treat the CRL as still current.

v2.4 SRL includes the following enhancements (compared to v2.3 SRL release):

1) Modified the default crlRefreshPeriod from 0 to LONG_MAX when CML creates an SRL session.  When zero, the CRLs in the database were always being treated as stale; the new default is the always treat them as fresh.

2) Added a location mask to SRL_URLrequestObjs() so the caller can specify whether to search the local databse, the remote server, or both.

3) Enhnaced LDAPInitSettings_struct with a timeout field that controls how long to wait for the ldap_result() function.  Previously, the timeout was hardcoded to 30 seconds.

 
All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees.  The CML was originally developed by the U.S. Government.  DigitalNet is enhancing and supporting the CML under contract to the U.S. Government.  The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software.
The CML makes calls to an algorithm-independent CTIL API that provides
access to a variety of external crypto libraries. There is a CTIL for
each crypto library that maps the generic CTIL API calls to the
specific calls for that crypto library. DigitalNet provides CTILs for
the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and
FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a
PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used
with the CML. The underlying, external crypto libraries are not
distributed as part of the CML software.


The CML has been successfully tested with the v2.4 S/MIME Freeware
Library (SFL) that is freely available from
<http://www.DigitalNet.com/knowledge/sfl_home.htm>.

The CML has been successfully tested with the v2.4 Access Control
Library (ACL) that is freely available to everyone from:
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The CML has been successfully used to build and verify
certificate paths used in the Bridge Certification Authority (BCA)
demonstration which includes cross-certified hierarchical and non-
hierarchical PKIs. The BCA Interoperability Test Suite (BITS)
is a free and openly available test resource provided to
facilitate vendor development of secure, interoperable Public
Key Enabled applications. The CML has been used to successfully
develop and verify the BITS X.509 certification paths available
from <http://bcatest.atl.DigitalNet.com>.

The National Institute of Standards and Technology (NIST) is
providing a standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be
used for testing applications against RFC 2459. The CML was
used to successfully process the NIST test data.

The CML meets the requirements stated in the SDN.706 Certificate/
CRL Profile required by the U.S. Defense Message System (DMS)
project.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml> and a CML mail list which is used to:
distribute information regarding CML releases; discuss CML-related
issues; and allow CML users to provide feedback, comments, bug
reports, etc. Subscription information for the imc-cml mailing list
is at the IMC web site listed above.

All comments regarding the CML source code and documents are welcome.
This CML release announcement was sent to several mail lists, but
please send all messages regarding the CML to the imc-cml mail list
ONLY. Please do not send messages regarding the CML to any of the IETF
mail lists. We will respond to all messages sent to the imc-cml mail
list. 
-- 
Matthew J. Bertapelle
DigitalNet Government Solutions, LLC
www.DigitalNet.com

--------------050304030007060200030803-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MH8rTO069737; Tue, 22 Jun 2004 10:08:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MH8rRt069736; Tue, 22 Jun 2004 10:08:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MH8qgB069727 for ; Tue, 22 Jun 2004 10:08:52 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5MH8gC0030871 for ; Tue, 22 Jun 2004 13:08:42 -0400 Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i5MH834B005688 for ; Tue, 22 Jun 2004 13:08:03 -0400 (EDT) Message-Id: <5.1.0.14.2.20040622130249.02af60c0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 22 Jun 2004 13:11:05 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: Agenda Requests, Please... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, The PKIX WG will be meeting at the 60th IETF in San Diego on Wednesday, August 4 from 9:30 - 11:30 AM. I would like to post a *draft* agenda for the PKIX WG by the end of this month . The final agenda will be posted towards the end of July, but the draft may help folks make their travel plans. I would appreciate receiving agenda requests by next Tuesday at the latest. I will post the draft agenda to the WG list the following day. WG activities will, as always, get preference for agenda time. However, we may be able to accomodate some "liasion" presentations. As always: (1) Please put the word "Agenda" in the subject line! (2) Please submit a new request *even if you sent me mail before*. I will try searching for the usual key words, but am likely to miss old requests. Thanks, Tim Polk Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HN61dM043983; Thu, 17 Jun 2004 16:06:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HN61uP043982; Thu, 17 Jun 2004 16:06:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HN602x043948 for ; Thu, 17 Jun 2004 16:06:00 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5HN4XJ13586; Thu, 17 Jun 2004 16:04:33 -0700 (PDT) Message-Id: <200406172304.i5HN4XJ13586@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3779 on X.509 Extensions for IP Addresses and AS Identifiers Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 17 Jun 2004 16:04:33 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3779 Title: X.509 Extensions for IP Addresses and AS Identifiers Author(s): C. Lynn, S. Kent, K. Seo Status: Standards Track Date: June 2004 Mailbox: CLynn@BBN.Com, Kent@BBN.Com, KSeo@BBN.Com Pages: 27 Characters: 60732 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-x509-ipaddr-as-extn-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3779.txt This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040617160206.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3779 --OtherAccess Content-Type: Message/External-body; name="rfc3779.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040617160206.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from cn-inflatables.com ([218.19.100.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i580H1vK022127 for ; Mon, 7 Jun 2004 17:17:04 -0700 (PDT) (envelope-from tian@cn-inflatables.com) Message-Id: <200406080017.i580H1vK022127@above.proper.com> From: "China Inflatable Inc." Subject: we got your info from your website,hope cooperation. To: ietf-pkix-archive@IMC.ORG Content-Type: text/html;charset="GB2312" Content-Transfer-Encoding: 8bit Reply-To: info@cn-inflatables.com Date: Tue, 8 Jun 2004 08:17:14 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 china inflatable
CHINEE£¬ China's   Inflatables.       £¨ ÖÐ ÎÄ £©
We offer high quality inflatable products in any size or style.
Please browse the product sorts.

¡¡

¡¡

¡¡

¡¡

----------------------------------------------------------------------------------------------------------

Download:

 Price List    Order Form   Catalogue

More info:

 www.china-inflatable.com

Contact us:

Tel:00 86 20 88395948  Fax:00 86 20 83684025

E-mail:

info@china-inflatable.com  

     If you do not need this info, Click here

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53Ej4r7067745; Thu, 3 Jun 2004 07:45:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53Ej4tT067744; Thu, 3 Jun 2004 07:45:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53Ej3Nu067721 for ; Thu, 3 Jun 2004 07:45:03 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 3C60234028; Fri, 4 Jun 2004 02:40:17 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BVtSu-0000FQ-Lz; Fri, 04 Jun 2004 02:45:08 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dpkemp@missi.ncsc.mil, tgindin@us.ibm.com Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Cc: ietf-pkix@imc.org In-Reply-To: <200406031329.i53DToWi000957@stingray.missi.ncsc.mil> Message-Id: Date: Fri, 04 Jun 2004 02:45:08 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David P. Kemp" writes: >I don't agree with Peter that two tags is massive overuse - there is no >difference in the number of octets with IMPLICIT TAGS, and the ASN.1 looks >more uniform when all optional fields are context-tagged. Maybe Peter is a >free spirit who just doesn't like all his text lined up in straight columns >:-). Hiding type information via unnecessary tagging makes data checking/display using ASN.1 tools extremely difficult. There's nothing more painful than having to debug/pick apart some implementation's broken PDUs where every field is an implicit OCTET STRING. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53DUefP053170; Thu, 3 Jun 2004 06:30:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53DUeab053169; Thu, 3 Jun 2004 06:30:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53DUdiu053145 for ; Thu, 3 Jun 2004 06:30:40 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200406031329.i53DToWi000957@stingray.missi.ncsc.mil> Date: Thu, 03 Jun 2004 09:30:30 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Gindin CC: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2004 13:30:36.0064 (UTC) FILETIME=[F3E9EA00:01C4496E] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, As long as we're being technical, either the first or the second tag is not needed - all that is required is to unambiguously distinguish between one optional field and the other. I don't agree with Peter that two tags is massive overuse - there is no difference in the number of octets with IMPLICIT TAGS, and the ASN.1 looks more uniform when all optional fields are context-tagged. Maybe Peter is a free spirit who just doesn't like all his text lined up in straight columns :-). I hope this thread will morph into a discussion of the wisdom of using DNS name as the identifier for assigner, vs. using an OID, or a CHOICE of DNS or OID. I think that the IESG's objections to using a URI do not apply to using a DNS name, because the URI always implies an online access by the client to fetch some resource, while the DNS name implies that the assigner has registered a name but does not require any online access to a changeable value (A / MX / RR lookup) by the client. OID registration is more formal and is free; DNS registration is a little more "internet friendly" but requires a fee if an assigner does not already have an internet presence. I don't have a preference for one over the other. I do oppose a CHOICE because of the unnecessary complexity. There should be no situation where an assigner could not register either an OID or a DNS name, so standardizing on either one is preferable to requiring support for both. I don't have any particular preference for a name for the second field, although the emphasis should be on "Assigner" (the fact that there is a registered business entity) rather than on the syntax of the registered name (the fact that it is a DNS domain or node). Dave Tom Gindin wrote: > David: > > The first tag (for Value) is not needed. I would think that the > second field should be called something like "assignerDomain" or > "assignerNode". > > Tom Gindin Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53Bs6rg034378; Thu, 3 Jun 2004 04:54:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53Bs6Qm034377; Thu, 3 Jun 2004 04:54:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53Bs5si034348 for ; Thu, 3 Jun 2004 04:54:05 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i53Bs0bl320602; Thu, 3 Jun 2004 07:54:00 -0400 Received: from d01ml062.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i53BslG0132162; Thu, 3 Jun 2004 07:54:48 -0400 To: "David P. Kemp" Cc: Anders Rundgren , ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Tom Gindin Message-ID: Date: Thu, 3 Jun 2004 07:53:52 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|May 18, 2004) at 06/03/2004 07:53:59, Serialize complete at 06/03/2004 07:53:59 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David: The first tag (for Value) is not needed. I would think that the second field should be called something like "assignerDomain" or "assignerNode". Tom Gindin "David P. Kemp" Sent by: owner-ietf-pkix@mail.imc.org 06/02/2004 03:22 PM To: Anders Rundgren cc: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Ahh, I had fancied that my ASN.1 did not suck, but you have shattered that illusion. It does need a [] or two: PermanentIdentifier ::= SEQUENCE { identifierValue [0] UTF8String OPTIONAL, identifierAssigner [1] UTF8String OPTIONAL } Anders Rundgren wrote: > > A margin comment: Although my ASN.1 surely sucks, shouldn't > there be a [] or two to properly spice this up? > > best > Anders > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5385eIN058568; Thu, 3 Jun 2004 01:05:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5385e3b058567; Thu, 3 Jun 2004 01:05:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5385a1I058457 for ; Thu, 3 Jun 2004 01:05:39 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id ACAA53406E; Thu, 3 Jun 2004 20:00:44 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BVnEC-00029S-5H; Thu, 03 Jun 2004 20:05:32 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: anders.rundgren@telia.com, dpkemp@missi.ncsc.mil Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Cc: ietf-pkix@imc.org In-Reply-To: <200406021927.i52JLOiG022721@stingray.missi.ncsc.mil> Message-Id: Date: Thu, 03 Jun 2004 20:05:32 +1200 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David P. Kemp" writes: >Ahh, I had fancied that my ASN.1 did not suck, but you have shattered that >illusion. It does need a [] or two: I wasn't sure of Anders was being sarcastic or not (that is, commenting on the massive overuse of redundant tags in most PKIX standards). Since it was a serious comment, it only needs one tag, on the second UTF8String. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52JRxoT063376; Wed, 2 Jun 2004 12:27:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i52JRxON063375; Wed, 2 Jun 2004 12:27:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52JRwYJ063342 for ; Wed, 2 Jun 2004 12:27:58 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200406021927.i52JLOiG022721@stingray.missi.ncsc.mil> Date: Wed, 02 Jun 2004 15:22:28 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Rundgren CC: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt References: <005701c3e08e$9b392fe0$1400a8c0@augustcellars.local> <00c701c3e121$0ae3af90$0500a8c0@arport> <4017C963.8060600@bull.net> <200405121708.i4CH7dim022214@stingray.missi.ncsc.mil> <006501c44861$ecf010c0$0500a8c0@arport> <200406021759.i52HtDii019283@stingray.missi.ncsc.mil> <01dc01c448d1$e3ceeb90$0500a8c0@arport> In-Reply-To: <01dc01c448d1$e3ceeb90$0500a8c0@arport> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2004 19:22:28.0956 (UTC) FILETIME=[F1C3D1C0:01C448D6] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ahh, I had fancied that my ASN.1 did not suck, but you have shattered that illusion. It does need a [] or two: PermanentIdentifier ::= SEQUENCE { identifierValue [0] UTF8String OPTIONAL, identifierAssigner [1] UTF8String OPTIONAL } Anders Rundgren wrote: > > A margin comment: Although my ASN.1 surely sucks, shouldn't > there be a [] or two to properly spice this up? > > best > Anders > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52Im2gs054456; Wed, 2 Jun 2004 11:48:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i52Im2tm054455; Wed, 2 Jun 2004 11:48:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av2-1-sn3.vrr.skanova.net (av2-1-sn3.vrr.skanova.net [81.228.9.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52Im1ot054426 for ; Wed, 2 Jun 2004 11:48:01 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id B666837EE2; Wed, 2 Jun 2004 20:47:59 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id A720937EE0; Wed, 2 Jun 2004 20:47:59 +0200 (CEST) Received: from arport (t8o913p96.telia.com [213.64.26.216]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id BD09538008; Wed, 2 Jun 2004 20:47:56 +0200 (CEST) Message-ID: <01dc01c448d1$e3ceeb90$0500a8c0@arport> From: "Anders Rundgren" To: "David P. Kemp" Cc: References: <005701c3e08e$9b392fe0$1400a8c0@augustcellars.local> <00c701c3e121$0ae3af90$0500a8c0@arport> <4017C963.8060600@bull.net> <200405121708.i4CH7dim022214@stingray.missi.ncsc.mil> <006501c44861$ecf010c0$0500a8c0@arport> <200406021759.i52HtDii019283@stingray.missi.ncsc.mil> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Date: Wed, 2 Jun 2004 20:45:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >My preferred syntax for the PI otherName form would be: >PermanentIdentifier ::= SEQUENCE { > identifierValue UTF8String OPTIONAL, > identifierAssigner UTF8String OPTIONAL >} >If the identifierValue field is omitted, the value MUST be >contained in the last serialNumber RDN of the subject field >of the certificate. >The identifierAssigner field, if present, MUST contain a Domain >Name System (DNS) name in the "preferred name syntax" as specified >in RFC 1034. If the identifierAssigner field is omitted, the >identifier assigner is the issuer of the certificate. C'mon Dave, this PI scheme would be compatible with RFC3039 and much existing PI practice! I thought this was out of question? :-) :-) A margin comment: Although my ASN.1 surely sucks, shouldn't there be a [] or two to properly spice this up? best Anders Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52I0aSF047250; Wed, 2 Jun 2004 11:00:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i52I0aFS047249; Wed, 2 Jun 2004 11:00:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i52I0Zo0047231 for ; Wed, 2 Jun 2004 11:00:36 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200406021759.i52HtDii019283@stingray.missi.ncsc.mil> Date: Wed, 02 Jun 2004 13:57:57 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Rundgren CC: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt References: <005701c3e08e$9b392fe0$1400a8c0@augustcellars.local> <00c701c3e121$0ae3af90$0500a8c0@arport> <4017C963.8060600@bull.net> <200405121708.i4CH7dim022214@stingray.missi.ncsc.mil> <006501c44861$ecf010c0$0500a8c0@arport> In-Reply-To: <006501c44861$ecf010c0$0500a8c0@arport> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2004 17:58:02.0817 (UTC) FILETIME=[261C5B10:01C448CB] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The problem isn't ambiguity, the problem is permanence and signalling. It would be wonderful if a new subject distinguished name structure could be established along the lines you suggest: A. CN=David Kemp; SN=1234567; DC=megabank; DC=com or even using a new Account Assigning Authority RDN attribute: B. CN=David Kemp; SN=1234567; AA=megabank.com But I'm enough of a pragmatist to believe that Country-based kitchen-sink DNs will not go away in my lifetime no matter how ugly they are. Closed PKIs can choose to use clean account-based DNs, but as long as some PKIs might use DNs with nonce disambiguators, general purpose applications will need custom configuration and multiple logic paths to know if and where an account number / PI can be found, unless a PI standard is adopted. So to answer your question starting with the DN example from RFC3280, the original (#1 below) is invalid in general because it might clash, (2a and 2b) contain a nonce disambiguator, and (3a/3b/3c) contain a larger disambiguator that may or may not be a permanent identifier. If (3) is a PI, then it might be assigned by the issuing CA, by the subject's organization nist.gov.US, or by a third party such as DEERS for DoD users. 1. CN=Tim Polk; OU=nist; O=gov; C=US 2a. CN=Tim Polk.3; OU=nist; O=gov; C=US 2b. CN=Tim Polk; SN=3; OU=nist; O=gov; C=US 3a. CN=Tim Polk.1234567; OU=nist; O=gov; C=US 3b. CN=Tim Polk; SN=1234567; OU=nist; O=gov; C=US 3c. CN=Tim Polk; SN=1234567; E=wpolk@nist.gov; OU=nist; O=gov; C=US The problem that a PI standard needs to solve is allowing an application to examine a certificate following one of many pre-existing DN schemas and determine if that certificate contains a PI. So your alternative 3 would be "inserting the existing serialNumber in the permanent identifier", not the other way around. It would be nice to be able to avoid duplication, so alternative 4 would be for the PI altname to contain only the account assigner and for the DN serialNumber to contain the account number. Alternatives 2, 3, and 4 are all OK, 1 is not. ------------------------------ My preferred syntax for the PI otherName form would be: PermanentIdentifier ::= SEQUENCE { identifierValue UTF8String OPTIONAL, identifierAssigner UTF8String OPTIONAL } If the identifierValue field is omitted, the value MUST be contained in the last serialNumber RDN of the subject field of the certificate. The identifierAssigner field, if present, MUST contain a Domain Name System (DNS) name in the "preferred name syntax" as specified in RFC 1034. If the identifierAssigner field is omitted, the identifier assigner is the issuer of the certificate. Dave Anders Rundgren wrote: >>It is my hope that PI will become an RFC in the near future, so >>that certificates (from an un-named large PKI :-) that currently >>handle PIs by munging them into Common Name (e.g., >>CN="Kemp.David.P.0514101404") will have a saner alternative. > > > Since you apparently plan to put PI through the litmus test, may I > repeat my request for a brief description of how you see that likely > DN name clashes should be handled when the current identifier > is removed from CN? Among possible alternatives I note: > > 1. Ignoring subject DN name clashes [1] > > 2. Having the CA issue and keep a specific registry [2] of "nonsense" > name disambiguers. Putting such disambiguers in serialNumber > > 3. Inserting the existing permanent identifier in serialNumber. This > is more or less a duplication of the PI object > > 4. Other? > > best > Anders R > > 1] violates RFC3039 > > 2] is effectively an RFC3039 requirement as DNs must never be > reassigned > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i525QbqG020917; Tue, 1 Jun 2004 22:26:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i525QbWG020916; Tue, 1 Jun 2004 22:26:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from av1-2-sn3.vrr.skanova.net (av1-2-sn3.vrr.skanova.net [81.228.9.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i525Qaxp020818 for ; Tue, 1 Jun 2004 22:26:36 -0700 (PDT) (envelope-from anders.rundgren@telia.com) Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 37C6237EA4; Wed, 2 Jun 2004 07:26:32 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 298A737E4E; Wed, 2 Jun 2004 07:26:32 +0200 (CEST) Received: from arport (t12o913p60.telia.com [213.64.28.180]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id CA5F938008; Wed, 2 Jun 2004 07:26:27 +0200 (CEST) Message-ID: <006501c44861$ecf010c0$0500a8c0@arport> From: "Anders Rundgren" To: "David P. Kemp" , References: <005701c3e08e$9b392fe0$1400a8c0@augustcellars.local> <00c701c3e121$0ae3af90$0500a8c0@arport> <4017C963.8060600@bull.net> <200405121708.i4CH7dim022214@stingray.missi.ncsc.mil> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt Date: Wed, 2 Jun 2004 07:24:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >It is my hope that PI will become an RFC in the near future, so >that certificates (from an un-named large PKI :-) that currently >handle PIs by munging them into Common Name (e.g., >CN="Kemp.David.P.0514101404") will have a saner alternative. Since you apparently plan to put PI through the litmus test, may I repeat my request for a brief description of how you see that likely DN name clashes should be handled when the current identifier is removed from CN? Among possible alternatives I note: 1. Ignoring subject DN name clashes [1] 2. Having the CA issue and keep a specific registry [2] of "nonsense" name disambiguers. Putting such disambiguers in serialNumber 3. Inserting the existing permanent identifier in serialNumber. This is more or less a duplication of the PI object 4. Other? best Anders R 1] violates RFC3039 2] is effectively an RFC3039 requirement as DNs must never be reassigned Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i51847CA061863; Tue, 1 Jun 2004 01:04:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i51847AZ061862; Tue, 1 Jun 2004 01:04:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from avir1.bancsabadell.com (tm01.bancsabadell.com [194.224.15.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i51845ha061790 for ; Tue, 1 Jun 2004 01:04:05 -0700 (PDT) (envelope-from gonzalezcarlos@netfocus.es) Received: from EFYBEM279076 (privadas.nuria.telefonica-data.net [172.18.16.2]) by mail.bancsabadell.com; Tue, 01 Jun 2004 10:00:04 +0200 Reply-To: From: =?iso-8859-1?Q?Carlos_Gonz=E1lez-Cadenas?= To: Subject: questions Date: Tue, 1 Jun 2004 10:02:25 +0200 Organization: NetFocus Message-ID: <000f01c447ae$c6b3a4c0$021012ac@extendforce.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C447BF.8A3C74C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C447BF.8A3C74C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =0D Two questions =0D * It=92s a common practice for a CA to issue different kinds of certificates (i.e. a CA issuing email certificates can issue two certificates, a certificate for signing and another one for encryption (key encipherment). Normally, when people want to differentiate this= certificates sintetically (not looking at the certificate characteristics, but looking= to an OID or similar), they derive the policy under the certificate is issued with an identifier determining the certificate type.=0D =0D Example: The class 2 certificate policy is identified under OID 1.3.6.1.4.1.x.100.2. So, we can obtain two more OIDs for the two different types of certificates 1.3.6.1.4.1.x.100.2.1 for the signing cert 1.3.6.1.4.1.x.100.2.2 for the encryption cert =0D I think using the policies this way we are somewhat perverting the= standard. What we must include in the Certificate Policies (in EE certs) is the= policy under the certificate is issued, not an hybrid between the policy and a qualifier of the certificate. =0D Questions about that: *Is this an ad-hoc standard?? (What=92s your oppinion about that??) *Is there any place (standard one) to include the certificate type OID? *Are there some ideas about this in son-of-3280?? (I wasn=92t able to find nothing comparable to that in 3280). =0D * I=92m trying to configure a hierarchy of tree levels of CAs, plus another level of end entity certificates.=0D =0D I want to maintain compatibility with Certificate Path Validation= algorithms in RFC3280, specially when referring to policy-tree validation. I want to assert that the points stated below are ok,=0D =0D * For the root certificate, no policies at all (it=92s a trust anchor, and by default can issue certificates with any policy).=0D * For the first intermediate certificate (it represents an organization), I must assert the anyPolicy special policy in the= Certificate Policies, if not, the policy tree gets null after evaluating this node.=0D * For the second intermediate certificate (it represents a class CA, issuing certificates under some well-known policies), I include these policies in the Certificate Policies (to restrict the policies that the EE certificates can be issued under).=0D * In the End entity, I include these Policies in the Certificate Policies, to state that the certificate is issued under these policies.=0D =0D Questions, =0D *Is my configuration considered as a =93best practice=94? *What are the possible modifications for a son-of-3280?. This configuration will be affected adversely for that? =0D Thank you very much in advance =0D Carlos =0D =0D Carlos Gonz=E1lez-Cadenas Jefe de Departamento de Arquitectura Software=0D Software Architecture Department Manager Responsable de Seguridad de la Informaci=F3n=0D Information Security Responsible netfocus by Siemens-BancSabadell =0D =0D C/Sena, 12 nucli C planta 2 Edifici Landscape 08190 Sant Cugat del Vall=E8s phone: +34933556139 fax: +34933556142 mailto: gonzalezcarlos@netfocus.es web: www.netfocus.es =0D =0D =0D Advertencia legal: Este mensaje y, en su caso, los ficheros anexos son confidenciales, especialmente en lo que respecta a los datos personales, y se dirigen exclusivamente al destinatario referenciado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o= borrarlo, y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo= pena de incurrir en responsabilidades legales. El emisor no garantiza la= integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. =0D Advertiment legal: Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial, especialment pel que fa a les dades personals, i s'adrecen exclusivament al destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o= se li ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per= aquesta mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui= d'utilitzar, reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no= garanteix la integritat, la rapidesa o la seguretat d'aquest correu, ni es= responsabilitza de possibles perjudicis derivats de la captura, incorporacions de virus o qualsevol altres manipulacions que facin tercers. =0D Disclaimer: This message and any attached files transmitted with it, is confidential, especially as regards personal data. It is intended solely for the use of= the individual or entity to whom it is addressed. If you are not the intended= recipient and have received this information in error or have accessed it for any= reason, please notify us of this fact by email reply and then destroy or delete the= message, refraining from any reproduction, use, alteration, filing or communication= to third parties of this message and attached files on penalty of incurring legal responsibilities. The sender does not guarantee the integrity, the= accuracy, the swift delivery or the security of this email transmission, and assumes no responsibility for any possible damage incurred through data capture, virus incorporation or any manipulation carried out by third parties. ------=_NextPart_000_0010_01C447BF.8A3C74C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

Two questions

 

  • It’s a common practice for a CA to= issue different kinds of certificates (i.e. a CA issuing email certificates= can issue two certificates, a certificate for signing and another one for= encryption (key encipherment). Normally, when people want to differentiate this certificates sintetically (not looking at the certificate= characteristics, but looking to an OID or similar), they derive the policy under the certificate is issued with an identifier determining the certificate= type.

 

Example: The= class 2 certificate policy is identified under OID 1.3.6.1.4.1.x.100.2. So, we can= obtain two more OIDs for the two different types of certificates

1.3.6.1.4.1.x.100.2.1 for the signing cert

1.3.6.1.4.1.x.100.2.2 for the encryption cert

 

I think using the policies this way we are somewhat perverting the standard. What we must= include in the Certificate Policies (in EE certs) is the policy under the= certificate is issued, not an hybrid between the policy and a qualifier of the= certificate.

 

Questions about= that:

*Is this an= ad-hoc standard?? (What’s your oppinion about that??)

*Is there any= place (standard one) to include the certificate type OID?

*Are there some= ideas about this in son-of-3280?? (I wasn’t able to find nothing comparable= to that in 3280).

 

  • I’m trying to configure a hierarchy of tree levels of CAs, plus another level of end entity= certificates.

 

I want to= maintain compatibility with Certificate Path Validation algorithms in RFC3280,= specially when referring to policy-tree validation. I want to assert that the points stated below are ok,

 

    • For the root= certificate, no policies at all (it’s a trust anchor, and by default can issue certificates with any policy).=
    • For the first= intermediate certificate (it represents an organization), I must assert the= anyPolicy special policy in the Certificate Policies, if not, the policy tree= gets null after evaluating this node.=
    • For the second= intermediate certificate (it represents a class CA, issuing certificates under= some well-known policies), I include these policies in  the= Certificate Policies (to restrict the policies that the EE certificates can be= issued under).
    • In the End entity, I= include these Policies in the Certificate Policies, to state that the= certificate is issued under these policies.=

 

Questions,

 

*Is my= configuration considered as a “best practice”?

*What are the= possible modifications for a son-of-3280?. This configuration will be affected= adversely for that?

 

Thank you very much in advance

 

Carlos

 

 

Carlos Gonz= =E1lez-Cadenas

Jefe de Departamento de Arquitectura Software 

Software Architecture Department= Manager

Responsable de Seguridad de la Informaci= =F3n 

Information Security= Responsible

netf= ocus
by Siemens-BancSa= badell

 

 

C/Sena, 12= nucli C planta 2
Edifici Landscape
08190 Sant Cugat del Vall=E8s

phone:=   +34933556139
fax:      +34933556142
mailto:  gonzalezcarlos@netfocus.es
web:     www.netfocus.es

 

=0D
Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o=
 borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo=
 pena
de incurrir en responsabilidades legales. El emisor no garantiza la=
 integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.

=0D
Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o=
 se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per=
 aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui=
 d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no=
 garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es=
 responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualsevol altres manipulacions que facin tercers.

=0D
Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of=
 the
individual or entity to whom it is addressed. If you are not the intended=
 recipient
and have received this information in error or have accessed it for any=
 reason,
please notify us of this fact by email reply and then destroy or delete the=
 message,
refraining from any reproduction, use, alteration, filing or communication=
 to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the=
 accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.
------=_NextPart_000_0010_01C447BF.8A3C74C0--