From nobody Thu Oct 2 13:03:21 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9041ACD38 for ; Thu, 2 Oct 2014 13:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.249 X-Spam-Level: ** X-Spam-Status: No, score=2.249 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBWwG0h_oa0F for ; Thu, 2 Oct 2014 13:03:14 -0700 (PDT) Received: from smtp-11.idc2.mandic.com.br (smtp-11.idc2.mandic.com.br [200.219.212.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104951ACD23 for ; Thu, 2 Oct 2014 13:03:14 -0700 (PDT) Received: by smtp-11.smtp.mandic.prv (Postfix, from userid 491) id 5495F802EEA; Thu, 2 Oct 2014 17:03:10 -0300 (BRT) Received: from mssrv001.ms.mandic.com.br (mssrv001.ms.mandic.prv [192.168.11.92]) by smtp-11.smtp.mandic.prv (Postfix) with ESMTP id 35E0980298B for ; Thu, 2 Oct 2014 17:03:09 -0300 (BRT) Received: from MSSRV018.ms.mandic.com.br ([192.168.11.5]) by mssrv001.ms.mandic.com.br ([::1]) with mapi; Thu, 2 Oct 2014 17:03:08 -0300 From: Anderson Farias To: "pkix@ietf.org" Date: Thu, 2 Oct 2014 17:03:07 -0300 Thread-Topic: Fermat 4 Standard Thread-Index: Ac/edpdyRRILdawPTe+fNhwmd85mZgABUCkA Message-ID: Accept-Language: pt-BR Content-Language: pt-BR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: pt-BR Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_057B_01CFDE62.BCAFE8C0" MIME-Version: 1.0 X-Mandic-Auth: eGADrKSChShDTpyCuhVL8E7pyOO3Fp9zVziD16bWjQ2hT9YoJyq7jWZFr7c/i1gGFJ34FY5MNyTkwRMnNDuoPQ== Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/GwOPI0brOMVKNekL5DnOR9MLcjw Subject: [pkix] Fermat 4 Standard X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:03:17 -0000 ------=_NextPart_000_057B_01CFDE62.BCAFE8C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_057C_01CFDE62.BCAFE8C0" ------=_NextPart_001_057C_01CFDE62.BCAFE8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 After comparing two PKCS#10 with public exponent fermat 4, I found out = that one of them was generated with a value composed by three octets (01 00 = 01) and the other one with a value composed by 4 octets (00 01 00 01).=20 =20 Even using different values, both PKCS#10 were decoded by ASN1 editors. =20 I searched on RFC 5280 but I didn=B4t find any standard for using Fermat = 4 in X.509 public key infrastructure certificates.=20 =20 Is there any RFC with requirements for Fermat 4 usage with X.509? =20 Thanks and best regards, =20 Anderson Farias=20 =20 =20 =20 ------=_NextPart_001_057C_01CFDE62.BCAFE8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

After comparing two PKCS#10 with public exponent fermat 4, = I found out that one of them was generated with a value composed by = three octets (01 00 01) and the other one with a value composed by 4 = octets (00 01 00 01).

 

Even using different values, both PKCS#10 were decoded by = ASN1 editors.

 

I searched =
on RFC 5280 but I didn=B4t find any standard for using Fermat 4  in =
X.509 public key infrastructure certificates. =
 =
Is there =
any RFC  with requirements for Fermat 4 usage with =
X.509?
 =
Thanks and =
best regards,
 =
Anderson =
Farias 

 

 

 

------=_NextPart_001_057C_01CFDE62.BCAFE8C0-- ------=_NextPart_000_057B_01CFDE62.BCAFE8C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU5TCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBYowggRyoAMCAQICEDThw9xNS9mlEQ6kB/fdnyowDQYJ KoZIhvcNAQEFBQAwggEQMQswCQYDVQQGEwJCUjEtMCsGA1UEChMkQ2VydGlzaWduIENlcnRpZmlj YWRvcmEgRGlnaXRhbCBTLkEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMT8wPQYD VQQLEzZUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9ycGEgKGMp MTExNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB MTkwNwYDVQQDEzBDZXJ0aXNpZ24gQXV0b3JpZGFkZSBDZXJ0aWZpY2Fkb3JhIENsYXNzZSAyIC0g RzIwHhcNMTQwMjExMDAwMDAwWhcNMTUwMjEwMjM1OTU5WjCBzzEtMCsGA1UEChQkQ2VydGlTaWdu IENlcnRpZmljYWRvcmEgRGlnaXRhbCBTLkEuMSUwIwYDVQQLFBxBdXRlbnRpY2FkbyBwb3IgQ2Vy dGlzaWduIFJIMSswKQYDVQQLFCJFLW1haWwgU2VndXJvIENvcnBvcmF0aXZvIENsYXNzZSAyMSEw HwYDVQQDExhBbmRlcnNvbiBTaWx2YSBkZSBGYXJpYXMxJzAlBgkqhkiG9w0BCQEWGGFmYXJpYXNA Y2VydGlzaWduLmNvbS5icjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANMJ3gjBO7ON Gw1NPyHeCXsnotHI3wWbxWou0rGP3dB4CNv9pNWh79/PRu9bu6t5Nr0vxDY+OfL2rtsm+3wf0wfz wZjG9WQabcBN2TgqNYW2Xa1mPK5ZJHPHhzpO9bZqzrTyOGujNqowOkl85qluKrST2L/4zwZPuF4P WJqUfeIksx4Mbbs0NDpcgM0xN+dibCwW5a8NHwPw67iM7euA5hNskSdsCgmM6C4ylHCfe9jXRWv/ vqTyloBizgs5dvjMjgCn50MAk3iYWeHhl7uWYlnAhUmTUcY39SsCiG6vsWzYQUcUan8U/+Rn8KQa MWGkV1KqhA3pVt1NkTNUuRHNVx0CAwEAAaOCARwwggEYMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBpBgNVHR8EYjBgMF6gXKBahlhodHRw Oi8vb25zaXRlY3JsLmNlcnRpc2lnbi5jb20uYnIvQ2VydGlzaWduQ2VydGlmaWNhZG9yYURpZ2l0 YWxTQUNMQVNTRTJHMi9MYXRlc3RDUkwuY3JsMHEGA1UdIARqMIFnMIFkBgtghkgBhvhFAQcXAjCB VDBSBggrBgEFBQcCARZGaHR0cDovL3Z0bi5jZXJ0aXNpZ24uY29tLmJyL3JlcG9zaXRvcmlvL3Bv bGl0aWNhcy9EUENfZGFfQ2VydGlzaWduLnBkZjANBgkqhkiG9w0BAQUFAAOCAQEAZaWgVuvspzui ZbaFbW5dWsBdqahbJLliiFQVllbM1xb+zKhlUCutgZTZYqxz/biJ0K+wriIDXkPzzQPl83tjyOVx Dgbu43qI8a5O+oPxq5yvVtR68e5a/rgpJRljkkogNqlv8c5HKvgX3HpS50Kf+I3+ztg6q6/woSe/ EYfJEAVh0kfDgLEuhM2FPOIXzwppPFFW5+Qk+zkuRJr58tWhNhz+o7IAg+UzO1oS5tDh7aTQffN1 ZEZeTyVisJ8cyV/rmN09HnElFXlo68BoQpbq4yuqRKzLHVa0VI0wHU2CUc+GZ/EuI7OCpivP7sa7 g7onSMJiYUbKO1MzxFpBlkQ/1zCCBYswggRzoAMCAQICEAbQ2k1yLOrQUgpYUiz13WIwDQYJKoZI hvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIElu Yy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDQxOTAwMDAw MFoXDTIxMDQxODIzNTk1OVowgYExCzAJBgNVBAYTAkJSMS0wKwYDVQQKEyRDZXJ0aXNpZ24gQ2Vy dGlmaWNhZG9yYSBEaWdpdGFsIFMuQS4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx IjAgBgNVBAMTGUNlcnRpc2lnbiBDbGFzcyAyIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDZPBWNERRE+1ozQb1pP4TUqONs7eGGxgFFtHkiY7YMoxApMms7R7JJs6FKfxZI YHhML4I2IUQ6XKMPamic350L6OPgUro8eNj/TD1vICCNvNhZp/Z8EPsKfzNzMbO4Zjy1fMQW+JSK k+CWQvTOH54ZUjSfKxjqBtkfovDgvuoQSK7Ujw6CHLFliw2C9AzvbX/wFxlEl5j7gFHEY1bSKEVf V1UuJx0N+HzheNn1zfU/qPZC6ZL+qcdKXvKKh+hllFdmQL9fudiVLKoXsW51BtnBEYRS7ibOcPb4 Z/FwZsK6W5+kZLGjYC/dOF1XQW/l6XeGmjaknXcxgn9I9qpjzPgJAgMBAAGjggGyMIIBrjAPBgNV HRMBAf8EBTADAQH/MBgGA1UdIAQRMA8wDQYLYIZIAYb4RQEHFwIwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFBZmZTQ0MyLTIwNDgtMS01NTAdBgNVHQ4EFgQUGkAXjzd3cUNl hAtapW0dsYv+BUswgfAGA1UdIwSB6DCB5aGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzOCEGFwy0mMX5hFKeewptlQW3owDQYJKoZIhvcNAQEFBQADggEBAHRBeuCmIdMahOu/ aHCLhF+TWBqyT8VlnnCTw0/2KpKf17QGYhEV1ylOtSBd8ajv0r6jsbfRBU5E5Y+JoviMUr7cZUcH EvsHSgASpQTEcThILTL0aFy82/jWs/eI7y0EI/iK954wxeQ14kCSwFSbHmJLq9Z0y2POXRISsEjS A2x7ATYzuOpumHm2MoZk1i8r5GMJxdNsYn/Tk7e2kl0ObWveYDjEYl6IzMQC2d+lpqpSEZZ5L5ke xK1Lg1ysRRaH50x0acxflC+jvp3Fy/chUJIcII3fnS6nZc+V0JUGJ8SkB3ICxhJq5PpUe6A3BUp8 ItshnxE6MJyOP4sqQtX335QwggWnMIIEj6ADAgECAhAM+gMpfFeqBrc5zpUw340yMA0GCSqGSIb3 DQEBBQUAMIGBMQswCQYDVQQGEwJCUjEtMCsGA1UEChMkQ2VydGlzaWduIENlcnRpZmljYWRvcmEg RGlnaXRhbCBTLkEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSIwIAYDVQQDExlD ZXJ0aXNpZ24gQ2xhc3MgMiBDQSAtIEcyMB4XDTExMDQxOTAwMDAwMFoXDTE2MDQxODIzNTk1OVow ggEQMQswCQYDVQQGEwJCUjEtMCsGA1UEChMkQ2VydGlzaWduIENlcnRpZmljYWRvcmEgRGlnaXRh bCBTLkEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMT8wPQYDVQQLEzZUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9ycGEgKGMpMTExNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTkwNwYDVQQDEzBD ZXJ0aXNpZ24gQXV0b3JpZGFkZSBDZXJ0aWZpY2Fkb3JhIENsYXNzZSAyIC0gRzIwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx9G4K9C65Di6kQWuMv35yDn/adoWwsiWtHuMSm8/SbkHF Mgd6OjAy4EbDtsWi3IxXZhKch5+ZI4i7ov0UhHiXW5483mIBeo7g3QOczNd4+4Oe3RfImaMbgr8S xp47V8A3LYryNh8nRZR10/8dSzgdisJsU7vwe55FiD1Y5k9V7u48TFPZj2E+VuOkRLUtQj6qF4co xHPV99zkCC+gVFL0vC1xVdrUQXcb3SFvF26d5sByBz4/68uzrQdHJZx8xdRcsYF0yPfVISCE5LIs sMtJpvWVXPxi8KpO2sT6WMXw7GtQkDXX/1BttAg1StqJt4uJUqfDQp2GUVdSs0DC8g0NAgMBAAGj ggGHMIIBgzASBgNVHRMBAf8ECDAGAQH/AgEAMHgGA1UdIARxMG8wbQYLYIZIAYb4RQEHFwIwXjAs BggrBgEFBQcCARYgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9jcHMwLgYIKwYBBQUHAgIw IhogaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9ycGEwZAYDVR0fBF0wWzBZoFegVYZTaHR0 cDovL29uc2l0ZWNybC5jZXJ0aXNpZ24uY29tLmJyL3JlcG9zaXRvcmlvL2xjci9DZXJ0aXNpZ25D bGFzczJDQUcyL0xhdGVzdENSTC5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMCoGA1UdEQQjMCGkHzAd MRswGQYDVQQDExJDZXJ0aXNpZ25DMUMyLTEtNTUwHQYDVR0OBBYEFCZKSDvXP+M+4CiXXk7Lnedr dVJGMA4GA1UdDwEB/wQEAwIBBjAfBgNVHSMEGDAWgBQaQBePN3dxQ2WEC1qlbR2xi/4FSzANBgkq hkiG9w0BAQUFAAOCAQEAD6eyadyRWkGRo9oyQlBAVdUkWBLyJynC8iBSrl9Nmfc0y8CEn7RehlvP oD2sGPp4BXGzja47LPb4nj4IOUf8btKVw6HeAilIOzTcB61xCirhfq5ilL4iiFeZqFWXlYDbs3Dn M/rABNWU6XuEVu7Sh/hrkmjG5zczBj9zOi6wxxJu/VVinJklEuqFe264FUjULL+WwrptfdXt7T70 J0hvfXn6sj6J8geGfisyYnwx0yyR07N5TWxKwnYrT01/60WUMSMltCOmN2qtyuyLm8noYYphJA0i +6XwjuLv0XPY0Qb0TI7BzA0yHPCs8unzVrbMu72SJUpDYjvBk565QXFPRTGCBeYwggXiAgEBMIIB JjCCARAxCzAJBgNVBAYTAkJSMS0wKwYDVQQKEyRDZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdp dGFsIFMuQS4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxPzA9BgNVBAsTNlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy5jZXJ0aXNpZ24uY29tLmJyL3JwYSAoYykxMTE1MDMGA1UE CxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOTA3BgNVBAMT MENlcnRpc2lnbiBBdXRvcmlkYWRlIENlcnRpZmljYWRvcmEgQ2xhc3NlIDIgLSBHMgIQNOHD3E1L 2aURDqQH992fKjAJBgUrDgMCGgUAoIIDkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEwMDIyMDAzMDdaMCMGCSqGSIb3DQEJBDEWBBQcvlpoUmnS6DDK5EnFjsmr rA7O2DCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZI hvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIB QDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCG SAFlAwQCATAKBggqhkiG9w0CBTCCATkGCSsGAQQBgjcQBDGCASowggEmMIIBEDELMAkGA1UEBhMC QlIxLTArBgNVBAoTJENlcnRpc2lnbiBDZXJ0aWZpY2Fkb3JhIERpZ2l0YWwgUy5BLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LmNlcnRpc2lnbi5jb20uYnIvcnBhIChjKTExMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFn ZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE5MDcGA1UEAxMwQ2VydGlzaWduIEF1dG9y aWRhZGUgQ2VydGlmaWNhZG9yYSBDbGFzc2UgMiAtIEcyAhA04cPcTUvZpREOpAf33Z8qMIIBOwYL KoZIhvcNAQkQAgsxggEqoIIBJjCCARAxCzAJBgNVBAYTAkJSMS0wKwYDVQQKEyRDZXJ0aXNpZ24g Q2VydGlmaWNhZG9yYSBEaWdpdGFsIFMuQS4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxPzA9BgNVBAsTNlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy5jZXJ0aXNpZ24uY29tLmJy L3JwYSAoYykxMTE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExOTA3BgNVBAMTMENlcnRpc2lnbiBBdXRvcmlkYWRlIENlcnRpZmljYWRvcmEgQ2xh c3NlIDIgLSBHMgIQNOHD3E1L2aURDqQH992fKjANBgkqhkiG9w0BAQEFAASCAQCnLXYF0jC5ZxGZ 5tdW/6Y/oXwpc2LBNNrhTj0cz/UuiIFYjHHIsFGngQPZzcjd6+NzBcGlfZeWcEuql006mDPE6mEV ig1+lC4mlPKIpSsr/HnUXXQ7nc3A7J8YbiSn4+i9Gi/GMFLol29hOTslSkY5LILxldYS0ZzJsvB0 lArFU8M7yZTgVNQGpdeWr+mHccbke+V/f4n3nfk9poC4lY+6YXSbTDN1K+FFDRQMym6ZWky6f1Oq UQHBDRVwTwhwinBvEC52LZnOoErgPHwM+acJcPguk1feJxizsaCVi3jjrgdw5CXSRUCOa7qOR8dd rpEnXev6WV+vlWDoASb8qtM/AAAAAAAA ------=_NextPart_000_057B_01CFDE62.BCAFE8C0-- From nobody Thu Oct 2 13:26:25 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7141A870C for ; Thu, 2 Oct 2014 13:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbuohvPoHXYj for ; Thu, 2 Oct 2014 13:26:23 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69631A870E for ; Thu, 2 Oct 2014 13:26:22 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id le20so1892233vcb.25 for ; Thu, 02 Oct 2014 13:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VxGyYRirojDTSoQYbLZJxD5wMwOHilxz/mJSvepD4HQ=; b=TDa7orC4VlumNzV6RfR82Cky8eek7Qq1st5+jmi2loxOZy+KjNZo/iasDbNcP4XKug BJuQmMkLdXUlgt29nU83KRmazsSIJEddO6ys2R9XeKDnNd3yLam3EQatxbKfOBCsF0tn ecSBZwZw/STnbzq9Q6enoYr9wvyvQSghIQR3RFfFnEQYcrDw0rL9TsDrH+WiOai26KLO THEb3dHjHRRRZt5PC9dzQGVw8m1WSaPp+wEl9AIpILJNdBkxvPBRILW7ujWGIf/SgXPp fg3GUaCDc3InIByl35kbUdMKSCaThVyAYsH1Ht7hATYmeolc0Too4/CmhCgErcjYO40s s9Ug== MIME-Version: 1.0 X-Received: by 10.220.168.74 with SMTP id t10mr594723vcy.35.1412281581966; Thu, 02 Oct 2014 13:26:21 -0700 (PDT) Received: by 10.52.156.168 with HTTP; Thu, 2 Oct 2014 13:26:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Oct 2014 22:26:21 +0200 Message-ID: From: Erwann Abalea To: Anderson Farias Content-Type: multipart/alternative; boundary=001a11c2bb1e041e5a0504766ee2 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/fh7a39xn1JlKwYpesrUBNwj50iU Cc: "pkix@ietf.org" Subject: Re: [pkix] Fermat 4 Standard X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:26:24 -0000 --001a11c2bb1e041e5a0504766ee2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonsoir, 2014-10-02 22:03 GMT+02:00 Anderson Farias : > After comparing two PKCS#10 with public exponent fermat 4, I found out > that one of them was generated with a value composed by three octets (01 = 00 > 01) and the other one with a value composed by 4 octets (00 01 00 01). > > The second one is invalid DER encoding, as the length is not the smallest possible. Even using different values, both PKCS#10 were decoded by ASN1 editors. > Different binary encodings, but the values are the same. I guess that your first one ends with "02 03 01 00 01" while the second one ends with "02 04 00 01 00 01". The first "02" declares an INTEGER, "03"/"04" is the length of the encoded value, the rest is the value. 0x00010001 and 0x010001 are 2 different textual representations of the same value (65537), that's similar here. I searched on RFC 5280 but I didn=C2=B4t find any standard for using Fermat 4 in X.509 public key infrastructure certificates. > > X.509 prefers DER encoding (X.690) of objects, you're talking about RSA keys, which are defined in PKCS#1. All this is standardized, and the standards are freely downloadable. --=20 Erwann. --001a11c2bb1e041e5a0504766ee2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bonsoir,

2014-10-02 22:03 GMT+02:00 Anderson Farias &l= t;afarias@cer= tisign.com.br>:

A= fter comparing two PKCS#10 with public exponent fermat 4, I found out that = one of them was generated with a value composed by three octets (01 00 01) = and the other one with a value composed by 4 octets (00 01 00 01).

<= p class=3D"MsoNormal">


The second one is invalid DER encoding, as the len= gth is not the smallest possible.

Even using different values, both PKCS#10 wer= e decoded by ASN1 editors.=C2=A0


Different binary encodings, but the values are the same.
I= guess that your first one ends with "02 03 01 00 01" while the s= econd one ends with "02 04 00 01 00 01".
The first &quo= t;02" declares an INTEGER, "03"/"04" is the length= of the encoded value, the rest is the value. 0x00010001 and 0x010001 are 2= different textual representations of the same value (65537), that's si= milar here.

I searched on RF=
C 5280 but I didn=C2=B4t find any standard for using Fermat 4 =C2=A0in X.50=
9 public key infrastructure certificates. 
<= div>
X.509 prefers DER encoding (X.690) of objects, you'r= e talking about RSA keys, which are defined in PKCS#1. All this is standard= ized, and the standards are freely downloadable.

= --
Erwann.
--001a11c2bb1e041e5a0504766ee2-- From nobody Thu Oct 2 14:07:10 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8D01ACD61 for ; Thu, 2 Oct 2014 14:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHgx-asi0Cwo for ; Thu, 2 Oct 2014 14:07:04 -0700 (PDT) Received: from smtp-06.idc2.mandic.com.br (smtp-06c.idc2.mandic.com.br [177.70.124.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE87A1A8707 for ; Thu, 2 Oct 2014 14:07:03 -0700 (PDT) Received: by smtp-06.smtp.mandic.prv (Postfix, from userid 491) id 79144801A11; Thu, 2 Oct 2014 18:13:50 -0300 (BRT) Received: from MSSRV010.ms.mandic.com.br (mdsrv01b.ms.mandic.prv [192.168.11.91]) by smtp-06.smtp.mandic.prv (Postfix) with ESMTPS id 656348019E5; Thu, 2 Oct 2014 18:13:49 -0300 (BRT) Received: from MSSRV018.ms.mandic.com.br ([192.168.11.5]) by MSSRV010.ms.mandic.com.br ([::1]) with mapi; Thu, 2 Oct 2014 18:06:58 -0300 From: Anderson Farias To: Erwann Abalea , Anderson Farias Date: Thu, 2 Oct 2014 18:06:57 -0300 Thread-Topic: [pkix] Fermat 4 Standard Thread-Index: Ac/efyK5J4i2qtIIRM+f0pHsVdQSyQABXHcg Message-ID: References: In-Reply-To: Accept-Language: pt-BR Content-Language: pt-BR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: pt-BR Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0610_01CFDE6B.9F31C620" MIME-Version: 1.0 X-Mandic-Auth: eGADrKSChShDTpyCuhVL8E7pyOO3Fp9zVziD16bWjQ2hT9YoJyq7jWZFr7c/i1gGFJ34FY5MNyTkwRMnNDuoPQ== Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/nDPw_zGzdsRJHoaEpJUy1gR14yg Cc: "pkix@ietf.org" Subject: [pkix] RES: Fermat 4 Standard X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:07:07 -0000 ------=_NextPart_000_0610_01CFDE6B.9F31C620 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0611_01CFDE6B.9F31C620" ------=_NextPart_001_0611_01CFDE6B.9F31C620 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Erwann, =20 Your answer was perfect for my understanding. =20 Thank you very much, =20 Anderson =20 =20 De: Erwann Abalea [mailto:eabalea@gmail.com]=20 Enviada em: quinta-feira, 2 de outubro de 2014 17:26 Para: Anderson Farias Cc: pkix@ietf.org Assunto: Re: [pkix] Fermat 4 Standard =20 Bonsoir, =20 2014-10-02 22:03 GMT+02:00 Anderson Farias : After comparing two PKCS#10 with public exponent fermat 4, I found out = that one of them was generated with a value composed by three octets (01 = 00 01) and the other one with a value composed by 4 octets (00 01 00 = 01). =20 The second one is invalid DER encoding, as the length is not the = smallest possible. =20 Even using different values, both PKCS#10 were decoded by ASN1 editors.=20 =20 Different binary encodings, but the values are the same. I guess that your first one ends with "02 03 01 00 01" while the second = one ends with "02 04 00 01 00 01". The first "02" declares an INTEGER, "03"/"04" is the length of the = encoded value, the rest is the value. 0x00010001 and 0x010001 are 2 = different textual representations of the same value (65537), that's = similar here. =20 I searched on RFC 5280 but I didn=C2=B4t find any standard for using = Fermat 4 in X.509 public key infrastructure certificates.=20 =20 X.509 prefers DER encoding (X.690) of objects, you're talking about RSA = keys, which are defined in PKCS#1. All this is standardized, and the = standards are freely downloadable. =20 --=20 Erwann.=20 ------=_NextPart_001_0611_01CFDE6B.9F31C620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Erwann,

 

Your answer was perfect for my understanding.

 

Thank you very much,

 

Anderson

 

 

De: = Erwann Abalea [mailto:eabalea@gmail.com]
Enviada em: = quinta-feira, 2 de outubro de 2014 17:26
Para: Anderson = Farias
Cc: pkix@ietf.org
Assunto: Re: [pkix] Fermat = 4 Standard

 

Bonsoir,

 

2014-10-02 22:03 GMT+02:00 Anderson Farias <afarias@certisign.com.br>:

After = comparing two PKCS#10 with public exponent fermat 4, I found out that = one of them was generated with a value composed by three octets (01 00 = 01) and the other one with a value composed by 4 octets (00 01 00 = 01).

 

The second one is invalid DER encoding, as the length = is not the smallest possible.

 

Even using different values, both PKCS#10 were decoded by = ASN1 editors. 

 

Different binary encodings, but the values are the = same.

I guess that your = first one ends with "02 03 01 00 01" while the second one ends = with "02 04 00 01 00 01".

The first "02" declares an INTEGER, = "03"/"04" is the length of the encoded value, the = rest is the value. 0x00010001 and 0x010001 are 2 different textual = representations of the same value (65537), that's similar = here.

 

I searched =
on RFC 5280 but I didn=C2=B4t find any standard for using Fermat 4 =
 in X.509 public key infrastructure certificates. =

 

X.509 prefers DER encoding (X.690) of objects, you're = talking about RSA keys, which are defined in PKCS#1. All this is = standardized, and the standards are freely = downloadable.

 

-- =
Erwann.

------=_NextPart_001_0611_01CFDE6B.9F31C620-- ------=_NextPart_000_0610_01CFDE6B.9F31C620 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU5TCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBYowggRyoAMCAQICEDThw9xNS9mlEQ6kB/fdnyowDQYJ KoZIhvcNAQEFBQAwggEQMQswCQYDVQQGEwJCUjEtMCsGA1UEChMkQ2VydGlzaWduIENlcnRpZmlj YWRvcmEgRGlnaXRhbCBTLkEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMT8wPQYD VQQLEzZUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9ycGEgKGMp MTExNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB MTkwNwYDVQQDEzBDZXJ0aXNpZ24gQXV0b3JpZGFkZSBDZXJ0aWZpY2Fkb3JhIENsYXNzZSAyIC0g RzIwHhcNMTQwMjExMDAwMDAwWhcNMTUwMjEwMjM1OTU5WjCBzzEtMCsGA1UEChQkQ2VydGlTaWdu IENlcnRpZmljYWRvcmEgRGlnaXRhbCBTLkEuMSUwIwYDVQQLFBxBdXRlbnRpY2FkbyBwb3IgQ2Vy dGlzaWduIFJIMSswKQYDVQQLFCJFLW1haWwgU2VndXJvIENvcnBvcmF0aXZvIENsYXNzZSAyMSEw HwYDVQQDExhBbmRlcnNvbiBTaWx2YSBkZSBGYXJpYXMxJzAlBgkqhkiG9w0BCQEWGGFmYXJpYXNA Y2VydGlzaWduLmNvbS5icjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANMJ3gjBO7ON Gw1NPyHeCXsnotHI3wWbxWou0rGP3dB4CNv9pNWh79/PRu9bu6t5Nr0vxDY+OfL2rtsm+3wf0wfz wZjG9WQabcBN2TgqNYW2Xa1mPK5ZJHPHhzpO9bZqzrTyOGujNqowOkl85qluKrST2L/4zwZPuF4P WJqUfeIksx4Mbbs0NDpcgM0xN+dibCwW5a8NHwPw67iM7euA5hNskSdsCgmM6C4ylHCfe9jXRWv/ vqTyloBizgs5dvjMjgCn50MAk3iYWeHhl7uWYlnAhUmTUcY39SsCiG6vsWzYQUcUan8U/+Rn8KQa MWGkV1KqhA3pVt1NkTNUuRHNVx0CAwEAAaOCARwwggEYMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBpBgNVHR8EYjBgMF6gXKBahlhodHRw Oi8vb25zaXRlY3JsLmNlcnRpc2lnbi5jb20uYnIvQ2VydGlzaWduQ2VydGlmaWNhZG9yYURpZ2l0 YWxTQUNMQVNTRTJHMi9MYXRlc3RDUkwuY3JsMHEGA1UdIARqMIFnMIFkBgtghkgBhvhFAQcXAjCB VDBSBggrBgEFBQcCARZGaHR0cDovL3Z0bi5jZXJ0aXNpZ24uY29tLmJyL3JlcG9zaXRvcmlvL3Bv bGl0aWNhcy9EUENfZGFfQ2VydGlzaWduLnBkZjANBgkqhkiG9w0BAQUFAAOCAQEAZaWgVuvspzui ZbaFbW5dWsBdqahbJLliiFQVllbM1xb+zKhlUCutgZTZYqxz/biJ0K+wriIDXkPzzQPl83tjyOVx Dgbu43qI8a5O+oPxq5yvVtR68e5a/rgpJRljkkogNqlv8c5HKvgX3HpS50Kf+I3+ztg6q6/woSe/ EYfJEAVh0kfDgLEuhM2FPOIXzwppPFFW5+Qk+zkuRJr58tWhNhz+o7IAg+UzO1oS5tDh7aTQffN1 ZEZeTyVisJ8cyV/rmN09HnElFXlo68BoQpbq4yuqRKzLHVa0VI0wHU2CUc+GZ/EuI7OCpivP7sa7 g7onSMJiYUbKO1MzxFpBlkQ/1zCCBYswggRzoAMCAQICEAbQ2k1yLOrQUgpYUiz13WIwDQYJKoZI hvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIElu Yy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDQxOTAwMDAw MFoXDTIxMDQxODIzNTk1OVowgYExCzAJBgNVBAYTAkJSMS0wKwYDVQQKEyRDZXJ0aXNpZ24gQ2Vy dGlmaWNhZG9yYSBEaWdpdGFsIFMuQS4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx IjAgBgNVBAMTGUNlcnRpc2lnbiBDbGFzcyAyIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDZPBWNERRE+1ozQb1pP4TUqONs7eGGxgFFtHkiY7YMoxApMms7R7JJs6FKfxZI YHhML4I2IUQ6XKMPamic350L6OPgUro8eNj/TD1vICCNvNhZp/Z8EPsKfzNzMbO4Zjy1fMQW+JSK k+CWQvTOH54ZUjSfKxjqBtkfovDgvuoQSK7Ujw6CHLFliw2C9AzvbX/wFxlEl5j7gFHEY1bSKEVf V1UuJx0N+HzheNn1zfU/qPZC6ZL+qcdKXvKKh+hllFdmQL9fudiVLKoXsW51BtnBEYRS7ibOcPb4 Z/FwZsK6W5+kZLGjYC/dOF1XQW/l6XeGmjaknXcxgn9I9qpjzPgJAgMBAAGjggGyMIIBrjAPBgNV HRMBAf8EBTADAQH/MBgGA1UdIAQRMA8wDQYLYIZIAYb4RQEHFwIwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFBZmZTQ0MyLTIwNDgtMS01NTAdBgNVHQ4EFgQUGkAXjzd3cUNl hAtapW0dsYv+BUswgfAGA1UdIwSB6DCB5aGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzOCEGFwy0mMX5hFKeewptlQW3owDQYJKoZIhvcNAQEFBQADggEBAHRBeuCmIdMahOu/ aHCLhF+TWBqyT8VlnnCTw0/2KpKf17QGYhEV1ylOtSBd8ajv0r6jsbfRBU5E5Y+JoviMUr7cZUcH EvsHSgASpQTEcThILTL0aFy82/jWs/eI7y0EI/iK954wxeQ14kCSwFSbHmJLq9Z0y2POXRISsEjS A2x7ATYzuOpumHm2MoZk1i8r5GMJxdNsYn/Tk7e2kl0ObWveYDjEYl6IzMQC2d+lpqpSEZZ5L5ke xK1Lg1ysRRaH50x0acxflC+jvp3Fy/chUJIcII3fnS6nZc+V0JUGJ8SkB3ICxhJq5PpUe6A3BUp8 ItshnxE6MJyOP4sqQtX335QwggWnMIIEj6ADAgECAhAM+gMpfFeqBrc5zpUw340yMA0GCSqGSIb3 DQEBBQUAMIGBMQswCQYDVQQGEwJCUjEtMCsGA1UEChMkQ2VydGlzaWduIENlcnRpZmljYWRvcmEg RGlnaXRhbCBTLkEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSIwIAYDVQQDExlD ZXJ0aXNpZ24gQ2xhc3MgMiBDQSAtIEcyMB4XDTExMDQxOTAwMDAwMFoXDTE2MDQxODIzNTk1OVow ggEQMQswCQYDVQQGEwJCUjEtMCsGA1UEChMkQ2VydGlzaWduIENlcnRpZmljYWRvcmEgRGlnaXRh bCBTLkEuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMT8wPQYDVQQLEzZUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9ycGEgKGMpMTExNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTkwNwYDVQQDEzBD ZXJ0aXNpZ24gQXV0b3JpZGFkZSBDZXJ0aWZpY2Fkb3JhIENsYXNzZSAyIC0gRzIwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx9G4K9C65Di6kQWuMv35yDn/adoWwsiWtHuMSm8/SbkHF Mgd6OjAy4EbDtsWi3IxXZhKch5+ZI4i7ov0UhHiXW5483mIBeo7g3QOczNd4+4Oe3RfImaMbgr8S xp47V8A3LYryNh8nRZR10/8dSzgdisJsU7vwe55FiD1Y5k9V7u48TFPZj2E+VuOkRLUtQj6qF4co xHPV99zkCC+gVFL0vC1xVdrUQXcb3SFvF26d5sByBz4/68uzrQdHJZx8xdRcsYF0yPfVISCE5LIs sMtJpvWVXPxi8KpO2sT6WMXw7GtQkDXX/1BttAg1StqJt4uJUqfDQp2GUVdSs0DC8g0NAgMBAAGj ggGHMIIBgzASBgNVHRMBAf8ECDAGAQH/AgEAMHgGA1UdIARxMG8wbQYLYIZIAYb4RQEHFwIwXjAs BggrBgEFBQcCARYgaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9jcHMwLgYIKwYBBQUHAgIw IhogaHR0cHM6Ly93d3cuY2VydGlzaWduLmNvbS5ici9ycGEwZAYDVR0fBF0wWzBZoFegVYZTaHR0 cDovL29uc2l0ZWNybC5jZXJ0aXNpZ24uY29tLmJyL3JlcG9zaXRvcmlvL2xjci9DZXJ0aXNpZ25D bGFzczJDQUcyL0xhdGVzdENSTC5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMCoGA1UdEQQjMCGkHzAd MRswGQYDVQQDExJDZXJ0aXNpZ25DMUMyLTEtNTUwHQYDVR0OBBYEFCZKSDvXP+M+4CiXXk7Lnedr dVJGMA4GA1UdDwEB/wQEAwIBBjAfBgNVHSMEGDAWgBQaQBePN3dxQ2WEC1qlbR2xi/4FSzANBgkq hkiG9w0BAQUFAAOCAQEAD6eyadyRWkGRo9oyQlBAVdUkWBLyJynC8iBSrl9Nmfc0y8CEn7RehlvP oD2sGPp4BXGzja47LPb4nj4IOUf8btKVw6HeAilIOzTcB61xCirhfq5ilL4iiFeZqFWXlYDbs3Dn M/rABNWU6XuEVu7Sh/hrkmjG5zczBj9zOi6wxxJu/VVinJklEuqFe264FUjULL+WwrptfdXt7T70 J0hvfXn6sj6J8geGfisyYnwx0yyR07N5TWxKwnYrT01/60WUMSMltCOmN2qtyuyLm8noYYphJA0i +6XwjuLv0XPY0Qb0TI7BzA0yHPCs8unzVrbMu72SJUpDYjvBk565QXFPRTGCBeYwggXiAgEBMIIB JjCCARAxCzAJBgNVBAYTAkJSMS0wKwYDVQQKEyRDZXJ0aXNpZ24gQ2VydGlmaWNhZG9yYSBEaWdp dGFsIFMuQS4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxPzA9BgNVBAsTNlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy5jZXJ0aXNpZ24uY29tLmJyL3JwYSAoYykxMTE1MDMGA1UE CxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOTA3BgNVBAMT MENlcnRpc2lnbiBBdXRvcmlkYWRlIENlcnRpZmljYWRvcmEgQ2xhc3NlIDIgLSBHMgIQNOHD3E1L 2aURDqQH992fKjAJBgUrDgMCGgUAoIIDkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEwMDIyMTA2NDNaMCMGCSqGSIb3DQEJBDEWBBSgU8QwP4T87b1ew5WkCyeJ VLLtjjCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZI hvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIB QDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCG SAFlAwQCATAKBggqhkiG9w0CBTCCATkGCSsGAQQBgjcQBDGCASowggEmMIIBEDELMAkGA1UEBhMC QlIxLTArBgNVBAoTJENlcnRpc2lnbiBDZXJ0aWZpY2Fkb3JhIERpZ2l0YWwgUy5BLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE/MD0GA1UECxM2VGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LmNlcnRpc2lnbi5jb20uYnIvcnBhIChjKTExMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFn ZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE5MDcGA1UEAxMwQ2VydGlzaWduIEF1dG9y aWRhZGUgQ2VydGlmaWNhZG9yYSBDbGFzc2UgMiAtIEcyAhA04cPcTUvZpREOpAf33Z8qMIIBOwYL KoZIhvcNAQkQAgsxggEqoIIBJjCCARAxCzAJBgNVBAYTAkJSMS0wKwYDVQQKEyRDZXJ0aXNpZ24g Q2VydGlmaWNhZG9yYSBEaWdpdGFsIFMuQS4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxPzA9BgNVBAsTNlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy5jZXJ0aXNpZ24uY29tLmJy L3JwYSAoYykxMTE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExOTA3BgNVBAMTMENlcnRpc2lnbiBBdXRvcmlkYWRlIENlcnRpZmljYWRvcmEgQ2xh c3NlIDIgLSBHMgIQNOHD3E1L2aURDqQH992fKjANBgkqhkiG9w0BAQEFAASCAQA1uEePAZDWgGiM +7HYuolYcCqoXs5jpSyJzlkJusKlgboMTr48FtoJYTPMmvXLayDwoJkcCSdjmiMpOr2U1rPDQE2Y eeeTWTF6qJFNPrBmWsdJdjVEND8VAIOB4tmppAqDCi77mZkm5HXjbXHVOCnx/uhEJBuFfbP/3ddf 4zaR40Nbt0wnx5CaSoP8ZitZORYBckXFskJ4DQ4mWY3tk+VILqmAM/xTXZ6+RG4irVJzQtX62r+N 8RAs/agGQPvg8otjeLRFmwKOktJthjAl+v4ekfsHpcIIc5sMW+odiFNN/c+wtYIypbzzqSEL+j1V bx6b4MsApHnDF9IJCHRXMuYNAAAAAAAA ------=_NextPart_000_0610_01CFDE6B.9F31C620-- From nobody Fri Oct 3 00:56:22 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE721ACFEA for ; Fri, 3 Oct 2014 00:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmWvpY0kb_iz for ; Fri, 3 Oct 2014 00:56:18 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619C11ACFE5 for ; Fri, 3 Oct 2014 00:56:18 -0700 (PDT) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 2E0105E21F; Fri, 3 Oct 2014 09:56:17 +0200 (CEST) Received: from [127.0.0.1] (unknown [192.168.18.180]) by mx1.on-x.com (Postfix) with ESMTP id 139AD5E218; Fri, 3 Oct 2014 09:56:17 +0200 (CEST) Message-ID: <542E56A0.1080908@edelweb.fr> Date: Fri, 03 Oct 2014 09:56:16 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080605050507060900020200" Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/kYs1cpQRomZD2g2-ksGuAsQXyP0 Subject: Re: [pkix] Fermat 4 Standard X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 07:56:21 -0000 This is a multi-part message in MIME format. --------------080605050507060900020200 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/02/2014 11:06 PM, Anderson Farias wrote: > > Hi Erwann, > > Your answer was perfect for my understanding. > > Thank you very much, > > Anderson > > *De:*Erwann Abalea [mailto:eabalea@gmail.com] > *Enviada em:* quinta-feira, 2 de outubro de 2014 17:26 > *Para:* Anderson Farias > *Cc:* pkix@ietf.org > *Assunto:* Re: [pkix] Fermat 4 Standard > > Bonsoir, > > 2014-10-02 22:03 GMT+02:00 Anderson Farias >: > > After comparing two PKCS#10 with public exponent fermat 4, I found out = that one of them was=20 > generated with a value composed by three octets (01 00 01) and the othe= r one with a value composed=20 > by 4 octets (00 01 00 01). > > The second one is invalid DER encoding, as the length is not the smalle= st possible. > > Even using different values, both PKCS#10 were decoded by ASN1 edit= ors. > > Different binary encodings, but the values are the same. > > I guess that your first one ends with "02 03 01 00 01" while the second= one ends with "02 04 00 01=20 > 00 01". > > The first "02" declares an INTEGER, "03"/"04" is the length of the enco= ded value, the rest is the=20 > value. 0x00010001 and 0x010001 are 2 different textual representations = of the same value (65537),=20 > that's similar here. > > I searched on RFC 5280 but I didn=B4t find any standard for using F= ermat 4 in X.509 public key infrastructure certificates. > > X.509 prefers DER encoding (X.690) of objects, you're talking about RSA= keys, which are defined in=20 > PKCS#1. All this is standardized, and the standards are freely download= able. > > --=20 > Erwann. > On 10/02/2014 11:34 PM, Viktor Dukhovni wrote: > On Thu, Oct 02, 2014 at 04:25:16PM -0300, Anderson Farias wrote: >> After comparing two PKCS#10 with public exponent fermat 4, I found out= >> that one of them was generated with a value composed by three octets (= 01 >> 00 01) and the other one with a value composed by 4 octets (00 01 00 0= 1). > These are not different values, they are different BER encodings > of the same value. The first form is also DER, while the second > is not. >> I searched on RFC 5280 but I didn't find any standard for using Fermat= 4 >> in X.509 public key infrastructure certificates. > This has nothing to do with F_4, rather the issue is how the integer > exponent in X.509 SPKI RSA keys is encoded. BER encodings are > widely tolerated in X.509 for interoperability reasons, so both > encodings are usable though of course the DER format should be > used. > >> Is there any RFC with requirements for Fermat 4 usage with X.509? > No, but there are ITU documents that define ASN.1 encoding. > > Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Informati= on > technology - ASN.1 encoding rules: Specification of Basic Encoding= > Rules (BER), Canonical Encoding Rules (CER) and Distinguished > Encoding Rules (DER) > Well, actually it is the following but the rules concerning content encod= ing for integers haven't changed since 30 years. ITU X.690 (11/2008) | ISO/IEC 8825-1:2008 02 03 010001 is a correct BER and DER encoding of the F4 integer 02 04 00010001 is simply incorrect. (violates 8.3.2b) 02 82 0003 010001 is a correct BER encoding but not DER. (does not respe= ct 10.1) 8.3 Encoding of an integer value 8.3.1 The encoding of an integer value shall be primitive. The contents o= ctets shall consist of one=20 or more octets. 8.3.2 If the contents octets of an integer value encoding consist of more= than one octet, then the=20 bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE =96 These rules ensure that an integer value is always encoded in th= e smallest possible number of=20 octets. 8.3.3 The contents octets shall be a two's complement binary number equa= l to the integer value, and=20 consisting of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second oct= et, followed by bits 8 to 1=20 of each octet in turn up to and including the last octet of the contents octets. NOTE =96 The value of a two's complement binary number is derived by numb= ering the bits in the=20 contents octets, starting with bit 1 of the last octet as bit zero and ending the numbering with bit 8 of th= e first octet. Each bit is=20 assigned a numerical value of 2 N , where N is its position in the above numbering sequence. The value of the= two's complement binary=20 number is obtained by summing the numerical values assigned to each bit for those bits which ar= e set to one, excluding bit=20 8 of the first octet, and then reducing this value by the numerical value assigned to bit 8 of the first= octet if that bit is set=20 to one. DER does not have restrictions for the encoding of the content octets of = an integer. 10 Distinguished encoding rules The encoding of a data values employed by the distinguished encoding rule= s is the basic encoding=20 described in clause 8, together with the following restrictions and those also listed in clau= se 11. 10.1 Length forms The definite form of length encoding shall be used, encoded in the minimu= m number of octets. [Contrast with 8.1.3.2 b).] best Peter --------------080605050507060900020200 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 10/02/2014 11:06 PM, Anderson Faria= s wrote:

Hi Erwann,

=

=A0

Your answer was perfe= ct for my understanding.

=A0

Thank you very much,<= /span>

=A0

Anderson

=A0

=A0

De: Erwann Abalea [mailto:eabalea@gmail.com]
Enviada em: quinta-feira, 2 de outubro de 2014 17:26
Para: Anderson Farias
Cc: pkix@ietf.org
Assunto: Re: [pkix] Fermat 4 Standard

=A0

Bonsoir,

=A0

2014-10-02 22:03 GMT+02:00 Anderson Farias <afarias@certisign.com.br>:

After comparing two PKCS#10 with public exponent fermat 4, I found out that one of them was generated with a value composed by three octets (01 00 01) and the other one with a value composed by 4 octets (00 01 00 01).

=A0

The second one is invalid DER encoding, as the length is not the smallest possible.

=A0

Even using different values, both PKCS#10 were decoded by ASN1 editors.=A0

=A0

Different binary encodings, but th= e values are the same.

I guess that your first one ends with "02 03 01 00 01" while the second one ends with "02 04 00 01 00 01".

The first "02" declares an INTEGER= , "03"/"04" is the length of the encoded value, the rest is the value. 0x00010001 and 0x010001 are 2 different textual representations of the same value (65537), that's similar here.

=A0

I searched on RFC 5280 but I =
didn=B4t find any standard for using Fermat 4 =A0in X.509 public key infr=
astructure certificates. 

=A0

X.509 prefers DER encoding (X.690)= of objects, you're talking about RSA keys, which are defined in PKCS#1. All this is standardized, and the standards are freely downloadable.

=A0

--
Erwann.

On 10/02/2014 11:34 PM, Viktor= Dukhovni wrote:
On Thu, Oct 02, 2014 at 04:25:16PM -0300, Anderson Farias wrote:
After comparing two PKCS#10 with public exponent fermat 4, I found out
that one of them was generated with a value composed by three octets (01
00 01) and the other one with a value composed by 4 octets (00 01 00 01).
These are not different values, they are different BER encodings
of the same value.=A0 The first form is also DER, while the secon= d
is not.
I searched on RFC 5280 but I didn't find any standard for using Fermat 4
in X.509 public key infrastructure certificates.
This has nothing to do with F_4, rather the issue is how the integer
exponent in X.509 SPKI RSA keys is encoded.=A0 BER encodings are
widely tolerated in X.509 for interoperability reasons, so both
encodings are usable though of course the DER format should be
used.

Is there any RFC=A0 with requirements for Fermat 4 usage with X.509?
No, but there are ITU documents that define ASN.1 encoding.

=A0=A0=A0=A0 Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2= 002, Information
=A0=A0=A0=A0 technology - ASN.1 encoding rules: Specification of = Basic Encoding
=A0=A0=A0=A0 Rules (BER), Canonical Encoding Rules (CER) and Distinguished
=A0=A0=A0=A0 Encoding Rules (DER)

Well, actually it is the following but the rules concerning content encoding for integers
haven't changed since 30 years.

ITU X.690 (11/2008) | ISO/IEC 8825-1:2008


02 03 010001=A0=A0 is a correct BER and DER encoding of the F4 inte= ger

02 04 00010001=A0=A0 is simply incorrect. (violates 8.3.2b)

02 82 0003 010001=A0 is a correct BER encoding but not DER. (does not respect 10.1)



8.3 Encoding of an integer value

8.3.1 The encoding of an integer value shall be primitive. The contents octets shall consist of one or more octets.

8.3.2 If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first
octet and bit 8 of the second octet:
a)=A0 shall not all be ones; and
b)=A0 shall not all be zero.
NOTE =96 These rules ensure that an integer value is always encoded= in the smallest possible number of octets.

8.3.3=A0 The contents octets shall be a two's complement binary number equal to the integer value, and consisting of
bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed by bits 8 to 1 of each octet in turn up to
and including the last octet of the contents octets.
NOTE =96 The value of a two's complement binary number is derived b= y numbering the bits in the contents octets, starting with bit
1 of the last octet as bit zero and ending the numbering with bit 8 of the first octet. Each bit is assigned a numerical value of 2 N ,
where N is its position in the above numbering sequence. The value of the two's complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are set to one, excluding bit 8 of the first octet, and then
reducing this value by the numerical value assigned to bit 8 of the first octet if that bit is set to one.

DER does not have restrictions for the encoding of the content octets of an integer.

10 Distinguished encoding rules
The encoding of a data values employed by the distinguished encoding rules is the basic encoding described in clause
8, together with the following restrictions and those also listed in clause 11.
10.1 Length forms
The definite form of length encoding shall be used, encoded in the minimum number of octets. [Contrast
with 8.1.3.2 b).]


best
Peter


--------------080605050507060900020200-- From nobody Thu Oct 9 05:56:04 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A191ACEA9 for ; Thu, 9 Oct 2014 05:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2BaifRAAEQz for ; Thu, 9 Oct 2014 05:56:01 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DD01ACE74 for ; Thu, 9 Oct 2014 05:55:09 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so1124096lab.35 for ; Thu, 09 Oct 2014 05:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=d8+3B0JqOcK5T8ZH6Q7KkRxx9XHaYEfud7I026NhX7A=; b=KbahT1fI8S4o58SAoyGWutbAfGk2XcHcn3lbzUIVzWvW/v0fe7/bYJGC3yiTYMvVmf 7q0cpPt/MKSr3hYaMI3EAMTiN//uemJUtSVVsyVxzy6BSai03ip6eGt8xuhChnXwbLUb Bgx/yt9MPNL2YY1/SzUcufcbJM7ZRT9WvtJg27yUxi2mC06KC7SYNflVfjiphauMZSri UbEQvsc7DSHyoLau68IFB3kCoSncWYimunfD/Dx7a7G9wBTXE7xIcgmsxXwAK7W7AFX2 K72m187YcPWbq6TMVFEv5nWPBl0j/4dZTGCOPsoSLm9BS346KdIShT5QukyPNIprNbWc SiLA== MIME-Version: 1.0 X-Received: by 10.152.8.194 with SMTP id t2mr13088128laa.85.1412859307698; Thu, 09 Oct 2014 05:55:07 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Thu, 9 Oct 2014 05:55:07 -0700 (PDT) Date: Thu, 9 Oct 2014 08:55:07 -0400 X-Google-Sender-Auth: NxsYKYBVbEb1G-WmPrHURrFq7Cg Message-ID: From: Phillip Hallam-Baker To: "pkix@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/q4DEqV9nt8BhXxYg0PpApI0ehbQ Subject: [pkix] Compressed CRLs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 12:56:02 -0000 I sent this to TLS in the first instance but it might be of more interest here. It turns out that we can compress CRLs much better than anyone imagined. Using compression we can issue a CRL for every unexpired SSL Server cert using less than the 250K that is the limit on Google's curated CRLSet. Please note: http://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/ Also note the pending IPR disclosure. In brief Rob Stradling and myself have come up with a radically new approach to certificate status that is vastly more efficient than any previous proposal that provides finer grain certificate status than the certificate validity interval. While compressing hash tables might appear to be a fools errand, it turns out that if the problem is correctly understood, CRLs actually compress astonishingly well. It is actually possible to represent the status of every one of the half million revoked certificates in the WebPKI using fewer bytes than the heavily edited Google CRLSet. There is still a powerful case for short lived certificates. But the minimum feasible expiry interval for short lived certs is 48 hours. Using a compressed CRL in combination with short lived certs would allow the vulnerability window to be reduced to minutes. We are of course aware that deployment will require a licensing regime that meets the need of all parties including competing CAs, open source software providers, etc. However lacking an existing licensing regime for the rights holder (if indeed any are granted), I thought it best to bring this to people's attention first. The nature of the invention is such that not applying for a patent would open the possibility that someone else might make a claim as has happened to me on numerous other occasions. In the past five years over $50 million has been spent on defending against such patent claims. From nobody Tue Oct 14 02:21:53 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DD71A6FEF for ; Tue, 14 Oct 2014 02:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.81 X-Spam-Level: * X-Spam-Status: No, score=1.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENmYzdCeQUZt for ; Tue, 14 Oct 2014 02:21:50 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CC21A6FEC for ; Tue, 14 Oct 2014 02:21:49 -0700 (PDT) Received: from Morten ([62.44.134.98]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id 2201410141121441208 for ; Tue, 14 Oct 2014 11:21:44 +0200 From: "Erik Andersen" To: "PKIX" Date: Tue, 14 Oct 2014 11:21:44 +0200 Message-ID: <000201cfe790$45dcd140$d19673c0$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01CFE7A1.096727E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/njzcKb1Xr+ImVQUWYJscmK+kLJw== Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/GGhGSpaz-ReJmiFTHFIhBLxxd_o Subject: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:21:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0003_01CFE7A1.096727E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Simple Certificate Enrollment Protocol (SCEP) (http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed6.0%7Den.pdf) appears to be widely used and implemented although it is specified in an old, expired Internet draft from 2011 that was never issued as an RFC. Why was it never issued as an RFC and why should it not be on the standards track? Kind regards, Erik ------=_NextPart_000_0003_01CFE7A1.096727E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Simple Certificate Enrollment Protocol (SCEP) (http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed= 6.0%7Den.pdf) appears to be widely used and implemented although it = is specified in an old, expired Internet draft from 2011 that was never = issued as an RFC.

 

Why was it = never issued as an RFC and why should it not be on the standards track? =

 

Kind regards,

 

Erik

------=_NextPart_000_0003_01CFE7A1.096727E0-- From nobody Tue Oct 14 03:18:31 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73F81A7023 for ; Tue, 14 Oct 2014 03:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncmQAfU7syQq for ; Tue, 14 Oct 2014 03:18:24 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0E81A701E for ; Tue, 14 Oct 2014 03:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413281904; x=1444817904; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=dG0npt8h81XUNtewHGoTOHjLmZXvXH5U0agXeKdNhJQ=; b=Sn3KYDuJM1tFLKDxudBzv+0gtHJNJ+ZK9WvMrNQLWnXLTzcjRyE78LQA /YUXCPZBPQIvY+iJqhuWd3M0tgeC/WuCtMBdLjLFIdXOW4Ce/5MJYKiqC ZjXX8b0KaJzfeM2h2eH0nZ9Sb0siVG0bkmlf+0if7U1m69vsizsJ576E/ w=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283037261" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 14 Oct 2014 23:18:17 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 23:18:17 +1300 From: Peter Gutmann To: IETF PKIX Thread-Topic: [pkix] Simple Certificate Enrollment Protocol (SCEP) Thread-Index: Ac/nmCuBMMt+dgzWQui3YPP1ZjLWfg== Date: Tue, 14 Oct 2014 10:18:16 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/XRuB90uUXcAPYGAm6pbj5j4veDc Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 10:18:29 -0000 Erik Andersen writes:=0A= >Simple Certificate Enrollment Protocol (SCEP) (=0A= >http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed6.0%7Den.pdf= )=0A= >appears to be widely used and implemented although it is specified in an o= ld,=0A= >expired Internet draft from 2011 that was never issued as an RFC.=0A= >=0A= >Why was it never issued as an RFC and why should it not be on the standard= s=0A= >track?=0A= =0A= Because it wasn't invented by PKIX. PKIX have their own two protocols, CMP= =0A= and CMC, both of which have practically nonexistent support, and even less= =0A= interoperability. SCEP was invented by Cisco but they're trying to disown = it=0A= in favour of another new protocol they've dreamed up with (you guessed it)= =0A= practically nonexistent support and interoperability.=0A= =0A= Peter.= From nobody Tue Oct 14 04:15:21 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04551A8549 for ; Tue, 14 Oct 2014 04:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON4hzQdPT0UH for ; Tue, 14 Oct 2014 04:15:16 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01101A82E2 for ; Tue, 14 Oct 2014 04:15:15 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id uq10so14108409igb.7 for ; Tue, 14 Oct 2014 04:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UAnTB2tDiHrA4A9Ge95QQ1qAiDvqd3Wij+i7N+0p80c=; b=cV4XHARnJusX2RXdH6QxX+4qHyMb8/3GXz+J2NI8VN1EMlHwNySQPCzYAlLWu7/wM/ TndnvXRXAVSEfm7C7n9T7IrDEHYgXluiNkks18Yywx6Vawco3JbhEBAo/0WCU02PdeV+ zUwkRALghkPqIoahqkFo8QcPGW9g4t8SatBrWPWH5N7WQMB7/DcvJrhmZCDl3zW5bfPD wrP2NpBz37K2kkQunJesf56vhJ9RAAnuIzTsuDB5bu3ox3JJ9EsematflUD2s6D2J4FR 8hiaBaMSiC3DS6193eNnQ2es9sTk09/13wRmHrS8wZa0s2Gj78X4yu517lRaxUlK5cHZ +INw== MIME-Version: 1.0 X-Received: by 10.50.70.40 with SMTP id j8mr6031138igu.31.1413285315363; Tue, 14 Oct 2014 04:15:15 -0700 (PDT) Received: by 10.107.11.84 with HTTP; Tue, 14 Oct 2014 04:15:15 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 14 Oct 2014 07:15:15 -0400 Message-ID: From: Michael Jenkins To: IETF PKIX Content-Type: multipart/alternative; boundary=047d7b3a9696306cc305056021d5 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/cS_MUhKbMbkFeeYtqri_FCIjTDM Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 11:15:17 -0000 --047d7b3a9696306cc305056021d5 Content-Type: text/plain; charset=UTF-8 The new protocol is documented in RFC 7030, "Enrollment over Secure Transport". I'm not familiar enough with SCEP to know what the differences are or if they are large; one primary reason for publishing the new protocol was to permit algorithm update. Mike On Tue, Oct 14, 2014 at 6:18 AM, Peter Gutmann wrote: > Erik Andersen writes: > >Simple Certificate Enrollment Protocol (SCEP) ( > > > http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed6.0%7Den.pdf > ) > >appears to be widely used and implemented although it is specified in an > old, > >expired Internet draft from 2011 that was never issued as an RFC. > > > >Why was it never issued as an RFC and why should it not be on the > standards > >track? > > Because it wasn't invented by PKIX. PKIX have their own two protocols, CMP > and CMC, both of which have practically nonexistent support, and even less > interoperability. SCEP was invented by Cisco but they're trying to disown > it > in favour of another new protocol they've dreamed up with (you guessed it) > practically nonexistent support and interoperability. > > Peter. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --047d7b3a9696306cc305056021d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The new protocol is documented in RFC 7030, "Enr= ollment over Secure Transport". I'm not familiar enough with SCEP = to know what the differences are or if they are large; one primary reason f= or publishing the new protocol was to permit algorithm update.

Mike

On= Tue, Oct 14, 2014 at 6:18 AM, Peter Gutmann <pgut001@cs.auckland= .ac.nz> wrote:
Erik Andersen <era@x500.eu> writes:
>Simple Certificate Enrollment Protocol (SCEP) (
>http://www.iec.ch/members_experts/refdocs= /iec/isoiec-dir2%7Bed6.0%7Den.pdf)
>appears to be widely used and implemented although it is specified in a= n old,
>expired Internet draft from 2011 that was never issued as an RFC.
>
>Why was it never issued as an RFC and why should it not be on the stand= ards
>track?

Because it wasn't invented by PKIX.=C2=A0 PKIX have their o= wn two protocols, CMP
and CMC, both of which have practically nonexistent support, and even less<= br> interoperability.=C2=A0 SCEP was invented by Cisco but they're trying t= o disown it
in favour of another new protocol they've dreamed up with (you guessed = it)
practically nonexistent support and interoperability.

Peter.
_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix

--047d7b3a9696306cc305056021d5-- From nobody Tue Oct 14 04:16:47 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C191A854B for ; Tue, 14 Oct 2014 04:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-h8K0399EWj for ; Tue, 14 Oct 2014 04:16:43 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28ED81A8549 for ; Tue, 14 Oct 2014 04:16:43 -0700 (PDT) Received: from Morten ([62.44.134.98]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201410141316388408; Tue, 14 Oct 2014 13:16:38 +0200 From: "Erik Andersen" To: "PKIX" References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 14 Oct 2014 13:16:37 +0200 Message-ID: <001001cfe7a0$52f31640$f8d942c0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIjz5o9RaDncOt0Yx4LRcCXToJP45uHnj0A Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/7XDReBo-HpIvOndHxAO_e33XcPM Cc: WG15@iectc57.org, Carsten Strunge , =?iso-8859-1?Q?S=F8ren_Peter_Nielsen?= Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 11:16:44 -0000 Hi Peter, Thanks for your quick answer. The smart grid security folks want to use SCEP as normative reference in their specification. In the current state of SCEP, this is probably = against the rules of IEC. It might be desirable to progress SCEP to a more = official status. That could be within PKIX as an RFC or as an ITU-T = Recommendation to be progressed very quickly. The latter might require some consent from Cisco. Regard, Erik -----Oprindelig meddelelse----- Fra: pkix [mailto:pkix-bounces@ietf.org] P=E5 vegne af Peter Gutmann Sendt: 14. oktober 2014 12:18 Til: IETF PKIX Emne: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) Erik Andersen writes: >Simple Certificate Enrollment Protocol (SCEP) ( >http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed6.0%7Den. >pdf) appears to be widely used and implemented although it is specified = >in an old, expired Internet draft from 2011 that was never issued as an = >RFC. > >Why was it never issued as an RFC and why should it not be on the=20 >standards track? Because it wasn't invented by PKIX. PKIX have their own two protocols, = CMP and CMC, both of which have practically nonexistent support, and even = less interoperability. SCEP was invented by Cisco but they're trying to = disown it in favour of another new protocol they've dreamed up with (you = guessed it) practically nonexistent support and interoperability. Peter. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From nobody Tue Oct 14 04:30:20 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716F41A86EE for ; Tue, 14 Oct 2014 04:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNRS90EINjEL for ; Tue, 14 Oct 2014 04:30:17 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516C11A854B for ; Tue, 14 Oct 2014 04:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413286217; x=1444822217; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=ab4DvkQGKdThFulrKndyszZVKYzqmXDzN4QymnFaQQc=; b=ZtrJvcuXiBduTYbSxcvVjmvWnnjvEJ0MAVnNoOew5g8N1YNmCZI30YpQ hZhsFHXYuhtG0UuOt5hAEsRPyu18SyDjeY0uci+HmHDrgGiyfp2dQ+x1c jFOVpf69gP0AoOp8KEZq1LwaEhpj9YjgHvCJbXmc9JMnAlVY0QZdO6EV9 M=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283044729" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Oct 2014 00:30:15 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Wed, 15 Oct 2014 00:30:15 +1300 From: Peter Gutmann To: IETF PKIX Thread-Topic: [pkix] Simple Certificate Enrollment Protocol (SCEP) Thread-Index: Ac/nojkd8b5ky4bsTai8zHCjpqK+hw== Date: Tue, 14 Oct 2014 11:30:14 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9CAFF4@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/kwIyVgeq4x-iGBtSTRf4DX8KuQQ Cc: "WG15@iectc57.org" , "CAS@energinet.dk" , "soren.peter.nielsen@gmail.com" Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 11:30:19 -0000 Erik Andersen writes:=0A= =0A= >The smart grid security folks want to use SCEP as normative reference in= =0A= >their specification. =0A= =0A= It's already being used in a variety of SCADA applications (and is required= in=0A= some SCADA standards), so they're in good company there.=0A= =0A= >In the current state of SCEP, this is probably against the rules of IEC. I= t=0A= >might be desirable to progress SCEP to a more official status. That could = be=0A= >within PKIX as an RFC or as an ITU-T Recommendation to be progressed very= =0A= >quickly. The latter might require some consent from Cisco.=0A= =0A= That's going to be tricky, Cisco really wants people to forget about SCEP a= nd=0A= move onto EST (thanks to Michael Jenkins for pointing out the name, I was t= oo=0A= lazy to Google it :-). I've submitted a bunch of corrections to SCEP (ther= e=0A= are some things that were bolted on later that really don't work as specifi= ed,=0A= or under-specified, in the spec) but haven't been able to get any traction = on=0A= it. At the moment I don't know what it'd take to get SCEP published as any= =0A= sort of standard. OTOH as you point out it is a very widely-used de facto= =0A= standard, while the actual "standards" (CMP, CMC, etc) barely exist and don= 't=0A= interoperate when they do).=0A= =0A= It's a bit of a COBOL vs. OCaml thing, one is old and clunky and just gets = the=0A= job done (SCEP), the other is complex and full of esoteric features and onl= y=0A= understood by about seven people, three of whom mutter to themselves a lot = and=0A= aren't allowed near sharp objects because of what they might do with them= =0A= (CMP/CMC/etc).=0A= =0A= Peter.= From nobody Tue Oct 14 04:47:29 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E91D1A86FF for ; Tue, 14 Oct 2014 04:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO5mYHu46L6V for ; Tue, 14 Oct 2014 04:47:25 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D44A1A86FA for ; Tue, 14 Oct 2014 04:47:25 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so10751360wgh.12 for ; Tue, 14 Oct 2014 04:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QjNOTBy+ss0ugfWWGZ8mvGMsEKnsCkx0PRuc2WZLhik=; b=hNVCBmrf9mJR5SI1EkBQD+0OVDDaZ0/HmwIOsBgOVTHKS05oDHxQd9t7d1x/ksBa+Q q3I4hMmJKFMrH/hRX8NADS/g7gIqjbA5yOrskhmO5w6vgLV30GVtja4D12fpgArlBa2z MVunxajtmY9TTQMXdcg6Z88eaGXv65gGkUJGQMDugbmCBGwB2RiBjRj1WCIB2TwnIw5E L3R4vgoN2Mlwd6sHt0pMuMdolnG8EuVubthQHcVrseCHqLTAZ1TkhUA1V5wWyhSYowW4 +J0158dqXUuaSvtCa+BrVP1n3yo2RQwZchLBPnmRBFMRNJkjt6dy1wJC/5JHwo00RVfp c9Pw== X-Received: by 10.180.102.135 with SMTP id fo7mr4941515wib.79.1413287244236; Tue, 14 Oct 2014 04:47:24 -0700 (PDT) Received: from [192.168.1.79] (222.118.176.95.rev.sfr.net. [95.176.118.222]) by mx.google.com with ESMTPSA id k2sm15437305wiz.18.2014.10.14.04.47.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 04:47:23 -0700 (PDT) Message-ID: <543D0D46.6020708@gmail.com> Date: Tue, 14 Oct 2014 13:47:18 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Erik Andersen , PKIX References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> In-Reply-To: <001001cfe7a0$52f31640$f8d942c0$@x500.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/G6rHtHdlGj-yd5wEozk8bq9BKME Cc: WG15@iectc57.org, Carsten Strunge , =?ISO-8859-1?Q?S=F8ren_Peter_Nielsen?= Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 11:47:27 -0000 On 2014-10-14 13:16, Erik Andersen wrote: > Hi Peter, > > Thanks for your quick answer. > > The smart grid security folks want to use SCEP as normative reference in > their specification. In the current state of SCEP, this is probably against > the rules of IEC. It might be desirable to progress SCEP to a more official > status. That could be within PKIX as an RFC or as an ITU-T Recommendation to > be progressed very quickly. The latter might require some consent from > Cisco. Unfortunately none of the PKIX enrollment protocols support E2ES (end-to-end security) so they are fairly useless for large-scale applications, including IoT. FIDO alliance have (with Google's help) produced new protocols that support E2ES. E2ES in this context means that the key-container attests its identity/authenticity as a part of the protocol. Anders > > Regard, > > Erik > > -----Oprindelig meddelelse----- > Fra: pkix [mailto:pkix-bounces@ietf.org] På vegne af Peter Gutmann > Sendt: 14. oktober 2014 12:18 > Til: IETF PKIX > Emne: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) > > Erik Andersen writes: >> Simple Certificate Enrollment Protocol (SCEP) ( >> http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed6.0%7Den. >> pdf) appears to be widely used and implemented although it is specified >> in an old, expired Internet draft from 2011 that was never issued as an >> RFC. >> >> Why was it never issued as an RFC and why should it not be on the >> standards track? > > Because it wasn't invented by PKIX. PKIX have their own two protocols, CMP > and CMC, both of which have practically nonexistent support, and even less > interoperability. SCEP was invented by Cisco but they're trying to disown > it in favour of another new protocol they've dreamed up with (you guessed > it) practically nonexistent support and interoperability. > > Peter. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From nobody Tue Oct 14 05:36:53 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F74C1A8781 for ; Tue, 14 Oct 2014 05:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsuxjOxXIGQG for ; Tue, 14 Oct 2014 05:36:51 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id DD5241A877B for ; Tue, 14 Oct 2014 05:36:50 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7C9BA72E0E2 for ; Tue, 14 Oct 2014 08:36:50 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 75C8372E0C2 for ; Tue, 14 Oct 2014 08:36:50 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 08:36:50 -0400 From: "Miller, Timothy J." To: IETF PKIX Thread-Topic: [pkix] Simple Certificate Enrollment Protocol (SCEP) Thread-Index: Ac/nmCuBb1Xr+ImVQUWYJscmK+kLJwAKXx6AAAYUtTA= Date: Tue, 14 Oct 2014 12:36:50 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200461CF280@IMCMBX01.MITRE.ORG> References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/BNemQquH4PcLZHPq6SZ-u5YlBYo Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:36:52 -0000 T24gVHVlLCBPY3QgMTQsIDIwMTQgYXQgNjoxOCBBTSwgUGV0ZXIgR3V0bWFubiA8cGd1dDAwMUBj cy5hdWNrbGFuZC5hYy5ueiA8bWFpbHRvOnBndXQwMDFAY3MuYXVja2xhbmQuYWMubno+ID4gd3Jv dGU6DQoNCj4JQmVjYXVzZSBpdCB3YXNuJ3QgaW52ZW50ZWQgYnkgUEtJWC4gIFBLSVggaGF2ZSB0 aGVpciBvd24gdHdvIHByb3RvY29scywgQ01QDQo+CWFuZCBDTUMsIGJvdGggb2Ygd2hpY2ggaGF2 ZSBwcmFjdGljYWxseSBub25leGlzdGVudCBzdXBwb3J0LCBhbmQgZXZlbiBsZXNzDQo+CWludGVy b3BlcmFiaWxpdHkuICBTQ0VQIHdhcyBpbnZlbnRlZCBieSBDaXNjbyBidXQgdGhleSdyZSB0cnlp bmcgdG8gZGlzb3duIGl0DQo+CWluIGZhdm91ciBvZiBhbm90aGVyIG5ldyBwcm90b2NvbCB0aGV5 J3ZlIGRyZWFtZWQgdXAgd2l0aCAoeW91IGd1ZXNzZWQgaXQpDQo+CXByYWN0aWNhbGx5IG5vbmV4 aXN0ZW50IHN1cHBvcnQgYW5kIGludGVyb3BlcmFiaWxpdHkuDQoNCk9uIFR1ZSwgT2N0IDE0LCAy MDE0IGF0IDY6MTUgQU0sIE1pY2hhZWwgSmVua2lucyA8TWljaGFlbCBKZW5raW5zIDxiZXJndGF1 QGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5UaGUgbmV3IHByb3RvY29sIGlzIGRvY3VtZW50ZWQgaW4g UkZDIDcwMzAsICJFbnJvbGxtZW50IG92ZXIgU2VjdXJlDQo+VHJhbnNwb3J0Ii4gSSdtIG5vdCBm YW1pbGlhciBlbm91Z2ggd2l0aCBTQ0VQIHRvIGtub3cgd2hhdCB0aGUgZGlmZmVyZW5jZXMNCj5h cmUgb3IgaWYgdGhleSBhcmUgbGFyZ2U7IG9uZSBwcmltYXJ5IHJlYXNvbiBmb3IgcHVibGlzaGlu ZyB0aGUgbmV3IHByb3RvY29sDQo+d2FzIHRvIHBlcm1pdCBhbGdvcml0aG0gdXBkYXRlLg0KDQpB bmQgbGV0J3Mgbm90IGZvcmdldCBYS01TIChXM0MpLCBLTUlQIChPQVNJUyksIFBDQVMgKFRDRyks IGFuZCBhdCBsZWFzdCB0d28gTWljcm9zb2Z0IHByb3RvY29scyBbMV0uICBEaWQgSSBtaXNzIGFu eW9uZT8gIDopDQoNCk9iWGtjZFJlZjogaHR0cDovL3hrY2QuY29tLzkyNy8NCg0KQW5kIGFzIGZh ciBhcyBTQ0VQIGJlaW5nIGEgIm9sZCBhbmQgY2x1bmt5LCIgSU1ITyBpdCdzIG1vcmUgYWNjdXJh dGUgdG8gc2F5ICJicm9rZW4gaW4gbWFueSBpbXBsZW1lbnRhdGlvbnMgYmVjYXVzZSBvZiBzdWJ0 bGUgZGVzaWduIGFzc3VtcHRpb25zLiIgIChSZWY6IGh0dHA6Ly93d3cuY3NzLXNlY3VyaXR5LmNv bS93cC1jb250ZW50L3RoZW1lcy9jc3Mvc2NlcC9TQ0VQX2FuZF9VbnRydXN0ZWRfRGV2aWNlcy5w ZGYpIA0KDQotLSBUDQoNClsxXSBJJ20gYWN0dWFsbHkgd2lsbGluZyB0byBnaXZlIFRDRyBhIHBh c3Mgb24gcmUtaW52ZW50aW5nIGVucm9sbG1lbnQgYmVjYXVzZSB0aGVpciB0aHJlYXQgbW9kZWwg aXMgc3VjaCB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSBhbmQgaXQncyBhc3NvY2lhdGlvbiB3aXRoIGFu IGVuZG9yc2VtZW50IGtleSBoYXZlIHRvIGJlIGtlcHQgcHJpdmF0ZSBmcm9tIGVhdmVzZHJvcHBl cnMsIGFuZCBJJ20gbm90IGNvbnZpbmNlZCB5b3UgY291bGQgZG8gdGhhdCB3aXRoIGFueSBvdGhl ciBleHRhbnQgZW5yb2xsbWVudCBwcm90b2NvbC4gIFRoYXQgZG9lc24ndCBleGN1c2UgVENHIGZv ciB0aGVpciBvdGhlciBzdGFuZGFyZHMgYWJ1c2VzLCBob3dldmVyLiAgOikNCg0K From nobody Tue Oct 14 06:40:10 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE2A1A8780 for ; Tue, 14 Oct 2014 06:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv3wzBYw669S for ; Tue, 14 Oct 2014 06:40:04 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411BB1A874D for ; Tue, 14 Oct 2014 06:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413294005; x=1444830005; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=nNeWfaFT23jZYgH7rsg28iiZSgILsr8vqOGd2jRSSxs=; b=N6NIwhAUMeUmi+9hCdVe+cRWCGCo912Y9JA/XnAk3a/VsLJVeNAIymk8 N1BSO5n4xwV3lSQT0rtqRWmPuyx8eRnNRLgnvpsGAyprfsfQHOCMIe32q vp9D/KDZ2ziUkAfIdKirsxGLQ3cGg4o7miONxMES857Eyav3Fb/xVy/oS M=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283062641" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Oct 2014 02:40:03 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Wed, 15 Oct 2014 02:40:02 +1300 From: Peter Gutmann To: IETF PKIX Thread-Topic: [pkix] Simple Certificate Enrollment Protocol (SCEP) Thread-Index: Ac/ntFpMbnsxHiw5TgCiKWGR693Ygg== Date: Tue, 14 Oct 2014 13:40:01 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9CB38D@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/DpayBKBw0F-Ek-rhQ9JKI2zg0cs Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 13:40:09 -0000 "Miller, Timothy J." writes:=0A= =0A= >And let's not forget XKMS (W3C), KMIP (OASIS), PCAS (TCG), and at least tw= o=0A= >Microsoft protocols =0A= =0A= None of those are really cert-enrolment protocols though...=0A= =0A= >And as far as SCEP being a "old and clunky," IMHO it's more accurate to sa= y=0A= >"broken in many implementations because of subtle design assumptions." (R= ef:=0A= >http://www.css-security.com/wp-content/themes/css/scep/SCEP_and_Untrusted_= Devices.pdf)=0A= =0A= I've read that before and found it a bit silly, it basically says "issuing = a=0A= certificate containing a verbatim copy of what the client asks for ('give m= e a=0A= certificate that makes me a CA, and issued for google.com') can result in= =0A= unexpected rights amplification". Well, duh.=0A= =0A= Peter.= From nobody Tue Oct 14 07:09:52 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435921A883D for ; Tue, 14 Oct 2014 07:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKN0CGV16wve for ; Tue, 14 Oct 2014 07:09:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677DB1A8742 for ; Tue, 14 Oct 2014 07:09:47 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:53302 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xe2nY-0002dp-Fe; Tue, 14 Oct 2014 10:10:00 -0400 Message-ID: <543D2EA7.6000505@bbn.com> Date: Tue, 14 Oct 2014 10:09:43 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Erik Andersen , pkix References: <000201cfe790$45dcd140$d19673c0$@x500.eu> In-Reply-To: <000201cfe790$45dcd140$d19673c0$@x500.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/9-QEnQQ7ucK_6_uUwxTdEumOgMo Subject: [pkix] SCEP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 14:09:49 -0000 Erik, Cisco developed and promoted SCEP without submitting it to the IETF, to compete with the cert management protocols that other vendors were developing. This end run of IETF process was not well received. I had first hand knowledge of how Cisco pushed SCEP because I served as CT for CyberTrust, a Web PKI CA, during this time. Several later Cisco staff approached the IETF asking that SCEP be published as an RFC. They agreed that it could be labelled Historic. (It did not offer alg agility, a feature that we required of all security protocols by that time.) We were told that Cisco just wanted a stable reference for it, nothing more, and that they agreed it should be replaced with a more modern protocol. So, Tim Polk and I re-wrote the seriously-flawed I-D that they had been repeatedly published (to keep it alive) as an individual submission. We got very close to a reasonable version that could be published as Historic. Then, during lunch at an IETF meeting, a different Cisco staff member showed up to discuss the status of SCEP. At this lunch meeting he noted that the reason Cisco wanted an RFC number for SCEP (irrespective of the status) was to be able to cite it in a submission to 3GPP! Apparently, this staff member had not been instructed to lie about their real intent. That ended the discussion of SCEP as an RFC. Subsequently, another Cisco staff member came forward wanting to pursue a replacement for SCEP, with up-to-date features and and a broader focus. This proposal went through numerous revisions and received input from several sources. It became EST and it was issued as an RFC from PKIX. Steve From nobody Tue Oct 14 07:26:03 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838BF1A8791 for ; Tue, 14 Oct 2014 07:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbCu0WBs570R for ; Tue, 14 Oct 2014 07:26:00 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 032451A8881 for ; Tue, 14 Oct 2014 07:25:59 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1C97172E191; Tue, 14 Oct 2014 10:25:59 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 1410C72E185; Tue, 14 Oct 2014 10:25:59 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 10:25:58 -0400 From: "Miller, Timothy J." To: 'Peter Gutmann' , IETF PKIX Thread-Topic: [pkix] Simple Certificate Enrollment Protocol (SCEP) Thread-Index: Ac/ntFpMb1Xr+ImVQUWYJscmK+kLJwAAoD8g Date: Tue, 14 Oct 2014 14:25:57 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200461CF342@IMCMBX01.MITRE.ORG> References: <9A043F3CF02CD34C8E74AC1594475C739B9CB38D@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9CB38D@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/_bUfohIM8QUeFLYBr6JvFuzfDUc Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 14:26:01 -0000 >None of those are really cert-enrolment protocols though... Well, PCAS is explicitly an enrollment protocol--you send a public key, you= get back a certificate--as are Microsoft's ICEnroll and the WS-Trust based= enrollment protocol (Certificate Enrollment Web Services) in Server 2k8r2.= =20 While it's true that KMIP explicitly disclaims enrollment, it nevertheless = has the features you need for enrollment and can be (mis?)used that way. S= imilarly so with XKMS. Besides, it's funnier when you include them. :) >I've read that before and found it a bit silly, it basically says "issuing= a >certificate containing a verbatim copy of what the client asks for ('give = me a >certificate that makes me a CA, and issued for google.com') can result in >unexpected rights amplification". Well, duh. IMHO the key point from CSS's discussion is that the SCEP authenticator doe= sn't actually bind to the identity to be requested or to the requestor, so = you can enroll a different device than the one the RA thinks you're enrolli= ng, or you can pass the authenticator along to an otherwise unauthorized pe= rson (or both). This isn't a concern in a closed environment as long as yo= u have either physical control of the devices enrolled, trusted and account= able "sponsors" acting on behalf of the non-person Subscriber, or (ideally)= both. Unfortunately in the general non-person Subscriber use case there's= a scalability requirement that incentivizes over-automation and reduces ac= countability and control--and that opens up a hole in SCEP you can drive a = truck through. (Cue Anders again. :) Naturally human Subscribers can attempt the same shenanigans but there are = at least the pretense of checks in those systems. =20 -- T From nobody Tue Oct 14 07:31:22 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16411A8742 for ; Tue, 14 Oct 2014 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb6ITUNGkiHU for ; Tue, 14 Oct 2014 07:31:17 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE70E1A8862 for ; Tue, 14 Oct 2014 07:31:02 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id u20so16456022oif.14 for ; Tue, 14 Oct 2014 07:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NLCa4nhz/LKi5Xj7NVhhqB1K4sR3jDfXwqck84kTjx8=; b=Yds/+PHj2mIJFJ0dAscmWsaiarhy2psEQZzVhiOIWegyQipIYvuIy+p+aqV1IJvxTd BTK50SN1k8p0q4uQ0ZjrWskx2B1NSOhZI1yojMcolVzKV5AZUCPX10WFJNkKu2ImiXwL NygsLbbA0aLcshVuDlFujNyFdMQYSE5ySI9dna+k+sBveR5WwbBSZqkhCRsFnPBzgtBS DH/k6BKsTl8n46C6oQL8g//cFE6p+LKz8Nn/d1sZqC/hQsXURwZfoLZYfR7o+fQLdr1v uDi2W+fFYQwTHKUPk++csz51bQUDkcvtFKmby8pvJ5sjsfc7HbOSe+m9bsIw2xRNn4y9 zL/w== MIME-Version: 1.0 X-Received: by 10.107.28.203 with SMTP id c194mr2579810ioc.29.1413297062287; Tue, 14 Oct 2014 07:31:02 -0700 (PDT) Received: by 10.107.3.87 with HTTP; Tue, 14 Oct 2014 07:31:02 -0700 (PDT) In-Reply-To: <001001cfe7a0$52f31640$f8d942c0$@x500.eu> References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> Date: Tue, 14 Oct 2014 10:31:02 -0400 Message-ID: From: Jeffrey Walton To: Erik Andersen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/rLXN-1IQDcxOsr7lpEUE6a9Axg4 Cc: PKIX , WG15@iectc57.org Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 14:31:19 -0000 On Tue, Oct 14, 2014 at 7:16 AM, Erik Andersen wrote: > Hi Peter, > > Thanks for your quick answer. > > The smart grid security folks want to use SCEP as normative reference in > their specification. In the current state of SCEP, this is probably against > the rules of IEC. It might be desirable to progress SCEP to a more official > status. That could be within PKIX as an RFC or as an ITU-T Recommendation to > be progressed very quickly. The latter might require some consent from > Cisco. Related: The Use of the Simple Certificate Enrollment Protocol (SCEP) and Untrusted Devices, http://www.css-security.com/wp-content/themes/css/scep/SCEP_and_Untrusted_Devices.pdf. From nobody Tue Oct 14 08:22:06 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9244A1A88D0 for ; Tue, 14 Oct 2014 08:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU4CW66Q5xPq for ; Tue, 14 Oct 2014 08:21:59 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAC41A88F0 for ; Tue, 14 Oct 2014 08:21:58 -0700 (PDT) Received: from [10.0.0.122] (rrcs-67-52-105-34.west.biz.rr.com [67.52.105.34]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9EFLON5007311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Oct 2014 08:21:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host rrcs-67-52-105-34.west.biz.rr.com [67.52.105.34] claimed to be [10.0.0.122] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <001001cfe7a0$52f31640$f8d942c0$@x500.eu> Date: Tue, 14 Oct 2014 08:21:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> To: Erik Andersen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/uOnblvRoInphinR7zqmjCGsKlr0 Cc: PKIX , WG15@iectc57.org, Carsten Strunge , =?iso-8859-1?Q?S=F8ren_Peter_Nielsen?= Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:22:02 -0000 On Oct 14, 2014, at 4:16 AM, Erik Andersen wrote: > Thanks for your quick answer. Which, unfortunately, was wrong. SCEP's lack of standardization was not = because PKIX had their own protocols: it was because it was a quick hack = by Cisco for one scenario (IPsec certs) and people kept pointing out = flaws that were only slowly fixed. That is, Cisco never wanted SCEP to = be standardized because doing so would mean that they had to change = their SCEP code to match the standardized version. > The smart grid security folks want to use SCEP as normative reference = in > their specification. Which SCEP? The on-the-wire protocol changed from draft to draft, and I = believe that the final draft does not match Cisco's implementation. If = you point at one draft, you will have terrible interoperability, and = what interoperability you get will be to a flawed protocol. See below. On Oct 14, 2014, at 7:09 AM, Stephen Kent wrote: > Cisco developed and promoted SCEP without submitting it to the IETF, = to compete > with the cert management protocols that other vendors were developing. = This > end run of IETF process was not well received. I had first hand = knowledge > of how Cisco pushed SCEP because I served as CT for CyberTrust, a Web = PKI > CA, during this time. Cisco consistently published drafts of SCEP without "submitting it to = the IETF" because Cisco and Cisco's competitors didn't want to deal with = having to change their codebases. This is a perfectly acceptable = practice in the IETF, even though you doesn't like it in this case. Just = to be clear: many of Cisco's competitors in the IPsec market were quite = happy that Cisco bothered to document their proprietary protocol so that = they could at least be bug compatible with Cisco. IIRC, there were at = least four separate SCEP implementations at the last large IPsec Bakeoff = that worked well with each other. > Several later Cisco staff approached the IETF asking that SCEP be = published as an RFC. > They agreed that it could be labelled Historic. There was also a discussion of labeling it Informational, because that = was a more accurate description: it was a vendor-proprietary solution = that was being documented so other vendors could interoperate if they = wanted to, even though the solution was kinda sucky. > (It did not offer alg agility, a > feature that we required of all security protocols by that time.) It did not offer a lot of stuff that a good cert enrollment protocol = should offer; that wasn't the point. > We were told > that Cisco just wanted a stable reference for it, nothing more, and = that they agreed > it should be replaced with a more modern protocol. Yes. > So, Tim Polk and I re-wrote the seriously-flawed I-D that they had = been repeatedly > published (to keep it alive) as an individual submission. We got very = close to a > reasonable version that could be published as Historic. Then, during = lunch at an > IETF meeting, a different Cisco staff member showed up to discuss the = status of SCEP. > At this lunch meeting he noted that the reason Cisco wanted an RFC = number for SCEP > (irrespective of the status) was to be able to cite it in a = submission to 3GPP! > Apparently, this staff member had not been instructed to lie about = their real intent. > That ended the discussion of SCEP as an RFC. Nice word, "lie". It indicates that everyone at Cisco has the same = intent, and they are all instructed in what to say in public. Anyone = working with the Cisco IPsec team at the time knows that such an = assertion is demonstrably false, even though it makes for good drama = here. > Subsequently, another Cisco staff member came forward wanting to = pursue a replacement > for SCEP, with up-to-date features and and a broader focus. This too is inaccurate because he wasn't "another" Cisco staff member, = he was the one who had be stuck with maintaining SCEP in its waning = years. He had first-hand understanding of where SCEP sucked and what to = do about it. > This proposal went > through numerous revisions and received input from several sources. It = became EST and > it was issued as an RFC from PKIX. If the "smart grid security folks" want to reference a well-written = certificate enrollment protocol, they should stay the heck away from = SCEP and point to EST. --Paul Hoffman= From nobody Tue Oct 14 09:21:57 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5261A87AF for ; Tue, 14 Oct 2014 09:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMPwbJCmSOYS for ; Tue, 14 Oct 2014 09:21:45 -0700 (PDT) Received: from epona03.ttu.edu (epona03.ttu.edu [129.118.201.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709181A8901 for ; Tue, 14 Oct 2014 09:21:45 -0700 (PDT) Received: from empusa09.ttu.edu (129.118.201.66) by mail.ttu.edu (129.118.201.76) with Microsoft SMTP Server id 14.3.181.6; Tue, 14 Oct 2014 11:21:44 -0500 Received: from CYCLOPS04.ttu.edu ([169.254.3.143]) by empusa09.ttu.edu ([129.118.201.66]) with mapi id 14.03.0181.006; Tue, 14 Oct 2014 11:21:44 -0500 From: "Sill, Alan" To: Paul Hoffman Thread-Topic: [pkix] Simple Certificate Enrollment Protocol (SCEP) Thread-Index: Ac/nmCuBb1Xr+ImVQUWYJscmK+kLJwAMg8eAAAiMY4AAAhtGAA== Date: Tue, 14 Oct 2014 16:21:43 +0000 Message-ID: <56E5D78C-1D42-4A14-9CC7-B90D49A36735@ttu.edu> References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> In-Reply-To: <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.118.242.5] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <365C2B0BF24A7E41A374210139D5FDAF@default.ttu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TechMail-Edge-Route: TTU Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/msBPhMC0SGuDWy3w_vepmWBKiEM Cc: =?iso-8859-1?Q?S=F8ren_Peter_Nielsen?= , Carsten Strunge , PKIX , "WG15@iectc57.org" Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:21:53 -0000 On Oct 14, 2014, at 10:21 AM, Paul Hoffman wrote: > If the "smart grid security folks" want to reference a well-written certi= ficate enrollment protocol, they should stay the heck away from SCEP and po= int to EST. With this in mind, I would appreciate some informed commentary from this gr= oup on the article by John Foley covering this topic in the September 2014 = issue of Linux Journal: http://www.linuxjournaldigital.com/linuxjournal/september_2014/?pg=3D62&pm= =3D2&u1=3Dfriend (You can close the subscription pop-in window to view the entire article, a= s it is an open article.) It refers to a Cisco test server, but otherwise appears to be a very genera= l technical treatment on implementing EST. Thanks, Alan From nobody Tue Oct 14 09:29:24 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6991A8A81 for ; Tue, 14 Oct 2014 09:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsqEYrqsGlv9 for ; Tue, 14 Oct 2014 09:29:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4818F1A8A80 for ; Tue, 14 Oct 2014 09:29:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49062 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xe4ya-00044s-Bu; Tue, 14 Oct 2014 12:29:32 -0400 Message-ID: <543D4F5C.4010000@bbn.com> Date: Tue, 14 Oct 2014 12:29:16 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Hoffman , Erik Andersen References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> In-Reply-To: <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/2hN3gjLU5Q7u01lDo38-7sHHIfc Cc: PKIX , WG15@iectc57.org, Carsten Strunge , =?UTF-8?B?U8O4cmVuIFBldGVyIE5pZWxzZW4=?= Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:29:24 -0000 Paul, > >> Several later Cisco staff approached the IETF asking that SCEP be published as an RFC. >> They agreed that it could be labelled Historic. > There was also a discussion of labeling it Informational, because that was a more accurate description: it was a vendor-proprietary solution that was being documented so other vendors could interoperate if they wanted to, even though the solution was kinda sucky. The discussion about a label of historic involved the PKIX chairs, the cognizant Sec AD, and the IETF chair. I think this superseded the discussion of an informational label. > >> So, Tim Polk and I re-wrote the seriously-flawed I-D that they had been repeatedly >> published (to keep it alive) as an individual submission. We got very close to a >> reasonable version that could be published as Historic. Then, during lunch at an >> IETF meeting, a different Cisco staff member showed up to discuss the status of SCEP. >> At this lunch meeting he noted that the reason Cisco wanted an RFC number for SCEP >> (irrespective of the status) was to be able to cite it in a submission to 3GPP! >> Apparently, this staff member had not been instructed to lie about their real intent. >> That ended the discussion of SCEP as an RFC. > Nice word, "lie". It indicates that everyone at Cisco has the same intent, and they are all instructed in what to say in public. Anyone working with the Cisco IPsec team at the time knows that such an assertion is demonstrably false, even though it makes for good drama here. I agree that Cisco may not have coordinated the rationale we were given for publishing SCEP, but we got the same story from multiple individuals in a few different parts of the organization. As an outsider, I think that "lie" is an appropriate characterization. Steve From nobody Tue Oct 14 10:31:21 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3234C1A90C4 for ; Tue, 14 Oct 2014 10:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS8zVGUAJ0ED for ; Tue, 14 Oct 2014 10:31:17 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5B71A90C3 for ; Tue, 14 Oct 2014 10:31:17 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id z10so7697954pdj.26 for ; Tue, 14 Oct 2014 10:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=hShtZddG2eG0/Ptz8tq2t4Gkv6nGw0zcKO/5mqBbvsM=; b=rgWDVjKXMPxnzg5ibhHpUILu2sbdxW7I3wXn2+7GaMx2JpK3Xw1dX/21k+TLSLtsI5 WkmL7+BajDrevDDYpDh/pluHXztqAePuQNdbaJG3GWGAe/VjYerp4zoe9m5+RW0P/jZ7 /aFDiyOKiAKZJrs/EsOVgLKgDGO2CeO65zgs+S5brHwNE9eta/WHmfOmvSPW5jZG9mZW sX9dciOunHVSU7C2npJSAOPEX68GxdX6wQc7918NnOFMZlhgid5Tn8qsvyxNk12+J7A3 JpHzd2J2MaLHHhfCMT8Hx6+H8jGDQExfdJzwMW7kJlJ8R97Y4g1am7FUx4x3SnddImwL lSAg== X-Received: by 10.68.248.40 with SMTP id yj8mr6907178pbc.58.1413307877446; Tue, 14 Oct 2014 10:31:17 -0700 (PDT) Received: from spandex.local (216-67-38-4-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.38.4]) by mx.google.com with ESMTPSA id j11sm14756766pdk.76.2014.10.14.10.31.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 10:31:16 -0700 (PDT) Message-ID: <543D5DE3.50507@gmail.com> Date: Tue, 14 Oct 2014 09:31:15 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pkix@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> <543D4F5C.4010000@bbn.com> In-Reply-To: <543D4F5C.4010000@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/7KJJVJ0CoW1OXbmldgwZ_md4Gyo Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 17:31:19 -0000 On 10/14/14 8:29 AM, Stephen Kent wrote: >> Nice word, "lie". It indicates that everyone at Cisco has the same >> intent, and they are all instructed in what to say in public. >> Anyone working with the Cisco IPsec team at the time knows that >> such an assertion is demonstrably false, even though it makes for >> good drama here. > I agree that Cisco may not have coordinated the rationale we were > given for publishing SCEP, but we got the same story from multiple > individuals in a few different parts of the organization. As an > outsider, I think that "lie" is an appropriate characterization. I was at Cisco at the time. That is not correct. Interest in bring SCEP to the IETF waxed and waned and at different points different people showed different levels of interest in working on getting the spec through the IETF process. Nobody was ever instructed to lie - I'd be hard-pressed to say that anybody was instructed to do much of anything in terms of publishing SCEP. My understanding of the 3gpp situation was that someone at Cisco wanted to take SCEP to 3gpp and that's what motivated a renewed interest in publishing it as an informational document (within Cisco; whether the responsible IETF people were more interested in publishing it as an historic RFC is largely orthogonal to that). Without actually talking with the people involved all we can go on is what we see. It's a black box problem. Fabricating a narrative and making judgments based on that fabricated narrative strikes me as profoundly unhelpful. Melinda From nobody Thu Oct 16 04:07:20 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9F1AD045 for ; Thu, 16 Oct 2014 04:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckTbwajgQ-Z8 for ; Thu, 16 Oct 2014 04:07:17 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CB21AD010 for ; Thu, 16 Oct 2014 04:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413457637; x=1444993637; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=TM+J3jvFA6E4ecsVn4OAhOW5sYGYzU3B6mD3DDDLbaA=; b=trzyajwhgp6H1xN8WsZlMJ967D+139BpIjdTBws/K2uQxEPXidyy5Emo 5vaLtfecNJOKZjhDzxo9cfY7LYMSBzJVMwH1PLAdZoVtowGXhWR88RF3A pBgIhLW0Aq49nEqLX+9TpPwr/YBCu+Y6uMHrKpc40YR6XAO0vGHpKcpab I=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="283652473" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Oct 2014 00:07:15 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 00:07:14 +1300 From: Peter Gutmann To: IETF PKIX Thread-Topic: [pkix] Simple Certificate Enrollment Protocol (SCEP) Thread-Index: Ac/pMQWWlHnlCFPDR7qAz+2+n2+q8A== Date: Thu, 16 Oct 2014 11:07:13 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9CD0CC@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/nYysQvdGdwzxqG-WzCWwcVgqYj0 Cc: "WG15@iectc57.org" , "CAS@energinet.dk" , "soren.peter.nielsen@gmail.com" Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:07:19 -0000 Paul Hoffman writes:=0A= =0A= >> Thanks for your quick answer.=0A= >=0A= >Which, unfortunately, was wrong. SCEP's lack of standardization was not=0A= >because PKIX had their own protocols: =0A= =0A= So PKIX would have adopted it as a WG item had Cisco asked?=0A= =0A= >Which SCEP? The on-the-wire protocol changed from draft to draft, and I=0A= >believe that the final draft does not match Cisco's implementation. If you= =0A= >point at one draft, you will have terrible interoperability, and what=0A= >interoperability you get will be to a flawed protocol. See below.=0A= =0A= I've been tracking SCEP for about a decade, including being involved in=0A= deploying stuff based on standards that refer to decade-old versions, and= =0A= never had any interop problems due to anything other than buggy=0A= implementations (and I'm specifically talking Microsoft's NDES here). That= =0A= has nothing to do with the spec, it's just a really bad implementation (thi= nk=0A= 1990s Microsoft, implementing about 2/3 of a protocol spec and then getting= a=0A= third of that wrong). However NDES is so widely deployed and used that pre= tty=0A= much everyone has worked around the problems in it, so it's not really an= =0A= issue.=0A= =0A= I'm looking at this from a non-Cisco point of view. Cisco's implementation= =0A= may have terrible interoperability (I have no idea, I've never used it), bu= t=0A= for general SCEP use it's been pretty good, and certainly far, far better t= han=0A= any of the more complex cert-enrolment protocols I've played with. And tha= t's=0A= SCEP's advantage, it may be very limited but there's not much you can get= =0A= wrong with PKCS #10-inside-PKCS #7.=0A= =0A= >Cisco consistently published drafts of SCEP without "submitting it to the= =0A= >IETF" because Cisco and Cisco's competitors didn't want to deal with havin= g=0A= >to change their codebases. =0A= =0A= The problem is that SCEP is no longer Cisco's baby, and hasn't been for a l= ong=0A= time. There are more than half a billion (non-Cisco) devices actively usin= g=0A= SCEP today (that's a lower bound since there's a lot of hidden SCADA gear t= hat=0A= can't be measured), and in the tens of millions of SCEP servers (or at leas= t=0A= SCEP-capable, they're not all being used to run SCEP). Cisco may not care= =0A= about SCEP any more, but an awful lot of other users do.=0A= =0A= >It did not offer a lot of stuff that a good cert enrollment protocol shoul= d=0A= >offer; that wasn't the point.=0A= =0A= Sure. If you just wanted to provision a device with an RSA cert, it was fi= ne.=0A= Anything else...=0A= =0A= >If the "smart grid security folks" want to reference a well-written=0A= >certificate enrollment protocol, they should stay the heck away from SCEP = and=0A= >point to EST.=0A= =0A= ... provided they don't mind doing their own implementation of EST from=0A= scratch, and persuading everyone they ever want to talk to to do the same.= =0A= =0A= Oh, and good luck finding a widely-used server implementation to=0A= run/administer the whole thing through.=0A= =0A= SCEP sucks for anything other than device-cert-provisioning, but it works (= and=0A= cert-provisioning is all that most users seem to want in any case, although= =0A= I'm not sure if that's a case of the Sapir-Whorf hypothesis for crypto in= =0A= effect :-). I can take my code, or JSCEP, or whatever, point it at a Windo= ws=0A= server, and issue certs with it, all administered through Active Directory = or=0A= whatever management tools you want. A Smith and Wesson beats four aces.=0A= =0A= Peter.= From nobody Thu Oct 16 10:17:54 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD991A1A51 for ; Thu, 16 Oct 2014 10:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFlngw2Sdyxy for ; Thu, 16 Oct 2014 10:17:50 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2233A1A0262 for ; Thu, 16 Oct 2014 10:17:50 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id lf12so3051909vcb.17 for ; Thu, 16 Oct 2014 10:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZhijK5d897jgDDH8t+I64iFYghXFDD555I2gmvK2uG0=; b=RucOLSoM0ohAyqn61IkBf/EE6b15j9hhFmuywoqxN4iyueW3OWngd1oQP/GGqPwmvh PfRJJnn4onykuPZJM+44mnpgW0kWnQF2CaYwJCf6sKyldsMHt+yaBCCxcKA4Zxbv0KRM ox+zpS3y/PH0m+TZIYuJEDySf3JGfHyNctch83nmvDiaG8YyxRikedgEOX2orU1rJg4Z O4/xcPRgp7sgG+XGCsdr9GwiAapNY9piZ0dwTbfNbuSDtgT+JJi8PXGqJ98MS5RCrJf1 cZ+3qrxw8aZN35/jTXZOxVUm5nwyQavpC5U8d9G/Qkg5mU7+JdbPANSg/Yjagls75Kor 9oUA== MIME-Version: 1.0 X-Received: by 10.220.202.72 with SMTP id fd8mr2434882vcb.59.1413479869294; Thu, 16 Oct 2014 10:17:49 -0700 (PDT) Received: by 10.52.35.235 with HTTP; Thu, 16 Oct 2014 10:17:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 19:17:49 +0200 Message-ID: From: Erwann Abalea To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a11c1a23681b07205058d6d0f Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/6GvQYHs2xfM6ieOPKFd4FT53Uro Cc: "pkix@ietf.org" Subject: Re: [pkix] Compressed CRLs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:17:52 -0000 --001a11c1a23681b07205058d6d0f Content-Type: text/plain; charset=UTF-8 Interesting draft. Can be implemented by a third party if and only if it has access to all the unexpired certificates (insert GoogleCT here), or by the CA itself. Will there be more details on the additional optimizations by Rob? Does this additional optimization apply to a complete CRLSet or only to deltas? Regarding the encoding, my preference goes to ASN.1 over JSON. ASN.1 has a native BITSTRING type and several already standardized encoding rules, one of them being optimized for space (PER and unaligned PER, X.691). But this is only a serialization issue and doesn't conflict with the general idea; some don't like ASN.1 (for bad reasons), some don't like PER (for not so bad reasons). A good compact and easy encoding may be the recently approved OER (X.696). 2014-10-09 14:55 GMT+02:00 Phillip Hallam-Baker : > I sent this to TLS in the first instance but it might be of more > interest here. It turns out that we can compress CRLs much better than > anyone imagined. Using compression we can issue a CRL for every > unexpired SSL Server cert using less than the 250K that is the limit > on Google's curated CRLSet. > > > Please note: > > http://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/ > Also note the pending IPR disclosure. > > In brief Rob Stradling and myself have come up with a radically new > approach to certificate status that is vastly more efficient than any > previous proposal that provides finer grain certificate status than > the certificate validity interval. > > While compressing hash tables might appear to be a fools errand, it > turns out that if the problem is correctly understood, CRLs actually > compress astonishingly well. It is actually possible to represent the > status of every one of the half million revoked certificates in the > WebPKI using fewer bytes than the heavily edited Google CRLSet. > > There is still a powerful case for short lived certificates. But the > minimum feasible expiry interval for short lived certs is 48 hours. > Using a compressed CRL in combination with short lived certs would > allow the vulnerability window to be reduced to minutes. > > > We are of course aware that deployment will require a licensing regime > that meets the need of all parties including competing CAs, open > source software providers, etc. However lacking an existing licensing > regime for the rights holder (if indeed any are granted), I thought it > best to bring this to people's attention first. > > The nature of the invention is such that not applying for a paten;t > would open the possibility that someone else might make a claim as has > happened to me on numerous other occasions. In the past five years > over $50 million has been spent on defending against such patent > claims. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Erwann. --001a11c1a23681b07205058d6d0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting draft. Can be implemented by a third party if = and only if it has access to all the unexpired certificates (insert GoogleC= T here), or by the CA itself.
Will there be more details on the additio= nal optimizations by Rob? Does this additional optimization apply to a comp= lete CRLSet or only to deltas?

Regarding the encodin= g, my preference goes to ASN.1 over JSON. ASN.1 has a native BITSTRING type= and several already standardized encoding rules, one of them being optimiz= ed for space (PER and unaligned PER, X.691). But this is only a serializati= on issue and doesn't conflict with the general idea; some don't lik= e ASN.1 (for bad reasons), some don't like PER (for not so bad reasons)= . A good compact and easy encoding may be the recently approved OER (X.696)= .


2014-10-09 14:55 GMT+02:00 Phillip Hallam-Baker <= phill@hallambake= r.com>:
I sent this to TLS = in the first instance but it might be of more
interest here. It turns out that we can compress CRLs much better than
anyone imagined. Using compression we can issue a CRL for every
unexpired SSL Server cert=C2=A0 using less than the 250K that is the limit<= br> on Google's curated CRLSet.


Please note:

http://datatracker.ietf.org/doc/draft-hallambaker-co= mpressedcrlset/
Also note the pending IPR disclosure.

In brief Rob Stradling and myself have come up with a radically new
approach to certificate status that is vastly more efficient than any
previous proposal that provides finer grain certificate status than
the certificate validity interval.

While compressing hash tables might appear to be a fools errand, it
turns out that if the problem is correctly understood, CRLs actually
compress astonishingly well. It is actually possible to represent the
status of every one of the half million revoked certificates in the
WebPKI using fewer bytes than the heavily edited Google CRLSet.

There is still a powerful case for short lived certificates. But the
minimum feasible expiry interval for short lived certs is 48 hours.
Using a compressed CRL in combination with short lived certs would
allow the vulnerability window to be reduced to minutes.


We are of course aware that deployment will require a licensing regime
that meets the need of all parties including competing CAs, open
source software providers, etc. However lacking an existing licensing
regime for the rights holder (if indeed any are granted), I thought it
best to bring this to people's attention first.

The nature of the invention is such that not applying for a paten;t
would open the possibility that someone else might make a claim as has
happened to me on numerous other occasions. In the past five years
over $50 million has been spent on defending against such patent
claims.

_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix



--
Erwann.
--001a11c1a23681b07205058d6d0f-- From nobody Mon Oct 20 05:27:01 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0485B1A8700 for ; Mon, 20 Oct 2014 05:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrSBbFzv7n1M for ; Mon, 20 Oct 2014 05:26:52 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC031A86FF for ; Mon, 20 Oct 2014 05:26:52 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id s18so3831488lam.37 for ; Mon, 20 Oct 2014 05:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ab5cPI3x4cK6dpTdVt4q1p4eO2AfMs7AdVHCHXVNGwM=; b=HJ33uCAVpa02rhnITJtlRrf4s2Nod3wBt1n8Q4fnG5jj2mOsa/gX/BPOnGqH4O1hg4 H6o6IaMzl5ZL4h3zPn4c+w1EQnSKqvFsg+nBjCMrUzjzxg7gxE+YvQpYEUWeYklNWCjg WukBYItg7JR7RhFPwE19GSaB6cO3xdJsO/VTUwPG68lm+9ySBY3sRMrRdJUfBabaPYI5 GXn345OhNllRGxtIQ87M+s1tYxK+p7U8XBWjda6q5SR4aEHVW9FlxyTJV6W/qSq22ehO y/WNSnZO5Y/ZH8q0YkUETDO8gmNknuasDtpir8wMoK7Jj38AvyVpPsyz/q7Nbhgcu5CK sygw== MIME-Version: 1.0 X-Received: by 10.152.243.8 with SMTP id wu8mr26959978lac.21.1413808010482; Mon, 20 Oct 2014 05:26:50 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.66.196 with HTTP; Mon, 20 Oct 2014 05:26:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 08:26:50 -0400 X-Google-Sender-Auth: GqqwAHfm1fjdRd22m6Mekm3ZeVY Message-ID: From: Phillip Hallam-Baker To: Erwann Abalea Content-Type: multipart/alternative; boundary=001a1133f7043edd9e0505d9d448 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/LOBBG3zk6zvVVnsSrL_NJQ8pN60 Cc: "pkix@ietf.org" Subject: Re: [pkix] Compressed CRLs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:26:54 -0000 --001a1133f7043edd9e0505d9d448 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 16, 2014 at 1:17 PM, Erwann Abalea wrote: > Interesting draft. Can be implemented by a third party if and only if it > has access to all the unexpired certificates (insert GoogleCT here), or by > the CA itself. > Will there be more details on the additional optimizations by Rob? Does > this additional optimization apply to a complete CRLSet or only to deltas? > I want to get folk to focus on the specific way they want to use it before we drill down into exactly how to represent it. If we are doing one big CRL per day then extra compression makes a lot of sense. If we are doing deltas we need to look at the total complexity of the scheme. > Regarding the encoding, my preference goes to ASN.1 over JSON. ASN.1 has a > native BITSTRING type and several already standardized encoding rules, one > of them being optimized for space (PER and unaligned PER, X.691). But this > is only a serialization issue and doesn't conflict with the general idea; > some don't like ASN.1 (for bad reasons), some don't like PER (for not so > bad reasons). A good compact and easy encoding may be the recently approved > OER (X.696). > We don't use ASN.1, never have. We use tools that happen to take ASN.1 syntax. And that is a huge difference. Unless the authors of OpenSSL and NSSAPI etc. tell me their compilers work just fine with PER than it doesn't exist as far as I am concerned. We have already broken with ASN.1 in TRANS which does not use ASN.1 for internal structures. It uses the TLS schema. As far as my personal code set goes, I can switch from generating ASN.1 to TLS or JSON at will. (I don't use ASN.1 schema which simplifies a lot.) So I am not protecting my code here. But in general discussions over encoding don't have a lot of weight for me unless they begin 'I am the maintainer of X. widely used code library). --001a1133f7043edd9e0505d9d448 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 16, 2014 at 1:17 PM, Erwann Abalea <eabalea@gmail.com> wrote:
Interesting dr= aft. Can be implemented by a third party if and only if it has access to al= l the unexpired certificates (insert GoogleCT here), or by the CA itself.Will there be more details on the additional optimizations by Rob? Does = this additional optimization apply to a complete CRLSet or only to deltas?<= /div>

I want to get folk to focus on = the specific way they want to use it before we drill down into exactly how = to represent it. If we are doing one big CRL per day then extra compression= makes a lot of sense. If we are doing deltas we need to look at the total = complexity of the scheme.

=C2=A0
Regarding the encoding, my pr= eference goes to ASN.1 over JSON. ASN.1 has a native BITSTRING type and sev= eral already standardized encoding rules, one of them being optimized for s= pace (PER and unaligned PER, X.691). But this is only a serialization issue= and doesn't conflict with the general idea; some don't like ASN.1 = (for bad reasons), some don't like PER (for not so bad reasons). A good= compact and easy encoding may be the recently approved OER (X.696).
<= /div>

We don't use ASN.1, never h= ave. We use tools that happen to take ASN.1 syntax. And that is a huge diff= erence.

Unless the authors of OpenSSL and NSSAPI e= tc. tell me their compilers work just fine with PER than it doesn't exi= st as far as I am concerned.

We have already broke= n with ASN.1 in TRANS which does not use ASN.1 for internal structures. It = uses the TLS schema.


As far as my p= ersonal code set goes, I can switch from generating ASN.1 to TLS or JSON at= will. (I don't use ASN.1 schema which simplifies a lot.) So I am not p= rotecting my code here. But in general discussions over encoding don't = have a lot of weight for me unless they begin 'I am the maintainer of X= . widely used code library).



--001a1133f7043edd9e0505d9d448-- From nobody Tue Oct 21 08:54:44 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485E91A875E for ; Tue, 21 Oct 2014 08:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEcaJEOPHySd for ; Tue, 21 Oct 2014 08:54:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C267B1A87A2 for ; Tue, 21 Oct 2014 08:54:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50517 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xgblb-000Pvb-K9; Tue, 21 Oct 2014 11:54:35 -0400 Message-ID: <544681B8.3080401@bbn.com> Date: Tue, 21 Oct 2014 11:54:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Melinda Shore , pkix References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> <543D4F5C.4010000@bbn.com> <543D5DE3.50507@gmail.com> In-Reply-To: <543D5DE3.50507@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/Y8DO5BgSNc0fHOIvXqP6E5IArDA Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:54:42 -0000 Melinda, > I was at Cisco at the time. That is not correct. Interest in > bring SCEP to the IETF waxed and waned and at different points > different people showed different levels of interest in working on > getting the spec through the IETF process. Nobody was ever instructed > to lie - I don't recall saying they were instructed. > I'd be hard-pressed to say that anybody was instructed to > do much of anything in terms of publishing SCEP. ibid. > My understanding > of the 3gpp situation was that someone at Cisco wanted to > take SCEP to 3gpp and that's what motivated a renewed interest > in publishing it as an informational document (within Cisco; whether > the responsible IETF people were more interested in publishing it > as an historic RFC is largely orthogonal to that). The individual who showed up at PKIX meetings to push for publication was someone who had no visible activity in PKIX prior to his arrival at a WG meeting. The individual who declared the intent to use the RFC to submit SCEP to 3GPP was different, and was different from the individuals who had previously met with us on the topic. So, yes, it is possible that these two individuals and the others who engaged with the IETF requesting publication of SCEP had completely different agendas. The real issue is that the argument put before PKIX and the Sec ADs, repeatedly, was that an RFC was needed to provide a stable reference document for SCEP. This is an absurd assertion; Cisco was capable of publishing its spec on a public Cisco web site, thus making it available to anyone who needed it. Internet search was already adequate (in that time frame) for anyone interested in the spec to find it on such a site. If Cisco vanishes, the doc will have been archived and thus remain available for many years. The only credible reason for publishing an RFC describing SCEP (with any RFC label) was to have an RFC number that one could use to claim the imprimatur of the IETF. Whether the RFC number is to be used to cause another SDO to accept the protocol, or for marketing purposes, is irrelevant. Such behavior is what caused me to use the term "lie." Steve From nobody Tue Oct 21 09:03:49 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3471A88E3 for ; Tue, 21 Oct 2014 09:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZYSljOuOEq1 for ; Tue, 21 Oct 2014 09:03:47 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A121A87ED for ; Tue, 21 Oct 2014 09:03:47 -0700 (PDT) Received: from [10.20.30.90] (50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9LG3eO1068074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 09:03:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-50-141.dsl.dynamic.fusionbroadband.com [50.1.50.141] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: <544681B8.3080401@bbn.com> Date: Tue, 21 Oct 2014 09:03:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> <543D4F5C.4010000@bbn.com> <543D5DE3.50507@gmail.com> <544681B8.3080401@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/jQFw0Gye40AfgaiAN7qPi1pTgu4 Cc: pkix Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:03:48 -0000 On Oct 21, 2014, at 8:54 AM, Stephen Kent wrote: > The real issue is that the argument put before PKIX and the Sec ADs, > repeatedly, was that an RFC was needed to provide a stable reference = document > for SCEP. This is an absurd assertion; Cisco was capable of publishing = its > spec on a public Cisco web site, thus making it available to anyone = who needed it. > Internet search was already adequate (in that time frame) for anyone = interested > in the spec to find it on such a site. If Cisco vanishes, the doc will = have been > archived and thus remain available for many years. If you want to change the rules for how RFCs are published, it might be = better done so as a participant in an IETF-wide discussion, not as a WG = chair who is preventing someone from using the process correctly. = Otherwise, it simply looks like you are wielding power just to seem = powerful. --Paul Hoffman= From nobody Wed Oct 22 16:39:20 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D621A87A3 for ; Wed, 22 Oct 2014 16:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S42c9Cm2qzSD for ; Wed, 22 Oct 2014 16:39:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562FE1A6F3A for ; Wed, 22 Oct 2014 16:39:17 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34155 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xh5Up-0003v6-T9 for pkix@ietf.org; Wed, 22 Oct 2014 19:39:15 -0400 Message-ID: <54484022.1010708@bbn.com> Date: Wed, 22 Oct 2014 19:39:14 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: pkix References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> <543D4F5C.4010000@bbn.com> <543D5DE3.50507@gmail.com> <544681B8.3080401@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/DHywO9Z3dtFTD0BbikqSjLG7uGM Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:39:19 -0000 Paul, The rules for what gets published as an RFC are flexible. Contrary to your assertion I did not change the rules. Decisions about publishing documents developed outside of WGs are based on inputs from relevant WG chairs (if any), and the IESG. The RFC editor of the relevant stream has the final say in such matters. In my role as PKIX chair I expressed my view that the cited justification for publishing SCEP was not credible, and shared that view with the Sec ADs and the IETF chair, i.e., I provided my input. However, I could not veto publication unilaterally as you seem to have suggested. If the IESG or the cognizant RFC Editor decided that the spec should be published as Informational or Historic they could have done so. In the end I suspect that IESG members involved with the discussion were as upset as I by the disclosure that at least one Cisco staff member had an ulterior motive for requesting publication. Steve > On Oct 21, 2014, at 8:54 AM, Stephen Kent wrote: >> The real issue is that the argument put before PKIX and the Sec ADs, >> repeatedly, was that an RFC was needed to provide a stable reference document >> for SCEP. This is an absurd assertion; Cisco was capable of publishing its >> spec on a public Cisco web site, thus making it available to anyone who needed it. >> Internet search was already adequate (in that time frame) for anyone interested >> in the spec to find it on such a site. If Cisco vanishes, the doc will have been >> archived and thus remain available for many years. > If you want to change the rules for how RFCs are published, it might be better done so as a participant in an IETF-wide discussion, not as a WG chair who is preventing someone from using the process correctly. Otherwise, it simply looks like you are wielding power just to seem powerful. > > --Paul Hoffman From nobody Thu Oct 23 12:24:10 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBC41A90D3 for ; Thu, 23 Oct 2014 12:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uDZ4FPtox3m for ; Thu, 23 Oct 2014 12:24:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 095641ACEAA for ; Thu, 23 Oct 2014 12:24:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CFDF018001B; Thu, 23 Oct 2014 12:23:33 -0700 (PDT) To: paul.hoffman@vpnc.org, jimsch@exmsft.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, kent@bbn.com, stefan@aaa-sec.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141023192333.CFDF018001B@rfc-editor.org> Date: Thu, 23 Oct 2014 12:23:33 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/vURQc5YO5kn6sSJOg_cuy9vq97I Cc: pleonber@gmail.com, pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC5912 (4145) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 19:24:07 -0000 The following errata report has been submitted for RFC5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=4145 -------------------------------------- Type: Technical Reported by: Pierce Leonberger Section: 14 Original Text ------------- -- 3. A more complex version, but one that automatically ties -- together both the signature algorithm and the -- signature value for automatic decoding. -- SIGNED{ToBeSigned} ::= SEQUENCE { toBeSigned ToBeSigned, algorithmIdentifier SEQUENCE { algorithm SIGNATURE-ALGORITHM. &id({SignatureAlgorithms}), parameters SIGNATURE-ALGORITHM. &Params({SignatureAlgorithms} {@algorithmIdentifier.algorithm}) OPTIONAL }, signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value( {SignatureAlgorithms} {@algorithmIdentifier.algorithm})) } Corrected Text -------------- SIGNED{ToBeSigned} ::= SEQUENCE { toBeSigned ToBeSigned, algorithmIdentifier SEQUENCE { algorithm SIGNATURE-ALGORITHM. &id({SignatureAlgorithms}), parameters SIGNATURE-ALGORITHM. &Params({SignatureAlgorithms} {@algorithmIdentifier.algorithm}) OPTIONAL }, signature BIT STRING } Notes ----- I *believe* the 3rd option for SIGNED{} is invalid. The "signature" BIT STRING contains an OpenType which references an optional class field. It's possible to define objects with no type and OpenTypes must refer to a type. There's no mechanism to allow an OpenType to reference random bytes (not ASN.1 encoded). I understand the intent is to allow for automatic decoding, but unless the "&Value" is required in SIGNATURE-ALGORITHM this will not work. Requiring it will not work because not all signature algorithms require the signature value to be encoded (e.g. RSA). The syntax would be valid is if "signature" was OPTIONAL (obviously not desirable). So I propose we revert "signature" to "BIT STRING" without constraints. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5912 (draft-ietf-pkix-new-asn1-08) -------------------------------------- Title : New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) Publication Date : June 2010 Author(s) : P. Hoffman, J. Schaad Category : INFORMATIONAL Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From nobody Sun Oct 26 08:36:59 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93DE1A890F; Sun, 26 Oct 2014 08:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrjRf-pWqC-R; Sun, 26 Oct 2014 08:36:50 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961681A0081; Sun, 26 Oct 2014 08:36:50 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7B10D509B5; Sun, 26 Oct 2014 11:36:49 -0400 (EDT) Message-ID: <544D14C8.4070604@seantek.com> Date: Sun, 26 Oct 2014 08:35:36 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: pkix@ietf.org, saag@ietf.org References: <540E0A56.7060301@seantek.com> In-Reply-To: <540E0A56.7060301@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/hO-beoaW5U0JrpJcFKfoS23uvS0 Subject: Re: [pkix] New Version Notification for draft-seantek-certfrag-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 15:36:53 -0000 Just wanted to follow up on this request for feedback/review for draft-seantek-certfrag, which defines fragment identifiers for certificates. This is a short draft (just four pages--and the fourth page is just the author info). If you read it and don't find any issues, please let me know as well. Thanks, Sean On 9/8/2014 12:58 PM, Sean Leonard wrote: Hello PKIX and SAAG lists: Based on discussions had at IETF 90, I have written up a new Internet-Draft to define URI fragment identifiers for certificates. The proposal is very simple, as there are only a limited number of well-defined PKIX certificate parts. This text is a spinoff of draft-seantek-certspec, since the fragment definitions depend on the media type (application/pkix-cert), not on the URI scheme or other parts. Feedback is appreciated. Sean ************************* A new version of I-D, draft-seantek-certfrag-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-certfrag Revision: 00 Title: URI Fragment Identifiers for the application/pkix-cert Media Type Document date: 2014-09-08 Group: Individual Submission Pages: 4 URL: http://www.ietf.org/internet-drafts/draft-seantek-certfrag-00.txt Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag/ Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-00 Abstract: This memo describes Uniform Resource Identifier (URI) fragment identifiers for PKIX certificates, which are identified with the Internet media type application/pkix-cert. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Oct 29 06:35:51 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B091A00EA for ; Wed, 29 Oct 2014 06:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4E8VACXJrkp for ; Wed, 29 Oct 2014 06:35:44 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29571A00E6 for ; Wed, 29 Oct 2014 06:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414589744; x=1446125744; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=WGmMaWP2J8VAXcN3v7Zwr5ZAgOCzHHqdVrqzuA4z0+U=; b=Al1oKBg3DzvOEaqO+D4bJCIaJkO23YwWDqw6RQz/BoK9bB9xlxM4aBxq xucRTzhBGl+ba87p1ac8NyNujUkUjG67x92aAhNjAZNXz52lJ4LJiL0Bf lbYhaPzBL+UcaX1S05qXmzjJAPIcUz1ZiOnfJ3G1hqfC+VBCi3bSYlpAP 8=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286444390" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 02:35:41 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 02:35:41 +1300 From: Peter Gutmann To: "pkix@ietf.org" , "pritikin@cisco.com" Thread-Topic: [pkix] Simple Certificate Enrollment Protocol (SCEP) Thread-Index: Ac/zfTr7GBrWCtIyTnqyZLG46sIQPw== Date: Wed, 29 Oct 2014 13:35:40 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB295@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/m9CwVi6P0eGJwGcokL0a5I2FFqY Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 13:35:49 -0000 I've spent the time since the last exchange of messages on this thread talk= ing=0A= to various SCEP users over their requirements. It turns out that the figur= e=0A= I'd previously posted, of half a billion SCEP devices in active use, was=0A= rather an underestimate. SCEP seems to be pretty much the universal device= -=0A= provisioning protocol for non-PC/laptop devices, including mobile phones,= =0A= SCADA devices, gaming machines, ATMs, firewalls, and so on. It's also been= =0A= described to me as the standard BYOD provisioning protocol, its use for thi= s=0A= being so widespread that Server 2012 even added new, extra capabilities for= =0A= dealing with BYOD use via SCEP (Windows Server 2008 and 2012 are pretty muc= h=0A= the standard server implementations for dealing with this sort of thing). = As=0A= one person told me, "if a device speaks anything, it'll speak SCEP".=0A= =0A= So, no matter how much Cisco would like to forget about it, it's extremely= =0A= widely used, and there's no sign that this is going to change in the future= .=0A= To paraphrase something someone said many years ago about IBM, "SCEP isn't = the=0A= competition, it's the environment".=0A= =0A= To that end I'd like to request that the SCEP authors give me (or someone e= lse=0A= who cares about it, e.g. one of the JSCEP folks) change control over the=0A= document so that we can finally get this published. I submitted a list of= =0A= changes for the current doc ages ago but things seem to have stalled since= =0A= then (the changes were minor things that have come up in real-world usage,= =0A= clarifications to the doc, places where ~15-year-old remnants still exist n= ext=0A= to current ones, and just a general cleanup of the neglect that it's had fo= r=0A= the last decade or so, it still talks about MD5 and single DES for example,= =0A= but doesn't mention that newfangled AES thing that everyone's talking about= ).=0A= =0A= Given that it's been more or less abandoned by Cisco, I'd like to finish th= e=0A= editing for it and finally get it published as an RFC so that the vast numb= er=0A= of devices out there using it, and that will use it in the future, have a= =0A= fixed standard that they can refer back to.=0A= =0A= Peter.= From nobody Wed Oct 29 09:19:50 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA261A1AE8 for ; Wed, 29 Oct 2014 09:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScF6TiX3VKF3 for ; Wed, 29 Oct 2014 09:19:45 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F191A1ADE for ; Wed, 29 Oct 2014 09:19:44 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id q5so1976629wiv.5 for ; Wed, 29 Oct 2014 09:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VN2y23GMz84R7Lk0HOKXcgagiSYcid2IIrJH4GG2lYk=; b=yImoUqeUxF9VKOkWx4kkBd7ctKfdksPzezFgw3ZHnPfsrV9ObB24KFTHkZJo+jHbyY yj1hlJG3L6/8M8SUA70Sd+8+grez9pMY8rgFy4v5tQc9XiUin56AKNvndaE29N0iZdSV hn6k5ZsnxLiLSy6yvfd1w1jbTLnGznhTfyZytT28VUfUJdggj/ZG9nEtDFYEbLhBerNC GENc7WByTjP/gd1wd7JJ3qTo0Hoo4HL1W8vGroYKeC/F8ZbNXcxULtdYQQHcVuY9Iozj gWBUPikxC9gITYWPCxwyStApk0ub8APXASfR53yjj7c31maP24uDDgWoJHLhkn886PpV yfhw== X-Received: by 10.180.184.129 with SMTP id eu1mr36614160wic.69.1414599583283; Wed, 29 Oct 2014 09:19:43 -0700 (PDT) Received: from [192.168.1.79] (222.118.176.95.rev.sfr.net. [95.176.118.222]) by mx.google.com with ESMTPSA id o1sm5673988wja.25.2014.10.29.09.19.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 09:19:42 -0700 (PDT) Message-ID: <5451138E.4000208@gmail.com> Date: Wed, 29 Oct 2014 17:19:26 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "pkix@ietf.org" References: <9A043F3CF02CD34C8E74AC1594475C739B9DB295@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB295@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/0-FMi4RMxg0wd6ujJwcDIt1vizE Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:19:47 -0000 The only thing that could eventually replace SCEP for "devices" including BYOD, would be a protocol that builds on embedded attestation keys like the FIDO/Google U2F scheme. Such a scheme could completely eliminate the reliance on enrollment passwords. For browsers-based enrollment none of the PKIX-protocols make any sense since the former effectively is server-driven. I.e. it is the server that asks the client (platform) to generate a key-pair according to the server's specification. Related: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ -Anders On 2014-10-29 14:35, Peter Gutmann wrote: > I've spent the time since the last exchange of messages on this thread talking > to various SCEP users over their requirements. It turns out that the figure > I'd previously posted, of half a billion SCEP devices in active use, was > rather an underestimate. SCEP seems to be pretty much the universal device- > provisioning protocol for non-PC/laptop devices, including mobile phones, > SCADA devices, gaming machines, ATMs, firewalls, and so on. It's also been > described to me as the standard BYOD provisioning protocol, its use for this > being so widespread that Server 2012 even added new, extra capabilities for > dealing with BYOD use via SCEP (Windows Server 2008 and 2012 are pretty much > the standard server implementations for dealing with this sort of thing). As > one person told me, "if a device speaks anything, it'll speak SCEP". > > So, no matter how much Cisco would like to forget about it, it's extremely > widely used, and there's no sign that this is going to change in the future. > To paraphrase something someone said many years ago about IBM, "SCEP isn't the > competition, it's the environment". > > To that end I'd like to request that the SCEP authors give me (or someone else > who cares about it, e.g. one of the JSCEP folks) change control over the > document so that we can finally get this published. I submitted a list of > changes for the current doc ages ago but things seem to have stalled since > then (the changes were minor things that have come up in real-world usage, > clarifications to the doc, places where ~15-year-old remnants still exist next > to current ones, and just a general cleanup of the neglect that it's had for > the last decade or so, it still talks about MD5 and single DES for example, > but doesn't mention that newfangled AES thing that everyone's talking about). > > Given that it's been more or less abandoned by Cisco, I'd like to finish the > editing for it and finally get it published as an RFC so that the vast number > of devices out there using it, and that will use it in the future, have a > fixed standard that they can refer back to. > > Peter. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >