May 2002 - Ietf-types

[KOffice 1.2] app/vnd.kde.{kword,kspread,kpresenter,kformula,kchart,kivio,kontour,karbon}
by Marc Mutz 29 May '02

29 May '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Please find attached the registrations for the KOffice 1.2 mime types. Their texts are equal except for the names of applications and the file extensions, so you only need to read one. Marc - -- Marc Mutz <mutz(a)kde.org> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE88TXM3oWD+L2/6DgRApzFAKCBX5pzJb0nfwM0scg8xSRXI2G6CgCeK2vz /DlErD27Dvv5lKVZW4JSdDw= =ovXo -----END PGP SIGNATURE----- ***KWord*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kword MIME media type name: application MIME subtype name: vnd.kde.kword Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KWord documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KWord feature scripting and macro recording facilities. It is, however, not intended to include active content into the KWord document itself. KWord documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KWord user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kword mime type for the obsolete format. Published specification: A KWord document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KWord can either be completely embedded in the KWord document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KWord. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kword File extensions: KWT, KWD Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***KSpread*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kspread MIME media type name: application MIME subtype name: vnd.kde.kspread Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KSpread documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KSpread feature scripting and macro recording facilities. It is, however, not intended to include active content into the KSpread document itself. KSpread documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KSpread user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kspread mime type for the obsolete format. Published specification: A KSpread document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KSpread can either be completely embedded in the KSpread document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KSpread. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kspread File extensions: KSP Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***KPresenter*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kpresenter MIME media type name: application MIME subtype name: vnd.kde.kpresenter Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KPresenter documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KPresenter feature scripting and macro recording facilities. It is, however, not intended to include active content into the KPresenter document itself. KPresenter documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KPresenter user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kpresenter mime type for the obsolete format. Published specification: A KPresenter document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KPresenter can either be completely embedded in the KPresenter document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KPresenter. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kpresenter File extensions: KPR, KPT Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***KFormula*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kformula MIME media type name: application MIME subtype name: vnd.kde.kformula Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KFormula documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KFormula feature scripting and macro recording facilities. It is, however, not intended to include active content into the KFormula document itself. KFormula documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KFormula user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kformula mime type for the obsolete format. Published specification: A KFormula document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KFormula can either be completely embedded in the KFormula document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KFormula. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kformula File extensions: KFO Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***KChart*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kchart MIME media type name: application MIME subtype name: vnd.kde.kchart Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, KChart documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of KChart feature scripting and macro recording facilities. It is, however, not intended to include active content into the KChart document itself. KChart documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The KChart user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kchart mime type for the obsolete format. Published specification: A KChart document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in KChart can either be completely embedded in the KChart document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. KChart. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kchart File extensions: CHRT Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***Kivio*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kivio MIME media type name: application MIME subtype name: vnd.kde.kivio Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, Kivio documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of Kivio feature scripting and macro recording facilities. It is, however, not intended to include active content into the Kivio document itself. Kivio documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The Kivio user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kivio mime type for the obsolete format. Published specification: A Kivio document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in Kivio can either be completely embedded in the Kivio document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. Kivio. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kivio File extensions: FLW Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***Kontour*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.kontour MIME media type name: application MIME subtype name: vnd.kde.kontour Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, Kontour documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of Kontour feature scripting and macro recording facilities. It is, however, not intended to include active content into the Kontour document itself. Kontour documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The Kontour user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-kontour mime type for the obsolete format. Published specification: A Kontour document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in Kontour can either be completely embedded in the Kontour document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. Kontour. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.kontour File extensions: KON Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org> ***Karbon*** To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.kde.karbon MIME media type name: application MIME subtype name: vnd.kde.karbon Required parameters: none Optional parameters: none Encoding considerations: Binary or base64 required Security considerations: As of this writing, Karbon documents do not contain any active content. As such, it is believed that usage of this mimetype does not introduce security concerns other than those already inherent in ZIP archives, XML files and supported image files. It is expected that later versions of Karbon feature scripting and macro recording facilities. It is, however, not intended to include active content into the Karbon document itself. Karbon documents include document metadata such as the name of the author, etc. However, none of this data is written automatically. The Karbon user has full control over what metadata is to be included and must actively request the inclusion. As such, the use of this mimetype does not lead to hidden leaking of possibly sensitive data. Interoperability considerations: Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX tar files as archive format. It is expected that this obsolete format will die out soon after the first release of KOffice 1.2. Thus, this registration does not apply to the obsolete format. Implementations are expected to use the old application/x-karbon mime type for the obsolete format. Published specification: A Karbon document consists of a series of XML streams and externally generated content which are bundled together as a ZIP archive. Any content placed in Karbon can either be completely embedded in the Karbon document or can be linked to using URIs. The DTDs used in KOffice can be obtained from http://www.koffice.org/DTD/. A description of the storage format is contained in the source code distribution (lib/store/SPEC). The current version can be obtained online via KDE's WebCVS interface: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC Applications which use this media type: All applications in the KDE KOffice Office Suite, esp. Karbon. Additional information: Magic numbers: This is an entry that can be used with the UNIX file(1) command's magic(4) file: 0 string PK\003\004 >30 string mimetype >>38 string application/vnd.kde.karbon File extensions: KARBON Macintosh File Type Codes: n/a Person & email address to contact for further information: David Faure <faure(a)kde.org> Intended usage: COMMON Author/Change contoller: Marc Mutz <mutz(a)kde.org>

2 1

Re: application/pkix-pkipath
by David Hopwood 24 May '02

24 May '02

-----BEGIN PGP SIGNED MESSAGE----- Peter Williams wrote: > All certs must comply with PKIX, it says. There are very real > communities of TLS users who use a non-PKIX profile of certs. - From RFC 2246, section 7.4.2: # All certificate profiles, key and cryptographic formats are defined # by the IETF PKIX working group [ref. to RFC 2459]. (In context, this applies only to X.509 formats. If other formats were added they obviously wouldn't be defined by PKIX. This should be made clearer in RFC2246-bis.) Which communities of TLS users are (deliberately, rather than just as a result of bugs) using non-PKIX-conformant X.509 certs, and why? > They should not be excluded from the use of the TLS proposed extensions. > There is nothing inherent in the nature of TLS or the extended handling > that requires that PKIX-designated controls be enforced. That's true, but specifying PKIX improves interoperability. It's not a new requirement; it is just clarifying how a requirement that is already in RFC 2246 applies for this type. > TLS should continue to be able to maintain current > interoperability AND exploit some of the newer extensions > even when certificates are not the means of distributing > public keys for the asymmetric cipher suites, as per > traditional SSL design. We (the extensions spec authors) were very careful not to do anything that would preclude or create problems for other public key authentication methods than X.509 certs. I don't see any good argument for using non-PKIX X.509 certs, though. - -- David Hopwood <david.hopwood(a)zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPO2zqjkCAxeYt5gVAQERdggAx5oxAZx9tm0NU1vjyfmjBbDShVAGyhkd 6Iw+sMVPIErBop61mE+8EC3vnM33yBD3fCQxWtE1L1a3LukxbKvlKzMZdl+GzIEk HJ93K42IC9xdw4yu32tGLFZhr3zMtM4nPCsowctQ5EirwNWQ2qGGGPHosgV3eIPV 36W3ZQWozKsayJM4+HLQLLpGMpEW221jMgYlyAGcwbyeXLZq9IaVud7Rbx4tVL5k lDnzQ1zSbwkvhCfTLehv2UHsvkLg8rhYCWsurU5lXxQR71wEBOBnNawy9mbltKCi r8ih+FGAMS4VWRA3PxGdW42A5iurW/ugC5HGFaCgDS9Q+acaE+28FQ== =aNbk -----END PGP SIGNATURE-----

1 0

Re: [ietf-tls] Re: application/pkix-pkipath
by David Hopwood 24 May '02

24 May '02

-----BEGIN PGP SIGNED MESSAGE----- "Housley, Russ" wrote: > The registration says: "... an update to [PKIX] ..." > > That update is (finally) finished. See RFC 3280. > Please reference RFC 3280 (not RFC 2459). Thanks, this will be fixed as follows: Change the [PKIX] reference to [PKIX] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", IETF RFC 3280, April 2002. and change the sentence in the registration to just "All Certificates MUST conform to [PKIX]." - -- David Hopwood <david.hopwood(a)zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPO2yNzkCAxeYt5gVAQEDmQf/Ug2IYX1t8P7N/o8pzKQwF+SbbjP/IMLY 96+llndPRHN3q1WPboAsCI+4zA+2LPEokN6PqivzXibKH9W+spSj1YZawu0kswoV /mmWFR4bYk0el2bn8yrjxJsYd/zrNs4eu+4ctkUPI2sEWQGRPdtzGrrFtihQ0wEZ AsuWNOrn/OIf+76J8kVOY6a4l8H3nkn3TWR4FiL9M9gDvXkdtmjvH3aO0M41fsXT YLKFTC2HmxQRaCCBkyHKdwZz51GVk3KC/rSvxzWoYfJS30rLk9ft6Inilmnbpast XcYW2EF1DLzFLtU8/MxKwTEdN5S0ZQwknAnRyRsTnBU8BrwDoiABRA== =iPEL -----END PGP SIGNATURE-----

1 0

application/pkix-pkipath
by David Hopwood 23 May '02

23 May '02

-----BEGIN PGP SIGNED MESSAGE----- The following template is from the Standards Track I-D <draft-ietf-tls-extensions-04.txt>, which has just been submitted for Last Call in the TLS WG. It's intended to be consistent with the types application/pkix-{cert,crl} from RFC 2585. (Note: Reply-To is set to the ietf-types list only.) To: ietf-types(a)iana.org Subject: Registration of MIME media type application/pkix-pkipath MIME media type name: application MIME subtype name: pkix-pkipath Required parameters: none Optional parameters: version (default value is "1") Encoding considerations: This MIME type is a DER encoding of the ASN.1 type PkiPath, defined as follows: PkiPath ::= SEQUENCE OF Certificate PkiPath is used to represent a certification path. Within the sequence, the order of certificates is such that the subject of the first certificate is the issuer of the second certificate, etc. This is identical to the definition that will be published in [X509-4th-TC1]; note that it is different from that in [X509-4th]. All Certificates MUST conform to [PKIX] (an update to [PKIX] is in preparation, and should be followed when it is published). DER (as opposed to BER) encoding MUST be used. If this type is sent over a 7-bit transport, base64 encoding SHOULD be used. Security considerations: The security considerations of [X509-4th] and [PKIX] (or any updates to them) apply, as well as those of any protocol that uses this type (e.g. TLS). Note that this type only specifies a certificate chain that can be assessed for validity according to the relying party's existing configuration of trusted CAs; it is not intended to be used to specify any change to that configuration. Interoperability considerations: No specific interoperability problems are known with this type, but for recommendations relating to X.509 certificates in general, see [PKIX]. Published specification: <draft-ietf-tls-extensions-04.txt> and [PKIX]. Applications which use this media type: TLS. It may also be used by other protocols, or for general interchange of PKIX certificate chains. Additional information: Magic number(s): DER-encoded ASN.1 can be easily recognised. Further parsing is required to distinguish from other ASN.1 types. File extension(s): .pkipath Macintosh File Type Code(s): not specified Person & email address to contact for further information: Magnus Nystrom <magnus(a)rsasecurity.com> Intended usage: COMMON Author/Change controller: Magnus Nystrom <magnus(a)rsasecurity.com> Normative References [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," IETF RFC 2119, March 1997. [PKIX] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", IETF RFC 2459, January 1999. [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, "Information Systems - Open Systems Interconnection - The Directory: Public key and attribute certificate frameworks." [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC 9594:8:2001. - -- David Hopwood <david.hopwood(a)zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPOrjTTkCAxeYt5gVAQHddQf5ATsJ4D4flPu6Y5JgtazAO/Fc0MxG9Iy6 XJsov+JNMmEwP66eESuSkgk44RWlk+TkHadGnsybRth9aRUumhni8GjnIO4UAn4I QghOXua2BZ8QoePEcm2i1BqlcTg7jgOHIcVXiRk3l/N3IvZviDy1a/h9B4pmYafV ZUgKhzwr7qFg63LWQyuSkOzisWpNeC778A6u95G+P0HhGdL77IEqiVz0GfWPuq2A jTmGP7kOl+WhS1pbjliGqxUNjYyw4fX/rcd5ltzhijY5LRa3jsUq+ixK8uSx4kle XXI1Aig8NLaX5Vfu2AkojMrcH2/wMFQK/JHwZY2cfs2mhdi7JBPUng== =6X2a -----END PGP SIGNATURE-----

1 0